Nowadays almost every software engineer is using Git as a version control system for their projects. There are a lot of GUI apps for working with Git, also integrations with IDEs and text editors. I know engineers that are using Git only from their IDE. But no matter what, one day you have to use Git from the command line.
When I started using Git the first time I used it from the command line and at the beginning, I felt like a cool engineer working with the terminal. So I decided to stick with this approach as usually from IDE it's not possible to do everything that Git is capable of. Maybe a more realistic reason is that I never worked with rich IDEs with support for Git. Although nowadays I use VSCode and sometimes I reach its integration with Git.
This is not a beginner guide on how to use Git, it's just my daily use of it. If you are using Git from the command line or trying to switch from GUI to the command line some of these tips may be helpful for you.
Usually when I open a project first thing that I do is looking into Git history to see what was done and where I am in the commits history.
Git doesn't have a beautiful way to show the history and many engineers that I know are using GUI to see a clear picture of the history.
But if you don't use Merge commits even a simple
git log is clear to understand.
My command for showing Git history is:
git log --oneline --all --graph
You can look at what all these arguments do at git-log docs. Basically, it prints the history in this format:
I can see my current location
HEAD, also local and remote branches.
git log --oneline --all --graph almost every time with other commands that I use.
Of course, typing
git log --oneline --all --graph every time takes a lot of time.
For these cases, people usually set Git Aliases.
But this means that you need to configure aliases on every new machine that you work on. You may use dotfiles.
I got used to doing a search using Ctrl + R where I type
git log --oneline --all --graph appears as a last used command.
I also use Ctrl + R for any other long command that I need again, so you may consider Ctrl + R over Git Aliases.
When I start a new task and need to get the latest changes from
master I do:
git checkout master # switch to master branch git fetch origin master # updating origin/master branch git reset --hard origin/master # reset local (master) branch to much origin/master
I know people that do:
git checkout master # switch to master branch git pull origin master # does git fetch + git merge
But I almost never run this command because I don't want to resolve any conflicts while merging and I don't care about changes in local
Sometimes I may run
git pull -r origin master which does
git rebase instead of
git merge because I don't like Merge commits.
When working on a new task I create a new branch with:
git checkout -b feat/4605-new-function
In the name of the branch I follow this format
<type of task>/<number of ticket>-<short description>.
When I am ready to commit a change in the repo, I add my changes to stage phase using:
git add -A
I know that some people are using
git add . but this command stages only the file from the current folder,
so with you run this command in a child folder changes from the parent folder will be not staged for commit.
|Command||New Files||Modified Files||Deleted Files||Description|
||✔️||✔️||✔️||Stage all (new, modified, deleted) files|
||✔️||✔️||✔️||Stage all (new, modified, deleted) files in current folder|
More info here.
When committing I use:
git commit -m "feat: add new function"
If I need to make a change to the previous commit I change the files and run:
git add -A git commit --amend --no-edit --no-verify
--no-edit if I want the message to stay the same and
--no-verify if I am sure of the change and don't want to wait for a long pre-commit check to run.
All this using Ctrl + R command to search for
ame text (contains in
If I need to move between branches and have an unfinished work, I run:
git add -A git stash git checkout other-branch # do some work on that branch git checkout wip-branch # come back git stash pop # applies and remove changes from stash stack
If I only need to apply the stash:
git stash apply
But once in a week or so, I clear my stash with:
git stash drop
When I have done some dummy changes and I want to flush every unneeded change I run:
git reset --hard HEAD
Before pushing, I check if there are no changes on the remote
master. If the
origin/master branch was updated I need to rebase on the new changes.
git fetch git log --oneline --all --graph # inspect any changes, mental preparation for any rebase conflicts git rebase origin master git push -u origin feat/4605-new-function
Also, I may change the history of the current branch using:
git rebase -i # Let you edit the history (changing messaging, squashing, ...)
Sometimes I have rebase use cases where I need to use a powerful option of rebase command.
Let's say that I finished a task on branch
topicA and created a new branch with commits for
. H---I---J topicB / E---F---G topicA / A---B---C---D master
Then I realize that
topicB doesn't rely on changes from
topicA and I should have started it from
git rebase master will not change anything because
topicB is based on
topicA which itself is based on
topicB to start from
master I run:
git rebase --onto master topicA topicB
topicB is optional if I am already being on
. H'--I'--J' topicB / | E---F---G topicA |/ A---B---C---D master
I remember corect command order by
git rebase --onto <new base> <old base>
More about Git rebase.
To remove old "red" branches.
git remote prune origin # add -n for dry run
More options here.
I don't use
git merge that often because I am more used to
git rebase, but then I need I always use
git merge --ff-only to not create a Merge commit.
I used several times
git bisect to find bugs in a 40 commits range history.
git reflog to recover some changes from wrong hard resets or rebases.
I am not that good at Git as I wish I was but I know enough to resolve almost any git related problems. I have friends that use Git in IDE and sometimes they ask me to help to solve a Git use case. Also I now enough to search and understand any solution for a new Git use case that I encounter.
I will update this post with new changes to my Git usage. Let me know what other commands do you use often!