David Brown <git@xxxxxxxxxx> writes: > Looking for some advice/ideas on a git workflow: > > We have three branches of the code: > > - upstream - The upstream release versions, tracks outside git repo. > - external - Other external patches not included in the main git repo. > - local - Our local development. > > For release reasons, we need to keep our local branch separate, but normal > development needs to be done on a merge of 'external' and 'local' (the tree > needs the merge of both just to build). Developers will generate patches, > and maintainers will apply these patches to 'local'. > > I've tried creating a 'next' branch where I merge each change from local > and/or external, and this seems to work, but the history gets very > cluttered with merge commits. For some reason, history simplification > doesn't seem to eliminate any of these merges. > > We also have an automated build/test system that checks out versions of > 'next', and when the build and test moves 'master' forward to that version. > Because of this, it would be nice to keep 'next' fairly up-to-date, which > implies having a lot of merges. You do not have to, and very likely do not want to, merge 'next' directly into 'master'. Instead of having a single local integration branch 'local', it is wiser to keep separate topic branches to house your local development. Each of them will start its life in an imperfect shape, and will need multiple rounds of fixups, which is normal, and you will merge them regularly into 'next' to make sure everything will work together, and 'next' will have tons of merges for this exact reason. However, what you will merge to 'master' is not 'next' as a whole. Instead, you will merge each individual topic, only it is fully cooked and proved to be Ok while it has been in 'next', to 'master'. That way, if a work to enhance an appliation area took four attempts to get it right over four 'next' cycles, 'next' branch may have four merges from that topic branch, you will see only one merge from that topic to 'master', that merges the enhancement in completed state. At that point, 'next' will have other topics in an earlier stage of polishing, and these imperfect ones will not in 'master' yet. IOW, just like you keep separate things separate by having distinction between 'external' and 'local', by keeping separate development tracks among what you currently use single basket 'local' to hold, your history will become much more meaningful and understandable. -- 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
