Our Git Workflow: Private Development, Public Releases

In 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.<p>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.<p>If you haven't checked out gitflow, I highly recommend it. Here's the original post that started it all: <a href="http://nvie.com/git-model" rel="nofollow">http://nvie.com/git-model</a><p>Has anyone else found git workflows that work well for them?

This 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.<p>It also amazes me that they consider branches to be cluttering.

Squashing can be useful but discarding potentially hundreds of commits and replacing them with one commit called "1.0.0" is very puzzling.<p>Instead, each developer should handle this on their own: commit often, once they're happy with their progress, theh rebase -i, squash and reorder their commits to make them look nice and push that tidy commit to master or release.<p>This gives you the best of both worlds: an accurate version of your history that doesn't contain throwaway or half baked commits.

I think it is strange that they found topic branches to be "cluttering", but find their current workflow convenient.<p>We use topic branches a lot in our startup and we find them convenient, useful and efficient. I would never consider doing what they do.<p>Then again, to each his workflow, I guess.

Excellent. We do open source development and I was about to write a complex script that moves patches around to be able to keep a few private commits and still stay in sync with the single-commit release repos.

I hadn't realized git incorporated the much-maligned svn merge as a feature.