"Andrew Arnott" <andrewarnott@xxxxxxxxx> writes: > Am I doing something wrong, un-knowledgeable of how to properly do > merges/cherry-picks, or is this just life as we know it? In any project, there typically is the 'master' branch that progresses the (b)leeding edge, and there may be one or more 'maintenance' branches that forked immediately after you tagged a commit on the 'master' branch. You however do not necessarily want to _develop_ on these branches. Their primary purpose is to give "integration area" for people (the developers and the customer end users). If you can plan ahead and carefully decide where you would first place each of your change, you can use merges more effectively. Suppose that you have (for the sake of simplicity of the discussion) two primary integration branches. You do not want to add any new features to the 'maint' branch, and you want to include all the fixes there. Also you would want to have all the fixes you give to 'maint' to your 'master' branch. When you found a bug, the first thing to think about might be fixing the bug (obviously), but before making that commit, you need to analyze where the breakage comes from. If the root cause of breakage is shared between 'maint' and 'master', then you are better off doing the fix on 'maint' and then merge the whole 'maint' back to 'master'. You might not be very confident with your "fix", however, and it is very valid to be hesitant to make that fix directly on 'maint' branch. In such a case, you can fork a topic branch for that single fix off of 'maint', test it out, and perhaps you may choose to first merge it to 'master' to see if the fix works for other people and also if it is free of unexpected side effects for a while, before deciding that the change is safe and is Ok to merge it to 'maint' [*1*]. In either case (the former gives the fix to 'maint' first and then to 'master'; the latter gives the fix to 'master' first and then to 'maint' after validating it), the general idea for keep this possible is to do the fix on a topic branch by forking _the oldest integration branch_ that the fix could possibly apply to. Often you would find that there still are breakages in your fix. In such a case, you can check out the topic branch you worked on the fix, fix the breakage there, and merge that again to appropriate branches. As long as the topic forked off of the right branch, merging it again to 'maint' will not contaminate 'maint' with unrelated things from 'master'. You need certain discipline to effectively use merges. In the "merge" approach, you have the topics branches keep track of which integration branches their commits should eventually go. Once you make a commit on top of something else that you do not want to pull in, you cannot merge that anymore and you need decide which individual commits need to be backported after the fact, and this is often cumbersome. It is not the end of the world --- it is called "backporting" and happens often in the real life. But you can reduce the need for it by bit of planning. You can never plan ahead perfectly, so do not be too hard on yourself if you occasionally screw up. Cherry-picking from time to time is Ok. With practice, you will get used to it. I juggle 5 integration branches to maintain git.git itself and it took some practice for me to get comfortable with the workflow. [Footnote] *1* The kernel folks have a policy that their maintenance track 2.6.X.Y will never have any fix that is not in the mainline. With such a policy, you _could_ use this "fork a topic from 'maint' first, merge it into 'master' and after proving it is Ok merge the topic to 'maint'" workflow. In practice, because different people maintain the mainline and the maintenance track in that project, this is not done and they do the equivalent of cherry-pick instead. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
