For branches that haven't diverged too much you can do a git rebase instead but that is more error prone and personally I dislike it because it essentially changes history and certainly you can't safely do it for branches that have been pushed remotely which is almost inevitable for longer lived feature branches. Given that one of the core ASF principles around IP is that the provenance of code should be maintained I prefer (at least for the ASF) not to do anything that changes the history.
(NB - Before git experts shoot me down technically you can do it for pushed branches but it likely requires deleting the remote branch and pushing the rebased branch. This is also very brittle if multiple people are trying to work on the same feature branch) Probably the best thing to do from a workflow perspective is to ask people to push new code separately from merges. So if I have a branch with changes that I want to bring up to date I would do the following: 1 - Push the new code for the feature branch 2 - Merge master into the feature branch 3 - Push the merged changes for the feature branch That way you'd get a separate set of emails for the merges and the actual new code Rob On 14/01/2015 11:09, "Andy Seaborne" <[email protected]> wrote: >Fine tuning our processes ... > >Rob is now ahead with "[??/93]" :-) OK - he's sub-contracted the work >of the actually commit to others. > >Is there anyway we can stop this? > >Is there a better way to merge two branches in git? > > Andy
