1

With the team we are working with git and unfortunately everyone on master. The problem is that everyone is also using default git pull, which quite often leads to "Merge branch..." and sometimes it contains too much files... So I read that to avoid those merges it would be better to use git pull --rebase, but is it safe in this case? Everyone will be doing commit, then git pull --rebase, then the files from remote will be taken at the top of HEAD and the commit on top of it.

So in this situation if someone modified the same file as me, after this steps I will see the conflict and would be able to resolve it and commit again and then there will not be a "Merge branch..." with files with someone else push, right?

Lui
  • 414
  • 2
  • 8
  • 17
  • 2
    Start using branches instead of everyone working on master. I can't understand why you would all work from master if you're running into merge conflicts so often. – Kirk Beard Nov 08 '17 at 09:00
  • 1
    Relevant answers [here](https://stackoverflow.com/questions/18930527/difference-between-git-pull-and-git-pull-rebase), [here](https://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions) and [here](https://stackoverflow.com/questions/5601931/best-and-safest-way-to-merge-a-git-branch-into-master/5602109#5602109) – Patrick Trentin Nov 08 '17 at 09:08
  • I don't see how "merge branch" contains too much files, presumably the commits you're pulling from the remote contains those files, so rebase or merge, the files are still there. As such, it sounds like you're describing one problem but mixing it with another. Can you explain more about the problems you're seeing? – Lasse V. Karlsen Nov 08 '17 at 09:25
  • 2
    Also know that if you **know** you're doing it wrong ("unfortunately everyone on master") then *most* of the explanations of how to deal with problems will be invalid, because you've explicitly voided the contexts where those problems have a good solution. – Lasse V. Karlsen Nov 08 '17 at 09:26
  • If you want to do it right, start using branches. Additionally, merges are not a problem other than making a history that sometimes can be hard to understand, but they *are* true to the actual way the project evolved. – Lasse V. Karlsen Nov 08 '17 at 09:27
  • @LasseVågsætherKarlsen the problem appeared yesterday/today. Surprisingly a lot of people were working on the master. And a lot of changes has been provided. It leaded to the situation where on git history appeared "Merge branches..." with hundreds of files, where the person only pushed 10 or 20... But I assume that problem is here that some people didn't make a pull before starting their work and this leaded to this situation... – Lui Nov 08 '17 at 09:36

1 Answers1

1

So I read that to avoid those merges it would be better to use git pull --rebase, but is it safe in this case?

Yes, its safe to use git pull --rebase.

You should check the git workflow. It's not encouraged for a team to work directly on the master, commit and push. Create a branch and the merge to the master and then pull/push the master to the origin.

@Patrick Trentin already provided the link to the questions that can help you to understand the usage of git pull --rebase.

Useful links

  1. Check this link to know in-detail about git pull --rebase.
  2. Git workflow guide.
danglingpointer
  • 4,071
  • 3
  • 20
  • 36
  • I'm confused at this place from @Patrick Trentin [link](https://stackoverflow.com/questions/16666089/whats-the-difference-between-git-merge-and-git-rebase/16666418#16666418): "`E` should be local to developer Ed and should have never been pushed to any other repository." So in this case when I make a pull rebase, the commit `D` is placed before my changes and my `E` just became `R`? – Lui Nov 08 '17 at 09:54