# 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

# 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

Now we will initialise git in our folder. The git init command initialise the current folder to become a git 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.

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.

After writing, we now have to save the commit message. Still remember how to 'save' and 'quit'?

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.

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.

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.

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.

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.

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.

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.

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.

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

Rename to README.md

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.

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.

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.