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?

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.

Bitbucket home

Create a Bitbucket repository

Login to Bitbucket and create a repository.

Bitbucket create repo 1

You can name the repository whatever you want.

Bitbucket create repo 2

You would see something similar to this

bitbucket repo initial page

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 Bash setup step 1Git Bash setup step 2Git Bash setup step 3Git Bash setup step 4Git Bash setup step 5Git Bash setup step 6Git Bash setup step 7Git Bash setup step 8Git Bash setup step 9

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

git bash window

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.

ls command

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.

cd command

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

home folder

Let's create a Project folder to organise our work

mkdir command

Change directory into Projects

cd in 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.

create repo folder

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

initialise git in 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.

inside git folder

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.

vi commandvi cli

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.

writing README.md

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.

save and quit

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

out of vi

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

README.md content

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

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.

track README.md

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.

commit changes

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.

vi again

Type the commit message as shown in the image below.

TIP

Still remember Command mode and Insert mode?

commit message

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'?

save commit message

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.

committed

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

connect repo to 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.

git push fail

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.

Shorthand

-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.

enter credentials

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

pushed

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.

uploaded readme

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

get new instance of repo

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.

git clone

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

project directory

Edit your README.md

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.

change README.md

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

git status

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).

Add and commit

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.

committed

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

new git bash window

cd into your first repo

first repo

vi the README.md here

vi README.md

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

README.md changed

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

staging

Commit this README.md

commit

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.

push

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.

pushed

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

other repo 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.

pull instead

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.

conflict

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.

how to resolve conflict

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 =.

resolving

Commit the edited README.md

commit

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

resolved

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.

update other repo

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

bitbucket repo page

SourceTree

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

sourcetree

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

clone / new button

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.

clone project

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'.

the cloned project

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

create README.md 1

Rename to README.md

TIP

Chances are your file explorer is not showing the file extension. just search 'Show file extension windows'.

create README.md 2

TIP

If you are prompted on whether you want to change the extension, click yes.

Type in the content of the markdown (md) file.

README.md content

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

sourcetree

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

stage README.md

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.

commit

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

log / history

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'.

push

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

pushed

Your repo should have updated to reflect the README.md

repoitory page

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.