

Our Git Workflow: Private Development, Public Releases - drewolson
http://www.braintreepaymentsolutions.com/devblog/our-git-workflow

======
jsarch
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?

------
henrikhansen
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.

~~~
dan_manges
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.

~~~
lnguyen
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.

------
billmcneale
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.

~~~
chousuke
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)

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

------
jwr
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.

------
Aegean
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.

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

~~~
najafali
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>

~~~
Zev
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.

