Lecture 7: Git

Dr.Omar Nasr + ChatGPT

What is Git?
Git is a popular version control system that allows you to efficiently manage and track
changes in your software projects. With Git, you can easily create, edit, and merge code
changes in a safe and organized manner. It is widely used for both individual and
collaborative software development, allowing multiple developers to work on the same
codebase simultaneously. By using Git, developers can work on their own local copies
of the codebase and then synchronize their changes with the central repository,
ensuring that everyone is always working with the latest code version. This makes Git
an essential tool for any software development team looking to streamline their
workflow and ensure efficient collaboration

Git stores the files in repositories. So what is a repo?

A "repo" is short for "repository" and it refers to a central location where you store your
code and other project files. In the context of Git, there are two types of repos: local and
remote.

A local repo is a copy of the central repository (the remote repo) that is stored on your
own computer. This allows you to work on the code and make changes to it without
affecting the main version. You can create, modify, and test the code in your local repo
before you commit it back to the central repo. This way, you can experiment with new
features or fix bugs without affecting the rest of the team.

A remote repo, on the other hand, is the main version of the repository that is stored on
a server or cloud-based platform like GitHub or GitLab. This is where all the changes are
ultimately stored and shared with the rest of the team. When you're ready to share your
changes, you can push them from your local repo to the remote repo, and everyone else
on the team can pull those changes down to their own local repos.
Basic terminology in Git:
1. Repository: A Git repository is a folder that contains all the files and version
history for a project. A repository can be either local or remote.
2. Local Repository: A local repository is a copy of the repository that is stored on
your local machine. This is where you make changes to the code and track the
history of those changes. You can create a local repository by cloning a remote
repository or by initializing a new repository in a local directory.
3. Remote Repository: A remote repository is a copy of the repository that is stored
on a remote server, typically on the internet. This is where the code is shared and
collaborated on with other developers. You can push changes from your local
repository to the remote repository and pull changes from the remote repository
to your local repository.
4. Clone: Cloning is the process of creating a copy of a remote repository on a local
machine. This creates a local repository that is identical to the remote repository.
You can clone a repository using its URL or by using a Git client, such as
GitKraken or SourceTree.
5. Commit: A commit is a snapshot of changes made to a file or group of files. Each
commit has a unique identifier and a message describing the changes made.
Commits are made in the local repository. You can view the history of commits
and revert to previous commits if necessary.
6. Branch: A branch is a separate version of the codebase that allows developers to
work on different features or fixes simultaneously without interfering with each
other. Branches can be created in either a local or remote repository. You can
create a new branch from an existing branch, switch between branches, and
merge branches when you are ready to incorporate the changes into the main
branch.
7. Merge: Merging is the process of combining two or more branches into a single
branch, typically to incorporate changes made in one branch into another.
Merging can be done in either a local or remote repository. You can merge
branches using various merge strategies, such as fast-forward merge or
recursive merge.
8. Fetch: Fetching is the process of downloading the latest changes from a remote
repository to your local repository, but without automatically merging them into
your local branch. This allows you to review the changes before merging them.
9. Push: Push is the process of uploading changes from the local repository to the
remote repository. This allows other developers to access the changes you have

1
 made. You can push changes to a specific branch or the main branch, depending
on your workflow.
10. Pull: Pull is the process of downloading changes from the remote repository and
merging them into the local repository. This allows you to stay up-to-date with
changes made by other developers. You can pull changes from a specific branch
or the main branch, depending on your workflow.
11. Pull Request: A pull request is a request to merge changes from one branch to
another. It allows other developers to review and discuss the changes before they
are merged. Pull requests are made in the remote repository. You can open a pull
request when you are ready to merge changes from your branch to the main
branch and assign reviewers to provide feedback.

Basic Git flow starting from a github repo

1. Create a new repository on GitHub:
● Go to GitHub and log in to your account.
● Click on the "+" icon on the top right corner of the screen and select "New
repository".
● Give your repository a name (e.g. "my-git-repo") and description.
● Choose whether you want it to be public or private. It is easier to start with public
repo
● Click on "Create repository".
2. Clone the repository:
● Open the terminal on your local machine and navigate to the directory where you
want to clone the repository.
● Copy the HTTPS or SSH URL of your repository from GitHub.
● Run the command "git clone [URL]" in your terminal, replacing [URL] with the URL
you copied from GitHub.
● The repository will be cloned to your local machine.
● Note: After running the git clone command, a new folder will be created in the
current directory on your local machine. This folder will contain a copy of the
entire repository, including all files and directories, as well as the full Git history.
You can now make changes to the files in the local repository and use Git
commands to manage those changes. Note that any changes you make to the
local repository will not be reflected in the original repository on GitHub until you
push those changes back to the remote repository using the git push command.

2
 3. Set username and email:

When using Git, it's important to set your global username and email so that your
contributions to the repository can be properly attributed to you. To do this, open the
terminal and run the following commands:

git config --global user.name "Your Name"

git config --global user.email "[email protected]"

Replace "Your Name" with your actual name and "[email protected]" with your
actual email address. These commands will set your global Git username and email to
the values you specify, which will be used for all commits you make on your local
machine. This ensures that your contributions are properly attributed to you and helps
to avoid confusion when collaborating with other developers.

4. Make a commit:

Definition: a commit is a snapshot of the current state of the repository at a given point
in time. It records changes to one or more files, along with a message that describes
the changes made. When you create a commit, Git saves a copy of the files that were
changed and adds metadata, such as the author and timestamp of the commit, to the
repository's history. Commits are used to track changes to the codebase over time, and
they provide a way to revert to a previous version of the code if necessary. In other
words, a commit is a fundamental unit of change in Git, and it represents a complete
and self-contained change to the repository that can be shared with others.

● Navigate to the cloned repository on your local machine. The folder name will be
the same as the repo name. This will be called working directory
● Open a text editor and create a new file in the repository directory (e.g.
"hello-world.txt").
● Add some text to the file (e.g. "Hello, World!").
● Check the status of the files in the folder by running “git status”
○ Note, to track a file in git, it should be added using “git add <filename>”
once. Any file that is in the working directory, but not added using “git add”
will NOT be tracked by git.
● Run the command "git add ." to stage the changes you made.
○ Staging is the process of preparing changes to one or more files to be
included in the next commit. It allows you to group together related

3
 changes and create a logical commit history for your repository. For
example, if you are making changes to a header file and a source file, you
can stage both files using the git add command and then make a single
commit that includes both changes. Git will take a snapshot of the
repository that includes the changes to both files, allowing you to track
changes to your codebase over time. In summary, staging enables you to
create well-organized commits that capture multiple related changes to
your repository.

● Run the command "git commit -m 'added hello-world.txt'" to commit the changes
with a descriptive message.
● Check the history of your commits by running “git log”
● Note: If you have made changes to a file in your local Git repository and want to
commit those changes as a new version, you should start by using the “git add
<filename>” command to add the modified file to the staging area. Once the file
has been added to the staging area, you can use the “git commit” command to
create a new commit with the changes. This ensures that the changes you've
made are included in the next commit you make.
● Change the file, add it, commit, and then try git log and git status few times to get
familiar of how to use it

This is a sample output that you will get

commit d5b580d7c6e23089ab5c67a6d023698f5b9212c4 (HEAD -> master)

Author: omaranasr <[email protected]>

Date: Wed Apr 19 11:47:40 2023 +0200

this is my second commit

commit 13bf4a8c235ad3d442202b81f291eb54c5e73ea4

Author: omaranasr <[email protected]>

Date: Wed Apr 19 11:44:16 2023 +0200

this is my first commit

4
Note: In the above, "commit d5b580d7c6e23089ab5c67a6d023698f5b9212c4 (HEAD ->
master)" contains two important pieces of information:

● The hash: "d5b580d7c6e23089ab5c67a6d023698f5b9212c4" is the unique

identifier for the commit. Every commit in Git has a unique hash that identifies it,
and this hash is used to track changes and reference commits in other Git
commands.
● The branch name: "(HEAD -> master)" indicates that this commit is on the
"master" branch, and that the "master" branch is currently checked out (i.e., it is
the active branch). The "master" branch is a default branch name in Git that is
often used as the main development branch for a project. By default, Git creates
a new "master" branch for each new repository you create.

Definitions: Tracking and staging:

1. Tracked files: These are files that are currently being managed by Git, either
because they have been previously committed or added to the staging area using
the git add command. Git keeps track of changes made to tracked files, making
it easy to see what changes have been made over time. The main difference
between tracking and staging is that tracked files have already been committed
or staged, while staged files are changes that are ready to be committed but have
not yet been committed.

To track a file, you can use the git add command followed by the filename(s) of the
file(s) you want to track. For example, to track a file named "newfile.txt", you can run git
add newfile.txt. Note, if the file is added even once, it is considered as a tracked file
even if it is included in the current commit

2. Staged files: These are files that have been modified and added to the staging
area using the git add command. Staged files are included in the next commit
you make, meaning that the changes you've made to these files will be saved in
the Git repository. The main difference between staging and tracking is that
staging is a step in the process of committing changes, while tracking refers to
the ongoing management of files in the repository.

5
To stage changes, you can use the git add command followed by the filename(s) of
the file(s) you want to stage. For example, to stage all changes in the current directory,
you can run git add .. To stage specific changes in a file, you can run git add
filename.

3. Unstaged files: These are files that have been modified but have not been added
to the staging area using the git add command. Unstaged files are not included
in the next commit you make, meaning that the changes you've made to these
files will not be saved in the Git repository unless you add them to the staging
area first.

To unstage changes, you can use the git reset command followed by the filename(s)
of the file(s) you want to unstage. For example, to unstage all changes, you can run git
reset. To unstage specific changes in a file, you can run git reset filename.

4. Untracked files: These are files that are not being tracked by Git, either because
they have not yet been added to the staging area using the git add command or
because they have been added to the repository but not yet committed.
Untracked files are not managed by Git and will not be included in the repository
unless you add them to the staging area first.

To untrack a file, you can use the git rm command followed by the filename(s) of the
file(s) you want to untrack. For example, to untrack a file named "oldfile.txt", you can run
git rm oldfile.txt.

Question: can you change a file and don't add it in the current commit

Answer: Yes, you can change a file and not add it to the current commit by leaving it in
the "unstaged" state. To do this, you can make changes to the file in your working
directory, but instead of using the git add command to stage the changes, you can
simply skip the staging step and go straight to creating the commit.

When you run the git commit command without first staging the changes using git
add, Git will create a commit that includes only the changes to files that were already
staged. Any changes to unstaged files will be left out of the commit and will remain in
the "unstaged" state.

6
 5. Pushing to remote repo:

In Git, pushing refers to the process of sending your local repository changes to a
remote repository, typically hosted on a platform like GitHub, GitLab, or Bitbucket. When
you push your changes, Git will upload the commits you have made to your local
repository, as well as any new branches or tags you have created, to the remote
repository.

Pushing is an important part of using Git for collaborative software development. By

pushing your changes to a remote repository, other developers on your team can access
those changes and collaborate with you. This allows you to work together on a project,
make changes, and track those changes over time.

When you run the git push command, Git will transfer the commits and other changes
you have made to the remote repository, updating the remote repository to include the
latest changes from your local repository. In order to push changes to a remote
repository, you will typically need to have permission to access the repository, and you
may need to authenticate yourself using a username and password or other credentials.

1. Use git status to check that you have committed the changes you want to push
to the remote repository.
2. Run git push -u origin master, where "master" is the name of the local
branch you want to push changes from.
● This command tells Git to push the changes you have made to the
"master" branch of your local repository to the "master" branch of the
remote repository named "origin".
● The -u option sets up a tracking relationship between your local "master"
branch and the "master" branch on the remote "origin" repository, so that
future pushes and pulls can be done without needing to specify the
remote branch each time.
3. After running the command, go to the remote repository on GitHub (or the
platform you are using). You will find that all changes made on your local
"master" branch have been reflected in the remote repository, including the
history of your commits.

7
 6. Branching:

Branching in Git refers to the process of creating a new line of development that
diverges from the main line, or "master" branch, of a repository. Each branch represents
a different version of the codebase, allowing developers to work on different features or
changes simultaneously without interfering with each other's work.

In simple terms, think of a branch as a separate copy of your codebase that you can
make changes to independently of the main copy. You can create a new branch for a
specific feature or bug fix, make changes to the code in that branch, and then merge
those changes back into the main branch when you are done.

Branching is a powerful feature of Git that allows developers to work on complex

projects with multiple contributors, without worrying about conflicting changes. By
using separate branches, developers can make changes to the codebase without
affecting the main copy, allowing them to experiment with new ideas and make changes
without fear of breaking the code.

In a local repository, branching allows you to work on different versions of the codebase
without affecting the main copy. You can create a new branch using the git branch
command, and switch between branches using the git checkout command. This allows
you to work on different features or bug fixes in parallel, without worrying about
conflicts with other changes in the codebase.

In a remote repository, branching allows multiple developers to work on different

versions of the codebase simultaneously. Each developer can create their own branch,
make changes to the code, and then push those changes to the remote repository. This
allows for collaborative software development, where different members of the team
can work on different parts of the codebase without interfering with each other's work.

● Run the command "git branch dev" to create a new branch called "dev".
● Run the command "git checkout dev" to switch to the new branch.
● Make changes to the code in the new branch and commit them as before (e.g.
remove lines and add new lines to the text file you created before). Don’t forget to
add the file and check the status and log of your commits.

8
 7. Switching between branches

To switch between branches in Git, you can use the git checkout command followed
by the name of the branch you want to switch to. Here are the basic steps to switch
between branches:

1. List the available branches in your local repository using the git branch
command. This will show you a list of all branches in your repository, with an
asterisk indicating the branch you are currently on.

$ git branch

* master

feature-branch

Bug-fix-branch

2. Choose the branch you want to switch to, and use the git checkout command
followed by the branch name. For example, to switch to the "feature-branch", run
the following command:
$ git checkout feature-branch

In the previous example, checkout the master branch and then open the text file.
Observe the content of the file. You should find the version of the text file that was
updated in the last commit of the last commit of the branch

8. Merge the branch:

Merging in Git refers to the process of combining two or more branches into a single
branch. This allows you to incorporate changes from multiple branches into the main
copy of the codebase. Here's how to do merging in a local Git repository:

1. Make sure you are on the branch you want to merge changes into. For example, if
you want to merge changes from the "feature-branch" into the "master" branch,
run the following command to switch to the "master" branch:
$ git checkout master

9
2. Run the git merge command followed by the name of the branch you want to
merge. For example, to merge changes from the "feature-branch" into the
"master" branch, run the following command:
$ git merge feature-branch

3. Git will try to automatically merge the changes from the specified branch into the
current branch. If there are no conflicts between the two branches, Git will
automatically merge the changes and create a new commit with the merged
changes. This can be the case if new files were added for example to the new
branch

4. If you receive a "Merge conflict" message when merging branches in Git, it means
that there are conflicting changes between the two branches that Git is unable to
automatically resolve. Here's how to resolve a merge conflict in Git:
1. First, use the git status command to check which files have conflicts.
This will show you a list of all files with conflicts, along with the message
"both modified" next to the file name.
2. Open the file with conflicts in a text editor. You will see that Git has
inserted special markers to indicate the conflicting changes. The changes
from the current branch are surrounded by <<<<<<< HEAD and =======
markers, while the changes from the other branch are surrounded by
>>>>>>> other-branch markers.
3. Edit the file to resolve the conflicts manually. Decide which changes to
keep, and remove the markers that Git added.
4. Save the file and exit the text editor.
5. After you have resolved all conflicts in the file, stage the changes using the
git add command.
6. Finally, commit the changes using the git commit command. Git will
automatically create a new commit with the merged changes.
7. If you still have other files with conflicts, repeat steps 2-6 for each file.
8. Check the log and the status of your repo
9. Once you have resolved all conflicts, you can push the changes to the
remote repository using the git push command.

10
 9. Check differences:

● Run the command "git diff dev" to see the differences between the main branch
and the dev branch.

10. Fetching from remote repo

Fetching in Git is the process of downloading the latest changes from a remote
repository to your local repository without merging those changes into your local code.
This means that the changes are downloaded and stored locally, but they are not
automatically applied to your code. Fetching is useful when you want to stay up-to-date
with the latest changes in the remote repository, but you are not yet ready to merge
those changes into your local codebase.

When you run git fetch in your local repository, Git will download the latest changes
from the remote repository and store them in your local repository's database. The
downloaded changes are stored in a separate branch in your local repository called
origin/master (assuming the remote branch is master), which is used to track the
remote branch's changes.

After running git fetch, you can use the git diff command to compare the changes
between your local repository and the remote repository. This allows you to review the
changes before merging them into your local code.

Fetching is an important part of the Git workflow because it allows you to stay
up-to-date with the latest changes in the remote repository without affecting your local
codebase. This means that you can review and test the changes before integrating
them into your code, which can help prevent errors and ensure that your codebase is
always up-to-date.

Here's how you can review the differences between your local repository (the last
commit of local repo) and the remote repository:

1. Open your terminal or command prompt and navigate to the root directory of
your local repository.
2. Run the following command to fetch the changes from the remote repository:

11
git fetch

Once the fetch is complete, run the following command to see the difference between
your local repository and the remote repository:

git diff HEAD origin/master

3. This will show you the differences between your local repository (HEAD) and the
remote repository (origin/master).
4. Review the differences carefully to ensure that you understand the changes.
5. If you are satisfied with the changes, you can merge them into your local
repository by running the git merge command.
6. If you are not satisfied with the changes, you can discard them by running the git reset
command.

By using git fetch and git diff, you can review the changes between your local repository and the

remote repository before merging them. This can help you ensure that the changes are correct and

that they reflect the desired changes to the codebase.

Question: What is the difference between Git pull and git fetch?

Answer: git pull and git fetch are both Git commands that allow you to update your
local repository with the latest changes from a remote repository. However, they work in
slightly different ways.

git pull is a combination of two Git commands: git fetch and git merge. When you
run git pull, Git will download the latest changes from the remote repository and
merge them into your local branch in a single step. This means that the changes in the
remote repository are automatically applied to your local codebase.

git fetch, on the other hand, downloads the latest changes from the remote repository
to your local repository but does not automatically apply them to your local branch. This
means that you can review the changes and decide whether to merge them into your
local branch.

12
The main difference between git pull and git fetch is that git pull automatically
merges the changes into your local codebase, while git fetch only downloads the
changes and leaves it up to you to decide whether to merge them.

The advantage of using git fetch is that it allows you to review the changes before
merging them into your local codebase. This can help prevent conflicts and ensure that
the changes are correct before they are applied to your local code.

In summary, git pull is a convenient way to update your local codebase with the latest
changes from the remote repository, while git fetch is a more flexible option that
allows you to review the changes before merging them into your local codebase.

Installing Git
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

Git cheat sheet

https://wac-cdn.atlassian.com/dam/jcr:e7e22f25-bba2-4ef1-a197-53f46b6df4a5/SWTM-2088_At
lassian-Git-Cheatsheet.pdf?cdnVersion=960

A nice article about Git

https://medium.com/@george.seif94/a-full-tutorial-on-how-to-use-github-88466bac7d42

13