As with everything in life, there will always be that pesky little problem that pops up as you work your way up from Novice to Master.
On this page, you will see a few of the ones we encounter the most when you begin learning Git.
If you need help with some of the Git-specific terms in this post, check out Git’s git glossary.
1. decapitated by beheading
While you’re getting used to how Git handles branches, it’s pretty easy to find yourself in something called “detached HEAD state.”
What this basically means is that you checked out a specific commit, rather than checking out the branch itself.
Git can also enter this state if you try to switch to an upstream branch instead of the local version.
When you check out the whole branch, Git moves chronologically with each recent commit (the HEAD commit at any given time).
When HEAD is detached, you’re basically on your own.
Staying in this state — if it’s not intentional — can cause a lot of problems, and any changes you commit from this state might not even belong to a specific branch, so you could end up losing changes.
The easiest way to get to the right branch and preserve your uncommitted changes is to just check out another branch:
git checkout master
2. divergence and diverge
If you see a message like the following one (perhaps when you run git status):
# On branch master # Your branch and 'origin/master' have diverged, # and have 72 and 29 different commit(s) each, respectively.
it may mean that your branch and the remote version have gone separate ways.
If this is because you haven’t pulled down updates from the remote repository, it’s a pretty simple fix.
Just run git pull and you should be good to go with your changes intact.
This problem comes with two solutions: merging or rebasing. The option you choose to go with largely depends on how you’d like the history to look.
When you merge, Git takes everything from your version of the branch and merges it into the remote version of the branch. This results in a multi-line history, with separate lines of development running in parallel.
If you rebase, Git goes back to the point when things diverged, adds the remote changes, and then applies the changes from your branch next, so you get the same nice linear history that you would’ve had if nothing had diverged.
git merge origin/masterOR
git rebase origin/master3. revert to a sinless state
Making changes to any project can require a lot of back-and-forths as you try out new ideas, iterate on improvements, or repair bugs before committing.
If something just isn’t working out, the simplest fix might be to just revert it to its original state.
git checkout -- path/to/fileThis will grab the version of the file from the last commit to the branch and give you a clean slate to work from.
But if you’re feeling a little more daring, and just want to trash everything on your path and start over, you can revert everything at once:
git reset --hardYou’ll be returned to the branch’s state at its last commit.
You gotta be careful with this option, though as this will reset your entire working tree, and you’ll lose all local commits.
4. branching into the wrong branch
You made some awesome changes and might have even committed those awesome changes!
Then went for a celebratory prune juice! … and then you realized that you did it all on the wrong branch.
This gets trickier if you already pushed your changes to your remote, but as long as things are just local, the fix isn’t too bad.
If you haven’t committed anything, you just need to create a new branch out of the current branch’s contents, and then you can reset the existing branch back to where it started:
git branch new-branch-name
git reset HEAD- --hard
Now, you can check out the new branch to add more changes or continue in your current branch, which is now in the state of the last commit.
If you made a commit or two, it’s just a little more complicated.
You’ll need to create and check out a new branch (or just check out an existing branch), cherry-pick the commit you want from the other branch, swap over to that branch, and then reset it:
git branch new-branch-name
git checkout new-branch-name
cherry-pick commit-branch
checkout commit-branch
git reset HEAD- --hard
Bam! Your changes are happily perched in the new branch, and the existing branch is back to where it started. Problem solved.
Protip: If you need to find out which branch you’re on, you can run ‘git status’ at any time.
It’ll show you your current branch, its state, and any modified tracked or untracked files.
5. commit phobia
Git wouldn’t be nearly so valuable without its revision history, and commits are a huge part of that.
So, it makes sense that updating commit messages and data after the fact is a pretty common Git function.
If you just need to alter the commit message itself, you only need:
git commit --amend
Git will open up the commit message in your preferred text editor, and you can make whatever changed you’d like.
This actually creates a new commit and uses it to replace the original, but the outcome is the same as just editing.
You can also use amending to add files you forgot to add to the commit or to update author information.
Using this to alter commits that you’ve already pushed is a bit trickier, though, so you’ll want a good understanding of how history revisions work before you give that a try.
6. merge conflict
Most of the time, when you integrate changes from one branch into another, Git’s ability to automatically merge everything together.
Sometimes, though, you’ll run into a merge conflict.
git merge warlike_wars Auto-merging timewars.html CONFLICT (content): Merge conflict in timewars.html Automatic merge failed; fix conflicts and then commit the result.
The most common merge conflict involves two sets of changes to the same line(s) of the same file(s).
The impacted file will show up in the initial warning message, or you can run git status to find a list of files:
git status
There are some pretty cool merge tools that you can use to handle these situations, or you can fix it on the command line.
If you open up a file with merge conflicts, you’ll see some helpful indicators that show you where the problems are and all you have to do is pick what you want to keep and delete everything else.
Save the file, commit the changes, and the conflict is over.
If you end up seeing the same conflict often, and you always want to fix it the same way, you can be proactive and add the rerere.enabled setting to your Git config file.
This records how you resolve the conflict so that Git can automatically resolve that specific conflict the next time that it occurs.
This is a little advanced, though, so before you use it, read up on it more here.
7. go nuclear and nuke everything
If you’ve exhausted everything else and your local, cloned repository’s still on fire, or if you tried a few things but don’t feel like trying anymore, you can ragequit the repository, too.
Be careful, this is NOT a safe option for your remote repository!
Only do this if you’re using a local repository and can re-clone a separate remote repository.
Otherwise, you’re deleting your entire project and won’t be able to recover it.
You could do that if you really want to, but starting over from scratch isn’t usually fun.
If you’ve decided it’s worth it, just get out of the repository directory, delete the whole thing, and then clone your project again.
cd ..
rm -rf project_I_gave_up_on
git clone https://goodboy_everything_is_cool.git
cd goodboy_everything_is_cool
courtesy of Sarah Haney, a Technical Writer at cPanel
