⚠ Important: If you have any local changes, they will be lost. With or without --hard
option, any local commits that haven't been pushed will be lost.[*]
If you have any files that are not tracked by Git (e.g. uploaded user content), these files will not be affected.
First, run a fetch to update all origin/<branch>
refs to latest:
git fetch --all
Backup your current branch:
git branch backup-master
Then, you have two options:
git reset --hard origin/master
OR If you are on some other branch:
git reset --hard origin/<branch_name>
Explanation:
git fetch
downloads the latest from remote without trying to merge or rebase anything.
Then the git reset
resets the master branch to what you just fetched. The --hard
option changes all the files in your working tree to match the files in origin/master
Maintain current local commits
[*]: It's worth noting that it is possible to maintain current local commits by creating a branch from master
before resetting:
git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master
After this, all of the old commits will be kept in new-branch-to-save-current-commits
.
Uncommitted changes
Uncommitted changes, however (even staged), will be lost. Make sure to stash and commit anything you need. For that you can run the following:
git stash
And then to reapply these uncommitted changes:
git stash pop
First, you create your branch locally:
git checkout -b <branch-name> # Create a new branch and check it out
The remote branch is automatically created when you push it to the remote server. So when you feel ready for it, you can do:
git push <remote-name> <branch-name>
Where <remote-name>
is typically origin
, the name which git gives to the remote you cloned from. Your colleagues would then just pull that branch, and it's automatically created locally.
Note however that formally, the format is:
git push <remote-name> <local-branch-name>:<remote-branch-name>
But when you omit one, it assumes both branch names are the same. Having said this, as a word of caution, do not make the critical mistake of specifying only :<remote-branch-name>
(with the colon), or the remote branch will be deleted!
So that a subsequent git pull
will know what to do, you might instead want to use:
git push --set-upstream <remote-name> <local-branch-name>
As described below, the --set-upstream
option sets up an upstream branch:
For every branch that is up to date or
successfully pushed, add upstream
(tracking) reference, used by
argument-less git-pull(1) and other
commands.
Best Answer
You can review the differences with a:
before pulling it (fetch + merge) (see also "How do you get git to always pull from a specific branch?")
When you have a message like:
, check if you need to update
origin
. Iforigin
is up-to-date, then some commits have been pushed toorigin
from another repo while you made your own commits locally.You based commit C on commit A because that was the latest work you had fetched from upstream at the time.
However, before you tried to push back to origin, someone else pushed commit B.
Development history has diverged into separate paths.
You can then merge or rebase. See Pro Git: Git Branching - Rebasing for details.
Merge
Use the git merge command:
This tells Git to integrate the changes from
origin/master
into your work and create a merge commit.The graph of history now looks like this:
The new merge, commit M, has two parents, each representing one path of development that led to the content stored in that commit.
Note that the history behind M is now non-linear.
Rebase
Use the git rebase command:
This tells Git to replay commit C (your work) as if you had based it on commit B instead of A.
CVS and Subversion users routinely rebase their local changes on top of upstream work when they update before commit.
Git just adds explicit separation between the commit and rebase steps.
The graph of history now looks like this:
Commit C' is a new commit created by the git rebase command.
It is different from C in two ways:
Note that the history behind C' is still linear.
We have chosen (for now) to allow only linear history in
cmake.org/cmake.git
.This approach preserves the CVS-based workflow used previously and may ease the transition.
An attempt to push C' into our repository will work (assuming you have permissions and no one has pushed while you were rebasing).
The git pull command provides a shorthand way to fetch from origin and rebase local work on it:
This combines the above fetch and rebase steps into one command.