Git and Version Control at Atlogys

Version Control using Git
Anoop Kumar Malav
Atlogys Technical Consulting
anoop@atlogys.com
February 8, 2018
Anoop Kumar Malav (Atlogys) Git Tech Talk February 8, 2018 1 / 65

Git: Original Author
Linus Torvalds
https://en.wikipedia.org/wiki/Linus_Torvalds

Overview
1 About Version Control
2 Git Basics
The Three States
Getting a Git Repository
Recording Changes to the Repository
Viewing Your Staged and Unstaged Changes
Committing Your Changes
Undoing Things
Working with Remotes
Tagging
3 Git Branching
Introduction
Branch Merging
Remote Branches
4 Git Tools

About Version Control
Version control is a system that records changes to a file or set of files
over time so that you can recall specific versions later.
It allows you to
revert selected files back to a previous state,
revert the entire project back to a previous state,
compare changes over time,
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.

About Version Control: Local VCS

About Version Control: Centralized VCS

About Version Control: Distributed VCS

Git Basics: The Three States

Git Basics: Getting a Git Repository
You typically obtain a Git repository in one of two ways:
You can take a local directory that is currently not under version
control, and turn it into a Git repository, or
You can clone an existing Git repository from elsewhere.
In either case, you end up with a Git repository on your local machine,
ready for work.
Example (Initializing a Repository in an Existing Directory)
$ cd /home/user/my_project
$ git init
$ git add *.c; $ git add LICENSE
$ git commit -m ’initial project version’
Example (Cloning an Existing Repository)
$ git clone https://github.com/libgit2/libgit2 mylibgit

Git Basics: Recording Changes to the Repository
The lifecycle of the status of your ﬁles

Checking the Status of Your Files

Tracking New Files

Staging Modiﬁed Files
- Modify previously tracked ﬁle called CONTRIBUTING.md

Staging Modiﬁed Files

Ignoring Files
→ Class of files that you don’t want Git to automatically add or even show you as being
untracked.
→ Setting up a .gitignore file for your new repository before you get going is generally a
good idea so you don’t accidentally commit files that you really don’t want in your Git
repository.
→ In the simple case, a repository might have a single .gitignore file in its root directory,
which applies recursively to the entire repository.
→ However, it is also possible to have additional .gitignore files in subdirectories.
The rules for the patterns you can put in the .gitignore file are as follows:
Blank lines or lines starting with # are ignored.
Standard glob patterns work, and will be applied recursively throughout the entire working tree.
You can start patterns with a forward slash (/) to avoid recursivity.
You can end patterns with a forward slash (/) to specify a directory.
You can negate a pattern by starting it with an exclamation point (!).
Note: GitHub maintains a fairly comprehensive list of good .gitignore file examples for
dozens of projects and languages at https://github.com/github/gitignore

diﬀ options –staged and –cached are synonyms.

Committing Your Changes
- The simplest way to commit is to type git commit. Doing so launches your editor of
choice.
- Alternatively, you can type your commit message inline with the commit command by
specifying it after a -m ﬂag, like this:
$ git commit -m "Story 182: Fix benchmarks for speed"
- If you want to skip the staging area, Git provides a simple shortcut.
- Adding the -a option to the git commit command makes Git automatically stage every
ﬁle that is already tracked before doing the commit, letting you skip the git add part:
$ git commit -a -m ’added new benchmarks’

Removing Files
- To remove a file from Git, you have to remove it from your tracked files and then
commit.
- The git rm command does that, and also removes the file from your working directory
so you don’t see it as an untracked file the next time around.
- To keep the file in your working tree but remove it from your staging area, use the
–cached option:
$ git rm –cached README
- This is particularly useful if you forgot to add something to your .gitignore file and
accidentally staged it.

View Commit History
The most basic and powerful tool to do this is the git log command.
git log branchname
git log ﬁlename
git log -n
git log -p
git log –author
git log –grep=pattern

View Commit History
git log –all –pretty=oneline –graph –abbrev-commit –decorate

View Commit History
There are many graphical interface to view commit history. One of these is gitk.

Git Basics: Undoing Things
Commit Amend (Redo commit)
One of the common undos takes place when you commit too early and possibly forget to
add some files, or you mess up your commit message.
If you want to redo that commit, make the additional changes you forgot, stage them,
and commit again using the –amend option:
$ git commit –amend
It’s important to understand that when you’re amending your last commit, you’re not so
much fixing it as replacing it entirely with a new, improved commit that pushes the old
commit out of the way and puts the new commit in its place.
Effectively, it’s as if the previous commit never happened, and it won’t show up in your
repository history.
Do not amend commit if you have already pushed your code on remote.

Unstaging a Staged File
Let’s say you’ve changed two ﬁles and want to commit them as two separate changes,
but you accidentally type git add * and stage them both.
How can you unstage one of the two? The git status command reminds you:

Unmodifying a Modified File
Let’s say you don’t want to keep your changes to the CONTRIBUTING.md file.
It’s important to understand that git checkout – <file>is a dangerous command.
Any changes you made to that file are gone.
git checkout command is used in two context. The first is to revert changes as in above.
But git checkout is also used to switch to a branch.
To avoid ambiguity, it is best practice to put in the double dash to indicate that we are
not switching branch and that we want to stay on current branch.

Git Basics: Working with Remotes
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.
Showing Your Remotes

Git Basics: Working with Remotes
Adding Remote Repositories
git remote add <shortname><url>
Fetching and Pulling from Your Remotes
Pushing to Your Remotes
git push <remote><branch>
Renaming and Removing Remotes
git remote rename <oldname><newname>
git remote remove <shortname>

Git Basics: Tagging
→ Git has the ability to tag speciﬁc points in history as being important.
→ Typically people use this functionality to mark release points.
Creating Tags
Git supports two types of tags: lightweight and annotated.
A lightweight tag is very much like a branch that doesn’t change - it’s just a pointer to a
speciﬁc commit.
git tag <tagname>
Annotated tags, however, are stored as full objects in the Git database. They contain the
tagger name, email, and date; have a tagging message.
git tag -a <tagname>-m <message>

Git Basics: Tagging
Listing Your Tags
git tag
Sharing Tags
git push origin <tagname>
If you have a lot of tags that you want to push up at once, you can also use the –tags option to
the git push command.
git push origin –tags
Checking out Tags
If you want to view the versions of ﬁles a tag is pointing to, you can do a git checkout, though
this puts your repository in “detached HEAD“ state.

Git Branching: Killer Feature
The way Git branches
is incredibly lightweight,
making branching operations nearly instantaneous, and
switching back and forth between branches generally just as fast.
→ A branch in Git is simply a lightweight movable pointer to one of the
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, it moves forward automatically.

Git Branching: Killer Feature
How does Git know what branch you’re currently on? It keeps a special
pointer called HEAD.

Git Branching
Creating a New Branch
git branch <branchname>
git checkout -b <branchname>
Switching Branches
git checkout <branchname>

Branch Merging: Fast Forwarding

Branch Merging: Merge Commit
git merge <branchtomerge>

Branch Merging: Merge Commit
When merging a Branch, make sure your working directory is clean. There
is a chance to loosing your uncommited work.
In case of merge conﬂict people make mistake to commit changes which
are not present in either of the branch.

Branch Merging: Merge Conﬂict

Branch Merging: Merge Conflict
Resolving conflict using git
git checkout –ours <filename>
git checkout –theirs <filename>

Branch Merging: Rebase then Fast Forward
git rebase <onbranch>

git checkout master; git merge experiment
git checkout experiment; git rebase master

git checkout experiment; git rebase master
git checkout master; git merge experiment

Branch Merging: Rebase vs. Merge
The Perils of Rebasing
Ahh, but the bliss of rebasing isn’t without its drawbacks, which can be summed up in a single
line:
Do not rebase commits that exist outside your repository.
If you follow that guideline, you’ll be fine.
In general the way to get the best of both worlds is to rebase local changes you’ve made but
haven’t shared yet before you push them in order to clean up your story, but never rebase
anything you’ve pushed somewhere.
Rule of thumb:
When pulling changes from origin/develop onto your local develop use rebase. (git pull
–rebase origin develop)
When finishing a feature branch merge the changes back to develop. (git merge –no-ff
feature)

Git Branching: Remote Branches

Staging Patches
It’s also possible for Git to stage certain parts of ﬁles and not the rest. For example, if
you make two changes to your simplegit.rb ﬁle and want to stage one of them and not
the other, doing so is very easy in Git.
git add -p -A
You have a lot of options at this point. Typing ? shows a list of what you can do:

Staging Patches
Generally, you’ll type y or n if you want to stage each hunk, but staging all of them in
certain ﬁles or skipping a hunk decision until later can be helpful too.

Git Stashing and Cleaning
Often, when you’ve been working on part of your project, things are in a messy state
and you want to switch branches for a bit to work on something else.
The problem is, you don’t want to do a commit of half-done work just so you can get
back to this point later.
git stash
Apply Stash
git stash apply
Apply and Drop Stash
git stash pop
Cleaning your Working Directory
Dry Run
git clean -d -X -n
Cleanup
git clean -d -X -f

Cherry-Pick
$ git cherry-pick e43a6

Git Reset

Git Revert
$ git revert 8d78c0f
Given one or more existing commits, reverts the changes that the related patches
introduce, and record some new commits that record them.
This requires your working tree to be clean (no modiﬁcations from the HEAD commit).

Interactive Rebase

Undoing Merges: Reset

Undoing Merges: Revert

Debugging with Git: File Annotation
If you track down a bug in your code and want to know when it was introduced and why, file
annotation is often your best tool.
It shows you what commit was the last to modify each line of any file.
The following example uses git blame to determine which commit and committer was
responsible for lines in the top-level Linux kernel Makefile and, further, uses the -L option to
restrict the output of the annotation to lines 69 through 82 of that file:

Useful Resources
Documentation Book
https://git-scm.com/book/en/v2/
GitHub Cheat Sheet
https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf
Visual Git Cheat Sheet
http://ndpsoftware.com/git-cheatsheet.html
Branching Workﬂows
https://www.atlassian.com/git/tutorials/comparing-workflows
Best Practices
1 https://www.git-tower.com/blog/version-control-best-practices/
2 https://www.lullabot.com/articles/git-best-practices-workflow-guidelines
3 https://blog.hartleybrody.com/git-small-teams/
4 https://sethrobertson.github.io/GitBestPractices/

Thanks for your attention!
Any questions?
Hope you slept comfortably!

Git and Version Control at Atlogys

More Related Content

What's hot

Similar to Git and Version Control at Atlogys

More from Atlogys Technical Consulting

Recently uploaded

Git and Version Control at Atlogys