5 Git Fundamentals

I’m starting a series on some of the git tips and tricks that I’ve learned the that I’ve been using it. We’ll skip the everyday basics and start off with the fundamentals that will help you utilize the true power and convenience of version control. during half-decade push, pull, log, status, diff, commit Let’s begin by creating a file in your home directory. This file is the basis for all your git configurations, customizations, and aliases. In case you’re curious, I have posted a link to mine at the end. **.gitconfig** [user]email = email@gmail.comname = Jorge Yau [core]editor = vimignorecase = false [push]default = simple [color "diff"]meta = yellow bold ulfrag = cyan bold ulold = red boldnew = green bold [color "status"]added = green boldchanged = yellow bolduntracked = red bold [grep]break = trueheading = truelineNumber = true [alias]g = grep --extended-regexp --break --heading --line-number Once the file exists, git will preload and use these configurations for all further commands. Try running a inside a repo and notice how the colors have changed. git diff I also have included a , which is basically a shorthand for a command. In this case, with all the additional flags can be executed as . git alias git grep git g # This longer command:$ git grep --extended-regexp --line-number --break --heading # Is the equivalent of:$ git g Also notice how there’s a for — this is where you can specify default options and arguments that will be applied every time you run . If you include the same option in an alias, it will override the default option. Lastly, sections can have subsections, e.g. section [grep] git grep [section “subsection”] There are hundreds of settings for every command, each with an expansive number of options that you can customize — read the official gitconfig documentation to discover what’s possible. While files are ubiquitous, did you know that you can globally ignore file patterns by creating a file in your home directory and adding it to your under the core section. I recommend putting software remnants, IDE and OS related files here. gitignore **.gitignore_global** **.gitconfig** .idea***~.DS_Store Then either add this line to your file: **.gitconfig** [core]excludesfile = ~/.gitignore_global Or run this command, which automatically appends it to your .gitignore git config --global core.excludesfile ~/.gitignore_global Speaking of grep, is my preferred choice for searching through a codebase over alternatives like GNU grep or ack. It’s fast, comes with git, and ignores files in your by default. **git grep** **.gitignore** # Here's how to use it with more options below.$ git grep 'debugger' # Show the count of occurrences found for each file.$ git grep --count 'debugger' # Ignore case sensitivity.$ git grep --ignore-case 'debugger' # Search through untracked files.$ git grep --untracked 'debugger' # Quiet mode. Exits 0 if match found. Useful for scripts and hooks.$ git grep --quiet debugger Speaking of grep, the command is without a doubt one of the most useful git commands. Very frequently, I use it with and to perform a bulk find-and-replace or code trimming — occasionally using regex with captured groups (more on this topic in the future). However, I also want to ignore third-party files such as the directory, which is just not as with regular grep or even ack. git ls-files grep sed **node_modules** sexy $ grep -E debugger . -rl --exclude-dir={*components*,*node_modules*} $ ack debugger -l --ignore-dir={components,node_modules} What if I need a list of in the repository — there’s no simple way to accomplish that with regular bash. Well, thankfully will list all files in the repository while also excluding the file patterns in your gitignore. all files **git ls-files** $ git ls-files .dockerignore.eslintignore.eslintrc.yml.gitignore.gitlab-ci.yml.scss-lint.ymlDockerfileREADME.md... You can then pipe in the results to grep to filter for certain files. In this case, I’m filtering for all JavaScript files in my repository — the is to make sure that files are excluded. $ .json $ git ls-files | grep -E \.js$ Git and grep are often paired together in many other commands. If you want to search through your commit messages you can use . Searching through commit messages from what I’ve seen is a seldomly used but exceptionally useful feature for tracking down bugs, tracing feature developing, and analyzing your codebase. More on that to come. **git log --grep** # Search for 'bug' in the git commit message history.git log --grep 'bug' # I recommend using this flag to ignore merge commits.git log --no-merges --grep 'bug' # Refine your searches to a particular author.git log --grep 'bug' --author 'codenameyau' I have an alias to pretty print the shortened commit hash, the date, the author, and the commit message in one line. You can use it like so: # Put this inside your ~/.gitconfig[alias]search = log --no-merges -i -E --pretty='%h (%ad) - [%an] %s %d' --date=format:'%b %d %Y' --grep # Then run the command like so:$ git search 'bug' # Pipe it to wc to get the number of occurences for 'fix' or 'bug'.$ git search 'fix|bug' | wc -l Git search in action. In order for to be useful, it’s best to have contextual but concise commit message under 80 characters. One very helpful convention is to include a hash (#) followed by the issue number. This will automatically link the commit to the issue for repository managers like GitHub, and it makes documenting and investigating issues much more feasible. **git search** $ git commit -m "#123 - Fix bug with useful git commit message" Bonus tip: once you’ve grasped the basic fundamentals, definitely check out the repository. It is an extension of git with extremely useful commands ( . git-extras I’m looking at you obliterate) https://github.com/tj/git-extras/blob/master/Commands.md As promised earlier, here’s a link to my . file. gitconfig _dotfiles - My dotfile and text editor configurations_github.com codenameyau/dotfiles If you learned something from this article or simply enjoyed it, please recommend it. I would greatly appreciated it! Here are some other articles in my series Git Fundamentals Updating Multiple Git Repos With One Command