Got git basics down? Cool! In this article, you’ll learn about some intermediate git tricks to streamline your workflows and make your life easier.
If you’re not familiar with branching, merging, committing, and other beginner git topics, that’s okay – we all have to start somewhere! Check out our introduction to git handbook.
“I love resolving merge conflicts!” said nobody ever. Sometimes it’s hard to know which branch is correct. When kids are fighting, sometimes they ask their parents for help; similarly, looking at the most recent common ancestor can help figure out how to resolve merge conflicts.
Setting your conflict resolution style to
diff3 in your git configuration exposes the recent common ancestor so that you can better understand change history.
For example, check out this merge conflict in standard diff resolution style:
List Of Best Emojis Rainbow 🌈 <<<<<<< HEAD Pizza 🍕 Unicorn 🦄 ======= Avocado 🥑 >>>>>>> topic-branch
You know that HEAD has pizza and unicorn, and the topic branch has avocado, but how do you know which is correct?
Check out the same diff in diff3 style:
List Of Best Emojis Rainbow 🌈 <<<<<<< HEAD Pizza 🍕 Unicorn 🦄 ||||||| merged common ancestors Pizza 🍕 ======= Avocado 🥑 >>>>>>> topic-branch
Pizza is present in the merged common ancestor, but unicorn is not. Therefore, to resolve the conflict you want to add pizza back in and keep avocado around. To enable diff3 conflict resolution, type
git config --global merge.conflictstyle diff3 in your command prompt.
Using a graphical merge conflict resolution tool, such as the ones built into Atom can simplify the conflict resolution process even more.
Commit message templates
Every team is a little different. Your team probably has some conventions for commits, such as every commit should link to an issue or the commit message should explain why the change was needed.
In order to keep your commits consistent, you can use a git message template. This template appears in the editor where you make your commits, to remind you of your team’s commit conventions. When you make the commit, any of the lines in the commit template that begin with a comment character are automatically stripped out.
Linters are programs that run in your development environment and check your code for errors on the fly. Although linters are incredibly useful, they can’t catch every kind of mistake. For example, I have committed code that focuses only one unit test an embarrassing number of times. Pre-commit hooks to the rescue! A pre-commit hook is a shell script that executes right before you make a commit.
You can make a pre-commit hook by creating a shell file in
.git/info/hooks/pre-commit. The script should exit with code
0 if no problems are found, and exit with code
1 if there is an issue.
Here is a snippet from a pre-commit hook that guards against committing focused tests. Replace
.only( with the name of the function that focuses a single unit test in your language and test framework of choice.
if [["$(git diff --cached $against | grep '^+')" = *".only("*]]; then echo "Oh noes you're about to commit a .only(" exit 1 fi
If I had a nickel for every time I typed
git stauts I’d have enough for the bus. In your terminal, you can run the command
git config --global help.autocorrect 1 in your command prompt to enable autocorrect. Then git will automatically understand that you mean
git commit not
git comet. If you type something that’s obviously not a git command, like
git pizza you’ll still get an error message though.
Let’s say you’re working on a branch. You see that your teammate pushed some changes to the same branch. If you’re not ready to make a commit but want to pull those changes in, you have to stash what you’re working on, fetch, rebase, and then apply your stash. Autostash automatically stashes your work, and then applies the stash after the rebase is done. You can enable autostash by typing
git config --global rebase.autoStash true in your terminal prompt.
But wait - what if there is a merge conflict when applying the stash? Not to worry! In that case git will let you resolve the conflict in your editor of choice.
Hopefully these tips have enriched your workflows and brought you closer to git. If you have any questions, or want to start a discussion about which emoji is actually the best, please feel free to comment below.