

Ask HN: What is wrong with this git workflow? - aditya
http://davidyang.posterous.com/git-and-workflow

======
luigi
Why wait 2-3 months to merge everything back into master? Why not do it every
day? Or better yet, do it whenever a good bit of functionality (a story) is
completed, which can be several times a day?

It's better to see where the dependencies are up front instead of waiting
until the very end of the iteration.

Here's the ideal Git workflow, described by three different people but all
pretty much recommending the same thing:

[http://blog.hasmanythrough.com/2008/12/18/agile-git-and-
the-...](http://blog.hasmanythrough.com/2008/12/18/agile-git-and-the-story-
branch-pattern)

<http://gweezlebur.com/2009/01/19/my-git-workflow.html>

[http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-
te...](http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html)

------
dawie
Continuous integration should help to get rid of your merging headaches. I
would merge way more often. The moment a developer has implemented and tested
a bit of code -> Merge and resolve conflicts. 2-3 months are very long
iterations. I think you should break your problems down into smaller parts.

------
mbrubeck
In a nutshell, merge more and rebase less.

If you can avoid it, don't maintain long-lived actively-developed branches -
especially several at once. You are certain to produce conflicts this way, and
they will require some amount of manual resolution no matter what SCM you are
using.

So my main suggestion is for everyone push their work onto the master much
more frequently throughout the development period (whenever it's at a point
where all tests are passing and it won't break things for other developers).
Anyone working on a long-lived branch can then pull periodically (like, daily)
from master and deal with the merge conflicts incrementally, before they've
diverged too much.

"Often, what happens in a release is that topic branch 1 relies on commits
from topic branch 2. We're not exactly sure how to best handle this, if we
start sending patches from topic branch 1 into topic branch 2, will that make
it harder for us to merge topic branch 2 into the system test branch?"

No, it won't make it harder. The developer of branch2 can merge from branch1.
Git will see in the history that branch2 now contains commits from branch1 and
that will help it with later merges.

"Is there a way to move the resolution of the conflicts back into the topic
branches? I know this sounds ridiculous but instead of resolving the conflicts
in the merge commit, is there a way we could push the resolutions into the
proper branches so that the merged version really holds no real state?"

Yes. Instead of checking out master and doing "merge branch1" or "pull
branch1", checkout branch1 and do "merge master" or "pull master". (As I
suggest above, you should actually do this frequently throughout the
development of branch1.) Then when you eventually finish with the branch1 and
merge it back into master, all (or almost all) of the merging is already done
and you won't have any conflicts.

"Where are the resolutions of the conflict stored right now?"

They're stored in the merge commits - any commit with more than one parent.
But if you rebase instead of merging, you lose this information. That's why I
say you should rebase less, and instead do "real" merges.

"If I start with a master branch, split off into four topic branches, then
merge them back into master, it does a 3-way merge of the end points of each
topic branch. If I do a rebase from the merge onto the original master branch,
it seems to replay the topic branch lines in sequential order of commits on
that line time-sorted by which topic branch was first spun off... is there a
way to compress these multiple topic branches and conflict into one patch?"

If you really want to destroy all the branch history and squash everything
down into one commit, you could continually "git pull --rebase" from 'master'
to 'topic' during development, and then "git merge --squash topic" onto master
when development is finished. You'll end up with just one commit.

But I wouldn't do that. If you're doing that, it says that you care more about
_how the history looks_ than about your actual development process. Merges may
look "ugly" and make it take longer to read through your project history, but
that ugliness reflects the reality of concurrent, multi-person development,
and merge commits retain accurate history that helps tools like "git merge"
work better with fewer conflicts.

~~~
dasil003
I think you've covered the important stuff here, but I'd like to add one
point:

 _We do this because we have a requirement that we need to be able to rip out
a topic branch at any time from this release_

It's nice to be able to rip out topic branches at any time, but I would submit
that once the topic branch is complete and its time to merge, the decision of
whether to use it or not needs to be finalized. If you don't do that you're
inflicting mental overhead on the developers to support the project manager's
waffling. Depending on the nature of the topic and how modular and well-
factored the code is, it may be more or less of a chore to maintain multiple
branches, but unless both you're going to release both versions of the
software, I say merge the branch ASAP and save yourself the trouble.

~~~
mbrubeck
Yes, definitely. No software is going to make it easy to rip out any of five
or six branches late in development. With five branches, this means that you
might ship any of 2^5 == 32 different products, and you don't know which until
right before it's released.

Merging late optimizes for the case where no branches are included, but as
you've learned it makes it painful for the normal case where all (or most) do
ship. Merging early optimizes for the case where all (or most) branches are
included, but yes it makes it harder to remove a branch later on. Or you could
always maintain each of the 32 possible release branches, and merge each topic
branch continually with 16 of them... :)

As a compromize, you can merge frequently from master to topic, but then merge
topic back to master only when you are fairly confident in it. (Hopefully this
will be early for at least some topic branches, so that any conflicts with
other topics can be resolved early.) And I totally agree with the other
commenters who suggest shorter iterations and continuous integration.

