Our Git Workflow: Private Development, Public Releases | Hacker News Reader

Our Git Workflow: Private Development, Public Releases

braintreepaymentsolutions.com

89 pointsdrewolson13 comments

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.

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?

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.

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.

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.

Ensuring that branches are useful and not "cluttering" requires a bit of discipline. It's easy to get a bit branch-happy in which case you end up with changes scattered across a number of branches that may or may not have a consistent starting point. This will cause issues when you have to merge all the updates for a release.

A general rule of thumb is only to create a branch when you need to work in parallel: code needs to be separated to allow for simultaneous updates or if a feature needs to be isolated until it's release timetable is set. This will vary depending on team size, work patterns and the nature of code changes.

Squashing can be useful but discarding potentially hundreds of commits and replacing them with one commit called "1.0.0" is very puzzling.

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.

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 this point is overlooked all too often. With git, just mashing out code and committing at regular intervals is not using git to its full potential. You're supposed to spend time crafting proper commits, consisting of logical, well-separated changes. The staging area and rebase feature make it easy, but it still requires effort that most developers are not used to.

Good, logically separate changesets make merging, backporting (cherry-picking), bisecting and reverting much easier. It is worth the trouble.

The version history of the git project itself serves as a magnificent example of what a commit history should look like. It's actually possible to read the logs and understand each committed change. (Most of the time)

This is what I always liked about darcs (it's still the DVCS I use at home): separating checkins into logical change sets.

I think it is strange that they found topic branches to be "cluttering", but find their current workflow convenient.

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.

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.

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:

http://progit.org/book/ch3-1.html

Merging is still a pain with git. Especially if you have to deal with xib or xcodeproj files (for iPhone/Mac dev). To the point where the usual process I see amounts to "don't touch this file -- I'm working with it (and don't want to lose any work)." instead of dealing with a merge that is almost guaranteed to make someone lose work.

Reply on news.ycombinator.com