Log in

No account? Create an account

January 14th, 2009

Previous Entry Share Next Entry
11:04 am - Never merging back

There are valid cases where you once fork with the intention to never merge back, but in general you should try very hard to keep changes on such a fork to the minimum.

In an open source setting, where you fork a release branch release near the tip of the primary development branch master when going into a pre-release freeze, the intention is largely not "never to merge back". You would either cherry-pick good fixes that still happen on the primary branch after such a fork, or you apply fixes to release and merge it back to master to propagate the fix forward:

     A'--B'--Z release                        A---B---Z release
    /                                        /     \
---o---o---A---o---o---B---o master      ---o---o---o---o---o master

Keeping your history in the latter shape needs more discipline, but it will pay off by releaving you from having to remember what was and what wasn't cherry-picked. In either way, the point is that even in such a setting, you may have some changes that you would never want to merge from release to master.

For example, imagine that the Makefile records a version number of the software to be embedded in the end product, and it always has to be set to wip on master, while release may say it is preparing for version 1.2.0. Maybe Z in the above picture is such a commit to change wip to 1.2.0 in the Makefile.

By keeping such a change to the minimum, you can still merge release to master to make sure that you do not forget to integrate any important fix made on the former to the latter. You may need to make an evil merge to keep the version number in the Makefile stay the same on master manually, and that is why it pays to be careful to keep the changes you do not want to have in the release to the minimum.

     A---B---Z-------. release
    /     \           \
---o---o---o---o---o---o master

An even better approach is this. You use two branches for the release (one for pre-release fixes, and the other for release engineering), and keep such changes that cannot be merged back to the master to the latter branch, while merging the former to the latter as needed.  The final release is cut from the latter.  And the pre-release fixes branch can be merged back to master without fear of contaminating master.

       Z-------o release engineering
      /       /
     /---A---B pre-release fixes
    /         \
---o---o---o---o---o---o master  

Outside open source settings, each of your customers may demand a specific customization for its own needs. You can treat such customization as if it is a fork with no intention to merge back.  I.e. the same way we used release engineering branch in the above picture.  One thing you will find useful is to never dismiss a crazy request that seems too specific to a single customer by throwing it into such a customer release branch without thinking.  Tomorrow another equally crazy customer may want the same feature, and you will regret that you did not implement it as a normal optional feature by forking a topic branch from master and merging it to the customer release branch.

       Z--------o release for customer A
      /        /
     /----A---B a random crazy feature #47
    /          \
---o---o master \
    \            \
     Y------------o release for customer B

Otherwise you would end up having to cherry-pick changes from everywhere to everywhere else and it will quickly get out of control.



(Leave a comment)

Never merging back - gitster's journal

> Recent Entries
> Archive
> Friends
> Profile

Pages at the k.org
The latest blog by Gitster

> Go to Top