Some Git tutorial
Who is this tutorial for?
This tutorial is for those who do not know git and wish to learn the basics of it.
Objective
After this tutorial you should have rough understanding of how git works and be able to use tools related to git.
What is used in the tutorial?
- Bitbucket to host our repositories
- Git Bash for windows (CLI)
- SourceTree (GUI)
Terminology
- Repository — Essentially the project folder
- CLI — Command Line Interface, basically working in the command prompt / terminal
- GUI — Graphical User Interface, a interface that uses visual elements, e.g. browser
Why use Git?
Git is used for its version control and team collaboration on a project. A team of developers can work together on the same project folder by utilising git. If any member or even the whole team loses the whole project folder, they would still have a copy of it remotely which they can continue from the latest version in that remote repository.
Tutorial start
Bitbucket
Bitbucket account
Firstly, we would require a Bitbucket account, so if you have yet to create an account there, please do so before proceeding.

Create a Bitbucket repository
Login to Bitbucket and create a repository.

You can name the repository whatever you want.

You would see something similar to this

Installing Git Bash on Windows
TIP
If you are on macOS and have HomeBrew installed, you can do brew install git
to get git command line
Download Git Bash
Go over to git scm downloads to get Git Bash for windows
Git bash setup
The setup process will look something like the following pictures









Git with Git Bash
Now we will take a look at how to do git in CLI using Git Bash
Git Bash window
This is the CLI of git

Basic commands
The ls
command list all the items in the current directory you are in. For me it is listing the directory where Git Bash is installed in.

The cd
command stands for 'Change Directory' and ~
in this context means your home folder. Thus cd ~
means change the directory to your home folder.

So let's do cd ~
to see what's in your home folder

Let's create a Project folder to organise our work

Change directory into Projects

We will create a folder that will connect to the repo on Bitbucket
TIP
Note the \
before spaces, without it you will create multiple folders instead.

Now we will initialise git in our folder. The git init
command initialise the current folder to become a git folder.
TIP
Notice the (master)
in the prompt. This is one way to know you are in a git enabled folder

Now that we have created a git folder, let's take a look inside it.
The ls
command will not show anything. However adding a switch -a
will list all the items in the folder even if they are hidden.

As you can see, . .. .git
are hidden.
.
refers to the current folder..
refers to the folder containing the current folder.git
is the folder where the git data reside in.
Now we shall create a README.md. Read-Mes are normally included in git projects to explain what the project is about. We will be creating the README.md using vi
, a command line text editor.


Now we will write the README.md. In vi
you start off in 'Command mode'. Press the key i
to go into Insert mode
. You can tell you are in Insert mode
if the bottom line says -- INSERT --
. Now in Insert mode
start typing as shown below.

TIP
In case you were wondering what to type, it is # Some Repository
.
Now that we have written our README.md, we need to save and exit vi
.
Press esc
to exit back into 'Command mode' then type :wq
to save the README.md and quit vi
. Similarly, you can do :w
first to save README.md then do :q
to quit vi
.

After you quit vi
you should be back in the project folder

Did the README.md get written? Well, you can check using the cat
command. cat
is derived from catenate/concatenate. Do cat README.md
to display the contents of README.md

Now we shall take a look at the status of our folder. Do a git status
.

As you can see, README.md is untracked. In git, files have 4 states:
- untracked
- tracked & unstaged
- tracked & staged
- ignored.
Lets do a git add README.md
to track & stage it.

Another git status
will show README.md as green, indicating it is now tracked. We need to track the file so as to let git know that this file is to be considered for version controling.
After tracking the changes (in this case is new file), we do a git commit
to commit the tracked files. Commiting is kind of like setting a milestone in your project.

Now we return to a familiar interface of vi
. #
in git commits means that anything after it on that line will be considered as a comment and not part of the commit message.

Type the commit message as shown in the image below.
TIP
Still remember Command mode
and Insert mode
?

TIP
Follow these git commit message conventions to have a structure in your messages.
After writing, we now have to save the commit message. Still remember how to 'save' and 'quit'?

TIP
If you do not want to write the message or do not want to commit, simply type :q!
to force quit vi without saving.
After you save and quit, you should see something similar to the image below.

Now that we have commited, we need to link up our folder with the remote repository on Bitbucket.

git remote
means commands related to remote
. remote
refers to the remote repository. Thus git remote add origin [insert your bitbucket repo url]
means to add a remote repository which you will name 'origin' and can be found at the specified url.
So let's try pushing it by using git push
to push this git folder to our Bitbucket repo.

Oh no, it failed. Why? Well that is because although we have added a remote to our Bitbucket repo, we didn't specify that this git folder will push its content there. Git has helpfully provided the command to do exactly what we need to do which is to set the upstream to be the the Bitbucket repo. You push your changes upstream and then anyone else who is also on this project will have the new changes flow down to their side when they do a git pull
.

-u
is the shorthand for --set-upstream
while master
refers to the branch you are pushing to (master
is the main branch).
You will be prompted for your Bitbucket credentials, just enter your account credentials and you will be able to push.

Now that you pushed your first commit and specified your upstream, you need not do git push -u origin master
anymore, that is for the first push. Now just do a git push
for any future pushes.
TIP
You can also choose to not set the upstream and opt to just type out git push [remote] [branch]
, e.g. git push origin master

Now we go back to your repo on bitbucket. You will see that your Bitbucket repo has updated its ui to reflect the README.md and other stats.

Git Conflict
What is a git conflict?
Conflicts normally occur when 2 or more people are editing the same file and end up having differnt code in said file. This difference causes the conflict as git has no idea which version it should take.
Let's simulate a conflict
To do so, we need to get another instance of our repo. Go up 1 level in your directory and create a new folder. cd
into that newly created folder.
TIP
..
— parent directory

Do a git clone [insert repo url]
to get your Bitbucket repo. This repo you clone will have all the git setup already so you need not do the initial setup again.

Go into the new project folder and do vi README.md

Edit your README.md

To simulate the conflict we will be changing the README.md in both this project folder and the first project folder.
TIP
You should edit the same line to simulate the conflict as git will attempt to resolve conflicts by auto merging for you first.

Do a git status
and you will see that your README.md is not staged for commit as it has been changed.

Do a git add README.md
to stage the README.md for a commit and then commit it.
TIP
As you may have noticed, you can only commit when you have files staged for commits (or in another words files ready to be committed).

git commit -m '[Insert message]'
is a shorthand for quickly typing a simple commit message. Normally used if your commit is insignificant.
You committed! Don't git push
yet, we will do that later.

Right click the top of window and click 'New'. Don't close this current window.

cd
into your first repo

vi
the README.md here

Edit your README.md. Remember to change the same line you change in the other repo.

When you are done, do :wq
.
Stage your changes
git add .
means git add
this current directory, which means everything that is untracked or changed in this folder will be tracked and staged.
TIP
.
— current directory

Commit this README.md

Ok before you push, it is up to you to decide which to push first (though it doesn't really matter). The repo that pushes second is going to be the one to experience conflict. Here I chose the second repo to push first.

TIP
Notice that it is not git push -u origin master
since you already set the upstream.
You can go to your Bitbucket repo page to see the updated README.

Go over to the other repo (for me it is the first repo) and do a git push
.

Rejected! it wants us to pull first. Normally you would pull first before pushing any changes so that you can resolve conflict, if any, on your side first.
Yes just type git pull
, nothing fancy.

git pull vs git fetch
CONFLICT!!!!
Finally we have a conflict. As you can read, git tried to auto merge the differences for you but failed and requires you to do the merge yourself.

How to resolve conflict?
To resolve a conflict, open the conflicted file and you will see a bunch of <
, >
and =
and a hash. The <
, >
and =
is to help separate your version and the other version while the hash is the hash of the commit from the other repo.

Decide whether you want to keep your changes or the other changes or combine them. Then do what you decide to do.
TIP
Remember to remove those <
, >
and =
.

Commit the edited README.md

Resolved. Now just push and you will be done on this repo.

Now the other repo can update to the new code. Do a git pull
on the other repo to update it with the new README.md.

Taking a look at the Bitbucket repo page we can see the README.md has been updated too.

SourceTree
If you have yet to install SourceTree, please install before continuing.

Click the 'Clone / New' button on the top left.

Instead of setting up a local git repo on our own, we will just git clone
the project which will already be a git project and have the initial git setup done for us.

Ensure the destination path is correct. You might want to bookmark this repo for easy reference in SourceTree.
Go to your destination path and you can see that the .git folder is already there.
TIP
If you do not see the .git
folder, chances are your file explorer is hiding it. Just search 'How to show hidden files in windows'.

Create README.md. To create it we will just make a new text file first.

Rename to README.md
TIP
Chances are your file explorer is not showing the file extension. just search 'Show file extension windows'.

TIP
If you are prompted on whether you want to change the extension, click yes.
Type in the content of the markdown (md) file.

Go back to SourceTree. Give SourceTree awhile to detect changes. You should see that README.md file apppears in the unstaged files section.

Stage the README.md. Click on the checkbox to the left of README.md to stage it.

Now to commit. At the bottom you will see a text field for commit message. Enter your commit message and press 'commit' at bottom right.

At the bottom there are 3 tabs, click on 'Log / History' to see what has happened in this repo.

Press the 'Push' button at the top to push your commits to the Bitbucket repo. A prompt will appear to ask what branches to push, check the only branch and click 'Ok'.

Your SourceTree will update to show the another branch 'origin/master' indicating that the commit is on the Bitbucket repo.

Your repo should have updated to reflect the README.md

Git conflict with SourceTree
Let's make a new folder to store another same repo.


Go over to SourceTree to and clone the repo into the newly created folder.
TIP
Ensure your destination path is not pointing to the first repo.

SourceTree should now show 2 bookmarks on the left (if you bookmarked).
Edit the README.md in 2nd repo. Open the README.md and add a new line as shown.

Edit the README.md in 1st repo. Open the README.md and add a new line as shown.

Go over to SourceTree to stage and commit README.md.

The Log \ History should now show a new line.

Change to your 1st repo in SourceTree and stage and commit too.

Now you choose which repo to push. I chose to push the 2nd repo.

Now try pushing the other repo, it should generate an error telling you to pull.
TIP
Basically you should do a pull first then do a push since there may have been updates that you are unaware of.

Click the 'Pull' button to pull from the Bitbucket repo and you should have a conflict.

Open README.md in the conflicted repo. You should see the familiar <
, >
, =
and a hash.

Edit the README.md to choose your change or the other repo change or combine the changes.

Go back to SourceTree and you will see another README.md at 'Unstaged files'. Stage the fixed README.md.

Just clicking on the commit text field, SourceTree has kindly prepared a commit message for us. Edit it to add more information if you like to.

Your Log \ History should have updated to reflect the new commits.

Push the 2 commits and you will be done with the conflict.

Your Bitbucket README.md section should reflect the new commit

End of basics
You have come to the end of this basic git tutorial. With this skillset, you will be able to utilise git for about 70% - 80% of the time. There will come the time when you need to learn how to git reset
, git revert
, cherry pick and many more commands and concepts but for now this is enought to get you going.