Git (GitBASH) - Version Control Programming

In 2005, the relationship between the community that developed the Linux kernel and the commercial
company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked. This
prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to
develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the
goals of the new system were as follows:

• Speed

• Simple design

• Strong support for non-linear development (thousands of parallel branches)

• Fully distributed

• Able to handle large projects like the Linux kernel efficiently (speed and data size)

Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial
qualities. It’s incredibly fast, it’s very efficient with large projects, and it has an incredible branching
system for non-linear development.

Git is a Version Control System (VCS), a tool which is an extremely smart choice to use even if it sounds
too overwhelming. Simply put, a VCS is a group of files with monitored access.

a VCS is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire
project back to a previous state, compare changes over time, see who last modified something that
might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally
means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very
little overhead.

How does a VCS work?

A collection of all the files you and your team are working on is called a Repository. It also contains some
special data such as the order in which the changes occurred, the description of the change and the
person responsible for that particular change.

A change in your project might take hours, days or even weeks to finish. It would be unfair to treat
unfinished work as a version. You are required to tell the VCS that you are done with the change and that
you wish you save it as a version so that it can track it for you. The act of telling a VCS that a version is
finished is called committing. Hence, versions are often referred to as commits.

VCS hides the complexity of multiple commits so that your project looks clean and tidy. It does this by
storing all data in folders which are marked hidden so you don't realize that they are present on your
computer until you need to interact with them.

This is the third major functionality of a VCS. It lets you view your project history. You can check how
your project looked yesterday, a month before or even a year ago, often with a single command.

They also let you share your repository with your other team members so that collaboration is easy.
Developers often work together on a single project and VCS just makes it easier for them.
Why should I use Git?

Git was originally designed to help manage the Linux Kernel and make collaboration easy from the
beginning. If Git can effectively manage a project as large as the Linux Kernel, it can manage your
projects easily and effectively.

Furthermore, the architecture of Git is distributed Version Control as opposed to a centralized, network
access VCS. A centralized VCS requires a network connection to work with and a central failure may
result in all your work being destroyed. A distributed VCS such as Git, does not require a network
connection to interact with the repository. Each developer has their own repository which makes it fast
and easy to collaborate with.

Finally, on to GitHub. GitHub is easily the most popular website for sharing your projects with
collaborators or with the whole world. It's like a social network for your projects. Repositories can be
made public so that anyone can submit a commit and help make your project better.

Git uses checksums to secure your data. This makes it impossible to make changes to the data without
Git getting a whiff of it. This functionality is built into Git at the lowest levels and is integral to its
philosophy. The basic idea is that you can't lose information in transit or have files corrupted without Git
being able to detect it.

Git> uses the SHA-1 hash system which as you may probably know, is a 40- character string composed of
hex characters and is calculated based on the content. Git extensively uses these values and stores files
in database by this hash and not by the name.

GitHub has been gaining popularity in the software development world and it is likely that you would
require to know Git if you are to be a collaborator on a project which is a reason on its own to learn
more about Git.

The major difference between Git and any other VCS (Subversion and friends included) is the way Git
thinks about its data. Conceptually, most other systems store information as a list of file-based changes.
These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set
of files and the changes made to each file over time.

Git does not think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots
of a miniature filesystem. Every time you commit, or save the state of your project in Git, it basically
takes a picture of what all your files look like at that moment and stores a reference to that snapshot.

To be efficient, if files have not changed, Git does not store the file again, just a link to the previous
identical file it has already stored. Git thinks about its data more like a stream of snapshots.

The Three States

▪ Committed means that the data is safely stored in your local database.

▪ Modified means that you have changed the file but have not committed it to your database yet.

▪ Staged means that you have marked a modified file in its current version to go into your next commit
snapshot
The Three Main Sections of a Git Project

▪ Git directory is where Git stores the metadata and object database for your project.

▪ The working directory is a single checkout of one version of the project.

▪ The staging area is a file, generally contained in your Git directory, that stores information about what
will go into your next commit.

Git (CLOUDSWYFT) - Version Control Programming (Branching)

• Elements of Professional Code (CLOUDSWYFT)

An Introduction to Source Control

Of the nearly 30,000 developers surveyed in this year's Stack Overflow developer survey, nearly 53% said
they check in code multiple times per day. Apparently, developers enjoy checking in code. According to
the survey, they achieve a real sense of satisfaction through this act of "shipping".

What is this "check in code" process that developers speak of and why do they do it? As it turns out, it is
a fundamental action in the world of Version Control that involves committing code changes or updates
to a version control system.

Version Control has been called "Source Code Management", "Source Control" "Revision Control" and
many other terms. These terms can be used interchangeably to mean a systematic way of managing
software and changes to it.

Version Control - the art of managing change, and it is a very important aspect of software development.
In fact, looking at the following graph from the Stack Overflow survey, we can see that there are many
different tools used to manage code. A small percentage of developers even admit to using zip files or
copy-pasting files around file shares.

While many of these tools use similar terminology to describe the actions you perform to manage file
changes, they are pretty different under the covers. These implementation details are beyond the scope
of this lesson. Instead, we'll learn how to use Git, one of the most widely used version control systems
currently.

Install Git on Linux

In this task, you will install Git on Linux. We will cover yum and apt-get, depending on which distribution
you are using.

1. To install Git using yum, open a terminal and enter the following command:

sudo yum install git-all

2. To install Git using apt-get (found on Debian-based distributions), open a terminal and enter the
following command

sudo apt-get install git-all

3. Follow any prompts from the installer and Git will be automatically installed on your system
Github

Hosting Services for Git

• Assembla - has a long history in the business with its Subversion hosting. It includes a “Workspaces
“platform with issue management, time tracking, and collaboration tools like wikis and its own
messaging system.

• Beanstalk - Being a very lean and reliable service, Beanstalk is a great choice for businesses. It offers its
own “deployment “infrastructure and integrates well with other tools like Zendesk, FogBugz, Basecamp,
or Lighthouse.

• Bitbucket - Coming from Atlassian, one of the giants in the industry. Therefore, integrations to other
Atlassian products like the JIRA issue tracker are seamless.

• CloudForge - Services go well beyond just code hosting: it calls itself a „platform for developers “,
offering development tools (e.g. Trac or Bugzilla) as well as integrations with JIRA, Basecamp, and others.

• Codebase - One of the few platforms that supports Git, Subversion, and Mercurial. Additionally,
ticketing, project management and deployment infrastructure tools are included.

• Fog Creek Kiln - The makers of the popular issue tracking solution "FogBugz" offer a solid code hosting
platform - and of course a tight integration with their bug tracking system.

• GitHub - The undisputed number one in the Open-Source world with projects like Ruby on Rails or
jQuery being hosted at GitHub. Offerings include great code review and collaboration features.

• GitLab - With an Open Source background, GitLab offers a fast-evolving platform for code
collaboration. The free community edition and the enterprise edition can be installed on your own
servers; a hosted offering that runs on GitLab.com is also available.

• Plan.io - Berlin startup Plan.io offers much more than just hosting: a complete project management
platform, including modules for task & file management, wiki, forums, helpdesk, and time tracking.

• Perforce - Perforce is one of the heavyweights in the business with a long history and extensive
experience. Its "Helix" platform offers a complete software collaboration system with issue tracking, code
review, and even advanced things like Threat Detection.

• RhodeCode - Sophisticated code review & approval system, including newsfeed and mentioning
system. With features like LDAP support and IP restriction, Rhodecode seems tailored for corporate use.

• Unfuddle - Comes with both wikis and its own messaging system.

What is GitHub?

– GitHub.com is a site for online storage of Git repositories.

– Many open-source projects use it (e.g., Linux Kernel)

– You can get a free space for open-source projects or you can pay for private projects
QUESTION: Do I have to use GitHub to use Git? ANSWER: NO! You can use Git completely locally for your
own purposes, or you or someone else could set up a server to share files, or you could share a repo
with users on the same file system.

The GitHub Flow

• GitHub Flow is a lightweight, branch-based workflow that supports teams and projects where
deployments are made regularly.

• This section explains how and why GitHub Flow works

Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule:
anything in the master branch is always deployable.

Commits also create a transparent history of your work that others can follow to understand what you've
done and why. Each commit has an associated commit message, which is a description explaining why a
particular change was made. Furthermore, each commit is considered a separate unit of change. This
lets you roll back changes if a bug is found, or if you decide to head in a different direction.

• Commit messages are important, especially since Git tracks your changes and then displays them as
commits once they're pushed to the server.

• By writing clear commit messages, you can make it easier for other people to follow along and provide
feedback.

• Pull Requests initiate discussion about your commits. Because they're tightly integrated with the
underlying Git repository, anyone can see exactly what changes would be merged if they accept your
request.

• You can open a Pull Request at any point during the development process: when you have little or no
code but want to share some screenshots or general ideas, when you're stuck and need help or advice,
or when you're ready for someone to review your work. By using GitHub's @mention system in your Pull
Request message, you can ask for feedback from specific people or teams, whether they're down the
hall or ten time zones away.

• Pull Requests are useful for contributing to open-source projects and for managing changes to shared
repositories.

• If you're using a Fork & Pull Model, Pull Requests provide a way to notify project maintainers about the
changes you'd like them to consider.

• If you're using a Shared Repository Model, Pull Requests help start code review and conversation about
proposed changes before they're merged into the master branch.

• Once a Pull Request has been opened, the person or team reviewing your changes may have questions
or comments. Perhaps the coding style doesn't match project guidelines, the change is missing unit tests,
or maybe everything looks great and props are in order. Pull Requests are designed to encourage and
capture this type of conversation.

• You can also continue to push to your branch in light of discussion and feedback about your commits. If
someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your
branch and push up the change. GitHub will show your new commits and any additional feedback you
may receive in the unified Pull Request view.

• Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-
formatted text blocks, and other lightweight formatting.

• Deploy Once your pull request has been reviewed and the branch passes your tests, you can deploy
your changes to verify them in production. If your branch causes issues, you can roll it back by deploying
the existing master into production.

• Now that your changes have been verified in production, it is time to merge your code into the master
branch.

• Once merged, Pull Requests preserve a record of the historical changes to your code. Because they're
searchable, they let anyone go back in time to understand why and how a decision was made.

❑ By incorporating certain keywords into the text of your Pull Request, you can associate issues with
code.

❑ When your Pull Request is merged, the related issues are also closed.

❑ For example, entering the phrase Closes #32 would close issue number 32 in the repository

Creating & Deleting Branch

• You can create a new branch in a repository's branch selector menu. Just start typing the name of your
branch; if it doesn't exist, GitHub will offer to create it for you.

Creating New File

When creating a file on GitHub, consider the following:

• If you try to create a new file in a repository that you don’t have access to, we will fork the project to
your user account and help you send a pull request to the original repository after you commit your
change

• File names created via the web interface can only contain alphanumeric characters and hyphens (-). To
use other characters, create and commit the files locally, then push them to the repository on GitHub.

• If you try to create a new file in a repository that you don’t have access to, we will fork the project to
your user account and help you send a pull request to the original repository after you commit your
change

• File names created via the web interface can only contain alphanumeric characters and hyphens (-). To
use other characters, create and commit the files locally, then push them to the repository on GitHub.

• In your repository, browse to the folder where you want to create a file.

• Above the file list, click +

• In the file name field, type the name and extension for the file. To create subdirectories, type the /
directory separator.
• On the Edit new file tab, add content to the file

• To review the new content, click Preview

• At the bottom of the page, type a short, meaningful commit message that describes the change you
made to the file.

• Below the commit message fields, decide whether to add your commit to the current branch or to a
new branch.

• If your current branch is master, you should choose to create a new branch for your commit and then
create a pull request.

PULLING/FETCHING A REMOTE:

$ git clone – to grab a complete copt of another user’s repository

- A new folder called ‘repo’ is made

- It is initialized as a Git repository

Fetch

• Use git fetch to retrieve new work done by other people. Fetching from a repository grabs all the new
remotetracking branches and tags without merging those changes into your own branches. If you
already have a local repository with a remote URL set up for the desired project, you can grab all the new
information by using

$ git fetch remotename in the terminal.

Merge

• Merging combines your local changes with changes made by others.

• Typically, you'd merge a remote-tracking branch (i.e., a branch fetched from a remote repository) with
your local branch:

$ git merge remotename/branchname

Pull

• git pull is a convenient shortcut for completing both git fetch and git merge in the same command:

$ git pull remotename branchname

• Because pull performs a merge on the retrieved changes, you should ensure that your local work is
committed before running the pull command.

• If you run into a merge conflict you cannot resolve, or if you decide to quit the merge, you can use $ git
merge --abort to take the branch back to where it was in before you pulled.
COMMANDS:

ls

cd dpcuments

mkdir “name of folder”

cd “name of folder”

cd .. – back to folder

git config –global user.name “kahit anong gusto mong ilagay” – set a name that is identifiable for credit
when review version history

git config –global user.email [email add] – set an email address that will be associated with each history
marker

git clone – retrieve an entire repository from a hosted location via URL

CHECK USERNAME:

git config user.name

git init (master) – initialize an existing directory as a Git repository

git status – show modified files on working directory, staged for your next commit

git add . – add a file as it looks now to your next commit (stage)

git commit -m “Message” – commit your staged content as anew commit snapshot

git log – show all commits in the current branch’s history

cd (return to previous folder) mkdir

BRANCHING AND MERGING

git brand – check branch, list your branches a* will appear next to the currently active branch

git checkout [name – branch] – switch branch

git checkout -b [name of branch]

git merge --no-f [branch name] -m “comment” – branch

git branch --no--merged – check not merged branch

git merge – merge the specified branch’s history into the current one

git push – transmit local branch commits to the remote repository branch
git pull – fetch and merge any commits from the tracking remote branch

git remote add [alias] [url] - add a git URL as an alias

git fetch [alias] - fetch down all the branches from that Git remote