When I made my first git initiation the trainer took one hour to explain us how it works. I then talked to my roomate which was already a confirmed Devops and he tolds me “But it took at least a year to learn core concepts”…
It’s now more than three years using “a revision control which is expressly designed to make you feel less intelligent than you thought you were” and I wanted to share some tips I wish I knew earlier.
Useful graphs
When using git with team you often need to go back in the past to understand when things went wrong. git graph is the tool you need for that but the vanilla command is not really as useful as you may need, that’s why you can use git log --graph --oneline and git log --graph --oneline --all
These commands produce a readable graph which you can easily go through. You can also use it as a help you for your releases notes if you use semver. Using the --all flag will have the advantage to show all the branches, can be messy sometimes…
Cut the crap
When doing rebase you may want to keep only one set of change from the commit you are reviewing. The official way is to furiously go through all your chunks and remove the code from the same branch without making any mistake…
Now the clever way is to use git checkout –ours/theirs which you can obviously use as this: git checkout --ours -- myfile to limit the change. With this you will be able to have a look to the different changes git is currently trying to apply, here is an example with the following conflict
Here we have a classical messy rebase where we need to choose the changes to keep. First let’s use git diff --ours to see where we come from:
We see in a quick sight the code we are editing, we can compare it with the code we should have in the next commit we are trying to apply (their changes) with git diff --theirs
By using the flags with git checkout we can directly get the code we want. Note you have to precise the file you want to change. Here is an example with the result of git checkout --theirs -- main.py
Pretty neat isn’t it ? But stay here for the next part, mixed with this feature changes will be way easier than now
A new way to conflict
We can discuss about git being funny or not but conflict never are. That’s why diff3 have been invented: trying to ease this hard process. Diff3 option will change the layout of conflicts so it will be easier to sort it out what to keep.
Default conflict mode show you actual commit and conflicting commit but it doesn’t show you the the first common ancester so you may have hard time finding what you actually wanted to write at this place
Easy ignore
Not really a git command but I would like spotlight the website gitignore.io that will generate a tailored .gitignore your project according to your needs
Last tips
If you are a zsh user, I would advise you to activate the git plugin which give you a lot of useful aliases. For examples our beloved git log --graph --oneline and git log --graph --oneline --all became glol and glola!