DEV Community

Cover image for 5 git tips for beginners
Olivier
Olivier

Posted on • Updated on

5 git tips for beginners

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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:
Image description
To this:

Image description

# Open interactive rebase with the last 6 commits
git rebase -i HEAD~6 
Enter fullscreen mode Exit fullscreen mode

That will open nano or vi with the ability to tell git what to do:
Image description

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!

Image description

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!

Discussion (18)

Collapse
cyberjack profile image
CyberJack

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.

Collapse
darkwiiplayer profile image
DarkWiiPlayer • Edited on

Good aliases make it easy to remember the long hand versions:

git config --global alias.dog 'log --decorate --oneline --graph'
Enter fullscreen mode Exit fullscreen mode

Checkout has multiple responsibilities, which isn't a good thing

Yep, that's really a problem with some git commands: they do too much and often unrelated things.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

Unless you where born in the 1980s you likely hate vi or vim editor

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.

Collapse
northbear profile image
northbear

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...

Collapse
northbear profile image
northbear

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!

Collapse
thumbone profile image
Bernd Wechner • Edited on

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.

Collapse
darkwiiplayer profile image
DarkWiiPlayer

I'm more of an ssh + tmux + neovim person myself, but sshfs go brrrrr

Collapse
thumbone profile image
Bernd Wechner

Each 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 ...

Thread Thread
darkwiiplayer profile image
DarkWiiPlayer

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.

Thread Thread
thumbone profile image
Bernd Wechner

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.

Collapse
elvisoric profile image
Elvis Oric

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 --graph

Collapse
harleendev profile image
Harleen 馃彸锔忊嶐煂

What's wrong with vi? ;)

Collapse
roneo profile image
Roneo.org

I would recommend 'micro' instead of nano. It comes with human-friendly shortcuts like Ctrl+S and Ctrl+Q

Collapse
sebbdk profile image
Sebastian Vargr • Edited on

First rule of git club, git gud'.

Collapse
ziker22 profile image
Zikitel22

Or you can use ZSH git plugin and you get all those aliases stanradized and for free
github.com/ohmyzsh/ohmyzsh/blob/ma...

Collapse
bobbyiliev profile image
Bobby Iliev

Great tips! Well done

For anyone interested in learning the basics of git here is a free eBook:

GitHub logo bobbyiliev / introduction-to-git-and-github-ebook

Free Introduction to Git and GitHub eBook

馃挕 Introduction to Git and GitHub

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.

馃殌 Download

To download a copy of the eBook use one of the following links:

馃摌 Chapters

Collapse
andrewbaisden profile image
Andrew Baisden

The more you use git the better you git 馃榿