Is it a good practice to do git merges on git server?

  • 3
    We don't help people win arguments with their colleagues here. – Robert Harvey Apr 10 '15 at 5:57
  • 1
    How would that even work? SSH into the (presumably headless) server and do the merge there? What advantage does your colleague hope to gain from that? – user7043 Apr 10 '15 at 6:05
  • 1
    recommended reading: How do I explain ${something} to ${someone}? – gnat Apr 10 '15 at 8:20
  • @RobertHarvey: I am not trying to win any argument.But just want too give facts to a person who has not done research himself. – Vinny Apr 11 '15 at 3:17

Facebook is actually in the process of implementing server side rebasing (there's a summary here or you can skip to to about 10:55 in the video).

In their case they have such a volume of pushes that developers are in competition to push, and they can get stuck trying to pull then push before someone else pushes and forces them to pull again.

By implementing server side rebases, pushes are simply added to a queue and processed in order, ensuring developers don't waste time getting stuck in a push/pull loop while waiting for an opportunity to push cleanly. The majority of rebases can be performed without conflict, but if there is then the developer gets notified to manually handle the merge then submit a new push. It also helps that they have a very intensive automated testing suite (also discussed in that video) so they can have greater confidence in the integrity of their automated merging.

Having said that, this approach only has benefits because they have such a high volume of pushes. These benefits don't exist if you don't have contention between pushes, and merging on the server side could significantly complicate conflict scenarios.

In general it makes more sense for the pusher to handle merging because they're in the best position to handle conflicts, and there isn't usually any time saved by performing the process on the server side.

  • 3
    facebook - seems they're a disaster internally as well as externally! How can you have any form of quality if you have so many merge requests you have to stack them in a queue? Seems to me they are layering sticking plaster on top of sticking plaster rather than look at their core development process - 100k commits per week with rebasing is a recipe for trouble! The linux kernel (and Windows) implements a federated system like a tree .. maybe that would solve their issues without so much brute force. – gbjbaanb Apr 10 '15 at 9:02
  • @gbjbaanb: Note that this really is a git design fault. It introduces an artificial global state of the database, which means every change needs to be serialized in relation to all other changes. By manually breaking up the repository, you work around this global synchronization. but this is the 21st century, we shouldn't be needing such workarounds anymore. That said, the Facebook solution is a hack. The proper fix would inside git, where it's possible to find dependencies within the pipeline – MSalters Apr 10 '15 at 13:26
  • @MSalters I don't think it is a git design fault - Torvalds designed it to suit his workflow, so if others want to use it in a different manner then that's their lookout. I think rebasing is a big problem - a SCM should be designed to never remove history (and thus cause this sync issue). But FB is the problem really, 100k commits, don't they finish their own code modules locally before pushing it upstream?! It sounds like they have a single internal FB site everyone works on simultaneously!! – gbjbaanb Apr 10 '15 at 13:34

The basic idea behind merging is that you have to consider resolving conflicts. You cannot just automatically merge and hope the system figured out what you meant - that is mostly does this is convenient but do not get confused and think that all merges work perfectly all the time.

After merging, you will want to review the results and only if it passes the human check (and possibly compiles and runs your local tests) then you can commit with a fair hope for correctness.

You can't do this on the server unless you log into it and treat the server as if it was your local workstation. And if you are doing that, why not do it on your local workstation in the first place!?

Not the answer you're looking for? Browse other questions tagged or ask your own question.