Skip to content
knormoyle edited this page Apr 1, 2013 · 3 revisions

Merging Local Work with Remote Changes

What is your current state?

  1. uncommitted changes
  2. committed but unpushed changes
  3. both
  4. neither

State 1 (uncommitted changes)

Option 1

  1. Commit local changes
  2. goto State 2

Option 2

$ git stash
$ git pull
$ git stash pop

If you did not have conflicts, your working copy will now have your uncommitted changes in it and you are done. At this point you are in a normal git state and can continue.

If you did have conflicts, your index will contain your non-conflict files and your working copy will contain your conflicted files. At this point you are in a normal git state and can continue as long as you understand the difference between your working copy and your index

State 2 (committed but unpushed changes)

Option 1 (merge)

Use this option if you have many made many commit and are likely to have multiple, sizable conflicts.

$ git pull
# this command is syntactic sugar for
$ git fetch -a
$ git merge

If you did not have conflicts, your working copy and index will be clean. You will have just made a merge commit. At this point you are in a normal git state and can continue.

If you did have conflicts, your index will contain your non-conflict files and your working copy will contain your conflicted files. You are in a merging git state and must not forget this fact.

If you panic and need to go back

$ git merge --abort

Once you have finished fixing conflicted files

# first add the conflicted files to your index
$ git add <conflicted>
# then commit everything
$ git commit

At this point you are in a normal git state and can continue

Option 2 (rebase aka replay commits individually)

$ git pull --rebase
# this command is syntactic sugar for
$ git fetch -a
$ git rebase

If you did not have conflicts, your working copy and index will be clean. You will have just made a series of rebased commits. At this point you are in a normal git state and can continue.

If you did have conflicts, your index will contain your non-conflict files and your working copy will contain your conflicted files. You are in a rebasing git state and must not forget this fact.

If you panic and need to go back

$ git rebase --abort

Resolve your local conflicts. At this point you should keep in mind that you will not see all of your changes. You will only see changes replayed up to the one that is producing the current conflict. This is normal. Do not reimplement your changes or you will create further conflicts for yourself. Handle the existing conflicts then:

# first add the conflicted files to your index
$ git add <conflicted>
# then resume the rebase
$ git rebase --continue

This resumes rebasing your commits onto the local. It may produce more conflicts (in which case repeat this step) or it may finish successfully.

State 3 (both local commits and uncommitted work)

Either

$ git commit
# go to State 2

or

$ git stash
# go to State 2
$ git stash pop
# resolve conflicts as in State 1

State 4 (no local work)

There is nothing really to do. There will be no conflicts.

$ git pull

Tips

  • Print deleted files
git log --all --pretty=format: --name-only --diff-filter=D

cherry-picking is easy

Scenario: master contains commit e234f1a5c6889006978b562ca42319f48746860e which needs to be integrated into 'erdos-3' branch.

# checkout remote 'erdos-3' branch into local 'erdos-3' branch
git checkout -b erdos-3 origin/erdos-3
# cherry-pick the commit from master (the commit has 'unique' ID)
git cherry-pick e234f1a5c6889006978b562ca42319f48746860e
# the command create a new commit in your 'erdos-3' branch, so you just need to push it
git push 
Clone this wiki locally