Version Control Using Git

ELECTGON
www.electgon.com
contact@electgon.com

19.04.2024
Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 What is Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Version Control systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Topologies of Repository Systems . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Centralized Version Control systems (CVCS) . . . . . . . . . . 4
1.3.2 Distributed Version Control Systems (DVCS) . . . . . . . . . . 5
1.4 Tools Used in Each Topology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Git Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Snapshot Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Staging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 HEAD Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Git Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Git Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Download Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Con igurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Building a Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Initialize or Copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Cloning From Different Machine . . . . . . . . . . . . . . . . . . . . . . . 10
5 Setting Repository for Multiple Users . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Create Repository as Shared: . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Create Shared Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Multiple Users for Multiple Repositories . . . . . . . . . . . . . . . . . . 12
6 Remote Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Generate ssh‐key at Client Side . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2 Add ssh‐key at Server Side . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3 Limiting User Activities to Git Only . . . . . . . . . . . . . . . . . . . . . . 14
6.4 Saving Credentials Locally only . . . . . . . . . . . . . . . . . . . . . . . . 15
7 Files Operations in Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Files Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Adding/Committing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.3 List iles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.4 Fix Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2
Version Control Using Git Contents

7.5 Remove Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7.6 Remove File in Old Commits . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.7 Ignore Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.8 Types of Allowed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8 Local and Remote Repositories Communication . . . . . . . . . . . . . . . . . . . 19
8.1 De ine Remote Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2 Push Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3 Pull Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.4 Fetch Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9 Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1 View Branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2 Create Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.3 Switch Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.4 Delete Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.5 Merge Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.6 Merge Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.7 View Content of Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.8 Pushing to Remote Repository . . . . . . . . . . . . . . . . . . . . . . . . 23
9.9 Track Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10 Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11 Repository Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.1 History Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.2 Difference Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.3 Check Difference with External Tool . . . . . . . . . . . . . . . . . . . . . 26
12 Submodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1 Adding Submodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.2 Clone Submodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.3 Get Submodule Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.4 Push Submodule Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1 Basic Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.2 Fork and Pull Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1 Create Repository at Server from Client . . . . . . . . . . . . . . . . . . . 36
14.2 Files Shared between Different Branches . . . . . . . . . . . . . . . . . . 37
14.3 Check Status of Speci ic File . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.4 Branch Merge Con lict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.5 Merg Branches in GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
15 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3
Version Control Using Git 1. Introduction

1 Introduction
1.1 What is Repository

In software development, a repository is a central ile storage location. It is used by version

control systems to store multiple versions of iles. While a repository can be con igured on a
local machine for a single user, it is often stored on a server, which can be accessed by multiple
users.[1]

1.2 Version Control systems

Version control is used to manage multiple versions of computer iles and programs. A version
control system, or VCS, provides two primary data management capabilities. It allows users
to
1) lock iles so they can only be edited by one person at a time, and
2) track changes to iles.[2]

1.3 Topologies of Repository Systems

There are currently many version control systems in the market. Some of them are open
source, others are proprietary. These tools, however is classi ied into two types:

1.3.1 Centralized Version Control systems (CVCS)

First let’s look at CVCS as shown in igure 1. The central repository serves as the hub and
developers act as separate spokes. All work goes through the central repository. This makes
version control easy and sharing dif icult.

Figure 1: CVCS System

When you’re working with a centralized version control system, your work low for adding
a new feature or ixing a bug in your project will usually look something like this:

• Pull down any changes other people have made from the central server.

• Make your development, and make sure they work properly.

• Commit your changes to the central server, so other programmers can see them.

4
Version Control Using Git 1. Introduction

1.3.2 Distributed Version Control Systems (DVCS)

With DVCS there is more interaction directly between developers as shown in igure 2. Systems
are designed with the intent that one repository is as good as any other, and that merges from
one repository to another are just another form of communication.

Figure 2: DVCS System

When you work with distributed version control system, your work low will be like this:

• Cloning the original repository, you will have local repository then.

• Make your development, and make sure that they are working properly.

• Commit your changes to your local repository.

• If you want to update other repository, you push your updated repository to the target
repository.

1.4 Tools Used in Each Topology

Here are most common softwares used as version control systems

CVCS: Open Source: CVS – Subversion (SVN) ‐ Vesta

Proprietary: IBM Rational ClearCase – Perforce – Team Foundation Server.

DVCS: Open Source: Bazaar – Git – Mercurial.

Proprietary: BitKeeper – Sun Workshop.

5
Version Control Using Git 2. Git Basics

2 Git Basics
2.1 Snapshot Storage

Git has been created and started to be used since 2005. It is storing versions of tracked iles
as “snapshot” of the ile. This means it is storing a copy of the entire ile when it is changing.
Conventional storing method in other version management tools is based on storing the
difference between versions of the ile. In Git when user is committing new version of a ile,
Git is storing the entire content of the ile, not the difference only. Other unchanged iles, Git
keeps a reference to it without copying it again. In that way a snapshot in Git means copying
changed iles and copy a reference (pointer) to unchanged iles.

2.2 Staging

Storing iles to Git repository is done in two steps, add then commit. This because Git needs
to take snapshot irst of the tracked iles then stores it. The irst step then (which is called
add) is adding the iles to a stage in which Git can take snapshot. Second step (which is called
commit) is storing or registering the copied snapshot into the repository.

2.3 Branching

As any usual version management tool, You can create many branches in your repository.
Each branch is able to store set of iles. This branching enables users from distributing and
organizing their design iles according to functionality or customer needs or implementation
methodology etc.

2.4 HEAD Pointer

Using any version management tool means that different and many iles are checked out
into the repository. In Git there is one pointer called HEAD is pointing to the last commit
by default. User can move the HEAD pointer to switch between recent or old commits.

2.5 Tagging

User can mark special commits with a tag. This is used to easily switch to this special commit
using the attached tag name. This tagging is used usually for labeling releases of the design
iles. Figure 3 shows how a repository looks like using these terminologies.

6
Version Control Using Git 2. Git Basics

Figure 3: Repository Structure Sample

2.6 Git Commands

Git is basically a command line tool in which we use a terminal window to issue git commands.
Git is using the following sample format when using it
 
$git CommandName <options> <values>
 
This means each command de ined in Git shall be associated irst with the word ’git’ to
direct the terminal to invoke git for running the commands which are case sensitive commands
and can be found at this link
https://git‐scm.com/docs
When Git is invoked, it will check irst whether the current directory is a repository directory
or not. This is because Git commands are used performed in a repository directory. If the
directory is not a repository, Git will result in error message if you tried to execute any of its
commands.
Many GUI tools exist for dealing with Git in Graphical User Interface to support different
users lavors. Most and common tools used for that is GitHub which is a web‐based interface
used to create and handle repository actions. Not only but also some packages are installed
with git to visualize the repository like gitk tool which can be invoked simply by
 
$gitk
 
Or another gui interface can be invoked by typing
 
$git gui
 

7
Version Control Using Git 3. Git Setup

3 Git Setup
3.1 Download Git

If you are working in Windows, go to this link to start downloading Git for windows:
http://git‐scm.com/download/win
Then start setup Git as any normal program.
If you are working with Linux, in a Terminal window then simply install Git by
 
$apt-get install git
 
Most Linux distributions come already with installed Git. You can make sure if it is installed
by typing
 
$which git
 

3.2 Con igurations

For launching Git in irst time, you have to provide some information . This information is
used by Git to track modi ications done in iles of your working repository. This can be set
using the command
 
$git config <option> <value>
 
Also some general con igurations can be done using this command like color of branches,
status, etc. To see current set con iguration for your Git setup, you can type
 
$git config --list
core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
...
 
What is needed actually at this step is your user name and email, this can be provided by:
 
$git config --global user.name "Working Tester"
$git config --global user.email tester@test.tst
 
you can later check that your user name is set by running:
 
$git config user.name
 

8
Version Control Using Git 4. Building a Repository

4 Building a Repository
A repository in git is meta‐data of different versions of the tracked iles. This meta‐data is
usually hidden as a .git ile in the directory of the created repository. Git repositories are able
to track only iles and folders of the repository directory i.e. it can’t track iles outside its
directory.

4.1 Initialize or Copy

To get a Git repository, you can create it or you can copy an existing repository. To create a
repository, it is advised always to think irst if it will be a local repository or it will act as a
central repository. Local repository means that it is aimed to include iles of one developer.
Of course it can be shared later with other developers but what is meant more is the user who
created it is going to track his own iles.
What is meant by central repository is a repository that is used by all users as a reference
or as a baseline. It doesn’t contain any design iles, it contains only the meta‐data. Knowing
that Git is a Distributed Version Control system, this can cause confusion about this local and
central types of repositories. To clarify it, originally in Git you can copy any repository from
or to any other user. But once copied, you can’t update the remote repository (that you copied
from) with any changes you made in your iles. You can update only a “central” repository. As
a side note, you are allowed to update other remote local repository but you have to con igure
that remote repository.
Git is designed to work so. To make difference then between the normal local repository
and the central one, when creating the repository you have to mention that. Central repository
in Git is known as bare repository. So to create a bare repository you can write the command
 
$git init --bare <name_of_created_repository>
 
or you can also create a bare repository from an existing normal one by typing
 
$git clone --bare <path_to_remote_normal_repository> <name_of_copied_repository>
 
Bare repository means that this repository contains only the meta‐data. No tracked iles
are stored in that repository. If you can browse to this bare repository in your ile system,
you will ind it contains only meta‐data. Clone means to get a copy of the remote repository
and handle this copy as a bare repository.
Without this mentioned switch “bare”, the created repository will be handled as a normal
local repository. For example, lets create a simple local repository called RepoA in a directory
called userA
 
$mkdir -p userA
$cd userA
$git init RepoA
 
In another directory (assume it is called userB), lets create another local repository by
cloning ReopA

9
Version Control Using Git 4. Building a Repository

 
$cd ..
$mkdir -p userB
$cd userB
$git clone ../userA/RepoA
 
Note here that we didn’t specify new name for the copied repository so that it will copied
with the same name. Now after adding some iles to the copied repository, if you tried to
update the original remote RepoA with these changes, it will give an error like in igure 4.

Figure 4: Error in Updating Remote Repository

This error resulted as we tried to update the original repository which is not a bare one.
More details about how to add iles and update the repository will follow in next sections.

4.2 Cloning From Different Machine

In case of cloning from a remote machine, this can be easily done by de ining the username
and destination machine before the target repository path
 
$git clone username@hostmachine.com:/path/to/target/repository
 
or using the IP address of that machine
 
$git clone username@1.2.3.4:/path/to/target/repository
 

10
Version Control Using Git 5. Setting Repository for Multiple Users

5 Setting Repository for Multiple Users

When Git repository is initialized, by default it will be initialized to a single user. Working with
a team requires then to give access for team co‐workers to the initialized repository in order
to be able to push and pull their work iles. In con iguration step, we have seen how we can
setup user name and email to be associated with the created repository. Git is NOT designed
to have multiple user names in one repository. This means that there is no mechanism in Git
to setup multiple user names in the repository. By default the user account who has created
repository is the only user who can push and make changes to the repository.
In order to overcome this point and allow team co‐workers to push and make changes in
the repository, there are mainly two con igurations can be used for that.

5.1 Create Repository as Shared:

Although you can not create multiple users for the Git repository but there is another option
while creating the repository to allow access from multiple user accounts. This option is to
de ine the repository as a shared repository. This can be set using the following command
while creating the repository
 
$git init --bare --shared=group RepositoryName
 
If the Git repository already created and you would like to modify it to be shared use the
following command then
 
$git config core.sharedRepository group
 
By con iguring the repository to be shared to group, this means that any user account
who has read and write permissions on the directory in which the repository is located will
be able to push and make changes to the repository. Simply, if the Git repository is located
in directory RepoDir, group members who has read and write permissions will be able to
modify the repository. Because of that, you have to make sure that needed user accounts are
included in the directory group. So it is always advised to de ine a group for Git users in your
Operating System, then assign group property of RepoDir to the created Git group. This can
be carried out using the following commands
 
$chgrp GitUsers /path/to/RepoDir
$chmod g+ws /path/to/RepoDir
 

5.2 Create Shared Account

The other way to have multiple access on the repository is to share the user account who is
registered in the Git repository with your team co‐workers. Each member of the team will
use this account then to push and pull from the repository. We can show here how we can
add this user account in Linux system. For our demo here, lets create a user called ProjUser.
 
$sudo adduser ProjUser
 

11
Version Control Using Git 5. Setting Repository for Multiple Users

then add password for this user.

Note that the way how a user account to connect to a remote git repository is discussed
in next section when discussing connection using SSH.

5.3 Multiple Users for Multiple Repositories

It worth mentioning here that it is possible to create different Git repositories, each repository
can be con igured with its dedicated used account. In Git you can create a global user name to
be used for any created Git repository in a machine. despite that, you can create a repository
with a dedicated user name but not as a global one. In this case, the assigned user name will
be local only to this speci ic Git repository. The following commands can be used to con igure
a local user name.
 
$git config user.name "Local User Name"
$git config user.email "name@local.com"
 
Remember how a global user name was created as discussed in previous section with the
option –global.

12
Version Control Using Git 6. Remote Connection

6 Remote Connection
In previous section we have discussed main settings and preparations for having multiple
users who can access the Git repository. If all team co‐workers are working on the same
machine, accessing the repository is a local operation then. But for a user who wants to access
a remote repository, connection protocol has to be de ined then. Although this discussion is
not related to Git operations or con iguration, however it may be useful to mention it for
having clear and complete guide while working with Git.
Git allows for remote connection using http protocol or ssh protocol or special git protocol.
This simply means we can clone a git repository using one of these protocols. For example
you can download Linux kernel using git over http protocol
 
$git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
or using git protocol
 
$git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
The case of using SSH protocol is discussed more here as it is connected more with software
development work structure. To clone a Git repository over SSH protocol this can be done in
similar way
 
$ git clone ssh://[UserAccount@]RemoteServer/GitProject.git
 
or shortly as
 
$ git clone [UserAccount@]RemoteServer:GitProject.git
 
In previous section we have seen example for cloning a repository using SSH protocol.
 
$git clone username@hostmachine.com:/path/to/target/repository
 

6.1 Generate ssh‐key at Client Side

What worth mentioning here is in SSH protocol an ssh‐key is needed while connecting from
one machine to another. So if the main Git repository is located in a remote server, a client
machine has to send ssh‐key to the server in order to get permission from the server to access
its ile system. Currently ssh‐key is generated automatically if the user has logged in with
right credential. Note here that ssh‐key is generated for the client machine i.e.not for the
accessing account. To avoid confusion, The logged in account is already setup in the server
machine, but still a security step has to be veri ied by the server in order to be sure that the
user is logging from a secure machine. So this security step is achieved by generating ssh‐key
for the connected machine.
In case of Linux, to generate an ssh‐key this can be simply done by
 
$ ssh-keygen
 
The generated key will be saved in id_rsa.pub ile ile. You can view this key using the
following command

13
Version Control Using Git 6. Remote Connection

 
$ cat ~/.ssh/id_rsa.pub
 
This id_rsa.pub ile shall be sent to server administrator in order to add it in public ssh‐
keys ile as will discussed in next steps.

6.2 Add ssh‐key at Server Side

At server side, you can give permission to certain machines to access the server using these
generated ssh‐keys. This can be done as discussed in the following steps
Go to home directory of the user that you want to add trusted machines to his account,
display content of home directory of that user, we need to review hidden folders and iles,
 
$ls -al
 
If a folder called .ssh is not created yet, so create it
 
$mkdir .ssh && chmod 700 .ssh
 
we need now to create a ile called Authorized_keys this ile should contain all keys of the
trusted machines.
 
$touch .ssh/authorized_keys && chmod 700 .ssh/authorized_keys
 
what we need to do now is to write public ssh keys of these machines in this ile. Assuming
that, the user has generated the ssh‐key as discussed in previous steps in id_rsa.pub
 
$cat /path/to/id_rsa.pub >> ~/.ssh/authorized_keys
 
Thus, the server will allow to machines with ssh‐key registered in that ile to access the
ile system.

6.3 Limiting User Activities to Git Only

There is more restriction that can be done for the user who is accessing the remote server.
We can limit this user to do only Git activities. This can be done with a limited shell tool called
git‐shell that comes with Git. To do so, you must irst add git‐shell to /etc/shells
Note: you have to be root in order to be able to edit this ile.
First you have to know where is the path to git‐shell
 
$which git-shell
 
it will be usually in /usr/bin/git‐shell. Then go to etc directory
 
$cd /etc
$vim shells
 
then add path of git‐shell to this ile. Now you can edit the shell for a user using
 
$sudo chsh GitUserName
 
this will ask for which shell you want to limit this user, enter path to the desired shell:
/usr/bin/git‐shell
you can test if this is working by opening another remote machine and type the following

14
Version Control Using Git 6. Remote Connection

 
$ssh GitUserName@ip.of.the.server
 
it should ask for the password of GitUserName, enter the password. You should receive
error message as:
 
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to 192.168.147.161 closed.
 
This means that user is not allowed to login using normal ssh protocol. He is allowed to log
in only within git command (“git clone ssh:\\GitUserName@ip.of.the.server” for instance).

6.4 Saving Credentials Locally only

Instead of generating ssh key and storing this key at both client and server, you can use the
following command to save username and password of the remote server.
 
$git config credential.helper store
 
When executing irst “push” or “pull” command, the username and password of the user
will be stored in an ASCII ile called (.git‐credentials) which will be stored in /home/<user>
directory. But note that using this method the credentials are stored as plain text in the ASCII
ile. So make sure that you are the only one who is able to read this ile.

15
Version Control Using Git 7. Files Operations in Git

7 Files Operations in Git

Assuming now that we have a Git repository. Whether it is created locally or cloned from
remote machine, the repository will have a hidden folder called .git where con igurations
and settings of the repository are stored in.

7.1 Files Status

To start tracking or adding iles to Git repository we have to know irst that Git is able to
track iles and folders within its directory only (directory that have .git folder). So Whenever
there is a ile in that directory Git repository prompts user about this ile if the user checked
repository status. The following command is used to check status of the repository
 
$git status
 
To understand this, we can do quick demo by creating a repository and checking its status
by issuing the following commands
 
$git init StartRepo
$cd StartRepo
$git status
On branch master
Initial commit
nothing to commit(create/copy files and use "git add" to track)
 
If there is any new ile or directory has been created in the Git repository, Git will prompt
about it if we checked the status again. So lets create a ile in the Git repository
 
$touch Userfile_01.txt
$git status
On branch master
Initial commit
Untracked files: (use "git add <file>..." to include in what will be
committed)
Userfile_01.txt report.txt
nothing added to commit but untracked files present (use "git add" to track)
 

7.2 Adding/Committing

As discussed before, checking in a ile in Git repository is done in two steps, add then commit.
To clarify how this can be used, we can use previous quick demo. Add the created ile
 
$git add Userfile_01.txt
$git commit -m 'initial commit'
[master (root-commit) 10ee409] initial commit 1 file changed, 0 insertions(+),
0 deletions(-)
create mode 100644 Userfile_01.txt
 
so $git add is used to add the ile to the stage, $git commit is used to check in the ile in the
repository. In the case of commit a message must be mentioned about committing process
which is attached using ‐m switch in previous example.

16
Version Control Using Git 7. Files Operations in Git

7.3 List iles

In our demo so far we have checked in one text ile into the Git repository. Lets assume
now that we have checked in other C iles. To check which iles do we have currently in the
repository we can use ls‐ iles command
 
$git ls-files
Userfile_01.txt
find_frame.c
find_frame.o
frames_fn.h
load_frame.c
load_frame.o
 

7.4 Fix Commit

It can occasionally happen that user forgets to add some ile to make modi ications to some
exiting iles after the commit process has been done already. In this case you can use –amend
switch to amend last commit.
 
$git commit --amend
 
This command then will commit missed iles or modi ications with the last commit without
causing new commit to the repository.

7.5 Remove Files

Since iles are added in two steps. it is possible to remove a ile from the stage and also it is
possible to remove it after committing. To remove from the stage we can use reset option.
 
$git reset load_frame.o
 
You can remove ile from the repository using rm command. But you have to be careful
when using it. Using git rm will delete the target ile from the repository and from the directory
in your ile system. In order to remove a ile from the repository without deleting it from the
system use –cached switch
 
$git rm --cached find_frame.o
 

7.6 Remove File in Old Commits

Previous command will remove ile from last commit. But what if you need to remove the ile
from all old commits. The following command can be used for that
 
$git filter-branch --force --index-filter "git rm --cached --ignore-unmatch
path/to/file" --prune-empty --tag-name-filter cat -- --all
 
This command will remove the ile from all commits in which it exists. If you need to
update a remote repository with this prune step
 
$git push origin --force --all
 

17
Version Control Using Git 7. Files Operations in Git

7.7 Ignore Files

Usually during any software project development cycles, there are some iles that are not
needed to be added to the repository. For exampled compiled code (.o iles) in previous
example are not needed. So to direct Git repository not to include these iles we have to
create a ile called .gitignore in which we can list all iles that we don’t need to commit to
the repository. In our example here we can create this .gitignore ile then writing in this ile
which iles we need to ignore. Then, we commit this .gitignore ile to the repository.
 
$touch .gitignore
 
Then add your iles list. In our example here I have included the following iles to be
ignored
 
$cat .gitignore
*.o
report.txt
*~
 
which means any ile ending with .o shall be ignored. Also the ile report.txt shall be
ignored. Also any ile ending with ~ shall be ignored. Afterward, we have to commit this
.gitignore ile.
 
$git add .gitignore
$git commit -m "Adding Ignore File"
 

7.8 Types of Allowed Files

It is possible to store in git repository any type of iles. In general we can classify iles as Binary
iles or Plain Text iles. Binary iles are those that can’t be read by human. It contains only
binary data that are understood by running machine.This includes executable iles(.exe ‐ .elf ‐
.bin), image iles (.svf ‐ .png ‐ .psd), audio iles (.mp3 ‐ .wmv), compiled iles (.o), compressed
iles (.tar ‐ .zip), etc. Plain Text iles are iles that can be read by human as it is based on ASCII
characters. So we can call it ASCII iles. For example text iles (.txt), PDF iles (.pdf), Word
processing iles (.doc ‐ odt ‐.rtf), Programming iles (.vb ‐ .java ‐ .c), etc.

18
Version Control Using Git 8. Local and Remote Repositories Communication

8 Local and Remote Repositories Communication

When working in a team, design iles shall be updated among other team members (if needed)
or at least a central repository shall have consolidated design iles. This means design iles
created in a local repository shall be transferred to another remote repository. Whether
the remote repository is the one we cloned our repository or not, stored iles in Git can be
propagated using mainly push and pull commands which will be discussed here.

8.1 De ine Remote Repository

If you have cloned a repository from a remote repository, you can check some details about
this remote repository using remote command
 
$git remote
origin
 
Here, the default name set for the remote repository is “origin”. If you want to know where
this repository is located, you can use the command with ‐v option
 
$git remote -v
origin user_ex@192.168.178.87:C:/RepoC (fetch)
origin user_ex@192.168.178.87:C:/RepoC (push)
 
It is not necessary to have omni‐remote repository, we can have multiple repositories.
This can be done by adding needed remote repositories as follows
 
$git remote add DevA /path/to/remote/RepoA
$git remote -v
DevA /path/to/remote/RepoA (fetch)
DevA /path/to/remote/RepoA (push)
origin user_ex@192.168.178.87:C:/RepoC (fetch)
origin user_ex@192.168.178.87:C:/RepoC (push)
 
Provided path shall be any valid path and it is not necessary to write a path to a valid
repository as this will not affect any operation here. You can use later de ined name (DevA
for instance) to push and pull iles using this name.

8.2 Push Changes

After adding changes and make necessary modi ications in design iles, the developer now
needs to push changes that he made to the remote repository. This can be done using git push
command. Pushing action takes place after committing the changes to local repository.
 
$git clone path/to/remote/bare/repo
$cd repo
...
.. user makes modifications
...
$git add .
$git commit -m 'Developer Modifications'
$git push origin master
 

19
Version Control Using Git 8. Local and Remote Repositories Communication

Last command has been issued as git push origin master to direct Git to push changes to
a remote repository called origin and add these changes to branch master.
It worth mentioning here that if the remote repository has been modi ied before developer
pushing his changes back again, the remote repository will not accept any pushing operation
from the developer until he pulls new modi ications to his local repository irst.

8.3 Pull Changes

If remote repository from which we cloned a local repository has been modi ied (new iles
have been committed for instance), we can update the local repository using pull command
 
$git pull origin
 
We can use simply git pull without specifying name of remote repository, in this case Git
will use default name which is origin. This pull command actually is getting last modi ications
in remote repository and merges it with local repository which means it will overwrite existing
iles in the same name. If some iles were deleted in the remote repository, it will not be
deleted from the local repository as git pull is doing merge for the changes. So iles with
same name will be affected as it will be overwritten. Therefore developer has to be careful
when using this command and make sure if there are modi ications in the remote repository:
 
$git remote -v update
$git diff origin/master
 
In this command we have irst gotten updates from the remote repository, then we checked
the difference using diff command.

8.4 Fetch Changes

Because it is important to check changes in remote repository, There is one command in Git
which we can use to get changes irst without merging with local repository. In previous
section we have seen it usinggit remote update. It can be done also using f etch command.
 
$git fetch
$git status
On branch master Your branch is behind 'origin/master' by 3 commits, and can be
fast-forwarded.
(use "git pull" to update your local branch)
nothing added to commit, working directory clean
 
In this example, there were 3 commits difference between local and remote repositories.
To know what changes have been made, you can use git diff command as shown previously.
If the changes are accepted from your side, you then update your local repository using merge
command
 
$git diff origin/master
$git merge origin/master
 

20
Version Control Using Git 9. Branches

9 Branches
9.1 View Branches

Branching system in Git is quite simple. First you may want to check what branches currently
exist in the repository, you can do that using branch command
 
$git branch
* master
 
This command will show you current branches in the local repository. If you want to
check branches that are currently in remote repository, you may use ‐r switch
 
$git branch -r
 
By default, when you create new repository a default branch named as master is created
and this will be the starting or main branch.

9.2 Create Branch

Lets create new branch in our Git repository by issuing the following command
 
$git branch Cdesign
 
This will create new branch called Cdesign. Note that it will create only the branch without
switching to it. Now lets create another branch and see what are the branches do we have so
far.
 
$git branch Pydesign
$git branch
Cdesign
Pydesign
* master
 
Note an asterisk is marked beside the master branch to indicate that the Head pointer is
still pointing at this branch, which means any coming commit process will be attached to that
branch as long we keep the header there, no matter how many branches do we have.

9.3 Switch Branch

To activate (or to make Head points to) other branch, use the following command
 
$git checkout Cdesign
 
This will switch the repository to point to our new created branch. Which means any new
commit process will be attached to that branch.

9.4 Delete Branch

To delete a branch use the following command

 
$git branch -d Pydesign
 
where Pydesign is a branch name created previously.

21
Version Control Using Git 9. Branches

9.5 Merge Branch

In our example so far we have two branches: master and Cdesign. Lets add one ile in the
master branch
 
$git checkout master
$git add hello.c
$git commit -m "adding hello world example"
 
Lets now switch to Cdesign branch and add the same ile
 
$git checkout Cdesign
$git add hello.c
$git commit -m "adding hello world example"
 
Lets add more C iles in that branch
 
$git add find_frame.c load_frame.c
$git commit -m "adding frame files"
 
The repository will have now a structure like what depicted in igure 5

Figure 5: Initial Branch Structure Example

Note that in this example both branches have a ile called hello.c. Now it is possible to
merge branches in git using git merge command. Merging means to add contents of other
branch to the current branch. For example we can merge branch Cdesign into master branch
as follows
 
$git checkout master
$git merge Cdesign
 
The content of Cdesign will be in master branch now.

9.6 Merge Commit

It can happen that you don’t need to merge the whole branch but you need to merge speci ic
commit of that branch, in this case we can use “cherry‐pick” command to merge one speci ic
commit. In previous example lets assume that when we added “hello.c” ile that it has been

22
Version Control Using Git 9. Branches

committed with commit number “6e4592f b32”. To merge only the changes of this commit
number to our master branch, we can simply do the following
 
$git checkout master
$git cherry-pick 6e4592ffb32
 

9.7 View Content of Branch

You can have a look over what iles are included in the branch using the following command
 
$git ls-tree -r --name-only branch_name
 

9.8 Pushing to Remote Repository

After inishing your modi ications, you can push it to the remote repository by specifying
branch name as follows
 
$git push origin Cdesign
 
And to push all branches you can use the following
 
$git push origin --all
 
Here we will update remote repository with the branch Cdesign only. While pulling you
can specify also branch name to pull it only
 
$git pull remote_repo branch_name
 

9.9 Track Branch

It can happen that remote repository has some branches that are not created in the local
repository. If the developer wants to update his branches to be exactly like what it is in the
remote repository, he can use tracking property. Tracking originally is a technique used to
match between local repository and remote repository. Matching means that both branches
are linked so that if you typed git push it will be pushed to that matching branch without
mentioning remote name or branch name. The same goes also for git pull. By default master
branch in local repository is tracking master branch in remote repository. To know what
branch is tracking which branch, you can use the following command
 
$git branch -vv
 
For the case that developer wants to have updated repository with a new branch, irst he
has to recognize which branches already exist in the remote repository. Then he has to fetch
new updates. Then use –track switch to create and match the new branch that he wants
 
$git ls-remote
$git fetch origin
$git checkout --track origin/Cdesign
 

23
Version Control Using Git 10. Tagging

This –track switch can be altered with more detailed option in case you want to create
the new branch but with different name
 
$git checkout -b TempBranch origin/Cdeisgn
 
You can now check which local branch is tracking which remote branch
 
$git branch -vv
Cdesign 408a932 [origin/Cdesign] hello message
* TempBranch 408a932 [origin/Cdesign] hello message
master 50f6a8c [origin/master: behind 11] changes 05
 

10 Tagging
Tagging is used in git as a mark for commits. We can make use of it to name versions for our
design iles. To attach a tag simply type
 
$git tag -a v1.0 -m 'first version'
 
This will add a tag called v1.0 to the current branch.
To view all available tags of that branch type
 
$git tag
 
Important to note that tagging needs to be mentioned when push/pull to remote repositories.
For example if you have branch tagged with v1.2, when you inish and push your branch you
have to specify lag –tag in order to update the remote repository with the tag, typically you
can do that
 
$git push remote_rep branch_name --tag
 
or to update all branches with all its tags write
 
$git push remote_rep --tag
 
To switch between tags
 
$git checkout tag_label
 
To switch back to wherever you were before checking out
 
$git checkout -
 

24
Version Control Using Git 11. Repository Views

11 Repository Views
11.1 History Review

Since many commits are performed in the repository, it is needed sometimes to review history
of these commit actions. In Git you can review logs associated with each commit process
using git log command. It will display all logs for all commits. You can manage displayed
output. For example you can review last 3 commits using the following command
 
$git log --pretty=oneline -3
408a93282b388f8f91b35796106cb3de7759e8af hello message
202d547fe7450421fcf10fbbbfcda85e3b5819a3 new hello
0378dc9d6cc295d77970c9ac260431a6b43a4ffd Merge branch 'master' into Cdesign
 
As shown, this command list last three commits shortly in one line. The irst long number
is called the hash value of the commit and it is generated by Git. Second ield displays attached
message that was used during the commit process. You can use this hash value to switch
between different commits (if you didn’t add a tag for the commit. If you used a tag it is
easier to switch using tag value). It is not necessary to write the whole hash value you can
use lowest 5 integers for example. You can even manage how this hash value can be displayed
 
$git log --pretty=format:"%h: %s" -3 --name-only
408a932: hello message
hello.c
202d547: new hello
hello.c
0378dc9: Merge branch 'master' into Cdesign
 
In last example, we directed Git to display short hash value then the attached message.
Using –name‐only we could display which iles have committed in this commit.
Using this hash value, you can switch between different commits
 
$git checkout 0378dc9
 
or you can switch back the HEAD pointer by 3 commits using
 
$git checkout HEAD~3
 
To switch back to wherever you were before checking out
 
$git checkout -
 
You can view also simple graph about all commits and branches using the following command
 
$git log --graph --oneline --decorate --all
 

11.2 Difference Review

Using git log we can check difference occurred in a commit using the following command for
example

25
Version Control Using Git 11. Repository Views

 
$git log -p -1 --oneline
408a932 hello message
diff --git a/hello.c b/hello.c
index 651ed60..225a8ab 100644
--- a/hello.c
+++ b/hello.c
@@ -1,5 +1,5 @@
#include <stdio.h>
void main(void) {
-printf("Hello World \n");
+printf("Test Message \n");
}
\ No newline at end of file
 
where ‐p denotes display patch difference, ‐1 to check last commit only.
It worth mentioning here that you can check the difference before committing also using
git diff. For example, if we had changes in hello.c ile, we can check the difference before
adding the ile to stage as follows
 
$git diff hello.c
diff --git a/hello.c b/hello.c
index 225a8ab..d02120c 100644
--- a/hello.c
+++ b/hello.c
@@ -1,5 +1,5 @@
#include <stdio.h>
void main(void) {
-printf("Test Message \n");
+printf("Test Message 2 \n");
}
\ No newline at end of file
 
If the changes were added already to stage still we can check the difference using –cached
switch
 
$git diff --cached hello.c
 

11.3 Check Difference with External Tool

You can integrate a third party tool to work with Git. For example we use difference comparison
tool to check difference between old commits or between some iles. This can be done using
the difftool command. For example we can use Meld to compare between a modi ication done
in a ile and the committed version of the ile. First we have to make sure that the tool is
supported in git. This can be done use the following command
 
$git difftool --tool-help
'git difftool --tool=<tool>' may be set to one of the following:
vimdiff
vimdiff2
The following tools are valid, but not currently available:

26
Version Control Using Git 11. Repository Views

araxis
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
emerge
gvimdiff
gvimdiff2
kdiff3
kompare
meld
opendiff
p4merge
tkdiff
xxdiff
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
 
Output of this commands lists then Meld as one of the supported tools. If Meld is not set
in the environment variable PATH. Then we have to tell Git where to ind Meld. This can be
set in the con ig ile
 
$vim .git/config
 
The con ig ile shall be opened. Add the following con iguration in the ile
 
[difftool "meld"]
path = /path/to/meld.exe
 
Or instead of editing the ile manually, you can use the following command to add the
con iguration
 
$git config difftool.meld.path /path/to/meld.exe
 
The tool is now ready for working with Git. To compare a single ile we can use the
following command
 
$git difftool --no-prompt --tool=meld hello.c
 
Meld shall be opened then to show difference between current ile “hello.c” the previous
version. Note that –no‐prompt switch is used to ignore some con irmation questions from
Git. Instead of comparing single ile, we can compare the whole repository with the previous
commit using the following command
 
$git difftool --dir-diff --tool=meld 408a932
 
where 408a932 is the hash value of a previous commit. Using same method we can
compare between two old commits if we know their hash values
 
$git difftool --dir-diff --tool=meld 202d547 408a932
 

27
Version Control Using Git 12. Submodules

12 Submodules
Some users may need to import some repositories as sub‐directory into their main repository.
In other words, we can say, they need to have repository of a repository. Git provide one
method to handle such situations which is called submodule. Using submodule command
in Git, we can de ine some sub‐directories as a dedicated repositories. To declare that, lets
assume that we have a repository of some C source codes and inside this C source code
repository we have a sub‐directory that contains some documentation and guides about the C
source codes. The situation now is that we need to de ine this documentation sub‐directory
as a dedicated repository as it will undergo to many versioning. The case now is we have
repository of C source code which contains another repository of some documentation.

12.1 Adding Submodule

We can de ine a sub‐directory as a submodule of the main repository. This can be done using
the following command
 
$git submodule add <URL> <local_path>
 
where URL is the remote path form where we can clone the sub‐repository, local_path is
the path in which the sub‐repository resides in our local machine. The URL is optional if we
know that we work locally only. After that, you can add and commit changes into your main
repository as usual.

12.2 Clone Submodule

In case that you need to clone a repository that already has submodule, there are two way,
either to simply use the following command
 
$git clone --recurse-submodules <path_of_main_repository>
 
or you can do it in two steps
 
$git clone <path_of_main_repository>
$git submodule update --init --recursive
 
or even it can be done in three steps
 
$git clone <path_of_main_repository>
$git submodule init
$git submodule update --recursive
 
note that –recursive is optional, it is used if you know that your submodule has other
submodules.

12.3 Get Submodule Updates

Since the submodule is another repository, it can happen that this submodule repository got
changes in the remote source but the local version didn’t get these changes. We need then to
update the submodule with these remote changes. This can be done using

28
Version Control Using Git 12. Submodules

 
$git submodule update --remote <submodule_repo>
 
Or an easy way is to deal with the submodule as a normal repository, so navigate to it and
pull the updates
 
$cd <submodule_repo>
$git pull
 

12.4 Push Submodule Updates

If the case is that we have local changes in the submodule repository and we need to push it
to remote repository, then we need to commit the changes irst in the submodule repository
and push it
 
$cd <submodule_repo>
$git commit -am msg
$git push
 
or if you want to push it only when you push changes of the main repository, you use the
following
 
$cd <submodule_repo>
$git commit -am msg
$cd -
$git commit -am msg
$git push --recurse-submodules=on-demand
 

29
Version Control Using Git 13. GitHub

13 GitHub
13.1 Basic Operations

GitHub is one of the important tools that are built to provide Git as an interface for users. It
became wide platform for publishing source codes for millions of users as it is a web‐based
interface. Users can clone easily any public repository using http protocol. It can be accessed
at this link
http://github.com
You can create account simply and start building repositories. Main operations that were
discussed before using command line interface can be operated in this web interface also.
Figures 6, 7, 8 show graphical interfaces for creating repository, adding ile and commit.

Figure 6: Create Repository in GitHub

30
Version Control Using Git 13. GitHub

Figure 7: Adding File in GitHub

Figure 8: Commit File in GitHub

31
Version Control Using Git 13. GitHub

13.2 Fork and Pull Request

Created repositories in GitHub can be created to be private (no one can see or access the
repository) or created as public (any person can clone the repository). Lets assume now
for the case of a public repository, a ForeignUser wants to clone certain repository from
OwnerUser account in GitHub.
As longas the ForeignUser can see the repository (public repository), he can download or
clone repository from GitHub. But in this case it is not possible to push some changes back
to the origin repository. To do this action in GitHub, ForeignUser has to use the fork option.
ForeignUser has to register an account irst in GitHub. After that he can search for the target
repository to fork it. For example you can search for repository called “TCL_Stories” from a
user called “electgon”, then you can fork this repository into your space. Figure 9 shows how
to fork a repository in Github

Figure 9: Fork a Repository in Github

When you click on ’fork’ you can notice now that you have mirror of this repository in
your space.

Figure 10: Forked Repository

Then you can clone or copy this repository into your machine

32
Version Control Using Git 13. GitHub

Figure 11: Clone Forked Repository

Afterwards, you can make your needed modi ications in this cloned repository and add,
commit, push the changes back to your forked repository. Now you can create Pull Request.
Which means, you ask the original owner of the repository (“electgon” in our example) to
merge your changes to his changes.

Figure 12: Create Pull Request

Figure 13: Start Pull Request

33
Version Control Using Git 13. GitHub

Figure 14: Write Comment for Pull Request

It is not enough to click on the Pull Request only, Actually you have to notify the original
owner that you wish him review your changes, this has to be done from the right side as
follows

Figure 15: Add the Owner as Reviewer

Figure 16: Send Review Request

The owner of origin repository then will get a noti ication that a change has been made
to the repository and he is requested to make pull for the repository in order to accept the
changes. He can accept the changes by merging it with the master branch or rejecting it by
simply ignoring this branch. When the owner accepts your changes, you will be noti ied

34
Version Control Using Git 13. GitHub

Figure 17: Con irmation of Changes Acceptance

35
Version Control Using Git 14. Use Cases

14 Use Cases
In this section we will try to demonstrate some use cases that could be used by some developers
to shed more light on how work low using Git can be done.

14.1 Create Repository at Server from Client

This is basic scenario that can be used to initialize a repository. It assumes here that user
wants to have central repository at a server machine from which different users can clone it.
The idea may be in initialization of the server repository. If the design iles reside at one of the
client machines, no need to transfer these iles to the server in order to create the repository.
It is enough to create a bare repository at the server using the following command
 
$cd path/to/server/repository
$git init --bare RepoA
 
Now to update this repository from client machine, we can clone it to the client machine
or create normal repository at the client machine, add needed iles, push the changes to the
server repository
 
cd myproject
$ git init RepoA
$ cd RepoA
### Import Repository files to add it
$ git add .
$ git commit -m 'initial commit'
$ git tag -a v1.0 -m 'starting version'
$ git remote add origin /path/to/ServerMachine/
$ git push origin master --tag
 
In this way repository at server machine will be updated. The following script can be used
to automate the process from a shell terminal
 
#!/bin/bash
Repo_Path="./Test/"
Repo_Name="RepoB"
RemoteRepoName="RepoC"

RemoteUserName="serverAccount"
RemoteHostName="192.168.178.87"
RemoteOperationPath="C:/Personal/git_tut/workspace_04"
RemoteOperation="cd $RemoteOperationPath;
pwd;
git init --bare $RemoteRepoName"

ssh -o StrictHostKeyChecking=no ${RemoteUserName}@${RemoteHostName} ${

RemoteOperation}

echo "Repo Name will be $Repo_Name"

git init $Repo_Path$Repo_Name
cd $Repo_Path$Repo_Name

36
Version Control Using Git 14. Use Cases

cat > hello.c << "EOF"

#include <stdio.h>
int main(void){
printf("Hello World \n");
return 0;
}
EOF

git add hello.c

git commit -m "initial commit"
git tag -a v0.0 -m "starting version"
git remote add origin ${RemoteUserName}@${RemoteHostName}:${RemoteOperationPath
}/${RemoteRepoName}
git push origin master --tag
 

14.2 Files Shared between Different Branches

Assume we have one simple SW application built using Python. This application is reading
some database from xls ile row by row. In each row the application is waiting for certain
response from the user. Since this application is interacting with the user i.e. asking and
waiting response from the user, there is one way to build this application to run in Python
console. Therefore, we can add design iles for this application is a Git repository. Assume
then the following steps were followed to create the repository and add iles
 
#!/bin/bash -e

## Prepare Repositories directories

BareRepo_Path="./BarePyRepo/"
Repo_Path="./ExamineUserApplication/"
Repo_Name="D_Py_Project"

mkdir -p $BareRepo_Path
mkdir -p $Repo_Path

## Create Bare Repository

git init --bare $BareRepo_Path$Repo_Name

## Create Local Repository for First Developer

cd $Repo_Path
git clone .$BareRepo_Path$Repo_Name
cd $Repo_Name

cat > hello.py << "EOF"

print('Hello World')

EOF

## Initialize Repository with simple hello file

git add hello.py
git commit -m "initial commit"

37
Version Control Using Git 14. Use Cases

git tag -a v0.0 -m "starting version"

git push origin master --tag

## create woring branch for First Developer

git checkout -b cmd_mode

## Commit Design files of First Developer

cp ../../*.py .
cp ../../*.xlsx .

git add *.xlsx

git add Revise_* git
add ReviseCMDmode.py
git commit -m "adding design files"
 
Previous procedure has added and committed some Python iles. These iles can be listed
by
 
$git ls-files
NewWords.xlsx
OldWords.xlsx
ReviseCMDmode.py
ReviseWords.xlsx
Revise_ask.py
Revise_init.py
Revise_parse.py
Revise_result.py
hello.py
 
So it consists mainly of some xlsx iles which contain our database, and some Python iles
which perform needed functionality of this application. The main execution of these Python
iles resides in ile ReviseCMDmode.py. This ReviseCMDmode.py is calling other functions
from the other associated Python module.
Assume now that there is a request to have GUI for this application and another developer
has worked on this request. The GUI module results then in the following design iles.
 
ReviseGUImode.py - Revise_ask.py - Revise_init.py - Revise_parse.py -
Revise_result.py
 
In which the developer has used previous modules of the CMD mode but replaced the
ReviseCMDmode.py with the new GUI mode ile ReviseGUImode.py. Now assume GUI developer
has used the following script to clone the repository and add his iles.
 
#!/bin/bash -e

## Prepare Repositories directories

BareRepo_Path="./BarePyRepo/"
Repo_Path="./GUIUserApplication/"
Repo_Name="D_Py_Project"

mkdir -p $Repo_Path

38
Version Control Using Git 14. Use Cases

## Create Local Repository for Second Developer

cd $Repo_Path
git clone .$BareRepo_Path$Repo_Name
cd $Repo_Name

## create working branch for Second Developer

git checkout -b gui_mode

## Commit Design files of Second Developer

git add ReviseGUImode.py

git commit -m "adding design files"
 
CMD developer has now master branch and cmd_mode branch. While GUI developer has
master branch and gui_mode branch. Assume now that both have pushed their changes to
the origin repository.
 
## CMD Developer
$git push origin cmd_mode
............
## GUI Developer
$git push origin gui_mode
 
To let each of them to get the other branch, they have to fetch it. For example if the CMD
developer issued
 
gitk --all
 
He will get the following graph

Figure 18: CMD Repository Before Branch Update

In order to update his repository, he has to issue the following commands

 
$git ls-remote --heads ## This step to list remote branches
$git fetch origin
$git checkout --track origin/gui_mode
 
Displaying new updates now using gitk will result in the following

Figure 19: CMD Repository After Branch Update

39
Version Control Using Git 14. Use Cases

The last step has to be done also for the GUI developer if he wants to get cmd_mode
branch. GUI developers needs the following design iles which is originally located at cmd_mode
branch
 
Revise_ask.py - Revise_init.py - Revise_parse.py - Revise_result.py
 
GUI developer can get it by simply using the following command
 
$git checkout cmd_mode Revise_ask.py Revise_init.py Revise_parse.py
Revise_result.py
 
In that command, GUI developer has used same design iles that reside in cmd_mode
branch. If any changes took place in these iles, GUI developer has to re‐issue previous commands
again in order to get the updates.

14.3 Check Status of Speci ic File

In last step of previous example, we needed to update gui_mode branch with design iles from
cmd_mode branch. To check whether there are changes in these ile at the cmd_mode branch
we can use the following command
 
$git diff --name-only cmd_mode gui_mode *.py
 
The displayed iles will be marked with one of the following letters if there are any change
D: which means that ile exist in cmd_mode branch (as it is written irstly).
M: if the ile is modi ied.
A: if the ile exist in gui_mode only.

14.4 Branch Merge Con lict

It can happen that we need to merge two branches to consolidate design iles. It can happen
also that two branches have the same ile but with different versions. In this case, Git will
issue a con lict error and pause the merge operation until user resolve the con licting part. To
discuss this, assume our previous example in which we have branches master, cmd_mode and
gui_mode for a Python based application. This application has design iles for GUI operation
contained in gui_mode branch. It has also design iles for command line operation contained
in cmd_mode. Lets assume now that we need to combine both branches (cmd_mode & gui_mode)
into the main branch (master). First we merge gui_mode branch into master branch as follows
 
$git checkout master
$git merge gui_mode
 
At this step, for demonstration purpose, some modi ication has been made to ile Revise_init.py
of the gui_mode branch. The same ile is contained also in cmd_mode but not updated.Then
we need to merge content of cmd_mode branch to the master branch. We should get error as
below
 
$git merge cmd_mode
Auto-merging Revise_init.py
CONFLICT (add/add): Merge conflict in Revise_init.py

40
Version Control Using Git 14. Use Cases

Automatic merge failed; fix conflicts and then commit the result.
 
By opening the ile which has con lict, we can ind the con licting part is labeled in the ile
as below for example
 
<<<<<<< HEAD
Table_Length = master_sheet.max_row
=======
while master_sheet.cell(row=k, column=1).value!=None:
k=k+1
Table_Length=k
>>>>>>> cmd_mode
 
Which indicates that developer has replaced part of the code. The corresponding content
of cmd_mode branch is indicated between (=======) and (>>>>>>> cmd_mode).
At this step user can break the merge operation by typing the following command
 
$git merge --abort
 
Then he can update the cmd_mode branch with the changes then merge again
 
$git checkout cmd_mode
$git checkout gui_mode Revise_init.py
$git checkout master
$git merge cmd_mode
 
Or after breaking the merge, he can revert the irst merge operation between master and
gui_mode using the following command.
 
$git revert HEAD
 
Or without breaking the merge operation, user can resolve the labeled part in ile manually
then add the ile again and commit
 
$git add Revise_init.py
$git commit -m "fixing conflict"
 

14.5 Merg Branches in GitHub

In case that we need to move our local repository to GitHub this can be done in simple steps.
First we need to create space for the local repository in GitHub. Then we push the local
repository to the created repository in GitHub. Lets continue with last example to see how
this can be done.
First step is to create repository in GitHub. Note that you have to avoid committing initial
ile to the create repository so that when you push the local repository, you will have exact
copy of the local repository in GitHub.
Then in your local repository add the link of the created GitHub repository as a remote
repository
 
$git remote add GitHubProj https://github.com/UserAccount/RepositoryName.git
 

41
Version Control Using Git 14. Use Cases

Note that UserAccount denotes here the name of your GitHub account. So this shall be
illed correctly. Also RepositoryName should be your GitHub repository name.
Now you can push the local repository to GitHub
 
$git push GitHubProj --all
 
After issuing last command you will be asked to provide UserAccount name and password.
After providing it successfully, your project shall be hosted now in GitHub.
For contribution between several developers in GitHub, Fork and Pull Requests are used
as discussed before.
Then in order to make changes in your GitHub repository, it is advised to detach new
branch to contain your changes. This can be done in GitHub in the Branch drop‐down list as
shown in igure 20

Figure 20: Create New Branch in GitHub

Then in your target ile, you can open it and edit it.

Figure 21: Edit File in GitHub

After that, you can commit your changes.

42
Version Control Using Git 14. Use Cases

Figure 22: GitHub Commit Changes

GitHub will detect that you have made changes in the repository and will prompt you if
you need to create Pull Request for these changes as shown in igure . You can create Pull
Request then.

Figure 23: Pull Request Button

Figure 24: Create Pull Request

Owner of the Repository will be noti ied then with this Pull Request in Pull Request tab.

43
Version Control Using Git 15. Summary

Figure 25: Pull Request Noti ication

He has the option now to accept the request by merging it to the main branch or discuss
further with the requester or ignore this request.

Figure 26: Pull Request Review

15 Summary
Git as a versions management tool provides various options and facilities to ease versions
management tasks during development of projects iles. It is the turn of the user to get
enough experience and learn how to use this tool. In table 1 we can check samples of git
commands that have been used during this tutorial to summarize important operations used
in Git.

44
Version Control Using Git 15. Summary

Table 1: Git Commands Sample

45
Bibliography

[1] Source: ”http://www.techterms.com/de inition/repository”.

[2] Source: ”http://www.techterms.com/de inition/version_control”.

46