Related
I accidentally ran git merge some_other_branch on my local master branch. I haven't pushed the changes to origin master. How do I undo the merge?
After merging, git status says:
# On branch master
# Your branch is ahead of 'origin/master' by 5 commits.
How do I undo all these commits?
With git reflog check which commit is one prior the merge (git reflog will be a better option than git log). Then you can reset it using:
git reset --hard commit_sha
There's also another way:
git reset --hard HEAD~1
It will get you back 1 commit.
Be aware that any modified and uncommitted/unstashed files will be reset to their unmodified state. To keep them either stash changes away or see --merge option below.
As #Velmont suggested below in his answer, in this direct case using:
git reset --hard ORIG_HEAD
might yield better results, as it should preserve your changes. ORIG_HEAD will point to a commit directly before merge has occurred, so you don't have to hunt for it yourself.
A further tip is to use the --merge switch instead of --hard since it doesn't reset files unnecessarily:
git reset --merge ORIG_HEAD
--merge
Resets the index and updates the files in the working tree that are different between <commit> and HEAD, but keeps those which are different between the index and working tree (i.e. which have changes which have not been added).
Assuming your local master was not ahead of origin/master, you should be able to do
git reset --hard origin/<branch-name>
So assuming you did this on master, then your local master branch should look identical to origin/master.
See chapter 4 in the Git book and the original post by Linus Torvalds.
To undo a merge that was already pushed:
git revert -m 1 commit_hash
Be sure to revert the revert if you're committing the branch again, like Linus said.
It is strange that the simplest command was missing. Most answers work, but undoing the merge you just did, this is the easy and safe way:
git reset --merge ORIG_HEAD
The ref ORIG_HEAD will point to the original commit from before the merge.
(The --merge option has nothing to do with the merge. It's just like git reset --hard ORIG_HEAD, but safer since it doesn't touch uncommitted changes.)
With newer Git versions, if you have not committed the merge yet and you have a merge conflict, you can simply do:
git merge --abort
From man git merge:
[This] can only be run after the merge has resulted in conflicts. git merge --abort will abort the merge process and try to reconstruct the pre-merge state.
You should reset to the previous commit. This should work:
git reset --hard HEAD^
Or even HEAD^^ to revert that revert commit. You can always give a full SHA reference if you're not sure how many steps back you should take.
In case when you have problems and your master branch didn't have any local changes, you can reset to origin/master.
Lately, I've been using git reflog to help with this. This mostly only works if the merge JUST happened, and it was on your machine.
git reflog might return something like:
fbb0c0f HEAD#{0}: commit (merge): Merge branch 'master' into my-branch
43b6032 HEAD#{1}: checkout: moving from master to my-branch
e3753a7 HEAD#{2}: rebase finished: returning to refs/heads/master
e3753a7 HEAD#{3}: pull --rebase: checkout e3753a71d92b032034dcb299d2df2edc09b5830e
b41ea52 HEAD#{4}: reset: moving to HEAD^
8400a0f HEAD#{5}: rebase: aborting
The first line indicates that a merge occurred. The 2nd line is the time before my merge. I simply git reset --hard 43b6032 to force this branch to track from before the merge, and carry-on.
If you are in a middle of merging you can always abort it
git merge --abort
With modern Git, you can:
git merge --abort
Older syntax:
git reset --merge
Old-school:
git reset --hard
But actually, it is worth noticing that git merge --abort is only equivalent to git reset --merge given that MERGE_HEAD is present. This can be read in the Git help for merge command.
git merge --abort is equivalent to git reset --merge when MERGE_HEAD is present.
After a failed merge, when there is no MERGE_HEAD, the failed merge can be undone with git reset --merge, but not necessarily with git merge --abort, so they are not only old and new syntax for the same thing.
Personally I find git reset --merge much more powerful and useful in everyday work, so that's the one I always use.
If branches are merged and not pushed, then git reset command given below will work to undo the merge:
git reset --merge ORIG_HEAD
Example:
git reset --merge origin/master
Okay, the answers other people here gave me were close, but it didn't work. Here's what I did.
Doing this...
git reset --hard HEAD^
git status
...gave me the following status.
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 3 and 3 different commit(s) each, respectively.
I then had to type in the same git reset command several more times. Each time I did that, the message changed by one as you can see below.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 3 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 2 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 1 and 3 different commit(s) each, respectively.
> git reset --hard HEAD^
HEAD is now at [...truncated...]
> git status
# On branch master
# Your branch is behind 'origin/master' by 3 commits, and can be fast-forwarded.
At this point, I saw the status message changed, so I tried doing a git pull, and that seemed to work:
> git pull
Updating 2df6af4..12bbd2f
Fast forward
app/views/truncated | 9 ++++++---
app/views/truncated | 13 +++++++++++++
app/views/truncated | 2 +-
3 files changed, 20 insertions(+), 4 deletions(-)
> git status
# On branch master
So long story short, my commands came down to this:
git reset --hard HEAD^
git reset --hard HEAD^
git reset --hard HEAD^
git reset --hard HEAD^
git pull
You have to change your HEAD, Not yours of course but git HEAD....
So before answering let's add some background, explaining what is this HEAD.
First of all what is HEAD?
HEAD is simply a reference to the current commit (latest) on the current branch.
There can only be a single HEAD at any given time. (excluding git worktree)
The content of HEAD is stored inside .git/HEAD and it contains the 40 bytes SHA-1 of the current commit.
detached HEAD
If you are not on the latest commit - meaning that HEAD is pointing to a prior commit in history its called detached HEAD.
On the command line, it will look like this- SHA-1 instead of the branch name since the HEAD is not pointing to the tip of the current branch
A few options on how to recover from a detached HEAD:
git checkout
git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits t go back
This will checkout new branch pointing to the desired commit.
This command will checkout to a given commit.
At this point, you can create a branch and start to work from this point on.
# Checkout a given commit.
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>
# create a new branch forked to the given commit
git checkout -b <branch name>
git reflog
You can always use the reflog as well.
git reflog will display any change which updated the HEAD and checking out the desired reflog entry will set the HEAD back to this commit.
Every time the HEAD is modified there will be a new entry in the reflog
git reflog
git checkout HEAD#{...}
This will get you back to your desired commit
git reset --hard <commit_id>
"Move" your HEAD back to the desired commit.
# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32
# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts if you've modified things which were
# changed since the commit you reset to.
Note: (Since Git 2.7)
you can also use the git rebase --no-autostash as well.
git revert <sha-1>
"Undo" the given commit or commit range.
The reset command will "undo" any changes made in the given commit.
A new commit with the undo patch will be committed while the original commit will remain in the history as well.
# add new commit with the undo of the original one.
# the <sha-1> can be any commit(s) or commit range
git revert <sha-1>
This schema illustrates which command does what.
As you can see there reset && checkout modify the HEAD.
It can be done multiple ways.
1) Abort Merge
If you are in-between a bad merge (mistakenly done with wrong branch), and wanted to avoid the merge to go back to the branch latest as below:
git merge --abort
2) Reset HEAD to remote branch
If you are working from remote develop branch, you can reset HEAD to the last commit on remote branch as below:
git reset --hard origin/develop
3) Delete current branch, and checkout again from the remote repository
Considering, you are working on develop branch in local repo, that syncs with remote/develop branch, you can do as below:
git checkout master
##to delete one branch, you need to be on another branch, otherwise you will fall with the branch :)
git branch -D develop
git checkout -b develop origin/develop
You could use git reflog to find the previous checkout. Sometimes that's a good state you want to return back to.
Concretely,
$ git reflog
$ git reset --hard HEAD#{0}
I was able to resolve this problem with a single command that doesn't involve looking up a commit id.
git reset --hard remotes/origin/HEAD
The accepted answer didn't work for me but this command achieved the results I was looking for.
If you didn't commit it yet, you can only use
$ git checkout -f
It will undo the merge (and everything that you did).
Got to this question also looking to revert to match origin (ie, NO commits ahead of origin). Researching further, found there's a reset command for exactly that:
git reset --hard #{u}
Note: #{u} is shorthand for origin/master. (And, of course, you need that remote repository for this to work.)
if no conflict and merge completed then:
git reset --hard HEAD~1
if while doing a merge got conflict then abort will take you out of the recent merge changes:
git merge --abort
or if you want to revert back to a specific commit id.
git reset --hard <commit-id>
Answering the question "Undo a Git merge that hasn't been pushed yet"
You can use git reset --hard HEAD~1
Consider the following situation where there are 2 branches master and feature-1:
$ git log --graph --oneline --all
Do Git merge
$ git merge feature-1
$ git log --graph --oneline --all
Undo Git merge
$ git reset --hard HEAD~1
$ git log --graph --oneline --all
You can use only two commands to revert a merge or restart by a specific commit:
git reset --hard commitHash (you should use the commit that you want to restart, eg. 44a587491e32eafa1638aca7738)
git push origin HEAD --force (Sending the new local master branch to origin/master)
Good luck and go ahead!
The simplest answer is the one given by odinho - Velmont
First do git reset --merge ORIG_HEAD
For those looking to reset after changes are pushed, do this
(Because this is the first post seen for any git reset merge questions)
git push origin HEAD --force
This will reset in a way that you won't get the merged changes back again after pull.
Just for an extra option to look at, I've been mostly following the branching model described here: http://nvie.com/posts/a-successful-git-branching-model/ and as such have been merging with --no-ff (no fast forward) usually.
I just read this page as I'd accidentally merged a testing branch instead of my release branch with master for deploying (website, master is what is live). The testing branch has two other branches merged to it and totals about six commits.
So to revert the whole commit I just needed one git reset --hard HEAD^ and it reverted the whole merge. Since the merges weren't fast forwarded the merge was a block and one step back is "branch not merged".
If your merge and the corresponding commits were not pushed yet, you can always switch to another branch, delete the original one and re-create it.
For example, I accidentally merged a develop branch into master and wanted to undo that. Using the following steps:
git checkout develop
git branch -D master
git branch -t master origin/master
Voila! Master is at the same stage as origin, and your mis-merged state is erased.
Strategy: Create a new branch from where everything was good.
Rationale: Reverting a merge is hard. There are too many solutions, depending on many factors such as whether you've committed or pushed your merge or if there were new commits since your merge. Also you still need to have a relatively deep understanding of git to adapt these solutions to your case. If you blindly follow some instructions, you can end up with an "empty merge" where nothing will be merged, and further merge attempts will make Git tell you "Already up to date".
Solution:
Let's say you want to merge dev into feature-1.
Find the revision that you want to receive the merge:
git log --oneline feature-1
a1b2c3d4 Merge branch 'dev' into 'feature-1' <-- the merge you want to undo
e5f6g7h8 Fix NPE in the Zero Point Module <-- the one before the merge, you probably want this one
Check it out (go back in time):
git checkout e5f6g7h8
Create a new branch from there and check it out:
git checkout -b feature-1
Now you can restart your merge:
Merge: git merge dev
Fix your merge conflicts.
Commit: git commit
When you're satisfied with the results, delete the old branch: git branch --delete feature-1
If you want a command-line solution, I suggest to just go with MBO's answer.
If you're a newbie, you might like the graphical approach:
Kick off gitk (from the command line, or right click in file browser if you have that)
You can easily spot the merge commit there - the first node from the top with two parents
Follow the link to the first/left parent (the one on your current branch before the merge, usually red for me)
On the selected commit, right-click "Reset branch to here", pick the hard reset there
Just create new branch, then cherry-pick desired commits to it.
Its saver and simpler then resets described in many answers above
I think you can do git rebase -i [hash] [branch_name] where [hash] is the identifying hash for however far back you want to rewind plus one (or however many commits back you want to go) and then delete the lines for the commits in the editor that you don't want any more. Save the file. Exit. Pray. And it should be rewound. You might have to do a git reset --hard, but it should be good at this point. You can also use this to pull specific commits out of a stack, if you don't want to keep them in your history, but that can leave your repository in a state that you probably don't want.
Use this command to abort a merge:
git merge --abort
First, make sure that you've committed everything.
Then reset your repository to the previous working state:
$ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36
or using --hard (this will remove all local, not committed changes!):
$ git reset f836e4c1fa51524658b9f026eb5efa24afaf3a36 --hard
Use the hash which was there before your wrongly merged commit.
Check which commits you'd like to re-commit on the top of the previous correct version by:
$ git log 4c3e23f529b581c3cbe95350e84e66e3cb05704f
commit 4c3e23f529b581c3cbe95350e84e66e3cb05704f
...
commit 16b373a96b0a353f7454b141f7aa6f548c979d0a
...
Apply your right commits on the top of the right version of your repository by:
By using cherry-pick (the changes introduced by some existing commits)
git cherry-pick ec59ab844cf504e462f011c8cc7e5667ebb2e9c7
Or by cherry-picking the range of commits by:
First checking the right changes before merging them:
git diff 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704f
First checking the right changes before merging them:
git cherry-pick 5216b24822ea1c48069f648449997879bb49c070..4c3e23f529b581c3cbe95350e84e66e3cb05704f
where this is the range of the correct commits which you've committed (excluding wrongly committed merge).
The simplest of the simplest chance, much simpler than anything said here:
Remove your local branch (local, not remote) and pull it again. This way you'll undo the changes on your master branch and anyone will be affected by the change you don't want to push. Start it over.
Using gitk log, I could not spot a difference between the effect of git merge and git merge --no-ff. How can I observe the difference (with a git command or some tool)?
The --no-ff flag prevents git merge from executing a "fast-forward" if it detects that your current HEAD is an ancestor of the commit you're trying to merge. A fast-forward is when, instead of constructing a merge commit, git just moves your branch pointer to point at the incoming commit. This commonly occurs when doing a git pull without any local changes.
However, occasionally you want to prevent this behavior from happening, typically because you want to maintain a specific branch topology (e.g. you're merging in a topic branch and you want to ensure it looks that way when reading history). In order to do that, you can pass the --no-ff flag and git merge will always construct a merge instead of fast-forwarding.
Similarly, if you want to execute a git pull or use git merge in order to explicitly fast-forward, and you want to bail out if it can't fast-forward, then you can use the --ff-only flag. This way you can regularly do something like git pull --ff-only without thinking, and then if it errors out you can go back and decide if you want to merge or rebase.
Graphic answer to this question
Here is a site with a clear explanation and graphical illustration of using git merge --no-ff:
Until I saw this, I was completely lost with git. Using --no-ff allows someone reviewing history to clearly see the branch you checked out to work on. (that link points to github's "network" visualization tool) And here is another great reference with illustrations. This reference complements the first one nicely with more of a focus on those less acquainted with git.
Basic info for newbs like me
If you are like me, and not a Git-guru, my answer here describes handling the deletion of files from git's tracking without deleting them from the local filesystem, which seems poorly documented but often occurrence. Another newb situation is getting current code, which still manages to elude me.
Example Workflow
I updated a package to my website and had to go back to my notes to see my workflow; I thought it useful to add an example to this answer.
My workflow of git commands:
git checkout -b contact-form
(do your work on "contact-form")
git status
git commit -am "updated form in contact module"
git checkout master
git merge --no-ff contact-form
git branch -d contact-form
git push origin master
Below: actual usage, including explanations.
Note: the output below is snipped; git is quite verbose.
$ git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: ecc/Desktop.php
# modified: ecc/Mobile.php
# deleted: ecc/ecc-config.php
# modified: ecc/readme.txt
# modified: ecc/test.php
# deleted: passthru-adapter.igs
# deleted: shop/mickey/index.php
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ecc/upgrade.php
# ecc/webgility-config.php
# ecc/webgility-config.php.bak
# ecc/webgility-magento.php
Notice 3 things from above:
1) In the output you can see the changes from the ECC package's upgrade, including the addition of new files.
2) Also notice there are two files (not in the /ecc folder) I deleted independent of this change. Instead of confusing those file deletions with ecc, I'll make a different cleanup branch later to reflect those files' deletion.
3) I didn't follow my workflow! I forgot about git while I was trying to get ecc working again.
Below: rather than do the all-inclusive git commit -am "updated ecc package" I normally would, I only wanted to add the files in the /ecc folder. Those deleted files weren't specifically part of my git add, but because they already were tracked in git, I need to remove them from this branch's commit:
$ git checkout -b ecc
$ git add ecc/*
$ git reset HEAD passthru-adapter.igs
$ git reset HEAD shop/mickey/index.php
Unstaged changes after reset:
M passthru-adapter.igs
M shop/mickey/index.php
$ git commit -m "Webgility ecc desktop connector files; integrates with Quickbooks"
$ git checkout master
D passthru-adapter.igs
D shop/mickey/index.php
Switched to branch 'master'
$ git merge --no-ff ecc
$ git branch -d ecc
Deleted branch ecc (was 98269a2).
$ git push origin master
Counting objects: 22, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (14/14), 59.00 KiB, done.
Total 14 (delta 10), reused 0 (delta 0)
To git#github.com:me/mywebsite.git
8a0d9ec..333eff5 master -> master
Script for automating the above
Having used this process 10+ times in a day, I have taken to writing batch scripts to execute the commands, so I made an almost-proper git_update.sh <branch> <"commit message"> script for doing the above steps. Here is the Gist source for that script.
Instead of git commit -am I am selecting files from the "modified" list produced via git status and then pasting those in this script. This came about because I made dozens of edits but wanted varied branch names to help group the changes.
Merge Strategies
Explicit Merge (aka non fast-forward): Creates a new merge commit. (This is what you will get if you used --no-ff.)
Fast Forward Merge: Forward rapidly, without creating a new commit:
Rebase: Establish a new base level:
Squash: Crush or squeeze (something) with force so that it becomes flat:
The --no-ff option ensures that a fast forward merge will not happen, and that a new commit object will always be created. This can be desirable if you want git to maintain a history of feature branches.
In the above image, the left side is an example of the git history after using git merge --no-ff and the right side is an example of using git merge where an ff merge was possible.
EDIT: A previous version of this image indicated only a single parent for the merge commit. Merge commits have multiple parent commits which git uses to maintain a history of the "feature branch" and of the original branch. The multiple parent links are highlighted in green.
This is an old question, and this is somewhat subtly mentioned in the other posts, but the explanation that made this click for me is that non fast forward merges will require a separate commit.
The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature
Other answers indicate perfectly well that --no-ff results in a merge commit. This retains historical information about the feature branch which is useful since feature branches are regularly cleaned up and deleted.
This answer may provide context for when to use or not to use --no-ff.
Merging from feature into the main branch: use --no-ff
Worked example:
$ git checkout -b NewFeature
[work...work...work]
$ git commit -am "New feature complete!"
$ git checkout main
$ git merge --no-ff NewFeature
$ git push origin main
$ git branch -d NewFeature
Merging changes from main into feature branch: leave off --no-ff
Worked example:
$ git checkout -b NewFeature
[work...work...work]
[New changes made for HotFix in the main branch! Lets get them...]
$ git commit -am "New feature in progress"
$ git pull origin main
[shortcut for "git fetch origin main", "git merge origin main"]
What’s a fast-forward?
A fast-forward is what Git does when you merge or rebase against a branch simply ahead of the one you have checked-out.
Given the following branch setup:
You’ve got both branches referencing the same commit. They’ve both got precisely the same history. Now commit something to feature.
The master branch is still referencing 7ddac6c, while the feature has advanced by two commits. The feature branch can now be considered ahead of the master.
It’s now relatively easy to see what’ll happen when Git does a fast-forward. It simply updates the master branch to reference the exact commit that feature does. No changes are made to the repository itself, as the commits from the feature already contain all the necessary changes.
Your repository history would now look like this:
When doesn’t a fast-forward happen?
Fast-forwards don’t happen when changes have been made in the original branch and the new branch.
If you were to merge or rebase the feature onto master, Git would be unable to do a fast-forward because the trees have both diverged. Considering Git commits are immutable, there’s no way for Git to get the commits from feature into master without changing their parent references.
has been pulled, the result is still an error ! [rejected] dev->dev(non-fast-forward)
D:\PPI_Roketin\Project\astrowatch (dev)
λ git add resources/views/reals/_form.blade.php
D:\PPI_Roketin\Project\astrowatch (dev)
λ git commit -m "resources/views/reals/_form.blade.php"
[dev db5ac99] resources/views/reals/_form.blade.php
1 file changed, 2 insertions(+), 2 deletions(-)
D:\PPI_Roketin\Project\astrowatch (dev)
λ git push origin dev
To gitlab.com:roketin-stellar/astrowatch.git
! [rejected] dev -> dev (non-fast-forward)
error: failed to push some refs to 'git#gitlab.com:roketin- stellar/astrowatch.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
error like this, why?
have done git checkout, and repeated the command, it's still an error like above
This is a classic git error. The problem is described in the error message: Updates were rejected because the tip of your current branch is behind, which means that there have been changes to the remote branch that you do not have locally. There are quite a few ways to fix this, one of which is also described in the git message: Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again.
If you do git pull origin dev this will merge whatever changes are made in the remote to your local branch. Once you fix the merge conflicts, you can then push the branch.
Another option would be to run a rebase by performing git pull --rebase origin dev, which will bring in the remote changes and rebase your commits on top of the remote commits. This will result in a cleaner git history.
The easiest for now would probably just doing a git pull, then once it's merged correctly, pushing to your remote.
I definitely recommend researching the git commands and learning how to find the resources correctly in the docs. There is a lot available online.
you can try git reset --hard HEAD
please remind that:
HEAD points to your current branch (or current commit), so all that git reset --hard HEAD will do is to throw away any uncommitted changes you have.
It's quite self explanatory, you need to keep yourself upto date with remote branch if you want to commit and it looks like git pull will overwrite files you've made changes to. You should commit your changes first.
After checking out the branch of a colleague, at some point
I couldn't push or pull from remote.
Each time I ran git push or git push origin branch_name or those variant, I always got a everything up to date even though I had committed changes. Ultimately, what did the trick was git push -f origin HEAD:origin/branch_name. So my question is, why did I have to run this? what did I do to get there?
the fatal error I got was:
fatal: You are not currently on a branch.To push history leading to current (detached HEAD) state now, use: git push origin HEAD:<name-of-remote-branch>
Current State: Your head isn't attached to a branch, so you pushed with the branch whose history was the same as the remotes. You were working with a detached head, so when you pushed the head instead of the branch, it worked.
If you do a git status it with show:
HEAD detached at XXXXXXX
Fixing it:
Now that your remote has the changes you made, you can checkout the branch_name and pull your changes from remote. Your branch_name should already be tracking that remote branch.
Why you had to do this: You somehow detached your head. Without knowing the commands you used, we won't be able to tell you why you had to do this.
An example of how you could have done this:
#Don't do this, because force pulling will make you lose your work.
git checkout --detach
git pull --all -f #Don't do this.
You should probably edit (parts of) your last two ... er, now, three—comments into your question, but for now, I'll just quote them here:
I found where I might have off road. When I checked-out the branch I was going to work on, I got this message (let's called the branch b1:
Branch b1 set up to track remote branch b1 from origin.
Switched to a new branch 'b1'.
I checked-out the branch this way:
git checkout b1.
Then when I tried to push I did:
git push --set-upstream origin b1.
Branch b1 set up to track remote branch b1 from origin.
Everything up to date
OK, in that case you are probably fine.
git checkout
The problem you are running into here (well, in my opinion it's a problem) is that git checkout crams three or four (or more, depending on how you count) different things into one command.
Normally you would use:
git checkout somebranch
to check out (switch to) your local branch somebranch. Of course, that's great for branches you already have, but no good for branches you don't have locally yet. So Git crams another, different, command into git checkout: the "create new branch, then switch to it" command.
Normally this command is spelled git checkout -b newbranch. The -b flag means "create new". It's pretty reasonable to have this command spelled the same as git checkout, with just a flag, since we're switching to this newly created branch, but it probably would be clearer if it were a separate command, such as git create-and-then-switch-to-new-branch.
Now, pretty often, when you are creating a new local branch, you are doing so with the intent of having it "track" (as its "upstream") some existing remote-tracking branch, origin/b1 or whatever. In this case, you originally had to type in:
git checkout -b b1 --track origin/b1
which is still really obvious: create new branch b1, base it off remote-tracking branch origin/b1, and make it track (have as its upstream) origin/b1. Again, this might be clearer as git create-and-then-switch-to, but it's not so bad to have it shoved into git checkout, plus checkout is a lot shorter to type!
Now, many years ago (back in 2013 or so), the Git folks saw that this action was pretty common, and decided to make Git do it "magically" for you under certain conditions. If you write:
git checkout b1
and you don't currently have a branch b1 and you do currently have an origin/b1 and you don't have any other remote-tracking branch whose name ends in b1, then (and only then!), git checkout uses the create-and-then-switch-to-new-branch command, with the --track flag. So:
git checkout b1
means
git checkout -b b1 --track origin/b1
in this one special (but common) case.
--track means "set upstream"
Each branch (well, each named, local, branch) can have one (1) "upstream" set. The upstream of a branch has a bunch of uses: git status, git fetch, git merge, git rebase, and git push all look at the upstream. Having an upstream set makes git status show how many commits you are ahead and/or behind of the current branch's upstream. And, it lets you run all the other commands with no additional arguments: they can figure out where to fetch from, or what to merge or rebase, or what to push, using the current branch's name and its upstream setting.
Branches do not have to have an upstream, and a new branch you create doesn't, by default. Moreover, if it's a "very new" branch—one that does not exist on origin, for instance—there's no origin/name yet to have as an upstream in the first place. But when you create a new branch from a remote-tracking branch, setting the remote-tracking branch as the upstream of the new branch is almost always the right thing.
(Note: having an upstream also affects git pull because git pull is just git fetch followed by either git merge or git rebase. Until they are very familiar with Git, I think most people are noticeably better off running git fetch first, then git rebase or git merge second, depending on which one they want—and more often, that's actually git rebase, which is not the default for git pull: git pull defaults to using git merge second. Once they are familiar with the fetch-and-whatever sequence, then people can configure git pull to do the one they intend, and use git pull as a shortcut to run both commands. However, there are times to keep them separate anyway.)
For completeness
The other things that git checkout can do, that don't change the current branch, are:
copy files from the index to the work-tree: git checkout -- <paths>, including the special git checkout --ours and git checkout --theirs variations
copy files from specified commits to the index and then on to the work-tree: git checkout <tree-ish> -- <paths>
restore conflicted merge files to their conflicted state: git checkout -m -- <paths> (as with --ours and --theirs, this only works during a conflicted merge)
interactively patch files: git checkout -p (this variant gets especially complicated and I'm not going to address it further)
The checkout command can also "detach HEAD" (see previous answer below) and create "orphan" branches, but both of these effectively change your current branch, so they don't fall into this special "non-branch-changing" class of checkout operations.
So what happened with the first git push
When you ran:
git push --set-upstream origin b1
you told your Git to contact the other Git on origin, give it the commit ID to which your branch b1 pointed, see if it needed any of those commits and files (it didn't), and then ask it to set its branch name b1 to point to the same commit.
Now, you'd just created your own local b1 from your origin/b1, which you recently git fetch-ed from origin, so your b1 already pointed to the same commit (you did not make any new commits) and hence your git push gave them their own commit hash back and they said "Well, gosh, that's what I already have! We're all up-to-date!" And then their Git and your Git said goodbye to each other, and your Git carried out your last instruction: --set-upstream.
This changed the upstream of your local branch b1 to origin/b1. Of course, this was already the upstream for your local branch b1, so that was not a big change. :-) But your Git did it anyway, and then reported that everything was still up to date.
Earlier answer (was mostly done when you added your third comment)
... I had one file committed with changes. git status didn't return nothing after I committed.
git status should always print something, such as (two actual examples):
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
or:
HEAD detached at 08bb350
nothing to commit, working directory clean
In this second case, you are in "detached HEAD" mode. This special mode means you are not on a branch—or it may be more accurate to say that you are on the (single, special-case) anonymous branch that goes away as soon as you get on any other branch.
Any commits you make while in detached HEAD mode are perfectly fine, normal commits—except that there is no branch name that will make them permanent. This means these commits can go away once you switch to some other branch.
All my attempts to push were unsuccessful.
Again, actual git push output might help here, so one could tell why the push failed or did nothing. If it complained about being in "detached HEAD" mode, that would be significant: we would know that you were in the detached HEAD mode.
git fetch -a didn't return nothing as well.
(Just an aside: It's a bit odd to use -a here: that flag is almost never useful to humans and is intended more for scripting purposes. It just makes your fetch append to FETCH_HEAD rather than overwriting it. The special FETCH_HEAD name is meant for scripts to use.)
the last step I had were to git checkout origin/branch_name.
This will take you off whatever branch you were on before, and put you in "detached HEAD" mode. If you used to be in "detached HEAD" mode, it will abandon your previous anonymous branch and put you on a new, different anonymous branch.
Any commits you made while on the previous anonymous branch are ... well, not lost, precisely, but are now difficult to find (and set to expire after 30 days).
When I tried to push from there I got the following message:
fatal: You are not currently on a branch.
To push history leading to current (detached HEAD) state now, use:
git push origin HEAD:<name-of-remote-branch>.
Which I did [... HEAD:origin/branch_name] and it worked
Yes, but alas, this did nothing useful, because you are now on an anonymous branch that is exactly the same as origin/branch_name. This ends up asking the remote to create—on the remote, as a local branch there—the name origin/branch_name. That's probably not a good idea, since having a local branch named origin/branch_name is like having a bicycle named "motorcycle". If you also have a motorcycle and ask your friend to bring you "motorcycle", which will he bring you, the bicycle named "motorcycle", or the motorcycle?
I am trying to make a hook on a remote --bare repository that will copy the source code I send from a local git, in different folders according the branch I'm sending to. I have 3 branches on local: master, development and release so I wish that on the remote would be 3 folders containing the source code of each branch. I found that using:
git rev-parse --abbrev-ref HEAD
in combination with a series of if conditions could do the trick. The only problem is that the HEAD remains the same on remote for whatever branch you send to. Is there any code that could be used in the hook, so it would know that I am sending to a certain branch? Or is there any other method for doing this? Thanks!
Your one bare repo will have all 3 branches on it. You can use git modifiers like this to make 3 separate directories update to what each branch contains:
git --work-tree=/some/project/dir/branch1 --git-dir=/path/to/bare/repo checkout branch1 -- .
To avoid specifying those options, you can set their corresponding environment variables:
GIT_WORK_TREE
GIT_DIR
This way you can keep one bare repo and 3 separate directories that update when branches are pushed. Remember what the arguments are that are provided in your hook. The first is the branch name.