loading...
Cover image for 6 Git commands every beginner should memorize

6 Git commands every beginner should memorize

jeremy profile image Jeremy Schuurmans Updated on ・4 min read

For people new to Git, it can be confusing and intimidating. If that's you, here are six Git commands for your toolbox. With these, you can become productive with Git and lay a solid foundation for your future Git mastery. Code along with these in order and learn them all!

Just a quick side note: this post is intended to be a quick, accessible breakdown of some of the most common Git commands I use every day, which were also the ones I had to look up most often when I was learning Git. Since it’s geared toward people who are just getting into Git, all my examples are trying to help people get practice using Git locally. I’ll save any discussion about remote repositories like GitHub and commands that interact with it for another post.

My hope is that this will reduce the time it takes for someone new to Git to become productive with it.

It will be most useful to you if you already have a basic understanding of what Git is, a concept of how the Git workflow works (branching, merging, etc.), some command line knowledge, and have Git installed and configured on your system.

I use Ruby in all my examples.

1. git init

git init is how you add Git to your project.

  • open your terminal, and create a new directory. I keep all my code-related files in a code folder, so I'll put it there. You can put it wherever you like. mkdir code/practice

mkdir code/practice

  • change to your newly created directory. cd code/practice

cd code/practice

  • create a new project directory named 'git-practice'. mkdir git-practice

  • cd into it. cd git-practice

  • run git init

mkdir git-practice, then cd git-practice, then git init

this will create an empty Git repository, a .git directory inside your project directory.

2. git status

git status lets you see the current state of your files.

  • create a file called "git_practice.rb". touch git_practice.rb

  • run git status. Git will tell you that you are on the master branch, you have not made any commits, and it will list all untracked files you have, in this case, we only have one, git_practice.rb.

touch git_practice.rb, then git status

3. git add

git add is how you start tracking individual files.

  • run git add . adding the space + . tells Git to add all files. You can also add individual files by running git add <filename>. This can be useful if you're ever in a situation where you want to add certain files in one commit, and other files in a different commit.

git add .

If you run git status now, it'll show you changes ready to be committed, in this case, that we created a new file.

4. git commit

git commit creates a new commit.

  • run git commit -m (the -m stands for message), and write "first commit" in quotation marks. git commit -m "first commit"

git commit -m 'first commit'

5. git checkout

You use git checkout to switch between branches.

Note: For convenience, you can abbreviate it to git co I'll use this example for the rest of this post, but you can just as easily skip this and stick with git checkout instead. To use git co you need to set that as an alias for checkout in your .gitconfig file. This file is responsible for your global Git configuration, and lives in your system's home directory, not in your project directory. You can easily set an alias using the command line. To set co as an alias for checkout run

git config --global alias.co checkout

This will create a line in your .gitconfig that looks like this:

alias co = checkout

If you like, you can alias all these other commands too. For example, if you want to set git st as an alias for git status, you would alter the above command with alias.st status where st is your alias, and status is the command you're aliasing. Feel free to play around with it.

Now instead of git checkout you can run git co If you add the -b option, it will both create a new branch and switch to it at the same time. You can name your branches whatever you like, but descriptive names are best, like so: git co -b add-example-code

  • running that command will create and switch to a branch called add-example-code.

git co -b add-example-code

  • open git_practice.rb in your text editor of choice.

  • add some code. Let's go with puts 'Hello World!' Save the file.

  • let's run git status again to see what happened. Again, it'll show you what branch you're on, and what changes you made that aren't staged for committing yet. In this case, that we modified git_practice.rb.

git status

  • add and commit this file. git add . then git commit -m "add hello world"

git add ., then git commit -m 'add hello world'

6. git merge

You use git merge to integrate your branch with the master branch.

  • switch to master. git co master

  • run git merge add-example-code. This will integrate our add-example-code branch with master, so now all changes made in the branch are present in master.

git co master, then git merge add-example-code

With these commands you will be well on your way to productivity with Git.

We're barely scratching the surface, however. Many good, in-depth resources for learning Git can be found here.

Posted on by:

jeremy profile

Jeremy Schuurmans

@jeremy

I love writing clean, simple code, and writing about code. I love building things that make people smile. I like computers, Ruby, people, music, and books.

Discussion

markdown guide
 

Don't forget about:

git push origin master --force
:)
 

and

git pull origin master
git reset --hard
git stash
git stash pop

merging into master should be done via pull request imho

 
 

You can appreciate the joke as an experienced developer in git, that knows the implications of using it, but we need to be careful when trying to make jokes for the ones that don't get the context of it, specially when the article is targeting beginners.

I thought it was pretty funny myself, but you also make a good point. Thank you for bringing it up!

I agree, hence my acknowledgement of the joke for what it is.

 

This is a very bad advice, and should be never used, not even in solo projects, because you get into a bad habit that can have pretty nasty consequences in a professional environment, like Jenkin developers accidentally do "git push --force" to over 150 repos on github.

I don't have the link anymore, but I read a story once of a company that took months to recover from a git push --force to their master branch.

To be on the safe side ALWAYS configure your Github, Gitlab or whatever you use to not accept push to master.

 
git push upstream master --force

Cause you are on forked repo

 
 

You forgot the most important of all git checkout -:

╭─exadra37@approov ~/Developer/Approov2/blog/shipfast-on-docker  ‹approov2-new-rebased› 
╰─➤  git checkout -
Switched to branch 'approov2-new'
╭─exadra37@approov ~/Developer/Approov2/blog/shipfast-on-docker  ‹approov2-new› 
╰─➤  git checkout -
Switched to branch 'approov2-new-rebased'

It's just like our old Linux friend cd - ;)

Ok, the above one is more a tip, but a very important command to know about for beginners is git stash --help and git show --help

With git stash we can save our changes that are not commited yet, and if we include -u we will save also the files not tracked. It's useful to clear the workspace or to move code not committed yet to another branch or just to later reuse on the same branch, just by doing git stash apply.

With git show we can see the git diff for the last commit, and with git show <commit-hash> or git show HEAD~3 we see the git diff for that specific point in history.

When things go terrible wrong, like you delete accidentally a branch, you can use git reflog --help to see your history of changes and get back to a good state.

 

Very useful tips.Thanks a lot, especially for the idea to use git stash apply

 

Agreed! These are awesome tips. Thank you!

 

git 2.23 introduced git switch for switching branches.

More info is available here

 

You mention you could shorten git checkout to git co, but you never explain how to configure that alias.

 

Good catch! Thank you -- it completely slipped my mind, which is unfortunate. I just edited the post with instructions on how to do it.

 

Extend it to 10 and add git rebase, cherry-pick, push, fetch

 

I feel like git clean would be a good one toio

 

Thanks to everyone in this thread for the responses! These are some really great tips.