Practical commands for efficiency and a clean tree
1. Shortcuts (aka Alias)
You will find tons of alias ideas out there, the ones I found using the most are these. You can edit them using nano ~/.gitconfig in mac/linux.
So instead of typing git checkout <branch> you can type git co <branch>
[alias]
co = checkout
br = branch
st = status
# create a new branch from current branch and check it out
cob = checkout -b
# stage all changes and commit (add a message)
a = !git add -A && git commit -m
unstage = reset HEAD --
last = log -1 HEAD
hist = log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short
# Meld the currently unstaged changes into the last commit
fixup = !git add -A && git commit --amend --no-edit
I will be using these throughout this article.
3. Bug and feature branches
From your main or dev branch use git cob bug/123 to create a branch that will be used to work on issue #123 .. you can use bug/123 or issue/123 if you want to distinguish between bugs, tasks, features. This will organize them in folders when using git gui tools because of the forward slash.
4. Change your git editor to nano
Unless you where born in the 1980s you likely hate vi or vim editor, you can change it with:
git config --global core.editor "nano"
Use Ctrl+o to save (ie o for output), Ctrl+x to quit, Ctrl+w to search
5. Clean up your commits
When creating a bug branch called say bug/123 you will likely have tons of wip ie. work in progress commits. If you want to squash them all down to 1 commit before publishing the branch, then you can do this with git rebase -i
You want to go from this:
To this:
# Open interactive rebase with the last 6 commits
git rebase -i HEAD~6
That will open nano or vi with the ability to tell git what to do:
What we want is to squash all the commits together.
The top commit is the oldest one so you need to pick that one because squash will squash with the previous commit. If you don't one to squash them all onto that commit (maybe you wanted the next or previous one as the starting point, just exit and change the HEAD to HEAD~5 or ~7. Caution: make sure to comment out all the lines with # so that the rebase does nothing!
Then save (Ctrl+o in nano, or <Esc> :wq in vim). It will then let you pick the commit message for that rebase, just comment out (#) all of them and type your own or just pick the best one.
Tip: If you have already published the branch (and all those noisy commits) you are working on, then rebasing it locally won't change it remotely. So delete the remote branch first git push origin --delete bug/123 (assuming you use origin as name of your remote) then publish it after the rebase, or else the next time you git pull it will pull those commits back into your local branch.
🤗 Thanks for reading. Open to feedback and other tips!
Top comments (17)
As a beginner, isn't it better to learn the real commands instead of learning the aliases?
Your aliases are only available on machines with your git configuration. If you depend on aliases, you'll run into problems if they're not available (if you need to work on another machine, for example).
Also, look at switch to manage branches. Checkout has multiple responsibilities, which isn't a good thing. Switch and restore were created to split these responsibilities into their own commands.
Good aliases make it easy to remember the long hand versions:
Yep, that's really a problem with some git commands: they do too much and often unrelated things.
Correction: unless you were born in the 1980s or have taste 😂
But seriously though, (neo)vi(m) is a great editor and too many people form their opinion of it based on memes and having been stuck in it half a dozen times because
:q<enter>is honestly just too hard to remember.It's how I distinguish first class citizens in Linux from guests. They may be advanced guests, but guests.
And I should say that there is nothing bad with being guests for me. I'm the similar guest in Windows systems and cannot say that I'm also a First-Class Citizen in MacOS (though I'm much stronger there than in Windows. I was grown up from FreeBSD that is in roots of MacOS). So, it's okey. Each to their own...
Good tips! I would skip the recommendation about dprod alias it's not for beginners and matched to a specific workflow. One more updates, I'd make about rebase. it's more comfortable to use a commit's short hash for rebasing. If the branch has more than 10 commits it's become tricky to count amount of commits...
Anyway, well done!
Born in the 1980s to love vi? Ha ha, I was born in the 1960s and was weened on vi.
Your point remains a good one, vi sorta sucks really. It's just that some of us were weened on it. And I can't stand nano.
I go one better IMHO. I tend to use Atom 😉. Of course that's a GUI editor but I manage all my servers from a desktop machine, mounting drives with sshfs and using ssh to get a CLI on them, in which context I use vi because it's familiar but appreciate nano is much easier for newcomers. But as I said, I don't do a lot of text terminal editing, I tend to mount with sshfs and edit in my DE.
I'm more of an
ssh + tmux + neovimperson myself, butsshfsgo brrrrrEach to their own. But what does "go brrrr" mean? sshfs rocks. I can mount userdirs and root dirs in a jiffy and navigate them with a system explorer, edit with GUI editors, check logs with klogg and more ...
I hadn't even considered the idea of mounting local directories with different users; so far I've only really used it to open remote files on my office PC in GUI editors on the laptop I use when working from home.
Oh, I only use it for different users when I'm working on my servers. For security reasons, every server has a name, and a user name that is mnemonically linked to the server name. Root login is then disabled on the server, and that main server admin account is a sudoer. Thus I would often sshfs using that admin account less commonly as root for the whole filesystem (root login only permitted from the LAN with a sshkey not a password). To keep risks low with both my use and any possible mal-vectors I use the lower level of accounts when that's all I need and I make sure its in the right groups to read logs and such.
In my opinion, shortcuts (aka aliases) should be avoided by beginners.
At the beginning, pay attention to familiarize yourself with the original commands.
And use "a dog" association if you have hard time remembering:
git log --all --decorate --oneline --graphWhat's wrong with vi? ;)
I would recommend 'micro' instead of nano. It comes with human-friendly shortcuts like Ctrl+S and Ctrl+Q
First rule of git club, git gud'.
Or you can use ZSH git plugin and you get all those aliases stanradized and for free
github.com/ohmyzsh/ohmyzsh/blob/ma...
Great tips! Well done
For anyone interested in learning the basics of git here is a free eBook:
Free Introduction to Git and GitHub eBook
This is an open-source introduction to Git and GitHub guide that will help you learn the basics of version control and start using Git for your SysOps, DevOps, and Dev projects. No matter if you are a DevOps/SysOps engineer, developer, or just a Linux enthusiast, you can use Git to track your code changes and collaborate with other members of your team or open source maintainers.
The guide is suitable for anyone working as a developer, system administrator, or a DevOps engineer and wants to learn the basics of Git, GitHub and version control in general.
To download a copy of the eBook use one of the following links:
Dark mode
Light mode