Unit – 2

Source Code Management (GIT)

• What is Version Control and GIT

• GIT Installation
• GIT features
• GIT workflow
• Working with remote repository
• GIT commands
• GIT branching
• GIT staging and collaboration.
What is Version Control?
• Version control, also known as source control, is the
practice of tracking and managing changes to software
code.
• Version control systems are software tools that help
software teams manage changes to source code over time.
• As development environments have accelerated, version
control systems help software teams work faster and
smarter.
• Version Control is especially useful for DevOps teams
since they help them to reduce development time and
increase successful deployments.
• Version control software keeps track of every
modification to the code in a special kind of
database.

• If a mistake is made, developers can turn back

the clock and compare earlier versions of the
code to help fix the mistake while minimizing
disruption to all team members.

• The version control system allows us to monitor

and work together with our team members at the
same workspace.
Git
• Git is a modern and widely used distributed version control system in
the world.

• It is developed to manage projects with high speed and efficiency.

• It is developed to co-ordinate the work among the developers.

• Git is foundation of many services like Github and Gitlab but we can
use Git without using any other Git services.

• Git can be used Privately and Publicly.

• Git was created by Linus Torvalds in 2005 to develop Linux Kernel.

• It is also used as an important distributed version-control tool for the

DevOps.
Features of Git
• 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.

• 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.
Benefits of Git
• A version control application allows us
to keep track of all the changes that we make
in the files of our project.
• Every time we make changes in files of an
existing project, we can push those changes to
a repository.
• Other developers are allowed to pull your
changes from the repository and continue to
work with the updates that you added to the
project files.
Some significant benefits of using Git are as follows:
GIT Installation
 Download Git for Windows
1. Browse to the official Git website: https://git-scm.com/downloads
2. Click the download link for Windows and allow the download to complete.
3. Browse to the download location (or use the download shortcut in your
browser). Double-click the file to extract and launch the installer.
4. Allow the app to make changes to your device by clicking Yes on the User
Account Control dialog that opens.
5. Review the GNU General Public License, and when you’re ready to install,
click Next.
6. The installer will ask you for an installation location. Leave the default, unless
you have reason to change it, and click Next.
7. A component selection screen will appear. Leave the defaults unless you have a
specific need to change them and click Next.
8. The installer will offer to create a start menu folder. Simply click Next.
9. Select a text editor you’d like to use with Git. Use the drop-down menu to select
Notepad++ (or whichever text editor you prefer) and click Next.
10. The next step allows you to choose a different name for your initial branch. The
default is 'master.' Unless you're working in a team that requires a different
name, leave the default option and click Next.
11. This installation step allows you to change the PATH
environment. The PATH is the default set of directories included
when you run a command from the command line. Leave this on
the middle (recommended) selection and click Next.
12. The installer now asks which SSH client you want Git to use. Git
already comes with its own SSH client, so if you don't need a
specific one, leave the default option and click Next.
13. The next option relates to server certificates. Most users should
use the default. If you’re working in an Active Directory
environment, you may need to switch to Windows Store
certificates. Click Next.
14. The next selection converts line endings. It is recommended that
you leave the default selection. This relates to the way data is
formatted and changing this option may cause problems.
Click Next.
15. Choose the terminal emulator you want to use. The default
MinTTY is recommended, for its features. Click Next
16. The installer now asks what the git pull command should do. The
default option is recommended unless you specifically need to
change its behavior. Click Next to continue with the installation.
17. Next you should choose which credential helper to use. Git uses
credential helpers to fetch or save credentials. Leave the default o
18. The default options are recommended, however this step allows
you to decide which extra option you would like to enable. If you
use symbolic links, which are like shortcuts for the command line,
tick the box. Click Next option as it is the most stable one, and
click Next.
19. Depending on the version of Git you’re installing, it may offer to
install experimental features. Unless you are feeling adventurous,
leave them unchecked and click Install.
20. Once the installation is complete, tick the boxes to view the
Release Notes or Launch Git Bash, then click Finish.
Git Work flow
• Git is the most commonly used version control system
today.
• A Git workflow is a recipe or recommendation for how to
use Git to accomplish work in a consistent and productive
manner.
• Git workflows encourage developers and DevOps teams
to leverage Git effectively and consistently.
• Git offers a lot of flexibility in how users manage
changes.
• Git's focus on flexibility, there is no standardized process
on how to interact with Git.
• When working with a team on a Git-managed project, it’s
important to make sure the team is all in agreement on
how the flow of changes will be applied.

• The array of possible workflows can make it hard to know

where to begin when implementing Git in the workplace.

• workflows are designed to be guidelines rather than

concrete rules.
Basic Git Workflow
What is a successful Git workflow?
• When evaluating a workflow for your team, it's most
important that you consider your team’s culture.
• You want the workflow to enhance the effectiveness of
your team and not be a burden that limits productivity.
• Some things to consider when evaluating a Git workflow
are:
Does this workflow scale with team size?
Is it easy to undo mistakes and errors with this workflow?
Does this workflow impose any new unnecessary
cognitive overhead to the team?
Centralized Workflow

• The Centralized Workflow is a great Git workflow for teams transitioning

from SVN.
• Like Subversion, the Centralized Workflow uses a central repository to serve
as the single point-of-entry for all changes to the project.

• Instead of trunk, the default development branch is called main and all
changes are committed into this branch.

• This workflow doesn’t require any other branches besides main.

• Transitioning to a distributed version control system may
seem like a daunting task, but you don’t have to change
your existing workflow to take advantage of Git.
• It gives every developer their own local copy of the entire
project.
• This isolated environment lets each developer work
independently of all other changes to a project.
• They can add commits to their local repository and
completely forget about upstream developments until it's
convenient for them.
• Second, it gives you access to Git’s robust branching and
merging model.
• Git branches are designed to be a fail-safe mechanism for
integrating code and sharing changes between
repositories.

• The Centralized Workflow is similar to other workflows

in its utilization of a remote server-side hosted repository
that developers push and pull form.

• A Centralized Workflow is generally better suited for

teams migrating from SVN to Git and smaller size teams.
How it works
• Developers start by cloning the central repository.
• In their own local copies of the project, they edit files and
commit changes as they would with SVN.
• However, these new commits are stored locally - they’re
completely isolated from the central repository.
• This lets developers defer synchronizing upstream until
they’re at a convenient break point.
• To publish changes to the official project, developers
"push" their local main branch to the central repository.
• This is the equivalent of subversion commit, except that it
adds all of the local commits that aren’t already in the
central main branch.
Initialize the central repository

• First, someone needs to create the central repository on a

server.
• If it’s a new project, you can initialize an empty repository.
• Otherwise, you’ll need to import an existing Git or SVN
repository.
• Central repositories should always be bare repositories (they
shouldn’t have a working directory), which can be created as
follows:
Clone the central repository
• Each developer creates a local copy of the entire project.
This is accomplished via the git clone command.

• When you clone a repository, Git automatically adds a

shortcut called origin that points back to the “parent”
repository, under the assumption that you'll want to
interact with it further on down the road.
Make changes and commit
• Once the repository is cloned locally, a developer can make
changes using the standard Git commit process: edit, stage,
and commit.

• If you’re not familiar with the staging area, it’s a way to

prepare a commit without having to include every change in
the working directory.

• Create highly focused commits, even if you’ve made a lot of

local changes.

• You can repeat this process as many times as he wants without

worrying about what’s going on in the central repository.
Push new commits to central repository
• Once the local repository has new changes committed.
These change will need to be pushed to share with other
developers on the project.

• This command will push the new committed changes to

the central repository.
• When pushing changes to the central repository, it is
possible that updates from another developer have been
previously pushed that contain code which conflict with
the intended push updates.
• Git will output a message indicating this conflict. In this
situation, git pull will first need to be executed.
Managing conflicts
• The central repository represents the official project, so its
commit history should be treated as sacred and
immutable.
• If a developer’s local commits diverge from the central
repository, Git will refuse to push their changes because
this would overwrite official commits.
• Before the developer can publish their feature, they need to
fetch the updated central commits and rebase their changes
on top of them.
• This is like saying, “I want to add my changes to what
everyone else has already done.”
• If local changes directly conflict with upstream commits,
• Git will pause the rebasing process and give you a chance
to manually resolve the conflicts.
• The nice thing about Git is that it uses the same git
status and git add commands for both generating commits
and resolving merge conflicts.
• This makes it easy for new developers to manage their own
merges.
• Plus, if they get themselves into trouble, Git makes it very
easy to abort the entire rebase and try again
Example
• Let’s take a general example at how a typical small team would collaborate
using this workflow.

• We’ll see how two developers, John and Mary, can work on separate
features and share their contributions via a centralized repository.

• In his local repository, John can develop features using the standard Git
commit process: edit, stage, and commit.

• Remember that since these commands create local commits, John can
repeat this process as many times as he wants without worrying about
what’s going on in the central repository.
• Meanwhile, Mary is working on her own feature in her
own local repository using the same edit/stage/commit
process.
• Like John, she doesn’t care what’s going on in the central
repository, and she really doesn’t care what John is doing
in his local repository, since all local repositories
are private.
• Once John finishes his feature, he should publish his local
commits to the central repository so other team members
can access it.
• He can do this with the git push command.

• Remember that origin is the remote connection to the

central repository that Git created when John cloned it.
• The main argument tells Git to try to make
the origin’s main branch look like his local main branch.
• Since the central repository hasn’t been updated since
John cloned it, this won’t result in any conflicts and the
push will work as expected.
• Let’s see what happens if Mary tries to push her feature
after John has successfully published his changes to the
central repository.
• She can use the exact same push command:

• But, since her local history has diverged from the central
repository, Git will refuse the request with a rather
verbose error message:
error: failed to push some refs to '/path/to/repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
• This prevents Mary from overwriting official commits. She needs to
pull John’s updates into her repository, integrate them with her local
changes, and then try again.

• Mary can use git pull to incorporate upstream changes into her
repository.
• It pulls the entire upstream commit history into Mary’s local
repository and tries to integrate it with her local commits.

• The --rebase option tells Git to move all of Mary’s commits to the
tip of the main branch after synchronising it with the changes from
the central repository.
• The pull would still work if you forgot this option
• Rebasing works by transferring each local commit to the
updated main branch one at a time.
• This means that you catch merge conflicts on a
commit-by-commit basis rather than resolving all of them
in one massive merge commit.
• This keeps your commits as focused as possible and
makes for a clean project history.
• This makes it much easier to figure out where bugs were
introduced and, if necessary, to roll back changes with
minimal impact on the project.
Working with remote repository : Git remote
• To be able to collaborate on any Git project, you need to know how
to manage your remote repositories.
• Remote repositories are versions of your project that are hosted on
the Internet or network somewhere.
• You can have several of them, each of which generally is either
read-only or read/write for you.
• Collaborating with others involves managing these remote
repositories and pushing and pulling data to and from them when
you need to share work.
• Managing remote repositories includes knowing how to add remote
repositories, remove remotes that are no longer valid, manage
various remote branches and define them as being tracked or not,
and more.
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.
• You can also specify -v, which shows you the URLs that Git has
stored for the short name to be used when reading and writing to
that remote.

• If you have more than one remote, the command lists them all. For
example, a repository with multiple remotes for working with
several collaborators might look something like this.
Adding Remote Repositories
• To add a new remote Git repository as a shortname you can
reference easily, run git remote add <shortname> <url>

• Now you can use the string pb on the command line instead of the
whole URL.
• For example, if you want to fetch all the information that Paul has
but that you don’t yet have in your repository, you can run git fetch
pb:

• Paul’s master branch is now accessible locally as pb/master

Fetching and Pulling from Your Remotes
• To get data from your remote projects, you can run.

• The command goes out to that remote project and pulls down all the
data from that remote project that you don’t have yet.
• After you do this, you should have references to all the branches
from that remote, which you can merge in or inspect at any time.
• If you clone a repository, the command automatically adds that
remote repository under the name “origin”.
• So, git fetch origin fetches any new work that has been pushed to
that server since you cloned (or last fetched from) it.
• It’s important to note that the git fetch command only downloads
the data to your local repository — it doesn’t automatically merge it
with any of your work or modify what you’re currently working on.
• You have to merge it manually into your work when you’re ready.
Pushing to Your Remotes
• When you have your project at a point that you want to share, you
have to push it upstream.
• The command for this is simple: git push <remote> <branch>.
• If you want to push your master branch to your origin server (again,
cloning generally sets up both of those names for you
automatically), then you can run this to push any commits you’ve
done back up to the server.

• This command works only if you cloned from a server to which you
have write access and if nobody has pushed in the meantime.
• If you and someone else clone at the same time and they push
upstream and then you push upstream, your push will rightly be
rejected.
• You’ll have to fetch their work first and incorporate it into yours
before you’ll be allowed to push.
Inspecting a Remote
• If you want to see more information about a particular remote, you
can use the git remote show <remote> command.
• If you run this command with a particular short name, such
as origin, you get something like this.

• It lists the URL for the remote repository as well as the tracking
branch information.
Renaming and Removing Remotes
• You can run git remote rename to change a remote’s short name.
• For instance, if you want to rename pb to paul, you can do so with git
remote rename.

• It’s worth mentioning that this changes all your remote-tracking branch
names, too.
• What used to be referenced at pb/master is now at paul/master
• If you want to remove a remote for some reason

• Once you delete the reference to a remote this way, all remote-tracking
branches and configuration settings associated with that remote are also
deleted.
Git Configuration
Setting Up a Git Repository
Local File Changes
Declare Commits
Branching
GIT branching
• Branching is a feature available in most modern version control
systems.
• In Git, branches are a part of your everyday development process.
• Git branches are effectively a pointer to a snapshot of your changes.
• When you want to add a new feature or fix a bug—no matter how
big or how small—you spawn a new branch to encapsulate your
changes.
• This makes it harder for unstable code to get merged into the main
code base, and it gives you the chance to clean up your future's
history before merging it into the main branch.
• The before diagram visualizes a repository with two
isolated lines of development, one for a little feature, and
one for a longer-running feature.

• By developing them in branches, it’s not only possible to

work on both of them in parallel, but it also keeps
the main branch free from questionable code.

• Git branches are an integral part of your everyday

workflow.
How it works
• A branch represents an independent line of development.
• Branches serve as an abstraction for the edit/stage/commit process.
• You can think of them as a way to request a brand new working
directory, staging area, and project history.
• New commits are recorded in the history for the current branch,
which results in a fork in the history of the project.
Common Options
• List all of the branches in your repository. This is synonymous
with git branch --list.

• Create a new branch called ＜branch＞. This does not check out the
new branch.

• Delete the specified branch.

• Force delete the specified branch

• Rename the current branch to ＜branch＞

• List all remote branches

Creating Branches
• It's important to understand that branches are just pointers
to commits.
• When you create a branch, all Git needs to do is create a
new pointer, it doesn’t change the repository in any other
way.
• If you start with a repository that looks like this:

• Then, you create a branch using the following command:

• The repository history remains unchanged. All you get is a new
pointer to the current commit:

• Note that this only creates the new branch.

• To start adding commits to it, you need to select it with git checkout,
and then use the standard git add and git commit commands.
Creating remote branches
• The git branch command also works on remote branches. In order to
operate on remote branches, a remote repo must first be configured
and added to the local repo config.
• $ git remote add new-remote-repo https://bitbucket.com/user/repo.git
# Add remote repo to local repo config
$ git push <new-remote-repo> crazy-experiment~
# pushes the crazy experiment branch to new-remote-repo
Deleting Branches
• Once you’ve finished working on a branch and have
merged it into the main code base, you’re free to delete
the branch without losing any history.

• To delete the branch regardless of its status and without

warnings use the following command.

• To delete a remote branch execute the following.

GIT staging
• One of the core functions of Git is the concepts of the
Staging Environment.
• As you are working, you may be adding, editing and
removing files.
• But whenever you hit a milestone or finish a part of the
work, you should add the files to a Staging Environment.
• Staged files are files that are ready to be committed to the
repository you are working on.
• For example, we are done working with index.html. So
we can add it to the Staging Environment.
• The file should be Staged. Let's check the status:

• Now the file has been added to the Staging Environment.

Git Add More than One File
• You can also stage more than one file at a time. Let's add
2 more files to our working folder. Use the text editor
again.
Now add all files in the current directory to the Staging Environment:
• Now all 3 files are added to the Staging Environment, and we are
ready to do our first commit.
Git Collaboration
• Collaboration is the way different people can work on the same
project together.
• It is like creating a group in GitHub just like Groups in other social
media.
• The people added to the collaborator’s list can be able to push,
merge, and do other kinds of similar things on the project.
• For doing collaboration you need to follow the steps given below:
Step 1: Create a Repository
Step 2: Add files to your project.

Step 3: Adding your Collaborators.

Click on setting and then follow below steps :

After clicking on “Invite a collaborator” fill the required details and then
you are done.