The software development world is almost completely git-based now. I’m sure there are other version control systems being used, but I personally haven’t seen anything but git for several years. Git even extends beyond code. Authors use git for books, Universities use git for documentation, and some designers use git for large image files.
And while git is awesome and makes our jobs easier, it’s complex. Most people new to git learn a couple of commands that help them get through their day, not realizing that they could do more with a little bit more knowledge of git and the command line. I want to outline three additional things that I use that help make git even more powerful.
Git Aliases
Lazy programmers are good programmers. We all should have aliases. And git has a system to define aliases that are just for git.
Your git config file can store these for you. And with the command line, you never even have to open the file to add one.
The syntax for adding an alias is git config [file-option] alias.[alias name] [git-command], where file-option is one of the following options --system, --global,
--local, --worktree and --file <filename>.
I typically use --global so my aliases are available on all of my projects.
To create an alias for git checkout you would type git config --global alias.co checkout at the command line. Now when you need to checkout a branch, you could type git co master.
Some other examples could be status or commit.
git config --global alias.st status
git config --global alias.ci commit
These types of aliases are great, but you do have to type git with everyone one. My laziness is on another level, so I use shell level aliases. My shell is zsh. For you that could be bash or something else.
The way I store my aliases may be a little different than what you’ve seen .I keep an .aliases file and source it from my .zshrc.
source ~/.aliases
In that aliases file, I define my aliases for git. A few of the most common ones are for diffing branches, committing, and seeing what local branches have been merged.
git diff
To see the diff, I define it in a way that allows me to just type gd.
alias gd='git diff --color'
This will display a pretty diff for me. So I can quickly see what has changed.
This also works with a file. gd assets/css/main.scss will display the changes for just that file. I often use this when a branch has a lot of changes staged for commit and I want to see what a file contains, so I can have smaller commits that make sense to go together.
I’ve defined gl so I can quickly view the logs.
alias gl='git log -n 20 --oneline --color --decorate'
And to commit my changes, I define this so I can type gc
alias gc='git commit -v'
I like the verbose view and this helps me avoid typing extra characters all the time.
And lastly, instead of typing git st, I’d rather type gst
alias gst='git status'
Global .gitignore
Another tool that will make your life easier is a global .gitignore. I use this to ignore some common files that I encounter a lot.
Two main things I put in my .gitignore are my tags file that gets generated by ctags and ignoring silly backup files like .DS_STORE. You can put anything in there that you want to ignore on all projects. Here is what mine looks like
.project_notes
.DS_STORE
tags
.byebug_history
.vscode
Just make sure it’s at your account level on Mac (your home directory), /Users/[username]/.gitignore. I’m not sure about Windows.
Move Between Branches Quickly
The other thing that really helps, and it may be the smallest thing, is jumping back to a branch that you just left. This is typically when doing a code review and I need to checkout a branch, do a few things, and then jump back. My branch names can get kinda long, and some recent teams that I’ve worked on have used the pattern feature/[ticket number]/description. That can be a lot to type. And even with auto-completion, it doesn’t always work well because so many branches share the same start of their name.
The solution is super simple.
git checkout -
or based on my aliases, it’s even shorter gco -
This will take you back to whatever the previous branch was. For example, let’s say you are on a branch called feature/5463/add-status-to-user-accounts, but need to checkout master to do some work and then back to feature/5463/add-status-to-user-accounts
git checkout master
Do work…
git checkout -
Once you use git for awhile, you start to see patterns of things that you use a lot. Hopefully this has given some ideas of how you can make your workflow a little better.