Question

In a few days, I must make one complex commit, I’ll try to explain in details:

We’re using GIT (after migrating from svn) and have 3 work branches:

• trunk – branch for immediate changes/fixes, developer’s playground, etc
• preproduction – branch, where all of the features for client testing goes
• production – the name says it all, working branch of the product

So usually developers go such sequence:

new ticket -> local copy -> trunk -> preproduction -> production

pretty standard, I guess.

Now, to the question itself:
In the trunk we have one completed hell of a task (1000+ hours), that was there before the migration from svn, so it’s not git-branched, or anything like that, it’s just a bunch of commits. We need to merge that task onto preproduction and then production branches accordingly.

I can’t quite sure what will be the most painless way of doing it. I’m not even sure branches have common ancestor commit after migration.

Is there a common way that problem could be solved? Maybe I can group commits, related to this task into branch followed by merging this branch with the pre and production?

Any advices greatly appreciated.

Answer 1

If you need an ancestor commit (always a good idea IMO), you can use SVN to find the actual divergence point where trunk and preproduction/production were last the same, then find the SHA1 of the corresponding commit on the preproduction branch in git and do this:

git checkout -b temp trunk // Don't use trunk itself in case it breaks
git rebase <SHA1 goes here> // Rewrite the commits as changes from that SHA1
// Possibly fix some conflicts
// Verify manually that you have the code you expect
git branch -m trunk old_trunk // Move old trunk aside
git branch -m temp trunk // Here's the new trunk!

Which will leave you with trunk branching off preproduction. You may with to repeat so that preproduction branches off production too.

In order to merge them cleanly, turn on git rerere (so that the way you resolve any conflicts is recorded and automatically reused when you merge pre-production into production) and then do:

git checkout preproduction
git merge --no-ff trunk

This will make a merge commit (no-fast-forward) so you can see where the feature starts and stops, rather than one long line of commits. It will also leave the trunk branch as it was, so you can keep committing to it ready to merge the next feature.

The model we use to manage this process is git-flow, which sounds a lot like the workflow you are describing, so I’d recommend checking this out, along with the command line tools to support it.

Also, if you wish to group the commits, I’d explore using rebase to take them out of the main flow of trunk and putting them back as no-fast-forward merges so you can see where particular feature start and end.