Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

git pull and resolve conflicts

Tags:

git

I am learning git and I have a scenario:

  1. My coworker makes changes and pushes the changes to the master.
  2. I make changes locally to my master.

So far from my understanding, at this point I can either:

  1. Pull the master that my coworker worked on and fix the merge conflicts that I will end up having.
  2. Create a back up of my local, clone a new copy of the master, and then merge my changes to the master.

I want to know if there is any better way of doing this.

like image 994
Asim Mahar Avatar asked Jan 26 '16 22:01

Asim Mahar


People also ask

How do you Git pull and merge?

The git pull command is actually a combination of two other commands, git fetch followed by git merge . In the first stage of operation git pull will execute a git fetch scoped to the local branch that HEAD is pointed at. Once the content is downloaded, git pull will enter a merge workflow.

Does Git automatically resolve conflicts?

Git Merge ConflictsWhen Git is unable to automatically resolve differences in code between two commits because there are conflicting changes to the same line of code, a merge conflict occurs. Merge conflicts in Git can happen when merging a Git branch, rebasing a branch, or cherry picking a commit.


2 Answers

If there are different changes on both the remote and the local branch, instead of just pulling the master by git pull, I rather would do:

git pull --rebase

I even have it in my default config so that it will always will do a rebase if required on git pull:

git config --global pull.rebase true

A rebase avoids a merge commit and keeps your changes on top of the current remote branch.

Yet you still have to resolve any occurring merge conflicts when different people are working on the same branch, which is a bad practice especially because it leads to conflicts.

(Also be aware that in the scope of a rebase, the meaning of theirs and ours is switched.)

In cases with minor changes, yours are just applied on the top.

You are changing the history, yet only your local one, not the remote's.

You won't need to git push --force. You just git push it as you are used to it.

In general, you should be working on feature branches and merge those back to the master branch.

When working on feature branches one can also keep the feature branch close to the master by:

git checkout feature-branch
git fetch && git rebase origin/master

Yet here one would need to git push --force the feature-branch, so one should be careful not to use this strategy if more than one person is working on the same feature-branch.

If one wants to use rebase and push forcing, consider using git push --force-with-lease over git push --force as it prevents accidentally deleting other's commits on the remote.

like image 177
k0pernikus Avatar answered Oct 08 '22 13:10

k0pernikus


One (simple*) way to handle this without branching or stashing:

  1. stage/commit your changes locally
  2. pull remote
  3. at this point you'll be notified of any merge conflicts. If git cannot automatically resolve merge conflicts, it will open the two versions in whatever editor you have set up as your default merge editor. I recommend BeyondCompare.
  4. commit your merge, push your merge and commits remote master
like image 28
Patrick Motard Avatar answered Oct 08 '22 13:10

Patrick Motard