/
Git (Basics of Source and Version Control)

Git (Basics of Source and Version Control)

Oct 28, 2021

0. Introduction

Do this tutorial with a colleague

This tutorial is for a pair (or small group) of colleagues to do together. It is not for one person to do alone. There are many other Git tutorials on the internet for one person to do by themselves.

This tutorial guides you and your colleague through a set of Git activities in three different user interfaces: web UI, VSCode, and command line. You should do all the activities in all of the user interfaces. Doing just the first few activities in the web UI will not be enough of an introduction for you to be able to work competently as part of a software development team.

Why Git?

Version control systems are the technological foundation of software engineering teamwork. They are how multiple team members all work together on the same code. 

Git is a popular and powerful version control system. Version control systems are the most important teamwork tool in software development: There are many version control systems. We are using Git because it is popular and powerful. It is not the most user-friendly tool. You will find it frustrating at times, as everyone does. Ask for help when you get stuck.

Why not Dropbox, Google Docs, Notion, Office365, etc?

There are now many tools for collaborative document editing or document sharing. It is possible to use them for collaborative code editing, but they are not optimized for this purpose. No professional software teams use these tools for code version control. Three key features of code version control systems include:

  • Names for every revision of the software. So you can always switch to a specific revision. Git uses hashes for naming revisions.

  • Merge strategies for managing multiple variants of the software.

  • Conflict resolution strategies for when different programmers make different edits to the same lines of code.

1. GitLab Web UI

Git is a command line tool. Many people confuse Git the command line tool with the commercial website GitHub.com. The GitHub.com website provides additional functionality on top of the Git command line tool. GitLab is open source website software that offers similar functionality to GitHub. The University of Waterloo runs its own instance of the GitLab software at https://git.uwaterloo.ca, which we will be using.

You do not have to install any software on your computer to use the GitLab web UI, so it is a good place to start. When you use the GitLab web UI, you do not have a copy of the files on your local computer. To do more significant software development you will need to have a copy of the files on your local computer, which you will set up after you complete these web UI activities.

Sign up or Log in to GitLab

  1. Go to https://git.uwaterloo.ca/

  2. Log in to your account

Your screen should look like this:

 

Creating a project

To create a new project follow the following steps: 

  1. Click on New Project>Create blank project 

  2. Enter project name and select your project visibility (private/public etc.)

  3. Click Create Project.

Adding your partner to your project

Click on the members tab in the sidebar to the left, and add the user ID of your partner. Give them Maintainer access (the second-highest level). Maintainer access is required to push to the main branch.

Adding your first file

To add a new file go back to project overview tab and click on the button 'New File'. Click the green 'New File' button again under the heading “Make and review changes in the browser with the Web IDE”. Enter a new filename (anything you want) and click the green Create File button.

Helpful Web IDE tabs

 

Committing and Branches

  1. If you would like to edit and commit (committing is like saving) your changes on the web IDE of git, you can press the Web IDE button on the project overview page.

  2. Here, you can edit the new file that you have made, and then "commit" the edit that you have made.

  3. Pressing commit will initialise the initial commit of this file.

  4. Click commit to master to have your initial commit added to the master branch.

Making commits one at a time (therefore no conflicts)

Now say you and other members of your project (here Tara and Giselle) wish to make changes to the project on the web IDE. The first case you will encounter is when the changes are done one at a time so there are no conflicts.

You can test this out as shown:

  1. Tara makes a second commit:                                                                     

  2. Then Giselle deletes Tara's change and replaces it with her own test. The changes are shown on the screen before final commit:

If you would like to view the Commit History of the project, you can view it by clicking on the word Commits under the project title on the project overview page

 

Git Color coding

Any changes made in any file in the repository will be colour coded. Additions will be shown in green whereas deletions will be shown in red. This allows you to review your changes to each file before committing the change. You will have the choice of committing your changes to the master branch or creating a new branch with your changes (recommended if working with other persons on a project).

This also applies for using VSCode for version control, this does not however apply to using the Command line for version control. In the command line it will be shown as regular text but will say who made what changes.

 

Simultaneous  Commits: same time, but compatible (no conflict)

If Giselle and Tara decide to add different lines of changes to the file and try to commit at the same time, what do you think will happen? Lets find out:

On Tara's Screen:

On Giselle's Screen:

 

When both press commit, we see that Giselle's commit goes through first. But Tara has also already made her change on that version of the branch that does not have Giselle's change. This means that Tara's branch is behind the recent commits and she has to create a new branch and then merge it into the master branch. 

She sees the following:

So after clicking 'Create new branch', she creates a merge request to merge the new branch back into the master:

To see the merge request, click the Merge Request tab on the left sidebar.

To see changes being made in the merge request go on the changes tab

You can also see the commit history of this branch by going on the commits tab.

If you choose the cherry-pick tab you can cherry pick what changes you want to save and what you want to discard. If you are unhappy with the all of the changes you can use the revert button:

 

Upon accepting the merge request, The final document now looks like:

 

 

Note

This only happens in the Web IDE and the procedure is different in the VSCode interface and the Command Line. We will get to that in a bit.