Home / Blog / How to Git 101

How to Git 101

You know the basics of things, you’re not new to this. Clearly you need version control because you’ve been programming already. In that programming you’ve learnt the basics of how things work. So lets skip explaining the fluff—let’s just explain in short brief bursts the quick-and-dirty of what you need to know to get started.

The remote instructions here might work for a team of 2 or 3 where commits are very far apart. If your team is larger then this then they should already have a merging strategy in place. If they don’t, well that’s a future tutorial.

git init
git add .
git commit -m "Initial Commit"

3 lines of code — start a life time of good habits

What is Git?

Git is your saviour. It’s the best version control utility for your code or anything else you find using text files for. Period. Get using it.

Why version control?

Seriously? Codes all working beutiful—what a happy life. It’s 3am and you have this idea for an awesome feature, 5am comes and you’re all done… you put it live. Theres a panic in the morning, you’re still in bed though. How does anyone know whats caused such horrendous changes? Lucky for you… they don’t know who to blame!

Save yourself the hassles

Staging V Unstaging

In a standard git flow you have Staging and Unstaging areas. Staging is everything that will commit when you type git commit. Everything in unstaging—well you guessed it—is what will not commit.

You can split up a bulk lot of work by adding individual files to your staging area then committing. The work done in your unstaging will not be touched and still be there after you have committed

You can see this using the command git status

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   lib/test.php

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	lib/test.rb

As you can see, I have lib/test.php staged, and lib/test.rb unstaged. Only lib/test.php will be commited on git commit

Basic housekeeping

When you make a commit, it saves your name and email address against it. It has to get that from somewhere…

# Set it globaly like 99% of other people
git config --global user.name "Full Name"
git config --global user.email "[email protected]"

# Change it for single repository if you're being a secret squirrel
git config user.name "Full Name"
git config user.email "[email protected]"

If you want to see what they are just drop the value: git config user.name

Initialize a git repo

If you haven’t used git in a repo already, you’ll have to initialise it first.

git init

Add everything and commit

just incase you didn’t pick it up from the home page

git add .
git commit -m "Your message"

Specify files to add

Every now and again, like most times actually, you’ll be adding individual files to your staging area ready for commiting. These are the basic commands you’ll use to add files there.

# Add a single file
git add directory/filename

# Add everything in a directory
git add directory/

# Add only certain file types
it add directory/*.rb

git commit -m "Your message"

Unstage a file

Staged a file by accident? Or like most times you did git add . but decided there was one file you didnt want? Well we got you covered there.

# If file already existed and is staged
git reset directory/filename

# If file didn't already exist but you want to keep it
git rm --cached directory/filename

Undo changes to a file and put it back to what it was before you started

If you’ve done all you can to fix a file but can’t work out what you did to break it? Just check it out from your git repo again and move on :)

# Checkout from last commit
git checkout directory/filename

# Checkout a file from a specific commit
git checkout f6b8a83d8e4d9d89510072b25febf9e9b40b8558 filename

# Checkout a whole dam commit
git checkout f6b8a83d8e4d9d89510072b25febf9e9b40b8558

See a list of git commits

Made a few commits by now and want to see the list of commits?

Take note of the commit hash when looking at this

git log

See current changes

Want to see the changes you’ve made since the last commit?

## See all changes
git diff

# See changes of specific file
git diff directory/filename

# See every change back until a certain commit; notice the lack of ^!
git diff f6b8a83d8e4d9d89510072b25febf9e9b40b8558

See the changes made on a specific commit

Remember that commit hash from git log? We will use that now to see the changes that were made on that commit.

# View a single commit changes
git diff 83a2fa00cf1135fbf824c2a6ffa7dafcebf9c2c2^!

# or even easier
git show 83a2fa00cf1135fbf824c2a6ffa7dafcebf9c2c2

# View the changes between a few commits; will show everything between the two.
git diff 83a2fa00cf1135fbf824c2a6ffa7dafcebf9c2c2 f6b8a83d8e4d9d89510072b25febf9e9b40b8558

Branches

If you haven’t noticed by now—all your work is done on a branch and you’ve been on master the whole time. Occassionally you’ll want to make life changing alterations to your code, and you wanna keep it out of master incase things go way to bad. Or simply multiple people are working on the code repository and you’re going to need a few commits to get it right and tested before releasing to master.

This is where branches comes in. You create a new branch, which starts at the current commit your on with git checkout -b branch-name. It’s then diverged from master at the commit you issued the checkout command on. You can then safely work on this branch without effecting master. If you want to work on master a bit more, commit all your changes on the branch your working on normally; as above, it already knows your current branch—then type git checkout master and you’ll be back to master. You can safely make changes on master without effecting your branch.

You’ve now got a tree

When you branch, your code history starts making a tree showing your diversions. Have a look at it by typing git log --graph --oneline --all

Joining the two branches

When your branch is finished, you’ll want to eventually bring it back into master. Or maybe you want to make it have any new changes on master so you can test. To do this you will either rebase or merge, depending on how much it varried and how much you care about your git’s tree looks

Rebasing

git rebase master

When you do this, it rewinds your HEAD—the current commit your branch is pointing to—all the way back to where you diverge from master. It then moves your head to master and starts applying all your commits onto each new commit made on master. You’ll then have to resolve any commits that didn’t allign correctly if it was pretty far out. It’ll tell you which files these are. Open the file and you’ll find some text around the offending changes on which you’ll have to resolve.

When you have resolved the conflicts, you then do git rebase --continue to continue rebasing… atleast until the next conflict. If your rebase was way to far out and you just can’t continue anymore then git rebase --abort be your friend.

Rebasing is good if you want to make your tree truly represent how it got to it’s current state, including the changes done in your alternate branch. It can get very laborious though if your branch and master diverge quite differently.

Generally if master is over 5 commits out I start considering a merge instead. Once you have rebased, you will need to merge it to master.

You guessed it: Yes you can rebase one branch on another, just substitute master.

Merging

git checkout -b new-branch
# ... do some work!
git checkout master
git merge new-branch

Git merging is more straight forward. It collects all your changes you made on your feature branch—after diverging from master. It then, in 1 commit, applies them to master. You may have to resolve any conflicts, but you’ll only have to do it once.

It’s important to note that when you merge you lose the commit history of the branch you’re merging in. Some see this as a benefit, as the branch is more a draft and the final commit is the only thing you want recorded. Make sure you keep such things isolate, as it’s going to be hard to rollback to certain points in that change later.

Working with others

Occassionaly… like you were forced to at UNI… You’re going to have to work with others.

git clone giturl

The above command gets you the repository from the remote host and copies it to your machine with full history any branches. If you don’t specify a folder it’ll create a folder with the last /name part of the url

If you’ve been coding for days on a new project, then need to push it to a local repository that has just been created, then you need to set the remote url.

git remote add origin giturl
git push origin master

Pushing your changes

In an ideal world, you’ll always write your code on a seperate branch. If it’s not ready to push into master yet and you want to save it for safe keeping. Just do:

git push origin branch

Though sometimes your commits are super small, or you are ready to push to master. The first stage is to pull the current master.

git pull origin master

Resolve any conflicts, then commit your work or merge your branch onto master, then type:

git push origin master

It will refuse you if someone else pushed changes before you that aren’t included in your tree.

TLDR;

Go back and read it, it’s not too long…

You should be ready to git now.