WORKING WITH GIT AND GITHUB.

Collaboration Made Easy.

INTRODUCTION

Imagine working on a project document with some collaborators, and you want to get answers to the following questions:

·       Who made changes to any document.

·       What changes were made.

·       When were those changes made.

·       Why were they made.

In other words, you want to track different versions of documents in the project folder over time. Any tool that answers the aforementioned questions is referred to as a version control system. Furthermore, suppose such a tool manages the projects without having one particular point of storage for the documents but is distributed on participants' devices; In that case, it is called a distributed version control system.

Git is a distributed version control system, different from GitHub, a web server that assists in hosting your project documents in a remote location; although, it uses the git system at the backend. There are other platforms that could host documents remotely, and example includes GitLab and Bitbucket.

1.      INSTALLATION AND CONFIGURATION OF GIT

Git can be used as a graphic user interface, but it is most efficient in the command line.

Git can be downloaded here ( https://git-scm.com/downloads ). Then you can install depending on your Operating System.

Open a terminal (command-line) on your system and start using git. To confirm that the installation was successful, type:

git –version in your terminal. This should return the git version as shown below.

It is necessary to supply your credentials to git for it to track project folders. Run the following in terminal

git config –global user.name “Your_user_name”

git config –global user.email “your_email”

Supply your username and email in the above without the inverted commas.

Note: if you have a GitHub account (or any other remote location account)- supply the same username and email above. This will allow git to share your document with the remote location.

2.      REPOSITORY AND DOCUMENT TRACKING

A repository (repo) is just a project folder on your device that you initialized with a .git file, making it possible to track all contained documents.

A repo could also be remote (such as those on GitHub), and it serves the same purpose of containing all documents that require tracking.

To create a repo, create a folder containing your project documents, navigate to the folder in your terminal (command-line), and run:

git init (This will generate a .git file which can be viewed)

To see the files in the repo:

Type dir /a in windows

Type ls -l in mac

NOTE: It is also possible to track your repo and share projects in a remote server if you are on a shared computer with an already initiated global credential.

2.1 Sharing project from a computer with global credential:

If you are working on a computer initiated with a global credential and want git to track and share your repo in GitHub using your own personal credential, you can link the repository to your GitHub account.

·       Open a terminal and be sure to navigate to the desired directory (folder) and run:

1.      git init (Used to initialize the folder as a git repository)

2.      git config user.name “your_user_name”

3.      git config user.email “your_email”

4.      git config credential.username “your _user_name”

Supply your username and email in the above without the inverted commas.

2.2 Tracking Documents in Repo

A created or modified document in a git repo can be tracked after saving the file only if two steps are completed. It is important to check the status of your file as you work along in git, especially for beginners (always use git status)

1)      Place the file in the staging (ready) area and to do this run:

git add name_of _file

Note: name_of_file should be replaced with the desired file name.

2)     Commit the modification.

git commit -m “message”

Type the desired message describing the changes that were done within inverted commas.

In the following example, I will create a folder, initialize it, create a file and commit the changes made.

Each commit is like a snapshot (version) of your project, which can be referred back to if necessary.

3.      GITHUB

Recall that the committed changes only occur on our local machine; we can make this folder and any changes within it available on a remote service such as GitHub.

You need to create a GitHub account and create a repository, as shown below.

Steps to create a repository on GitHub:

a)      Navigate to your account and click on the plus (+) sign in the top right corner, then choose “new repository” (fig 3.1).

b)     Type your repository name as requested and click "create repository".

After creating a repository in the GitHub account, go back to the command-line on the local machine

a)      Add the URL of the GitHub repository using the following command

git remote add origin [GitHub repository URL] (fig 3.2)

b)     We can now push the files committed in the local repository to the one created on GitHub

git push origin master (fig 3.2)

The file is now available in our GitHub repository, as shown below:

4.      BRANCHING

Branching is creating a copy of your repository at a specific point in time. It allows you to work on the copy while not affecting the original codes. The branched copy could be worked on in isolation and later merged with the original when satisfied with the changes made. The original folder is referred to as the “master” (main) branch, while the user could name every manually created branch as wished. You can create a branch by using the following:

git branch new_branch

The above code creates a branch called “new_branch”

To check the branches in a particular repository type:

git branch

In the above picture (Fig. 4.1):

i)        I navigated to a git repository called “mygit”.

ii)       Typed git branch to check available branches, and the output was just the “master” branch.

iii)      I created a branch called new_branch.

iv)       I checked the available branches, and now we got “master” and “new_branch”.

4.1 Changing Branch

To move from one branch to another, use:

git checkout [name of branch]

In figure 4.2 above;

i)                   I moved to the branch new_branch

ii)                  I checked the branch by running “git branch”

NOTE: The branch we are currently working on is indicated by a preceding asterisk. Therefore, I am currently in the branch called “new_branch”

4.2 Update a file and commit (Picture below in figure 4.3):

i)                   I checked my status; “Nothing to commit” signifies that there are no changes made

ii)                  I opened a file in the directory(repository) and modified it

iii)                I checked the status again, and now it shows in red colour, a signal that the file is modified

iv)                I added the changed file to the staging area, and the word “modified” is now in green

v)                  I committed the changes and added a comment

Note that these changes will only be reflected in the file while we are on the branch “new_branch.” If you switch to the “master” branch and open the file, that updated line of code will not be present.

After modifying a code via branching, we might want to make the branch available for our collaborators in a remote server like GitHub. Now let’s push the branch to GitHub for others to have access.

See the pictures of available branches before and after pushing the new_branch (fig 4.4 and 4.5, respectively)

Notice the branches and the additional statement on the readme.md file after the push.

5.      MERGING

After satisfactorily modifying a branch, you would like to incorporate your changes into the main repository: this is called merging. To merge an updated branch, you have to check out to the “master” branch and then type:

git merge [new branch]

The master branch on our local machine is updated, as shown in fig 5.1 but not that on GitHub. To update the master branch in GitHub, we push the master branch:

git push origin master.

6.      GIT CLONE

If you want to work on another person’s project present in a remote server such as GitHub and that project is not on your local machine, you can get a copy of the project by cloning it using:

git clone [repository URL]

This will create a new directory locally on your machine with the same name as the remote and also create a copy of all the files in the remote repository. However, access will be denied if you make changes to this repository locally and attempt to push to a remote. This is because the remote repository you cloned from belongs to another user. Therefore, if you want to work on a cloned copy and keep track of it in GitHub, you will have to change the URL of the remote to a repository URL in your GitHub account.

Follow these steps to do that:

i)                   Create a similar repository on your GitHub as explained in fig 3.4 above.

ii)                  Copy the URL of that repo.

iii)                Back to the local terminal and reset your remote while in the directory of the cloned repo.

git remote set-url origin [new github repo url]

Any changes made to the cloned repo can now be pushed to your GitHub account.

Another important question is, what if you still want to maintain a connection to the initial remote you cloned from while you work on the cloned copy locally and in your personal GitHub? Then the best method comprises the steps below rather than those above after cloning the repository.

i)                   In terminal type, git remote rename origin upstream

ii)                  Create a similar repo on your GitHub

Back to terminal type: git add remote [URL of the GitHub repo]

7.      FORKING

This is similar to cloning in that it refers to creating a copy of a remote repository in your GitHub account. However, unlike cloning, it allows you to contribute your changes to the original repository using a "pull request". This is useful when you want to contribute an idea to an open-source project. In addition, “fork” is a GitHub thing, not git. When you fork, a copy of the forked project will be created in your GitHub account, and to have a local copy of the repo; you can simply clone it.

Steps

i)                   You will need to navigate to the remote repository from your GitHub account as shown below: Here, the user Ola20 navigates to the repository owned by another user, Fawzaan50.

ii)                  He clicked on "fork", then "create fork".

iii)                Then the user now has the forked repository owned by Fawzaan50.

iv)                Ola20 can now clone the repository to have it on a local machine.

8.      PULL REQUEST

This is a way to request the maintainers of a project repository to review and merge changes made to the repository. This request is typically made after forking a repository. The request could be approved, or the project's maintainers may request further changes before accepting the modification and subsequent merging.

8.1. Typical steps on "fork" and "pull request"

i)                   Click on "fork" from the remote repository as shown in fig 7.1, the repo will be transferred to your GitHub page, and you can click “create fork”

ii)                  Clone the repo from your command-line using “git clone [forked repo URL]”

iii)                Navigate to the cloned repository

iv)                Use git branch “new branch” to create a branch (third highlight in fig 8.1)

v)                  Use git checkout “new branch” to move to the branch and make the required changes.

vi)                Make any changes to the files in the repository (example in fig 8.2)

vii)              Use git add and git commit to save the changes as usual (Fig. 8.3)

viii)             Now use git push origin “new_branch” to push back to GitHub (third highlight in Fig. 8.3)

Refresh your GitHub page: You will get information relating to the recent push

ix)                Click “compare and pull request” then “create pull request” (fig 8.4 and fig 8.5)

x)                  Lastly, you can leave a comment or click “close pull request” (fig 8.6)

xi)                A request for merge will be sent to the owner of the repository (Fawzaan50) figure 8.7 below.

xii)               The owner fawzaan50 sees the pull request as shown

xiii)             He can proceed to merge if all seems good, or he can request modification

Note: Forking does not copy the number of pull requests and issues on the original repository, but it copies over all the files therein.

8.2 When should I Fork or Clone?

You should fork a repo when:

·      You are collaborating on a project and wish to submit a contribution via a pull request.

You should clone a repo when:

·      You simply want to get the files from a repository and learn or use codes personally.

9.        GIT IGNORE

When creating a repository, you can create a ".ignore" file in the root directory of your repo. This file can contain patterns of files that you do not want git to track within your project. Each pattern will occupy a line within the file.

The rules in the git ignore file also affect all subdirectory files and folders.

Example: if you create a .ignore file, you can specify a pattern as follows:

git ignore *.[py]

The above means git will not track all .py files.

10.      CONCLUSION

The usage of Git and GitHub is an important skill necessary to be possessed by professionals working in a software development team. These tools help manage the development process and ensure that the codebase is synchronized and organized.