How to Win Git and Influence Repositories: 15 Git Commands Every Engineer Needs by@dtolmachov

How to Win Git and Influence Repositories: 15 Git Commands Every Engineer Needs

tldt arrow
Read on Terminal Reader

Too Long; Didn't Read

Based on my own experience, let's summarise which top 15 commands each software engineer should know while using a version control system(VCS) based on Git.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - How to Win Git and Influence Repositories: 15 Git Commands Every Engineer Needs
Danylo Tolmachov HackerNoon profile picture


Danylo Tolmachov

Software expert with 10 YoE and a passion for technology...

react to story with heart

Without a version control system, it would be impossible to complete team/product development on time. As a result, I start all of the technical onboarding for the projects by explaining how this component operates and the regulations that are in place.

Many people encapsulate VCS with fancy GUIs (SourceTree, GitHub Desktop, Tortoise, etc.) or use them indirectly through their IDE. I’m definitely not against this, it is more pleasant and sometimes easier. That being said it is still important to understand how and what a given operation would accomplish.

Below, I try to list the commands that any engineer will encounter at some point in their career.

1. Clone

Most of the time, there’s a good chance that you would work on repositories that already exist. When this happens, understanding the operation of getting source code on your local machine named clone becomes important. It repeats the entire remote repository structure, complete with folders and files to a new directory named accordingly.

git clone [email protected]_provider:account/your_repo.git

Tips and Tricks (TnT). SSH is usually considered more secure when compared to the HTTPS way of cloning.

2. Status

This is a simple and straightforward command for getting the status of your current local branch. Compare it to the remote one to understand where you left it last time and whether there are any updates, uncommitted, or untracked changes.

git status

TnT. Useful commands when you’re not the only one working on the same branch. This could prevent possible conflicts in the future.

3. Log

The right way to check branch history is to look into the commit log list. Here you could find everything connected to commits: author, SHA, commit message, date, etc.

git log

TnT. A good way of tracking branch history and could provide helpful information for any sort of investigation during or after troubleshooting.

4. Diff

Command for showing the difference between branches/commits. Target it at the whole local directory or on a specific file.

git diff remote-branch

TnT. Good for making a quick check and for small changes, really hard to navigate and work with a huge discrepancy.

5. Fetch

Command for getting accessing all changes in the current branch or just in the repository. It will show you what branches were created and updated. It also gives information on you what happens in your repository.

git fetch

TnT. Extra information that would not hurt you and gives a better understanding of activity in a repository.

6. Merge

Put two commit histories from different branches together by creating an extra merge commit.

git merge other-branch

TnT. Sometimes it is much easier to merge through pull/merge requests.

7. Pull

Get all changes from the remote branch into your local one. You could imagine it as a command with two simple steps - fetch and merge.

git pull

TnT. Pull frequently when you are working in a team on the same code in the same branch.

8. Checkout

The essential command for moving forward and backward through your git tree, creating new branches, etc

git checkout other-branch

TnT. Use this command to travel in time.

9. Add / Rm

Adding and removing files for index. An index is the staged area of your next commit.

git add & git rm

TnT. Before adding or removing check files if all code from them is ready to be staged. Sometimes sneaky debug logs or comments that you do not expect to see in a commit could appear in files.

10. Commit

Make a snapshot of your staged changes to the git tree. Commit is your building block in your git tree.

git commit -m "Commit message with sense"

TnT. Commit messages must make sense. “Fix”, “check” and “log” would bring confusion to the person who would see them.

11. Tag

Instead of remembering long SHA with letters and numbers, it is much easier to make a tag with a user-friendly name.

git tag v.1.0.0

TnT. Good practice to make tags on stable states of your code. E.g. release version.

12. Push

Just sync your remote branch by sending your local one to it.

git push

TnT. Make a golden rule, push all your changes at least once a day.

13. Reset

Rewrite all your local state to provide one. E.g. Reset the current state of your branch to some specific tag.

git reset v.1.0.0

TnT. Check some options like soft/hard/mixed; they could be used for solving branch issues.

14. Rebase

Change the base branch/commit for your current one. It would reapply/recommit all diff commits on top of a base.

git rebase main

TnT. Always keep your current working branch up to date with the main one. My recommendation is to use rebase instead of merging main in current.

15. Revert

Rollbacks commit by creating new with opposite updates.

git revert commit-sha

TnT. Use it wisely. In many cases, it would make more sense just to make this revert manually.


This is not in any way a conclusive list. There are many more commands that contribute to a seamless experience. You can find some of them . Don’t shy away from learning something new, just find places to learn them from.

P.S. Article was inspired by the trainee which I am currently mentoring. Thank you for this idea


. . . comments & more!
Hackernoon hq - po box 2206, edwards, colorado 81632, usa