Crash Course - Commits and Branches

Here is a 15 step crash course covering all the basics. It was based on the video here:

Step 1

Create a new empty repository in any folder by navigating to that folder and typing

git init

Step 2

Tell git to start tracking files by adding them to the repository

git add .

This "stages" the changes. Staging is the process of choosing what changes you want to include in a given commit. If you are familiar with Hg, this is equivalent to selecting/deselecting files prior to committing.

Step 3

Check on the status of the local folder, and git, by typing

git status

Step 4

Commit the staged changes to the repository by doing 

git commit -a -m "Adding new function"
git push

The -m flag gives the commit a name. If you don't use this flag, you'll enter an annoying vim editor to enter a message.

Step 5

Check what branch you're on by typing 

git branch

New repositories will only have 1 branch, the "master" branch.

Step 6

Have a look at the history by typing 

git log

This enters you into a menu where you can scroll up and down and you can see all the commits you've made. Each one has a GUID, and the associated commit message. Exit the menu by entering "q".

Step 7

Have a look at the last commit. You will see the text  next to this commit. This means the HEAD (=my current working directory?) reflects this commit, and that this is the last commit in the master branch.

Step 8

Go back to a previous commit by typing 

git checkout 7ab3017ab4cfeb3e22a32e7bf2058e65d7418b3e

where "7ab3017ab4cfeb3e22a32e7bf2058e65d7418b3e" is the GUID of the commit that you want to go back to. This moves the HEAD to this commit. When the HEAD is not pointing at the last commit in a branch, you are in a so-called "detached head" state. This is convenient for having a poke around, but since this commit isn't the last in any branch, the repository can't track any changes you make from this point. Running "git log" here shows  meaning that the HEAD is looking at this commit, but without  it means this is not the last commit on the master branch. If you want to actually resume working from that old commit, then there are a couple of ways to do that. These are discussed in the following steps.

Step 9 "git reset --hard"

If you want to rewind the current branch to a previous commit and abandon the subsequent commits, you can do that by 

git reset --hard 7ab3017ab4cfeb3e22a32e7bf2058e65d7418b3e

This will wind back the branch to the commit you specify, and delete the future ones. BE CAREFUL WITH THIS. IT IS PERMANENT!

Step 10 "git checkout -- ."

If you have some changes in your project, but they are not yet staged, you can revert back to the previous commit by this

git checkout -- .

Step 11

If you want to start working on some new experimental feature in parallel to main development, you can create a new branch in your repository. Do this by typing

git checkout -b name-of-my-new-branch

This will create the branch. It will also check it out, so subsequent staging and commits will happen on that branch. You can see a list of all the branches by typing

git branch

and the one you are working on will be highlighted.

Step 12

Switching between branches is done by using the checkout command

git checkout name-of-my-new-branch
git checkout master

Step 13

To merge changes from one branch (say "name-of-my-new-branch") into another (say "master") checkout the destination branch (in this case "master") and then type 

git merge name-of-my-new-branch

When you do this, the changes in your feature branch will be brought into the master, and there will be a new commit (a new head) on the master.

Step 14

The above merge doesn't change the feature branch at all. The feature branch still exists, and its last commit is the same as it was before merging. Once you are satisfied that you have what you need from the feature branch, you may want to actually delete it from the repository so that you don't end up with millions of branches in your repo. Do that by 

git branch -D name-of-my-new-branch

Step 15

If you have conflicting changes on both branches, they may not be automatically merged. Trying to merge as in Step 13 could generate an error like "CONFLICT (content): Merge conflict in my-file.txt". In response to this, some IDEs may jump in and try to help you resolve the conflict. Basically when you've sorted out what you want in the conflicting files, save the files, stage the changes, and then commit them, and that's it.

git add .
git commit -m "merge resolved"