1. UNIT2
Managing Code The need for Source Code, Overview of Version Control systems Setting up a basic Git server, Hosted Git Server,
Branching and merging in Git, Git Server implementation, Working with Remote repository
2. Introduction
• What is Git?
• Git is an open-source distributed version control system. It is designed to
handle minor to major projects with high speed and efficiency. It is developed to
co-ordinate the work among the developers. The version control allows us to track
and work together with our team members at the same workspace.
• Git is easy to learn, and has fast performance. It is superior to other SCM tools
like Subversion, CVS, Perforce, and ClearCase.
3. Features of Git
1.Open Source
2.Scalable
3.Distributed
4.Security
5.Speed
6.Supports non-linear
development
7.Branching and
Merging
8.Data Assurance
9.Staging Area
10.Maintain the clean
history
4. • Open Source
Git is an open-source tool. It is released under the GPL (General Public License) license.
• Scalable
Git is scalable, which means when the number of users increases, the Git can easily handle such
situations.
• Distributed:
One of Git's great features is that it is distributed. Distributed means that instead of switching the project
to another machine, we can create a "clone" of the entire repository. Also, instead of just having one
central repository that you send changes to, every user has their own repository that contains the entire
commit history of the project. We do not need to connect to the remote repository; the change is just
stored on our local repository. If necessary, we can push these changes to a remote repository.
5. • Security
Git is secure. It uses the SHA1 (Secure Hash Function) to name and identify objects within its
repository. Files and commits are checked and retrieved by its checksum at the time of checkout. It stores
its history in such a way that the ID of particular commits depends upon the complete development
history leading up to that commit. Once it is published, one cannot make changes to its old version.
• Speed
Git is very fast, so it can complete all the tasks in a while. Most of the git operations are done on the local
repository, so it provides a huge speed. Also, a centralized version control system continually
communicates with a server somewhere.
• Performance tests conducted by Mozilla showed that it was extremely fast compared to other VCSs.
Fetching version history from a locally stored repository is much faster than fetching it from the remote
server. The core part of Git is written in C, which ignores runtime overheads associated with other high-
level languages.
Git was developed to work on the Linux kernel; therefore, it is capable enough to handle
large repositories effectively. From the beginning, speed and performance have been Git's primary
goals.
• Supports non-linear development
Git supports seamless branching and merging, which helps in visualizing and navigating a non-linear
6. • Branching and merging
Branching and merging are the great features of Git, which makes it different from the other SCM tools. Git allows
the creation of multiple branches without affecting each other. We can perform tasks like creation, deletion,
and merging on branches, and these tasks take a few seconds only. Below are some features that can be achieved
by branching:
• We can create a separate branch for a new module of the project, commit and delete it whenever we want.
• We can have a production branch, which always has what goes into production and can be merged for testing in
the test branch.
• We can create a demo branch for the experiment and check if it is working. We can also remove it if needed.
• The core benefit of branching is if we want to push something to a remote repository, we do not have to push all of
our branches. We can select a few of our branches, or all of them together.
• Staging Area
The Staging area is also a unique functionality of Git. It can be considered as a preview of our next commit,
moreover, an intermediate area where commits can be formatted and reviewed before completion. When you make a
commit, Git takes changes that are in the staging area and make them as a new commit. We are allowed to add and remove
changes from the staging area. The staging area can be considered as a place where Git stores the changes.
Although, Git doesn't have a dedicated staging directory where it can store some objects representing file changes (blobs).
Instead of this, it uses a file called index. Another feature of Git that makes it apart from other SCM tools is that it is
possible to quickly stage some of our files and commit them without committing other modified files in our
working directory.
9. • Git Integrity
Git is developed to ensure the security and integrity of content being version
controlled. It uses checksum during transit or tampering with the file system to
confirm that information is not lost. Internally it creates a checksum value from the
contents of the file and then verifies it when transmitting or storing data.
• Trendy Version Control System
Git is the most widely used version control system. It has maximum projects among all
the version control systems. Due to its amazing workflow and features, it is a preferred
choice of developers.
10. • Everything is Local
Almost All operations of Git can be performed locally; this is a significant reason for the use of Git. We will
not have to ensure internet connectivity.
• Collaborate to Public Projects
There are many public projects available on the GitHub. We can collaborate on those projects and show our
creativity to the world. Many developers are collaborating on public projects. The collaboration allows us to
stand with experienced developers and learn a lot from them; thus, it takes our programming skills to the
next level.
• Impress Recruiters
We can impress recruiters by mentioning the Git and GitHub on our resume. Send your GitHub profile link to
the HR of the organization you want to join. Show your skills and influence them through your work. It
increases the chances of getting hired.
11. What is GitHub?
GitHub is a Git repository hosting service.
GitHub also facilitates with many of its
features, such as access control and
collaboration. It provides a Web-based
graphical interface.
GitHub is an American company. It hosts
source code of your project in the form of
different programming languages and keeps
track of the various changes made by
programmers.
It offers both distributed version control
and source code management
(SCM) functionality of Git. It also facilitates
with some collaboration features such as bug
tracking, feature requests, task management
for every project.
Some of its significant features are as
follows.
12. The Need for Source Code
• Source code is the human-readable form of a program, written in
programming languages like Python, Java, C++, etc.
• It acts as the blueprint for software applications.
• Maintaining and managing source code effectively is crucial for collaboration, debugging, and
software evolution.
• Example - Imagine building a weather forecasting app. Developers write the code (source code) in a
repository.
• Each developer contributes their part—some handle the user interface, while others handle data
fetching from APIs.
13. Git Version Control System
• A version control system is a software that tracks changes to a file or set of files over time so that
you can recall specific versions later. It also allows you to work together with other programmers.
• The version control system is a collection of software tools that help a team to manage changes in
a source code. It uses a special kind of database to keep track of every modification to the code.
• Developers can compare earlier versions of the code with an older version to fix the mistakes.
Benefits of the Version Control System
The Version Control System is very helpful and beneficial in software development; developing
software without using version control is unsafe. It provides backups for uncertainty. Version control
systems offer a speedy interface to developers. It also allows software teams to preserve efficiency
and agility according to the team scales to include more developers.
14. Types of Version Control System
• Localized version Control System
• Centralized version control systems
• Distributed version control systems
Localized Version Control Systems
• The localized version control method is a common approach because of its simplicity. But this
approach leads to a higher chance of error. In this approach, you may forget which directory
you're in and accidentally write to the wrong file or copy over files you don't want to.
• The Version Control System is very helpful and beneficial in software development;
developing software without using version control is unsafe. It provides backups for
uncertainty. Version control systems offer a speedy interface to developers. It also allows
software teams to preserve efficiency and agility according to the team scales to include more
developers.
15. Benefits of VCS
Some key benefits of having a version control system are as follows.
• Complete change history of the file
• Simultaneously working
• Branching and merging
• Traceability
16. Centralized Version Control System
The developers needed to collaborate with other developers on
other systems. The localized version control system failed in this
case. To deal with this problem, Centralized Version Control
Systems were developed.
These systems have a single server that contains the versioned
files, and some clients to check out files from a central place.
Centralized version control systems have many benefits, especially
over local VCSs.
• Everyone on the system has information about the work what
others are doing on the project.
• Administrators have control over other developers.
• It is easier to deal with a centralized version control system
than a localized version control system.
• A local version control system facilitates with a server software
component which stores and manages the different versions of
the files.
It also has the same drawback as in local version control system
that it also has a single point of failure.
17. Distributed Version Control System
Centralized Version Control System uses a central server to store all the database
and team collaboration. But due to single point failure, which means the failure
of the central server, developers do not prefer it. Next, the Distributed Version
Control System is developed.
In a Distributed Version Control System (such as Git, Mercurial, Bazaar or
Darcs), the user has a local copy of a repository. So, the clients don't just check
out the latest snapshot of the files even they can fully mirror the repository. The
local repository contains all the files and metadata present in the main repository.
DVCS allows automatic management branching and merging. It speeds up of
most operations except pushing and pulling. DVCS enhances the ability to work
offline and does not rely on a single location for backups. If any server stops and
other systems were collaborating via it, then any of the client repositories could
be restored by that server. Every checkout is a full backup of all the data.
These systems do not necessarily depend on a central server to store all the
versions of a project file.
34. Git Branching
• Nearly every VCS has some form of branching support.
• Branching means you diverge from the main line of
development and continue to do work without messing with
that main line.
• In many VCS tools, this is a somewhat expensive process,
often requiring you to create a new copy of your source
code directory, which can take a long time for large projects.
35. Branches in a Nutshell
• Understanding Git Branching: How Git Stores Data
• Git stores data as a series of snapshots, not changesets or
differences.
• Each commit creates a commit object that includes:
• A pointer to the snapshot of staged content.
• Author’s name and email address.
• The commit message.
• Pointers to previous commit(s) (parents):
• Zero parents Initial commit.
→
• One parent Normal commit.
→
• Multiple parents Merge commit (from multiple branches).
→
36. To visualize this, let’s assume that you have a directory
containing three files, and you stage them all and commit.
37. Visualizing Git Data Storage
• Staging Files
• Computes a SHA-1 checksum for each file.
• Stores the file versions as blobs in the Git repository.
• Adds the checksum to the staging area.
• Example command:
$ git add README test.rb LICENSE
$ git commit -m 'Initial commit'
•
• Creating a Commit
• Git checksums the root directory and stores it as a tree object.
• Generates a commit object with:
• Metadata (author, message, timestamp).
• A pointer to the root tree for snapshot recreation.
• Git Repository Structure After Commit
• Contains five objects:
• Three blobs (representing file contents).
• One tree (maps filenames to blobs).
39. Commits and their parents
If you make some changes and commit again, the next
commit stores a pointer to the commit that came
immediately before it.
40. A branch and its commit history
• A branch in Git is simply a lightweight movable pointer to one
of these commits. The default branch name in Git is master.
• As you start making commits, you’re given a master branch
that points to the last commit you made.
• Every time you commit, the master branch pointer moves
forward automatically.
• The “master” branch in Git is not a special branch. It is exactly
like any other branch. The only reason nearly every repository
has one is that the git init command creates it by default and
most people don’t bother to change it.
42. Creating a New Branch
• What happens when you create a new branch? Well, doing
so creates a new pointer for you to move around. Let’s say
you want to create a new branch called testing. You do this
with the git branch command:
Two branches pointing
into the same series of
commits
43. HEAD pointing to a branch
• In Git, this is a pointer to the local branch you’re currently
on. In this case, you’re still on master. The git branch
command only created a new branch — it didn’t switch to
that branch.
44. Switching Branches
• To switch to an existing branch, you run the git checkout
command. Let’s switch to the new testing branch:
This moves HEAD to point to the testing branch.
46. The HEAD branch moves forward when
a commit is made
• What is the significance of that? Well, let’s do another
commit:
47. HEAD moves when you checkout
• This is interesting, because now your testing branch has
moved forward, but your master branch still points to the
commit you were on when you ran git checkout to switch
branches. Let’s switch back to the master branch:
That command did two things.
• It moved the HEAD pointer back
to point to the master branch, and
• It reverted the files in your
working directory back to the
snapshot that master points to.
48. Divergent history
• Let’s make a few changes and commit again:
You created and switched to a branch, did some work on
it, and then switched back to your main branch and did
other work.
Both of those changes are isolated in separate branches:
you can switch back and forth between the branches
and merge them together when you’re ready.
49. Why Git Branching?
• This is in sharp contrast to the way most older VCS tools
branch, which involves copying all of the project’s files
into a second directory.
• This can take several seconds or even minutes,
depending on the size of the project, whereas in Git the
process is always instantaneous.
• Also, because we’re recording the parents when we
commit, finding a proper merge base for merging is
automatically done for us and is generally very easy to
do.
• These features help encourage developers to create and
use branches often.
50. Example of the Branching on Git
Let’s go through a simple example of branching and merging with a workflow that you might
use in the real world. You’ll follow these steps:
1. Do some work on a website.
2. Create a branch for a new user story you’re working on.
3. Do some work in that branch.
At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the
following:
1. Switch to your production branch.
2. Create a branch to add the hotfix.
3. After it’s tested, merge the hotfix branch, and push to production.
4. Switch back to your original user story and continue working.
51. Basic Branching and Merging
• Basic Branching
First, let’s say you’re working on your project and have a
couple of commits already on the master branch.
52. Creating a new branch pointer
To create a new branch and switch to it at the same time, you can run the git checkout command
with the -b switch:
53. The iss53 branch has moved forward
with your work
• You work on your website and do some commits. Doing so
moves the iss53 branch forward, because you have it
checked out (that is, your HEAD is pointing to it):
54. Hotfix branch based on master
• Now you get the call that there is an issue with the website, and you need to fix it immediately. With Git, you don’t have
to deploy your fix along with the iss53 changes you’ve made, and you don’t have to put a lot of effort into reverting those
changes before you can work on applying your fix to what is in production. All you have to do is switch back to your
master branch.
Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s
completed:
56. master is fast-forwarded to hotfix
• You can run your tests, make sure the hotfix is what you
want, and finally merge the hotfix branch back into your
master branch to deploy to production. You do this with the
git merge command:
57. Fast forward merge
You’ll notice the phrase “fast-forward” in that merge. Because the commit C4 pointed to by the branch hotfix you merged in
was directly ahead of the commit C2 you’re on, Git simply moves the pointer forward.
To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first
commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together
— this is called a “fastforward.”
58. Work continues on iss53
• After your super-important fix is deployed, you’re ready to switch back to the work you were
doing before you were interrupted. However, first you’ll delete the hotfix branch, because you
no longer need it — the master branch points at the same place. You can delete it with the -d
option to git branch:
• Now you can switch back to your work-in-progress branch on issue #53 and continue working
on it.
60. Basic Merging
• Suppose you’ve decided that your issue #53 work is complete and ready to be
merged into your master branch. In order to do that, you’ll merge your iss53 branch
into master
61. Three snapshots used in a typical
merge
• This looks a bit different than the hotfix merge you did earlier. In this
case, your development history has diverged from some older point.
Because the commit on the branch you’re on isn’t a direct ancestor of
the branch you’re merging in, Git has to do some work. In this case,
Git does a simple three-way merge, using the two snapshots pointed
to by the branch tips and the common ancestor of the two.
62. A recursive merge commit
• Instead of just moving the branch pointer forward, Git
creates a new snapshot that results from this three-way
merge and automatically creates a new commit that points
to it. This is referred to as a merge commit, and is special in
that it has more than one parent.
63. Working with Remotes
What are Remote Repositories?
• Versions of your project hosted on the Internet or a network.
• Can be read-only or read/write for users.
Why Manage Remote Repositories?
• Essential for collaborating on Git projects.
• Enables pushing and pulling data to share work.
Key Remote Management Tasks:
• Adding and removing remote repositories.
• Managing remote branches.
• Defining tracked branches.
64. Showing Your Remotes
• To see which remote servers you have configured, you can run the git
remote command. It lists the short names of each remote handle
you’ve specified. If you’ve cloned your repository, you should at least
see origin — that is the default name Git gives to the server you
cloned from:
75. Generating a new SSH Key
Link
• https://docs.github.com/en/authentication/connecting-to-gi
thub-with-ssh/generating-a-new-ssh-key-and-adding-it-to-th
e-ssh-agent
