Published on 10/2/2021
Permalink: https://marcoslooten.com/blog/10-quick-git-command-line-tips/
First, let get this out of the way: I don't think using the command line is better than using a GUI for git (like Tower, SourceTree, gitKraken, github Desktop, etc). I personally do find it easier, because I always have a terminal window open in my editor (VSCode). Once I memorized just a few commands, I felt like the workflow was quicker with less friction (not having to switch applications). If you want to give it a try, I'd say the following commands are enough for most daily use cases!
From the source code directory, you can add files to be staged (staged filed will be included in your commit):
git add .
If you just want to add a specific folder or file you can do so as well:
git add path/to/myFolder
git add path/to/myFile.ts
Pro tip: use tab while typing to autocomplete directory and file names.
Once you've staged your changes with git add
, it's time to create a commit. Simple use the following:
git commit -m "Your message"
Adding a message is recommended. Writing a good message is hard, but makes it much easier down the line and for your team members to understand what is going on. I like the approach of finishing the sentence: 'Once merged, this commit will...'. So my commit message may look like this: 'Add the datepicker component to the homepage'. In many teams, it's expected that you will also add the (Jira) ticket number as a prefix in the message.
Once you've done the previous step, don't forget to push. Sometimes people forget, but then there's no backup for your code if your laptop crashes and coworkers cannot checkout your code (say if you're ill, on holiday or if they just want to collaborate). Pushing is easy.
git push
Use git fetch
to make sure you're up to date. That way, your local git knows what branches and commits there are.
Switching branches can be done with:
git checkout branch-name
Again, you can use the tab key for autocomplete on the branch name!
Very similar to the previous command, this one adds a flag to create a new branch:
git checkout -b branch-name
If you're working on a branch, and need to switch to another branch, you can save your work easily. Of course you can commit, but sometimes it's a work in progress that you don't want to commit. Then you can use stash:
git stash
When you're back on the relevant branch and want to have that code available again, use the following:
git stash apply
If you're working on a feature, sometimes the development branch gets updated. It's good practice to often merge that in to prevent large conflicts. You can use the following syntax:
git merge origin/branch-name
An often made mistake is replacing the slash with a space. It will not return an error, but it will not merge the branch you want (instead it will merge the default branch). So always use a slash between 'origin' and the branch name.
If there are conflicts, you can manually fix them in the conflicted files and then add & commit them. After that, you should be good to go.
Say you've created a new branch locally that doesn't exist in the remote yet, git will show an error when you try to push. They suggest to use the following syntax: git push --set-upstream origin branch-name
, but there's a shorthand available:
git push -u origin branch-name
It's like turning back time to that specific point in history. Just a week ago I needed to check out some commits, because something was broken but we didn't really know the cause. After checking a few commits I found the culprit. It's also very useful if you have a couple commits that you want to disregard. The syntax is:
git checkout hash
Every commit has a hash, that's the alphanumeric string that belongs to it. For instance, something like b8f5439. You can view them with git log
or in your repository web page.
Using these commands (not even 10 if you just count the 'base' commands without the flags or parameters) you can absolutely do all daily git tasks. This is all I use on a daily basis and I can confidently say that for about 99% of the cases, this is enough. In the odd case that there's something more complex going on, I can always google git commands or open a git UI program.