So I've done some work in the repository and when I'm about to commit I realize that I'm not currently on any branch.
This happens a lot when working with submodules and I am able to solve it, but the process is tedious and I've been thinking that there must be an easier way to do this.
Is there an easy way to get back on a branch, while keeping the changes?
If you have not committed:
git stash
git checkout some-branch
git stash pop
If you have committed and have not changed anything since:
git log --oneline -n1 # this will give you the SHA
git checkout some-branch
git merge ${commit-sha}
If you have committed and then done extra work:
git stash
git log --oneline -n1 # this will give you the SHA
git checkout some-branch
git merge ${commit-sha}
git stash pop
git checkout master
That's result something like this:
Warning: you are leaving 2 commits behind, not connected to
any of your branches:
1e7822f readme
0116b5b returned to clean django
If you want to keep them by creating a new branch, this may be a good time to do so with:
git branch new_branch_name 1e7822f25e376d6a1182bb86a0adf3a774920e1e
So, let's do it:
git merge 1e7822f25e376d6a1182bb86a0adf3a774920e1e
Alternatively, you could setup your submodules so that rather than being in their default detached head state you check out a branch.
Edited to add:
One way is to checkout a particular branch of the submodule when you add it with the -b flag:
git submodule add -b master <remote-repo> <path-to-add-it-to>
Another way is to just go into the submodule directory and just check it out
git checkout master
One way to end up in this situation is after doing a rebase from a remote branch. In this case, the new commits are pointed to by HEAD but master does not point to them -- it's pointing to wherever it was before you rebased the other branch.
You can make this commit your new master by doing:
git branch -f master HEAD
git checkout master
This forcibly updates master to point to HEAD (without putting you on master) then switches to master.
I recently ran into this problem again. It's been a while since I last worked with submodules and having learned more about git I realized that simply checking out the branch you want to commit on is sufficient. Git will keep the working tree even if you don't stash it.
git checkout existing_branch_name
If you want to work on a new branch this should work for you:
git checkout -b new_branch_name
The checkout will fail if you have conflicts in the working tree, but that should be quite unusual and if it happens you can just stash it, pop it and resolve the conflict.
Compared to the accepted answer, this answer will save you the execution of two commands, that don't really take that long to execute anyway. Therefore I will not accept this answer, unless it miraculously gets more upvotes (or at least close) than the currently accepted answer.
The following method may work:
git rebase HEAD master
git checkout master
This will rebase your current HEAD changes on top of the master. Then you can switch the branch.
Alternative way is to checkout the branch first:
git checkout master
Then Git should display SHA1 of your detached commits, then you can cherry pick them, e.g.
git cherry-pick YOURSHA1
Or you can also merge the latest one:
git merge YOURSHA1
To see all of your commits from different branches (to make sure you've them), run: git reflog.
I know I told babay in 2012 that I thought it was unlikely that someone wouldn't realize that they weren't on a branch and commit. This just happened to me, so I guess I have to admit that I was wrong, but considering that it took until 2016 for this to happen to me, you could argue that it is in fact unlikely.
Anyway, creating a new branch is overkill in my opinion. All you have to do is:
git checkout some-branch
git merge commit-sha
If you didn't copy the commit-sha before checking out the other branch, you can easily find it by running:
git reflog
