Git — Beyond the very basics
In my last few project I was getting along well with some fundamental git commands (like git add, commit, push and pull), and in the majority of cases that was more than enough to handle a situation. Until a certain point, when I realized that in order to solve the minority — but at least as important — problems I must go deeper into this topic and find more advanced commands.
So, if you are confident enough with the basics, let’s start our trip together to explore the deepest circle of hell of git.
Showing the differences
If we want to see the differences between the current files we are working on and between the last checkpoint:
git diffIf the purpose is to find the difference between the staged files and the latest checkpoint:
git diff --stagedIf the purpose is to find the difference between branches:
git diff master mybranchThis last command makes the comparison based on the committed changes.
Git reset
There are certain cases when we want to make a step back. Or two. In this case we can reverse our head with the following command (the number denotes here how many commits to go back):
git reset HEAD~1or
git reset doitback.pyor
git reset [the very long log number comes here]if you want to go back until a certain checkpoint. For that purpose you certainly want to check your commit history with
git logcommand. If you want to remove both the stages and the actual changes on the file level, go ahead with hard reset:
git reset --hardBut be careful, it deletes the changes even from your files of the given repository! Also you can do it on a soft way, and both the file content and the stages will be kept.
git reset --softThe ordinary reset is actually the inverse of git add command, as a result it removes the changes from the checkpoint (looks like the changes were not added), but does not keep the changes on your repository. If the commit is already proceeded, the reset command works only with the log number.
Stashing
This is also a very useful command if you have some changes which are not ready to stage, but meantime have other issues to solve on the repository. Git forces you to add/commit your changes before making pull/push commands. In this case the stash command will the solution:
git stashor
git stash save notreadytostage.pyThis will neither add nor commit your actual changes. It looks like packing up all your unstaged changes to a box and putting away to a bookshelf and keeping them there until you are ready to continue your job. You can easily continue your work with the changes made before by just retrieving them with the following command:
git stash popYou also can change your mind and want to discard the last stashed changes:
git stash dropGit remove
This command removes the file and stages the change:
git rm readytodelet.pyGit merge
It is very commonly occurs if we work on branch and would like to push back our latest commits to the master branch. First, we should switch to the master and initiate a merge of our working branch:
git checkout mastergit merge mybranch
This command merges the specified branch’s history into the current branch. If you want to make sure to create an extra checkpoint before the merging commit, it is worth to include in the command that you don’t want to do it the ‘fast forward’ way:
git merge --no-ff mybranchIf the files are easily mergeable — there might be added rows but there were no differences in existing rows since the latest branching — the merge takes place smoothly, all changes are staged. You just have to commit and push the changes on the master branch.
But — honestly saying — this is the rare case. It is more likely that we will run into a merge conflict!
Solving the merge conflict
One of the solutions here is to abort the merge process and try to reconstruct the pre-merge version of the files with the following command:
git merge --abortHowever some experts warn us using this command as it is not the best way to solve the merge conflict if we might have uncommitted changes. It can be ended up by losing our changes and with a situation from which it will not be able to reconstruct the previous one.
Certainly, our purpose is not to ignore the changes but compare the versions and manage the differences. After the merge commit the affected file will contain the conflicts you probably want to solve. It is possible to solve it in an editor or even the Github provides editor to proceed the necessary changes. After the merge conflict has been solved, the changes should be added and committed the usual way.
This is an example how the merge conflict is shown on the Github editor:

