Our Git Workflow: Private Development, Public Releases
braintreepaymentsolutions.com
Our Git Workflow: Private Development, Public Releases
1–10 of 17 posts
Re: Our Git Workflow: Private Development, Public Releases
#2In my own startup we're using git to handle our version control as well. As mentioned in the article, git is flexible enough to allow you to create your own workflow, which is what we did when we started.
However, our workflow became much too convoluted and we switched to gitflow by Vincent Driessen (nvie.com). In fact, there are similarities between gitflow and the braintree workflow but gitflow now has as a git "flow" module to help you out.
If you haven't checked out gitflow, I highly recommend it. Here's the original post that started it all: http://nvie.com/git-model
Has anyone else found git workflows that work well for them?
Re: Our Git Workflow: Private Development, Public Releases
#3This reminds me of The Myth of the Genius Programmer. I.e. the developers who don't want others to see them make mistakes and instead want to look like geniuses.
I don't see how they "dig" Open-Source when they really are just releasing their source publicly. No one can see the progress of their projects or participate in their work.
It also amazes me that they consider branches to be cluttering.
Re: Our Git Workflow: Private Development, Public Releases
#4In my own startup we're using git to handle our version control as well. As mentioned in the article, git is flexible enough to allow you to create your own workflow, which is what we did when we started. However, our workflow became much too convoluted and we switched to gitflow by Vincent Driessen (nvie.com). In fact, there are similarities between gitflow and the braintree workflow but gitflow now has as a git "fl…
[deleted]
Re: Our Git Workflow: Private Development, Public Releases
#5This reminds me of The Myth of the Genius Programmer. I.e. the developers who don't want others to see them make mistakes and instead want to look like geniuses. I don't see how they "dig" Open-Source when they really are just releasing their source publicly. No one can see the progress of their projects or participate in their work. It also amazes me that they consider branches to be cluttering.
I wish developers could participate in the work, but unfortunately this is difficult because feature development on the client libraries is tied to feature development on the gateway. Until we release the corresponding features in the gateway, the client libraries wouldn't work.
I was thinking about your comment about seeing the progress of the project. While that is conventional for open source projects, it is unconventional for products. And since our client libraries are tied so closely to our product, progress of libraries is progress of our product. Anybody have thoughts/experiences/etc on sharing day-to-day development of their products? I know some companies do it, but it doesn't seem very common.
Re: Our Git Workflow: Private Development, Public Releases
#6I hadn't realized git incorporated the much-maligned svn merge as a feature.
Re: Our Git Workflow: Private Development, Public Releases
#7I hadn't realized git incorporated the much-maligned svn merge as a feature.
If you're referring to the `git merge` command then the actual things they do are quite different.
In svn it applies specified changes to your working copy, while in git it either fast-fowards branch-a to branch-b if applicable, or finds a common ancestor for the commits and creates a 'merge commit' so the commit history won't be linear (it will branch and re-converge). If all the branches are local, you can also use 'rebase' and that will make the history a little cleaner (well, linear at least).
The chapter on branches in the pro git book is enlightening:
Re: Our Git Workflow: Private Development, Public Releases
#8This reminds me of The Myth of the Genius Programmer. I.e. the developers who don't want others to see them make mistakes and instead want to look like geniuses. I don't see how they "dig" Open-Source when they really are just releasing their source publicly. No one can see the progress of their projects or participate in their work. It also amazes me that they consider branches to be cluttering.
I wish developers could participate in the work, but unfortunately this is difficult because feature development on the client libraries is tied to feature development on the gateway. Until we release the corresponding features in the gateway, the client libraries wouldn't work. I was thinking about your comment about seeing the progress of the project. While that is conventional for open source projects, it is uncon…
One of the issues you'll run into is that if you do make the day-to-day progress available, someone will expect you to support it. You'll either need to explicitly say that it's "use at your own risk" or have to make sure that the exposed "daily" branch works. The former probably isn't useful for the majority of your end users while the latter introduces extra overhead to your development process that you may not want or have time for.
Re: Our Git Workflow: Private Development, Public Releases
#9I hadn't realized git incorporated the much-maligned svn merge as a feature.
If you're referring to the `git merge` command then the actual things they do are quite different. In svn it applies specified changes to your working copy, while in git it either fast-fowards branch-a to branch-b if applicable, or finds a common ancestor for the commits and creates a 'merge commit' so the commit history won't be linear (it will branch and re-converge). If all the branches are local, you can also use…
[deleted]
Re: Our Git Workflow: Private Development, Public Releases
#10I hadn't realized git incorporated the much-maligned svn merge as a feature.
If you're referring to the `git merge` command then the actual things they do are quite different. In svn it applies specified changes to your working copy, while in git it either fast-fowards branch-a to branch-b if applicable, or finds a common ancestor for the commits and creates a 'merge commit' so the commit history won't be linear (it will branch and re-converge). If all the branches are local, you can also use…
I'm referring to git merge --squash.