Troubleshooting With Git - Git Series Part 3

From time to time, you will encounter problems while using Git. The most common of these is a merge conflict. Fortunately, git will provide solutions to many problems for you. Sometimes, though, there are certain problems that do require the assistance of more experienced people. Most of these problems that I will describe are what I have encountered personally in my line of work.

​Troubleshooting Issues in Git

Follow the full Git series here.

1. Merge Conflict

If you use git long enough, you are bound to come across a merge conflict. It may be daunting for a newbie to encounter such errors. However, rectification is usually pretty easy. It does require manual intervention, that is, editing the files that git reports merge conflicts for.

How can these occur?

There are a few different ways. You may have pulled changes and git found that someone else has changed the same file, or files, in around the same area after you committed yours. This what a merge conflict is. Typically, you open up your editor and resolve them. Git will add extra code to separate your changes from the one found on the repository.

As you may see, the changes in this area are listed with your changes. It is up to you to decide how to resolve this. Whether you put your changes in, keep the other change, or do something else entirely is up to you. Once you have completed the changes, you can then use ‘git add’ to add the files to mark that a resolution has been completed.$ gedit index.html # Or whichever text editor you prefer

$ git add index.html
$ git commit -m “Resolve a merge conflict” # Up to you what message.
OR
$ git rebase –continue # If rebase was used.

Here’s an example: if your commit was made later than what was pulled from the repo, ‘git pull –rebase’ will successfully do a 3-way merge.

If not, a conflict will occur and you will be forced to resolve it yourself.

As you can see, git will give you directions on what to do after you have made the necessary changes.

2. Rebase

You may have noticed that I use ‘git pull –rebase‘. This parameter invokes the ‘git rebase‘ functionality. I use this so I don’t have to provide any merge messages whenever I’m pulling changes to my repository when I have my own changes committed. Normally, if there are changes that have occurred in the repo that you don’t have, but have change that isn’t in the repo, git requires that a merge be performed. In this case, it will ask why a merge is necessary.

Now given that you could be working with a large team of developers, you may end up having to deal with merge messages quite frequently. What the ‘–rebase’ parameter does is take your commits away puts in the commits from the repo, and then applies your commits. This removes the need to provide merge messages.

There will be more on the rebase feature in the next guide.

3. Detached Head

This one can be rather annoying to deal with. A detached head is simply when HEAD pointsto a single commit rather than a whole branch. You can still make changes, but you will lose them if you checkout a branch. I have ended up in this state while I was learning how to properly reverting changes. There is a purpose for detached heads. It is useful for browsing through a previous version of a repository, but I didn’t want that at the time.
​
The solution is quite simple. If you haven’t made any changes, simply checkout the branch you want (e.g. master).$ git checkout master

If you have made changes, there a few ways you can resolve this.
​
The first option, commit any changes, create a temporary branch to store those commits in, checkout master, then merge the new branch into master. Use this if you have already made several commits.

The second option is to use ‘git stash’ to put away uncommitted changes, check out the desired branch, and run ‘git stash apply’. You can then run ‘git stash drop’ to forget about the stash. Use this if you have changes that have not been committed. Can be used with both options 1 and 3.

The third option is to copy the hash IDs of each commit somewhere, check out the branch you need, then use ‘git cherry-pick‘ with the hash ID of the commit you wish to cherry-pick into the branch. This is more suitable if you only have very few commits (1 – 3).

4. Tip Of Your Branch Is Behind The Remote’s

The cause of this issue is when you have used ‘git reset <commit-hash>‘ and you attempt to push new commits without reverting back to the latest commit on your computer. Here is a screenshot of the solution. Git notifies you of what you must do.

Conclusion

I have described a few issues you may be likely to face when using Git and how to resolve them. I also mentioned ‘git rebase‘ as a way of pulling changes without needing to do merge messages. In the next guide, I will expand on ‘​git rebase‘ followed by an overview of a few GUI front-ends for Git and more troubleshooting tips.