A core feature of Git is the ability to create aliases. This effectively allows you to customize Git's command set. As a developer, of course, you're going to want to do this.
However, lately I've come across numerous claims stating aliasing core commands is the Right Way to use Git. Unfortunately, even Pro Git aliases core Git commands in their examples.
Regardless, this is not the Right Way.
Why? Two reasons: obfuscation and speed.
Obfuscation
While aliases give us freedom, there's no convention for aliasing core commands. So they're all subjective.
While these commands exhibit our personal flare, they've lost their meaning. Sure git up sounds cool and might impress your coworkers. But they have no idea what it does and it isn't available on their setup.
Speed
The primary motivation for aliasing core commands is speed. Oh, the need for speed. Anything to save a few keystrokes. But how many keystrokes are you really saving by aliasing core Git comamnds?
Let's compare some common aliases against command completion.
With the exception of git status, command completion tied or beat aliases. In addition, command completion also completes references and options. So command completion saves keystrokes across all commands, not just aliases.
In the end, aliases are a useful feature. But stop aliasing core Git commands. Instead, use command completion as a clearer and often faster alternative.
Reserve aliases for Git commands you run frequently and require options. For example, here are my current aliases. Two alias long git log commands and the others compliment Git's command set with additional custom commands.
Update
There seem to be confusion about scope. My suggestion is not to create Git aliases for core Git commands. This includes things like git st, git co, git ci as shorthands for git status, git checkout, git commit respectively. It does not include Git aliases in general or system aliases.
Want to master Git? Getting Git contains over 60 videos covering Git commands as well as scenarios you'll encounter using Git every day.
Oldest comments (41)
git config --global alias.gud checkout --recursive dev.to/gonedark/stop-aliasing-core...
(Disclaimer: I'm aware that this isn't a legal git command)
I'm quite sorry, but the point of having my own personal development machine is to set it up the way I like :)
So what? I'll tell them if they ask nicely :) I don't see how setting up shortcuts, aliases or magical key combinations is anyone's business but mine...
Unless it's on a common server of course, in which case I tend to agree.
“Stop doing whatever you want” could be a good title for this post.
Git aliases are for PERSONAL use. Why shouldn't I do if I feel more confortable with those?
Okay, run your tests against my most used ones:
gst==git statusgca==git commit --allgcam "message"==git commit -am "message"gp==git push:D I know what they stand for, don't care if others do, and don't care if they aren't available on a computer that's not mine.
gst? That's far too many characters!I have a bash function
gthat aliasesgitunless you pass no arguments, then it aliasesgit status.Single characters FTW! :D
haha! that's great xD
Kinda cool ^^
I have "g." for "git status ." but may switch to "g" :D
If aliasing core commands is wrong and
git log --onelineis only 3 keystrokes more thangit logowhy do you have an alias for it?git log --onelineis not an alias for a core command. My issue is with an alias forgit logitself, for examplegit l. I believe such aliases obfuscate the commands and often don't save keystrokes.Your comparison of
git log --onelinelies in a section where you are comparing keystrokes against core commands.And frankly, as others have said, who are you obfuscating those commands to? Only yourself. Aliases don't overwrite core commands, so you are not making it harder for anyone else to use your command line, only making it easier and more comfortable for yourself.
This so called Right Way in this blog post is simply your opinion. And you would probably do better to not force it upon others.
You'll like this one:
cheat = !git log -1 && git add -A && git commit --amend -C HEAD && git push -f && git log -1I've messed around with Bash, and created a specific "Git shortcuts" bash file that essentially omits the "git" command.
This won't work in all setups, but it allows me to shorten commands while retaining readability, and tab-completion works still because it's used as a CLI:
status=>git statuslog=>git logbranch -c someBranch=>git branch someBranch && git checkout someBranchclone -p someGitURI=>git clone $(pbpaste)pushup remoteName workingBranch=>git push -u remoteName workingBranchetc. Wondering what everyone's take on this method is.
You can use
git checkout -bto create new branch and checkout to it.I've aliased
git add . && git commit -m wiptosave_gamewhich makes me smile whenever I use it. You'll need to understand rebase to clean up after tho.So we shouldn't alias git commands because someone else might need to use my computer and not immediately know what my aliases are bound to?
Maybe you don't mean it that way, but all this comes off as needlessly puritanical.
You also don't remove the original command when doing an alias, so if somebody were to sit in my computer (which no one does) he'd just have to type
git statusinstead ofgstorgit s.sorry but i'll setup my personal aliases however i like? i dont care what aliases my coworkers use for the same tasks and im sure they dont care what i use. its our own systems setup how the way we like and are comfortable with. im totally baffled by this article to be honest.
Sorry, but I don't use aliases to impress anybody. I just like having shortcuts. And it definitely minimizes the chances of errors. A two character command is easier to get right than say a 12 character command.
Yeah I agree with a lot of the responses I'm seeing. Why should it matter to my coworkers what I do on my laptop? If we're pairing and there's something they don't understand, I can always explain it. And they probably are going to be able to guess what "git co" and "git st" mean, especially if they see the output. As long as I'm not putting the short versions in documentation, I don't see a problem. You could probably extrapolate this to a lot of shell aliases too and I'd have the same opinion.
Also I've been typing "git st" and "got co" for years now. It would not make me more efficient to remove those and have to tab complete them. I've been in shells without my aliases and believe me, it does not save me keystrokes.
You can autocomplete branches etc with single letter git ...
stackoverflow.com/questions/342969...
Why should I care if others can't use my git configuration un my machine. aliases should make working more comfortable for me not for others. If i want to explain how they work i can introduce them to my set of alias or use the default ones.
Under the same logic we should all use the same editor with no configurations, since "somebody could use my computer at some point" the article is useless.
I think aliases are a personal choice, someone prefers to use it, and someone prefers to use tab completion.
When I switched from subversion to git, at the beginning I missed the short commands, but finally I started using tab completion.
As author said, aliases are indisposable to run commands with a specific options.
For my daily work, I don't use aliases, but I use "custom" commands for my daily workflow:
git branch-create $JIRA_ISSUEcreates new branch from the right branch with the right name according our rulesgit branch-sync <--rebase>Merges or rebases branch from the base branch(it's deducted by the branch name)git prsimple ncurses interface to open a pull requests, you don't need to specify the base branch againgit branch-clean <--remote>Cleans local/remote branches which has been merged into masterWe have more, but I think these ones may be interesting :D