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.
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?
- 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.
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
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
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.
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
We will create a folder that will connect to the repo on Bitbucket
\ 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.
(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.
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
.gitis 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.
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
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
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 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
As you can see, README.md is untracked. In git, files have 4 states:
- tracked & unstaged
- tracked & staged
Lets do a
git add README.md to track & stage it.
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
# 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.
Command mode and
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'?
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 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
-u is the shorthand for
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.
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.
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.
.. — parent directory
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
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.
You should edit the same line to simulate the conflict as git will attempt to resolve conflicts by auto merging for you first.
git status and you will see that your README.md is not staged for commit as it has been changed.
git add README.md to stage the README.md for a commit and then commit it.
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
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.
. — 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.
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
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
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 a hash. The
= 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.
Remember to remove those
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.
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.
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
Chances are your file explorer is not showing the file extension. just search 'Show file extension windows'.
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.
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.
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 revert, cherry pick and many more commands and concepts but for now this is enought to get you going.