Join Kevin Skoglund for an in-depth discussion in this video Setting up aliases for common commands, part of Git Essential Training.
- View Offline
In this movie, I want us to take a look at some of the tools and next steps that you should consider as you continue to grow your skill set. I want to start by talking about how to set up aliases, or keyboard shortcuts for common Git commands. Now aliases can be a little bit dangerous, especially if you are beginner, what you don't want to do is accidentally confuse yourself and start using an alias and thinking it is the actual command. So it may be to your benefit, to stick with the actual Git commands for a while, until you get really familiar with them, and then when you are really are looking for a speed increase and trying to have less typing, to do something that you already know how to do well, then you can start using aliases.
When we set up aliases, we are going to set them up in any git config file, but it probably makes more sense to have them in our user global config file then it does to have them in the project config file, because we probably want to have them available to us in every project that we work on, and they are often going to be user specific. I don't necessarily want to have the same aliases as one of my coworkers does. So instead of putting them inside our explore_ california directory, we are going to put those in our user directory in the git config file there, which is a refresher, if we go back and take a look, that's going to be inside this directory here .gitconfig.
On Linux you can also just use the tilde to represent your user directory. Now there are two ways to add aliases to that file. One is to go and then edit the file directory, the other one which we are going to use is the git config using the global option. We saw how to do that in the early configuration, and then we will use alias, followed by what we want to alias. So we want to have, what keyboard shortcuts related to what command. I am going to do status first.
Status is something that we type all the time, and we definitely can save ourselves some time by just having to type st instead of having to type out status, so st space and then the command that we want. You can put the command inside double quotes here but they are optional unless the command has a space in it. If the command that you are going to enter has a space in it, you need the double quotes. Once I do that, it now adds it to my config file, we can take a look at that, I will use.. /.. to get to my git config file.
And you can see that it added an entry here for alias with square brackets around it, and I have got st = status. So you could go into the file directly and use the same format to just continue adding new entries, right under st, st= whenever, you don't need to do the alias portion again, you are just in a big block here. The same way that these are done, one after another for this block, but I am going to ahead and keep using git config to set these up. So let's try that out, I am inside my git repository, I can now say git st instead I git status, and you see that it comes up and tells me the status.
Okay, let's try creating some more now. Now the set that I am going to give you is a very common, very popular set. I think probably most git developers use these or some version of them. So while you can use whatever aliases you want these have become kind of standard. The first one is co which is for checkout, makes sense, co checkout. The next one we can have ci which is for commit. When I see ci I think check in, which is not the same thing as commit, checkout and check in but just don't be tricked by it.
Don't thing that check in is an actual command in Git, it's not. Commit is the command. And then we can have one for branch, we will use br for branch, and this one I find less useful, but for diff we can use just df. It really doesn't save that many keystrokes, so I usually go ahead and type diff myself. And then a lot of developers use some version of either dfc or dfs, and then they use diff --staged, or diff --cached.
And that shows the difference between the staging index and your repository. Now because it has a space in it, we want to make sure that we do put double quotes around it. Now note that just because these are shortcuts for the command, we can still put other options and arguments after it. So for example, if want to do git branch with a -r option I can use br with the r option, and it does the exact same thing. That's kind of a standard set. Let me show you just one more that I think you might find useful, and that's a log, and I just do a logg with another g after it. You can use whatever you want, but log with a g after it, and I am going to say that is going to be in double quotes, log --graph, --decorate, --oneline, --abbrev-commit and --all and then double quotes that the end.
I used this a couple of times during the tutorial, so you probably remember it. So now if I just type git logg I don't have to remember all of those options. It goes ahead and gives me the nice graphical representation of my log showing where all the branches and the merges are over the course of time. So feel free to customize the aliases to your liking, but don't let them become a substitute for understanding what the actual commands are and what they actually do.
- Exploring the history of version control
- Installing Git on Mac, Windows, and Linux
- Initializing a repository
- Writing useful commit messages
- Understanding the Git three-tree architecture
- Tracking when files are added, edited, deleted, or moved
- Viewing change sets and comparing versions
- Undoing changes and rolling back to previous versions
- Ignoring changes to select files
- Creating and working with code branches
- Merging branches and resolving merge conflicts
- Stashing changes for later
- Working with hosted repositories and remote branches
- Developing an effective collaboration workflow