loading...
Cover image for Git cheatsheet for beginners

Git cheatsheet for beginners

duomly profile image Duomly Updated on ・5 min read

This article was originally published at Git cheatsheet


Git is a very useful skill to have and almost necessary in many companies. Browsing job offers for software engineers, you many realize that knowing git is nearly as important as knowing an actual programming language. But still many people forget to check out how git works and what commands are responsible for what action.

When some time ago, I created a simple Git and Github tutorial for Youtube, I noticed how many people were interested in this topic.

This is why today, I decided to create a simple cheat sheet with the basic git commands which you can take a look at and use whenever you’ve just forgotten what you have to put inside the command line or need to refresh your memory. Also, I would like to go through some basic terms every developer should know to understand git-flow.

In the end, I will also tell you about the GUIs for git, which I used some time ago or use right now and which I really like because of their simplicity.

If you don't know how to set up a git repository, check out our Youtube tutorial.

Let’s start!

A few basic terms which help to understand git commands

repository keeps all your project's files, including commits and branches.

branch is a copy of the repository holding the specific version. The main branch in git is master.

commit may be imagined as a single save of changes to the specific branch.

checkout is the operation of switching between the current branch and the one specified in the command.

master is the main branch of the repository.

merge is an action that adds changes from one branch to another.

fork is a copy of the repository.

head is the most recent commit of the repository you work with.

Basic git commands everyone should know

git init | git init [folder]

Git init is used to initialize an empty repository from the folder you are currently using this command or using folder path, both ways are correct. It’s used while starting a new project or if you want to initialize the git repo inside the existing project.

git clone [repo URL] [folder]

Git clone is used to copy the existing repository to the specified folder on your computer. Git clone can be used only with repo URL as a parameter, then it will copy the repository to the folder from where you used the command. If you want to copy the repository to a different location on your computer, add a folder path as a second parameter.

git add [directory | file]

Git add stage all changes in the directory or in the file, and it depends on what you add as a parameter. In most cases, it's followed by git commit and git push commands.

git commit -m "[message]"

This command is used to commit all staged changes with the custom message passed as a string. By changing -m parameter to -am it's possible to add and commit changes at once.

git push

This is the command, which pushes changes to the origin branch.

git status

Git status is used to check the status of the modified files and it shows which files are staged, unstaged, and untracked.

git log

Git log is used to display the history of the commit in the default format.

git diff

Git diff shows all unstaged differences between the index and the current directory. This command can be used with -staged to display differences between staging files and the most recent versions. And another option is to use the command with the file name to display differences between the file and in the last commit.

git pull

Git pull is used to get changes from the original branch, and it merges the changes into the local branch.

git fetch

This command retrieves the most recent changes from the origin branch but doesn't merge.

Git branch commands

git branch

This command displays the list of all branches in the repository. It can also create a non-existing branch if you add a branch name as a parameter.

git branch -d [branchname]

Using -d flag will delete the branch with the specified branch name.

git checkout [branchname]

This command switch to the branch named [branchnamed]. If you add -b flag before branch name, it will checkout to a new branch, which will be created automatically.

git merge [branchname]

It merges the branch with the specified branch name to the current branch.

Git undoing changes commands

git revert [commit]

This command creates a new commit that undoes changes made in the specified commit and applies it to the current branch.

git reset [filename]

It remotes specifies a file from the staging and leaves the working directory unchanged.

Git config commands

git config -global user.email [user_email]

git config -global user.name [user_name]

The commands above are used to set current user email and name configuration.

git config --global --edit

And this command is very useful, as it allows for editing user configuration in a text editor.

Git GUIs

Not everyone likes to use git in the command line. It's very easy to make a mistake there, which will take some time to revert it. That's why GUIs for git become very popular. Let's check a few of them.

Sourcetree


Duomly - Programming Online Courses

Sourcetree is a git GUI which is available for Mac and Windows, and it's free. I really like it's UI, and it makes using git much easier for me, as I can see all the changes very clearly.

Tower


Duomly - Programming Online Courses

Tower is another great tool that makes using git nice and easy. It's also available for both Mac and Windows, but this one is not free. I had a chance to use it, they have a trial option, so everyone can try this software and check all its advantages.

Github Desktop


Duomly - Programming Online Courses

Github Desktop is another competitive tool, allowing us to use git in a nice and user-friendly way. It's also available for both Mac and Windows. Also, it's an open-source app, and it's free to use.

Conclusion

In this article, I went through the most basic git commands to keep it in one place and make it easy for you to check it and use it. Also, I listed a few terms which understanding may be very helpful to understand what's happening behind some of the commands. In the end, I've presented three GUIs that I had an opportunity to use. In my opinion, using git GUI may be very helpful, especially for junior programmers, who don't feel comfortable width command line yet and for those who like to have an easier and more visible way of working with git.

If you would like to learn how to create your first git repository in Github, check out this Youtube video, where I also share some information about git GUIs.

Have a nice coding!


Duomly - Programming Online Courses

Thank you for reading,
Anna from Duomly

Posted on by:

duomly profile

Duomly

@duomly

We believe everyone can learn how to code, so we are making learning fun and easy!

Discussion

markdown guide
 

I would like to disagree that writing git commands in the command line is hard. On the contrary, using commands is as easy as ABC especially when you have the "cheatsheet". If you want to understand git, use the command line and start to visualize the process in your head, not with UI.

 

While GUI might be easier, it does have learning curve as well.

I really recommend simply -- VSCode, PyCharm, IntelliJ, Android Studio, or WebStorm... That is, your GUI-based Text Editor / IDE.

 

I do command line mostly as well, but for beginners it can be a bit more difficult than just use GUI.

 

"head is the most recent commit of the repository you work with."

Even if it's for beginner and you need simplification. It's far from what HEAD really is.

Maybe you can forget what it is for beginners or you can just say "It's where you are currently". ;)

 

It's where you are currently

Yup!

And on that note, in my personal experience, commits and branching become much easier to understand and visualize once you think of your commit history as a linked list, and HEAD as a pointer that you can position at will.

In fact, this is hinted at in the syntax of git log: HEAD -> master, where HEAD is quite literally pointing to master (assuming that's where we are atm).

Also, I agree: We shouldn't make things simpler for beginners, even if it means they may initially be confused. It's part of the learning process!

 

IMHO the best way to demystify what HEAD is, is to go inside the .git folder.
After that you go to the refs folder and you can explain the branches ;)

head-ref

Personally I understood many things by watching inside this .git folder.

I didn't mention that, but your article is nice. I will send it to my students :)

 

I wrote this one about 1 years ago now -- github.com/patarapolw/SimpleGit

Actually, I have tried GitHub Desktop before, but I uninstalled.

Now I using only VSCode (Visual Studio Code). I can help with some GUI. People could probably do the same in PyCharm or WebStorm or IntelliJ-based.

 

Nice, useful article.
Cheat sheets are not just for beginners even if that is their focus. It's always a good idea to have quick references. Especially, with my failing memory as I get older & all the different languages I know with various syntax it's hard for me to keep together. What I find for me is I don't try to remember every little detail right away; I keep quick referencing until I know it so well I no longer need to unless I haven't done it in a few years.

 

While this may be "very basic" introduction, it is confusing. Nothing is explained in detail on how things work and relate to each other.
After reading this article you might be able to manage a single repository of configuration files on your own computer, that's it. For a software developer part of a team this is simply not even a start.

In a company with a team of SW developers you:

  • use git flow to work on features and bugs with many branches like: features, develop, release, hotfixes in addition to master
  • amend commits to update it
  • work with remotes to fetch/push/pull your code
  • work with tags for versioning
  • use .gitignore to exclude files/folders from index
  • merge or rebase changes onto different branches while resolving conflicts in the process
  • as a maintainer merge or cherry-pick commits from pull requests
  • use submodules for dependencies and checkout recursively, committing to superproject as well
  • use pre- and post- hooks to integrate with CICD pipeline
  • stash/shelve push/pop to save uncommitted changes while switching branches
  • using bisect to find bugs
  • using blame to find changes/bugs
  • using git reset/clean to revert mistakes
  • etc., etc. Each of these operations changes in some way your local or remote repository or some of the refs or files in working tree or your index. Make a mistake and you either lose your important changes or overwrite someone else's code with its history making it disappear forever. (unless you're lucky and can extract commits using git's reflog).

I just named about 30 new terms you need to know how to use, know all of their command line parameters and be aware what changes they do to your refs, files, index, branch or repository.

Confused? No wonder. Git has so many commands, terms and parameters that you can generate random legit looking git man pages without noticing that they are nonsense jokes. Just have a look at this "Git random man page generator" git-man-page-generator.lokaltog.net/

 

I have one important problem on Git CLI on macOS...

How do I change the default text editor? I am too bad at vi. Wanna change it to Nano or Code or something.

Otherwise, I will need vi cheatsheet as well, even when productivity doesn't matter.

 

You can setup default editor in the .bash_profile or .zshrc file in your users profile :)

 

Thanks, found it. A better way, actually.

git config --global core.editor "nano"

And, git config --global --edit, of course.

 

Great one - i would recommend to add the word „locally“ at the description for the branch delete command with the small „-d“.

 

Thanks for doing this! I was about start writing something similar. I want add to GUI list something useful I used to work with every day Git Graph extension

 

I've been using Git for about 10 years and started using GUIs early on. I started going command line only as of 6 months ago and love it because you really learn the underpinnings of Git which is abstracted away by most Git GUIs.

Great article.

 

Thanks for the cheatsheet but what theme is in the header cover?

 

Some modified monokai or flat material.

 
 

Very use full. Thanks for writing.

 

I stopped reading here:
"repository keeps all your project's files, including commits and branches.

branch is a copy of the repository ..."

So the repository holds copies of itself?

 

I would say yes, without going deep into "how git works inside", when you create a new branch, you create a new version, something like copy of code from the branch which is the parent for your new branch.

 

A copy of a branch, yes. But not a copy of the whole repository (which would be impossible, since copying the whole repository into itself would be subject to recursion).

en.wikipedia.org/wiki/Russell%27s_...

 
 

I actually like using VSC with Git Lense etc - vs like sourcetree etc..

 

Great one. This will certainly help beginners!

 

If someone is interested, I automated some of the git commands on my automation repository and this is great!