Source Control (Git and GitHub)

SEG2105 - Introduction to Software Engineering – Fall 2019

Presented by: Wassim El Ahmar – TA & Ph.D. Student

Emad Badawi

Faculty of Engineering | Faculté de Génie

uOttawa.ca
Overview

• Overview:
– Key Concepts
– Installation and Setup
– GitHub Introduction
– Basic Git WorkFlow
– Utility Commands

2
THE BASICS

3
Source Control? Version Control?

• Management tools used to manage changes to files

• Isolates developers from one another while they work

• Allows for selective and predictable integration of different portions of a

project

• Can be directly integrated into development platforms like Android Studio

• Common Version Control Systems (VCS):

– SVN: Very Simple, single repository shared by all users.
– Mercurial: Medium Complexity, distributed repository system.
– Git: Medium-high Complexity, distributed repository system.

4
Why Git?

• Distributed source control system

– Most operations in Git are local
– Only a few commands require a network connection
• Massively scalable
• Open Source
• Developed for Linux project requirements
– 15 million lines of code
– 12000 worldwide developers contributing to project
– Dozens of active branches
• Fast, FREE and Open Source
• Very active community

5
Core Concepts

• Repository contains:
– Files
– History
– Special configurations

• Three (local) States of Git

– Working directory is the directory or folder on your computer that
holds all the project or application files. It’s a copy of the remote
repository in which you add/remove/edit your files
– Staging Area (holding area or Git Index): Queues up all changes for
the next commit
• Files can be put into the staging area if they have been modified
• Files in the staging area can be moved in and out
– Repository – Git Repository (.git folder)

6
Core Concepts (cont’d)

• Remote Repository:
– The remote repository is just another repository of the same workspace,
on the remote server.
– Last step in the basic Git Workflow

• Master Branch
– Default branch that contains your changes
– Git provides a default branch named master

7
Git - Command Line

• Git was originally designed as a command line tool, and graphical support
came later.
• Features make it onto the command line before they are integrated into a
graphical client
• Documentation
• More power!
• Consistency:
– Terminal on Mac/Linux
– Git Bash on Windows

8
Git Installation

• Windows
– https://git-scm.com/download/windows

• Mac OS X
– https://git-scm.com/download/mac
– Or type git version on the terminal

• Linux
– Use your package manager to install git, e.g.: “apt-get install git”

Git Commands are the same!

Test your installation by typing: git version

9
GitHub – Create account

• Navigate to GitHub.com
– You can sign in or sign up.
– Select the 'Unlimited public
repositories' free plan if you
sign up.
– Follow the steps to verify
your account

10
GitHub – First repository

• After you’ve signed up/

logged in, click “New
Repository”
– Name: my_first_github
– Description: A simple demo
to show the basic Git
Workflow;
– Select the option ‘Initialize
this repository with a
README’

11
Prepare your local system

• Create a folder named ‘projects’

• Open your terminal and navigate to the created folder
– If you’re using Windows, you can right-click anywhere in the folder, then
click “Git bash here” to open the git command line in that folder

• Git requires two pieces of information before we proceed

– Name: git config --global user.name "Miguel Garzón"
– Email: git config --global user.email [email protected]
– This information will be associated with every commit made by the user

12
Cloning a Repository

• Type: “git clone <link to the the repository>”

– e.g.: git clone https://github.com/mgarzon/my_first_github.git

• Confirm that a folder named “my_first_github” has been created and that
you have the README file . You can add a creation folder name after the
repository name to specify the name of the folder you’d like to create

• Navigate to “my_first_github” using the command line

• Type: “git status” and pay attention to the information displayed.

– If you cloned the repository correctly, you should have all commits and
be in the repository head.

13
Our First commit

• Add a new file to your

working repository
directory
– (you can create a new
text file)

• Type git status in the

command line. What do
you see?
– The file you created
should be listed as
“untracked”

14
Our First commit (cont’d)

• Use the add command

to add your file to the
staging area.
– E.g.: “git add
newfile.txt”

• Then type git status

again. What do you see
now?
– The file you created
should be listed in commit
list

15
Our First commit (cont’d)

• Use the commit

command to add the file
you created
– E.g.: “ git commit –m
“first commit” ”

• Then type git status

again. What do you see
now?
– You should now be in the
master branch

16
Publishing changes to GitHub

• Your previous commit is still a local command

• Use the push command to send your changes to the remote server
– Type git push origin master
– origin: refers to the GitHub copy of our repository
– master: refers to our default and only branch of the repository

• The git push command will prompt you for your

GitHub username and password (first time only).

• Check your results on Github.

17
Make Modifications to Files

1. Modify the Readme.md by adding the following text: "Welcome to my

Project ".

1. Modify the file you created, add some text to it.

1. Add, Commit and Push your changes. Commit message should be ‘Second
commit’.

1. Commit multiple files at the same time:

– git add .
– git commit –m “second commit”
– git push origin master

18
Comparing two commits
• You can check the changes made by every commit
by going to your project page on Github ->
commits -> then selecting the commit you want to
analyze

• Portions
removed are
marked in
red and
those added
are marked
in green.

19
Pulling Remote Updates

• If someone else has made changes to your project and has sent them to
the remote server, in order to be able to synchronize, you need to run a
pull command

• Trying to push commits when the remote contains changes not visible
locally will cause the push to fail. You need to integrate the changes before
submitting your own.

• If there are not conflicts, using “git pull” will download the outstanding
changes without issue. Then, you will be able to push your own changes.

• Cases where multiple team members change the same files will be treated
in the following slides, during discussion of “merging”.
INTERMEDIATE CONCEPTS

21
Starting With an Existing Project

1. Consider a project where you already have source code. If you have a project in
your computer you want to use, make a copy of it in a separate folder. You can
also create a new folder, create a test text file for this example.

1. To place this folder under version control with Git, we use the init command.
git init
– At this point, Git has initialized an empty Git repository in the current folder.

2. Verify that a .git folder exists in the current folder.

– Type "dir /a" in windows, or "ls –la" in linux/mac

3. Type git status to check the current state of the (local) repository.

22
Commit Untracked Files

• Before committing our changes let’s create a file called LICENSE.MD

Commit all files at the same time, remember to add a message:

– "git add ."
– “git commit –m “Created a repository from an existing project” “

Don’t push it! We still want to play with the staging area!

23
Logs!

• Use the git log to see the

list of commits made locally.
The log contains:
– A long identifier (SHA-1 identifier)
– Author
– Timestamp
– Commit message

• git show gives you more

details, give it a try.

24
Making changes to Staging area that will be
reverted

• Make any changes to the LICENSE.MD file (add some text to it)

• Add the changes to the staging area

“git add LICENCE.MD”

• Unstage your changes ☺ (Unstage the file)

“git reset LICENSE.MD”

• Were the changes reverted?

– At this point, your file should go back to being listed as modified but not be in
the staging area (run another git status to check)

25
Fully Reverting Changes (Backing out)

• The changes were unstaged but not reverted. To revert:

– git checkout LICENSE.MD

• Check the contents of the file now. What happened?

– The file changes should have been reverted to their prior status
– Your status should read “ nothing to commit” if the changes were
reverted successfully

26
 Push changes to GitHub

• Before pushing any changes remotely, you need to connect first your local copy
with you GitHub remote repository.

• Create a repository online for you to send your new local repository.
– Do not use the repo from the previous example.

• Type:
– git remote add origin your_url
– In my case:
“git remote add origin
https://github.com/wassimuottawa/github_from_existing.git”

• You can now push your changes:

git push -u origin master

27
ADVANCED CONCEPTS

28
Branches

• A branch is a timeline of
commits

• Branch names are labels, they

do not carry special meaning
other than the one given by the
development team
– Deletion removes label only

• You can use branches to allow

for independent development by
different team members or for
specific development
components.

29
Creating a Branch

• We will rejoin the Master Branch later.

• Running a “git branch <new branch name>” command will create a new
branch

30
Merging Scenarios

• Running a “git merge” command will merge two separate branches

1. Fast-Forward:
• Simplest case
• No additional work has been detected on the Master (parent) Branch

31
Merging Scenarios (cont’d)

2. Automated
• Non-Conflicting states
• Preserves both Timelines

32
Merging Scenarios (cont’d)

3. Manual
• Conflicting Merge State
• Git is unable to automatically resolve any conflicts
• Merge conflicts must be resolved before doing the commit
• Some tools can assist in solving file conflicts. 3-Way file diff is useful
when two people make multiple changes to the same file.

33
Branching

• Type git branch to see the list of branches

• To create the branch and switch to that branch, type:

– git checkout –b <your first name>
– E.g.: “git checkout –b Miguel”

• Now, modify the README file and add, commit and push it.
– git add .
– git commit –m “committing to another branch”
– git push origin Miguel

• You can compare the branches by typing:

– git diff master Miguel

34
Merging

• To integrate the changes into the master branch:

1. Switch to my parent branch (master): git checkout master

2. Type git log –-all. What do you see?

3. Merge : “git merge Miguel”

4. Type git log –-all. What do you see now?

– At this point, the Miguel and master branches should have the same
files and should be in the same revision.

4. Now delete the branch

– “git branch –d Miguel”

4. The merge is still local on your machine. If you want to push it to the
remote repository, do a “git push origin master” command
35
Example Conflict File after Merge

Consider the following Scenario where two people have to merge:

• Student 1 writes “Miguel” to their file, commits and pushes it to the server
• Student 2 writes “Felipe” to their file, commits and tries to push.
• Student 2 gets a warning about differences, pulls from remote server and
gets a conflict warning.
• At this point, the file should look something like:

<<<<<<< HEAD
miguel
=======
felipe
>>>>>>> 42708f7a9040d44b00998d8846be0bed0fc5ca3a
• After editing the file to fix the conflicts (or using a conflict resolution tool),
Student 2 adds the file with conflict to the staging area, makes another
commit and successfully pushes his changes to the remote.
THANK YOU

37