Version Control

with Git
Basics of git,
integrating git with
GitHub and equivalent
platforms
 Introduction

In this course, will cover the basic functions of Git and how it can be integrated
with GitHub (or equivalent platforms).

You’ll practice using Git commands in the terminal to add version control to your
project, allowing you to switch between different versions of your progress and
branch off to create new features.
 Introduction
By the end of this course, you’ll be able to:

• Create a Git project and setup a remote copy on GitHub.

• Label changes and move between different versions of your project.

• Create branches in your Git project so you can collaborate with others.

• Use Git commands to make sure your local copy of code matches the remote
copy on GitHub.

• Be familiar with Git rebase, GitHub repository settings, and how to keep a
remote repository organized.

• How to create a GitHub profile and explore code written by others

 01
Presentati
on of Git
 Version Control Systems
• (VCS)
Git is one of the most popular version control systems (VCS).

• A version control (or revision or source control) system is any system that
manages multiple versions of files(e.g. source code, reports, videos, etc)

• Version control is essential for team projects and also very useful for individual
projects.

• There are 2 main types of VCS; centralized and distributed.

• Some other version control systems are CVS, Subversion and Mercurial. CVS and
Subversion are centralized while Mercurial and Git are distributed.
 Why version control?
• For working by yourself:
• Gives you a “time machine” for going back to earlier versions

• Gives you great support for different versions (standalone, web app, etc.)
of the same basic project

• For working with others:

• Greatly simplifies concurrent work, merging changes

• For getting an internship or job:

• Any company with a clue uses some kind of version control

• Companies without a clue are bad places to work

 Setting up Git
• After installing git, open a terminal (or Git Bash)

• Enter these lines (with appropriate changes), should be done just once:
git config --global user.name "your intended name"
git config --global user.email youremail@provider.com

• If you want to use a different name/email address for a particular project, you
can change it for just that project
• cd to the project directory
• Use the above commands, but leave out the --global

• You may also want to turn on colors:

• git config --global color.ui auto
• See your options:
• git config -l
 Setting up Git
• git --version

• git config --global user.name “Sherlock Holmes”

• git config --global user.email “Imsherlocked@gmail.com”

• git config -h (list of commands)

• git config --help (git manual)

 Creating a Repository
• mkdir gitlab (make a directory - repository)
• cd gitlab
• git init . (to initialise git)
• Create a README.md file in this folder and put some text into it.
• ls (to list items)
• ls -a (to show hidden directory)
• git status (to show on which branch are you)
• git add . (sends file to staging area)
• git commit -m “my initial commit” (sends file to local repo)
How does Git work?
How does Git work?
 Track changes
• git status

• git log (shows the time and date of each commit)

• git log --patch (shows the details of the file)

• git diff (helps to review changes)

• git diff --staged (Press q to quit)

 Committing a folder
• mkdir temp

• ls -a

• git status

• touch temp/.gitkeep (Create an empty file inside an empty folder)

• git status

• git add .

• git commit -m “Added a temp folder”

• git status
 Delete Files
• touch newfile.txt

• ls -a

• git status

• rm newfile.txt

• git status

• Question: Will it be removed?

 Delete Folder
• rm -rf -- temp

• ls -a

• git status

• git add .

• git commit -m “removed file and folder”

 Ignore files
• mkdir config
• touch config/private.txt
• git status

• Create a .gitignore file (config/ - specify files and folders you want to ignore)

• git status
• ls -a
• git add .

• git commit -m “Added gitignore config”

• git status
 02
Git
branching
 What are branches?
• In Git, a branch is a new/separate version of the main repository

• Take an example of Thierry Henri, Nadia and Zida working on a group project
together. Their repo will have one main version (main branch) but the different
team members need to work on different parts at the same time.

• Instead of modifying the same files and messing up the report, each person
takes a copy (creates a branch) and works on their section separately:
• Thierry works on the introduction (intro-branch)
• Nadia works on the presentation (presentation-branch)
• Zida worjs on the conclusion (conclusion-branch)

• Once everything is done, they bring back their changes, merge them into the
main project and nothing gets lost or overwritten.
 Working with branches – creating and
•
switching
Show the branches on your repo: git branch (it will highlight the branch you’re
currently on.)

• To create a branch, we use the git checkout command: git checkout –b

feature/web-interface
• git status
• Create an index.html file. Put in boilerplate HTML code
• Make a commit

• Switch back to the main branch: git checkout main (or master, depending)
• Can you see the index.html file there?

• Switch to the feature/web-interface branch. Is the index.html file back?

 Working with branches – merging
• The goal of most branches is to work on a feature or a bug fix and once the
work is done and has been tested, to merge this branch back to the main

• To merge a branch into the main branch,

• Switch to main branch
• Make sure you’re on the main branch (run the git branch command)

• Use the command: git merge feature/web-interface

• List the content of the repository. Have you seen the html file now?
• Switch back to the feature/web-interface branch, is it different from the main?

• Once you’ve merged a branch into main (and are no longer in need of it), you
can delete it using the git branch –d branch_name command.
• Delete the feature/web-interface branch.

• NB: there are 2 ways to delete a branch git branch –d branch_name or git
branch –D branch_name. How are they different?
 Working with branches – rebasing
• Both git merge and git rebase are used to integrate changes from one branch
into another.

• Git rebase integrates changes by rewriting the commit history

• To understand the difference between merge and rebase, do the following:

• While on the main branch, create a new branch called feature, and switch to it
(git checkout –b feature)

• Create a file, file.txt and put the text “Feature work” in it. Make a commit

• Create another file, file2.txt and put the text “Another file in my path”. Make a
commit

• Create one more file (I promise this is the last one) called file3.txt put the text
“April Fools Day?”. Make a commit

• Create one more file called file4.txt, put the text “Fooled you didn’t I 😏”. Make a
commit
 Working with branches – rebasing
• At this point in time, the feature branch should have 4 commits.

• Experimenting with git merge

• Switch back to the main branch and merge it with the feature branch
• Run the command git log --oneline –graph --all

• Experimenting with git rebase

• While on the main branch, we are going to do a hard reset to go back to a
previous version of the code
• Run git reset --hard HEAD~1 (to be explained)
• Switch to the feature branch
• Run the command git rebase main
• Run git log --oneline --graph, compare this output to the one from git
merge.
 Working with branches – rebasing

Git merge Git rebase

• Preserves commit history • Rewrites commit history
• Creates a merge commit (in the • Does not create a merge
case when it’s not a fast-forward commit
merge) • Maintains chronological order
• Safer to use on shared branches • Not safe to use on shared
branches
OOPS,03
I messed
up
Undoing mistakes
• So, you being human made a mistake like
all other humans (except me, I’m a
demigod) and need to undo your mistake.

• In real-life, the best you can hope for is

another chance but in computer science,
we have a time machine known as git.

• In git, there are several ways one can

undo a mistake, we will cover the most
common ones.
 Undoing mistakes – git checkout
Working with
commits Working with files
• Looking at (checking out) a • Undoing unstaged changes: you
commit: git checkout <commit- modified a file but haven’t
hash> staged it yet and want to
• You can check out an old discard the changes: git
commit and create a new checkout -- <file>
branch from there: git checkout
–b new-branch. This is useful if • Recovering a deleted file that
you want to make modifications was in a previous commit: git
to some files in that commit. checkout HEAD -- <file>
 Undoing mistakes – git reset

Soft reset Mixed reset Hard reset

• You want to undo • You want to • Undoing a commit
the last commit discard the and discarding
but keep the commit and changes: git reset
changes: git reset unstage changes: --hard HEAD~1
–soft HEAD~1 git reset --mixed • Deletes the last
• Puts the last HEAD~1 commit and
commit in the • Unstages discards all
staging area and changes, does not changes from the
keeps all file delete them from working dir and
modifications. the working staging area.
directory

NB: HEAD~1 simply refers to the commit hash of the previous commit.
These commands can work using the hash of any commit.
Undoing mistakes – git revert and commit
--amend
Git revert Git commit --amend
• Git revert is used to undo a • A convenient way to modify the
commit without changing most recent commit: git commit
history: git revert --amend
<commit_hash>
• Lets you combine staged
• It creates a new commit that changes with the previous
undoes the changes from the commit instead of creating an
specified commit. entirely new commit.

• This is the safest option to use in • Can also be used to simply edit
the case of a collaborative the previous commit message
project with multiple
collaborators.
Working with
remote
repositories
Git vs Gitlab. Pushing, pulling,
handling conflicts
 Git vs (GitHub & Gitlab)
● Git vs (GitHub and Gitlab)
○ Git is a version control system that helps you track changes to your files
locally (on your computer).

● GitHub and GitLab are remote hosting platforms for git repositories. They add
collaboration tools on top of git, such as:
○ A central place to store and share code (remote repositories).

○ Pull/Merge Requests – Where others review your changes before they’re

accepted.

○ Issues and Project Management – A way to track work and discussions.

○ CI/CD Pipelines – Automated tests to ensure your code meets quality

standards before being served.
 Git vs (GitHub & Gitlab)
● Analogy: Cooking at home vs a family meeting
● Git is like cooking in your own kitchen.
○ You decide what to make, how to prepare it, and when to save your
progress (commit).
○ If you try a new recipe but don’t like it, you can always go back to an
earlier version (checkout a previous commit). Everything stays in your
kitchen.

● GitHub/Gitlab on the other hand are more like a family meeting

○ Each family (developer/team) prepares food (code) at home using their
own kitchen (local git repository).

○ When they’re ready, they bring their dishes to the meeting

○ At the gathering, everyone can taste each other’s food, or even mix
dishes together (collaborate on projects, submit pull/merge requests).
 GitHub vs Gitlab
● GitHub and Gitlab are both git repository hosting platforms.

● They both provide a web application (hosted by them) that users can use to
interact with the repositories hosted there.

● Gitlab is the only one of the two that can be self-hosted. Gitlab is an
application that you can download and run on your machine whereas GitHub
is only available online.

● GitHub is the most popular for open-source software. GitLab is preferred by

enterprises that need mor control.
 Working with remote repos
● A remote repository is a version of the repo stored on a different machine or
server, allowing multiple people to collaborate.

● Normally, services like GitHub/GitLab provide hosting, but here, we will

simulate it using another folder on the same machine.

● Creating a "Remote" Repository Locally

○ Create a directory to act as the remote repo (in the course’s folder)
mkdir git-remote
cd git-remote
git init --bare

○ The --bare flag tells Git that this repository will not contain working files
(since a remote repo is usually just for storing changes).

○ This simulates a remote repository like GitHub or GitLab.

 Working with remote repos
● Now, we need to connect our local repo to this remote repo
○ cd into our gitlab repo we created earlier
○ run the command git remote add origin ../git-remote
○ origin is the alias for the remote repo (you can call it whatever)
○ Try running git remote -v to show the linked remotes

● Our remote repo is currently empty, let’s push some code to it: git push
origin main

● Now we want to add some files, it is best practice to create a new branch
whenever you’re working on a feature. Create a new branch called feature-
branch

● Make a change (create a new file and commit)

echo "Hello, Git!" > file.txt
git add file.txt
 Working with remote repos
● Push the changes to the feature-branch on the remote repo: git push
origin feature-branch (this creates a new branch on the remote)
○ You can check if it worked by doing ls ../git-remote/refs/heads/, this
should show feature-branch
○ You can also cd into the git-remote folder and type git branch

● Ok, now we want to simulate pulling from the remote. Switch to the main
branch (git checkout main)

● Pull changes from the remote’s feature-branch: git pull origin feature-branch
(this is not the ideal way but for explanation purposes...)
○ This command merges the remote’s feature-branch into the local repo’s
main branch
 Working with remote repos
● We will create a merge conflict and then resolve it. We will do this by
modifying a file in both the main and feature-branch and trying to merge the
two.

● Ensure you’re on main: git checkout main

○ Modify file.txt and commit
echo "This line is from main." >> file.txt
git add file.txt
git commit -m "Update file from main"

● Switch to feature-branch
○ Modify file.txt different and commit
echo "This line is from feature-branch." >> file.txt
git add file.txt
git commit -m "Update file from feature-branch"
 Working with remote repos
● Merge branches
○ Switch back to main (git checkout)
○ Attempt to merge feature-branch: git merge feature-branch. Git will show
a merge conflict

● Resolve the conflict

○ Open file.txt and you’ll see:
 Working with remote repos
● Resolve the conflict
○ Edit the file manually to keep the desired lines. Let the file look like:

○ Mark the conflict as resolved

git add file.txt
git commit -m “Resolved merge conflict”

○ Push the resolved changes to the remote: git push origin main
 Working with remote repos
● Managing remotes
○ Adding remotes: git remote add remote_name remote_url e.g. git remote
add origin ../git-remote

○ Viewing remotes: git remote -v

○ Renaming a remote: git remote rename old_name new_name e.g. git

rename origin local_origin

○ Changing a remote’s url: git remote set-url remote_name new_url e.g. git
remote set-url origin ../git-remote/remote-repo

○ Removing a remote: git remote remove origin

 Working with remote repos
● Best practices recap
○ Always work on branches instead of main

○ Pull before pushing to avoid conflicts

○ Write clear commit messages

○ Resolve conflicts carefully and commit the resolved version

○ Use git remote commands to manafe repo connections.

● There’s still a world of git commands and functionalities out there but we have
covered the most essential. The rest you shall encounter on your
codeventures.