git, github, bitbucket - git basics

Scope and Objectives

In this article, let’s take a look at the basics of GIT – remote vs local, clone, commit, push & pull, pull request & approve/merge pull requests. If you don’t understand 100% of this article, it is okay as this article is only meant as a high -level visual introduction of various GIT commands/activities:

  • git clone
  • git commit
  • git push
  • git pull request
  • git approve and merge a pull request
  • git pull

Intended Audience

This article is intended for beginner developers or QA automation engineers who have little or no prior knowledge of GIT.

What’s a GIT repository – Informally Speaking

You can think of a GIT repository (or “repo”) as a safety deposit box for all your files.

  • You have a master copy of these files in the safe. This is the master branch.
  • You can create a new branch from the master branch by making a full copy of these master files and give this branch a unique name. This branch also resides in the safe. E.g. Alice creates a new branch called : alice-workspace
  • Likewise, Alice’s team mate Bob can make his own branch inside the safe i.e., his own copy of all the master files and call the branch : bob-workspace

A sample scenario – a team that is using the GIT repository

In this example, imagine a team with 3 people :

  • Alice, a team member
  • Bob, a team member
  • Lena, a team lead who oversees all updates made by Alice or Bob

The team is working on three files which are all put in the GIT repo’s master branch initially:

  • Alice is working on the file : alice-expenses.csv
  • Bob is working on the file : bob-expenses.csv
  • Alice and Bob both work on the file:  consolidated-expenses.csv

A visual tour of the basic GIT commands

1. Remote vs Local

Note: In all the images below, remember that the top part of the image is the “remote” or “origin” e.g.  Bitbucket or GitHub. The bottom part of the image is the “local”, which is your mac or laptop/desktop.

2. Initially, the repository is on the Remote only

The team lead Lena created a repository called git-super-basic-intro on the remote, e.g. bitbucket or github, and added 3 initially empty files for use by the team members. Notice that the repository initially only has the master copy of the 3 files (in the master branch).


3. Alice creates a branch on the remote

Alice creates a new branch from master and names it alice-workspace. This branch has a full copy of all the files in the master branch. Alice will use her own branch to work on the team’s files.


4. Alice clones the remote repo into her local laptop

Alice wants to bring the files on the remote repo into her laptop. She clones the remote repo on to her laptop. Now Alice has all the files on her laptop as shown here.


5. Alice checks out the local alice-workspace branch

Notice that on Alice’s laptop there are 2 branches.

  • master
  • alice-workspace

So there are 2 sets of the three files, one set per branch.  In order to specify which GIT branch files she will work on, Alice needs to do a checkout on that branch. In this scenario, Alice wants to work in her newly created workspace, so she checks out the branch: alice-workspace.


6.  Alice updates and saves the changes to two files on her laptop

Alice makes these changes but these changes are not written to and updated in the local alice-workspace branch. This is because Alice has not done a commit to the local repo yet.

7. Alice does a commit to her local repo

After the commit, the 2 files in the local alice-workspace branch are updated with her changes. Note that all other branches – the 2 branches in the remote and the master branch in the local are untouched and not yet updated.

8.  Alice pushes her changes to the remote

Alice pushes her changes in the local alice-workspace branch to the remote alice-workspace branch. Now, the changes she made to the 2 files are also applied to the remote alice-workspace branch.


9.  Alice makes a pull request

Alice makes a pull request from the remote alice-workspace branch to the remote master branch, and adds her team lead Lena as a reviewer. A pull request is exactly what it says : it’s a request to Lena to “pull” Alice’s changes to the master branch i.e., review, approve and merge Alice’s changes to the master branch.


10. Lena approves Alice’s pull request

Lena gets notified of Alice’s pull request. After closely reviewing Alice’s changes to the team’s files, Lena approves the request, then merges the changes to the master branch. Now the files in the remote master branch are updated with Alice’s changes.


11. Alice pulls from the remote to her local

Alice pulls from the remote and her local laptop’s master branch is now updated from this pull.

Note : notice the terms “pull” and “pull-request” are different as illustrated by the above examples!

12. Summary

In the above scenario, we have seen Alice start with the clone, commit her changes to local repo, push her changes to remote, create a pull-request for Lena to approve and merge, and finally pull the remote master to her local.

Further reading / Suggested links

Both GitHub and Bitbucket have excellent tutorials on GIT which is a good next step if you want to deep dive into GIT. Good luck!