Git more

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Git more
Carl Jiang
April 2014

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
Git more
Slides Prerequisites:
Assume audiences have already
attended Dream’s previous session
about Git or they have already
mastered basic idea about Git.

Git more
• Git can be powerful
• Git can be confusing
• Best Practice we should follow
• Gotchas
• Tips
• Workflow in SP
• References
Agenda

Git can be powerful
• Most operations are offline, extremely FAST. Branches are CHEAP.
• Want to refine commit message? No problem.
• Want to reorder commits? No problem.
• Want to merge certain commits into one? No problem.
• Committed too often, too fast, so you end up having some commits with typos, trivial bugs. Want to
fix them? No problem.
• Accidently lost some changes? Want to get them back? No problem, as far as it was committed,
stashed, or even “git added” before.
• After 10 commits, you noticed that you were working on the wrong branch? No problem.

Git can be powerful
as far as you understand it

Git more
• Gotchas
• Tips
• Workflow in SP
• References

#1 git push & pull
Git can be confusing
Beautiful work, let me try git push
now.

git push & pull
I already committed something.
What happened? Let me try git
pull instead?

git push & pull
What’s wrong?

tracked, remote tracking branch, Upstream
• Git add/commit makes a file “tracked” by Git
• remote-tracking branch is a local cache of the state of a branch in a remote
repository (for example, origin/master)
• You can create a new local branch to track “remote-tracking branch”. And this
“remote-tracking branch” is now “Upstream” to your local branch.

What does registering upstream bring us?
Having an upstream branch registered for a local branch will benefit:
• tell git to show the relationship between the
two branches in git status and git branch -v.
• directs git pull without arguments to pull from the upstream when the new branch is
checked out.

Other ways to check upstream branch relationship

How to setup upstream branch?
To solve this problem,
Set upstream branch relationship like what Git has been trying to tell you:
git branch --set-upstream-to=origin/branch_name
Or
git branch -u origin/branch_name
Or
git pull with specific remote name and branch name

How to setup upstream branch automatically?
Good news is you already do..(sort of)
There is a git config named “branch.autosetupmerge” decides whether automatic setup
upstream when checkout starting point is a remote-tracking branch;
You all know what does “false” means here.
Default value is “true”
This means if you are checking out a new local branch from a remote-tracking branch you will always (by
default) have a new local branch with upstream setup correctly.
And there is another valid value “always”
automatic setup is done when the starting point is either a local branch or remote-tracking branch.

What does setuping upstream do behind the scene?
After you setup upstream branch, if you check.git/config, you will find:
This means it’s part of git config, you can also setup upstream branch by using “git
config”
git config branch.branch_name.remote remote_repository
git config branch.branch_name.merge upstream_branch_name

git pull problem solved.
This is what Older version of Git has been
trying to tells us……
A little too complicated?
That’s why they simplified the messages
in newer version.

git push problem solved?
Now, do you know why we failed to “git push”
last time? I bet you do.

But you probably don’t.

Another git config “push.default” (since Git 1.6.3)
• nothing: do not push anything
• matching: push all matching branches
All branches having the same name in both ends are considered to be matching. This is the default
in Git 1.x.
• current: push the current branch to a branch of the same name. (I consider it’s light version of “matching”)
• upstream: push the current branch to its upstream branch (they used to call it tracking, now it is a
deprecated synonym for upstream)
• simple: (since Git 1.7.11) like upstream, but refuses to push if the upstream branch's name is different from
the local one
This is the safest option and is well-suited for beginners. This will become the default in Git 2.0.
The simple, current and upstream modes are for those who want to push out a single branch after finishing
work, even when the other branches are not yet ready to be pushed out

So what you should do is
git push -u origin branch_name
for the first time. And you are welcomed to
use
git push
starting from 2nd time

Summary:
• git pull & push need “upstream” set to work properly(mindless).
• “git push” by default push all “matching” branch to remote, which is something 99.9% time we don’t
want. We should change it to “simple” or “upstream”
• Does it pull everything from remote? We don’t know that yet.

#2 git pull generates empty merge commits
Why does git generate such a meaningless
empty merge commit?

git pull = git fetch + git merge/rebase
Default git pull = git fetch + git merge FETCH_HEAD
So git fetch (update) ALL remoting-tracking branch from remote repository
and
mark upstream of current branch in FETCH_HEAD
and
merge freshly fetched remote-tracking branch into local branch

What should we do?
We should use
git pull --rebase

Make git pull by default git pull –rebase
Setup git config ‘branch.autosetuprebase’
This option controls whether new branches should be set up to be rebased upon git pull, i.e. your
setting of always will result in branches being set up such that git pull always performs a rebase, not a
merge.
(Be aware that existing branches retain their configuration when you change this option.)
# make `git pull` on master always use rebase
$ git config branch.master.rebase true and Yes, it is stored as plain
text in the .git/config

Or
What do I do is I DONT use git pull at all.
I usually use
git fetch origin -p or git remote update -p
then
use git status/git log/git diff to check my remote tracking branch.
Then I will decide whether I use git merge to fast-forward changes or git rebase my branch or email
someone asking about changes before I do anything.

Summary:
• git pull fetch all changes from remote branch and only update current branch based it’s
upstream branch.
• git pull by default merge upstream branch into current local branch
• We may want to use git pull --rebase or make it default setting.

#3 git rebase squeeze “bubbles”
preview of those bubbles

Let’s squeeze it
with
git rebase -i HEAD~2

Bubbles gone! Pew!

git reset --hard 51c43b4
git reflog master
How to recover?

git rebase –i --preserve-merges HEAD~2
Or
git rebase -i @{u}
How to prevent?

How to prevent “git pull --rebase” from squeezing “bubble”?
git pull --rebase=preserve
Since Git 1.8.5

#4 git rebase
git checkout experiment
git rebase master
Pictures From “Pro Git”

git rebase
git rebase --onto master server
client

git rebase
git checkout experiment
git rebase master
git rebase --onto master master experiment

git rebase v.s cherry-pick
git rebase's task is to forward-port a series of changes a developer has in its private repository,
created against version X of some upstream branch,
git cherry-pick is for bringing an interesting commit from one line of development to another.

git rebase v.s cherry-pick
Well…….
Since its first appearance, git cherry-pick learned to be able to pick several commits at once,
one-by-one.
e.g git cherry-pick 234d34a 3ak23akl 6u2k12k
Since Git 1.7.2+, it now supports ranges
e.g. git cherry-pick A..B

#5 git rebase -- conflict
I just invoked git rebase
otherbranch, and encounter
“CONFLICT”,
It tells me to run “git rebase –
continue” after resolve it.
no big deal!

git rebase -- conflict
I just resolved it by accepting
changes from one side.
And run “git rebase –continue”
Huh? Git seems still not happy.
Ok, I forget to use “git add” to mark
“resolved”, easy.

What?
I just run “git add .”
And Git is still not satisfied.
What now?

Some times, conflicts occurs not just because both
branch modified on same places of same files. Someone
could have done exactly same thing like you did in this
single commit.
So after you resolved the conflict, you might end up
seeing Git tells you
“hey, nothing to commit, working directory clean”.
That’s totally ok, move on. Just skip this patch (git rebase
--skip)
It’s called “英雄所见略同” in Chinese.

#6 git reset
• ALL reset moves HEAD to specified commit.
• git reset never touches untracked files. git clean will.
• git reset --hard resets the index and working tree (but not untracked files). Very
dangerous.
• git reset --soft does NOT reset index or working tree. BUT it will move all changes files
from resetted commits to index.(so git status could see it)
• git reset --mixed (this is default) resets the index but not the working tree (i.e., the changed
files are preserved but not marked for commit). You can call it “unstage”.
• git reset --merge save you from middle of merge conflict

git reset --hard HEAD
BEFORE AFTER

git reset --soft HEAD
BEFORE AFTER

git reset HEAD (--mixed)
BEFORE AFTER

git reset HEAD~1
• git reset --hard all committed or added file are GONE. Only untracked file are kept.
• git reset --soft move all changes files from commit 3 will be moved to index(stage). (as they have
been added, ready for commit)
• git reset --mixed move all changes files from commit 3 will be moved to working file. (as they have
been modified, ready for git add)

Commands & areas

Git more
• Gotchas
• Tips
• Workflow in SP
• References

Best Practice we should follow
• Try to use latest version of git
• Commit Often, Perfect Later, Publish Once
• Do make useful commit messages
• Don't change published history
• Do choose a workflow
• Don’t Panic

Characters of commits
“As a general rule, you should try to split your changes into small logical
steps, and commit each of them. They should be consistent, working
independently of any later commits, pass the test suite, etc. This makes the
review process much easier, and the history much more useful for later
inspection and analysis, for example with git-blame(1) and git-bisect(1).”
From https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

Do experiments(merge, rebase, cherry-pick, reset ….) on a new branch,
so you can switch back easily

Squash duplicates commits into one commit for sure

Write commit message more specific,
changed WHAT, for WHAT REASON, etc.

Avoid creating “empty merge commit“

But try to keep history of feature
branch, which will be delete
after merge, in master by
creating “empty merge commit”
explicitly
Use git merge --no-ff

Git more
• Gotchas
• Tips
• Workflow in SP
• References

Gotchas
Easy one,
Just git branch new_branch_name
And
git reset --hard
HEAD~HOW_MANY_COMMITS_YOU_HAVE_MADE

Git stash lost
Gotchas
If you have only just popped it and the terminal is still
open, you should be able to see the SHA hash value
when you popped it
Or
gitk --all $( git fsck --no-reflog | awk '/dangling commit/
{print $3}' )
Try to find poped stash as a dangling commit in the
window

git merged while should have rebased
Gotchas
git reset --hard HEAD

Git more
• Gotchas
• Tips
• Workflow in SP
• References

Tips
@{-1} or - represent last branch
For example, git checkout - to checkout last branch, git merge - to merge last branch
@{u} upstream
git reset --hard @{u}
- reset to upstream state
git log @{u}..HEAD
git add -u
- help you to “git rm” those files you have already manually removed.
git add .
git add -A .= git add . + git add -u .
git config merge.defaultToUpstream true
- so you can use git merge without any parameters directly merge upstream

git commit -a --fixup (commits you want to fix) Since Git 1.7
Tips
And then run git rebase -i @{u}
You will see
pick SHA message_of_commit_you_want_to_fix
fixup SHA fixup! message_of_commit_you_want_to_fix
pick SHA other commits
So the last commit will be automatically “merged” into your commit history
Assume you all know about
“git commit --amend“, and
“git rebase -i"

Delete branch from remote repository
Tips
Sicne Git v1.7.0, you can delete a remote branch using
git push origin --delete <branchName>
which is easier to remember than
git push origin :<branchName>

Git GUI client
Tips
• SmartGit -- not free
• GitExtensions
• Atlassian SourceTree
• gitk (from Git)
• tig (https://github.com/jonas/tig)

SmartGit
Tips

GitExtensions
Tips

Atlassian SourceTree
Tips

gitk
Tips

tig
Tips

Git more
• Gotchas
• Tips
• Workflow in SP
• References

Branches
Workflow in SP
• Master branch (develop)
• Feature branches
• Bugfix branches
• Maintenance branches
• Hotfix branches

Branches
Workflow in SP
Master branch
We consider origin/master to be the
main branch where the source code
of HEAD always reflects a state with
the latest delivered development
changes for the next release.

Branches
Workflow in SP
Feature branch
Feature branches (or sometimes called topic
branches) are used to develop new features for
the upcoming or a distant future release. When
starting development of a feature, the target
release in which this feature will be incorporated
may well be unknown at that point. The essence
of a feature branch is that it exists as long as
the feature is in development, but will eventually
be merged back into develop (to definitely add
the new feature to the upcoming release) or
discarded (in case of a disappointing
experiment).
Naming convention: feature-AGM_STORY_NO
Forked from master, merged back to master

Branches
Workflow in SP
Bugfix branch
Bugfix branch is like feature branch, it’s
used to develop “bugfix” for any defect not
going to be a hotfix for any previous release.
Naming convention: bug-
AGM_DEFECT_NO
Forked from master, merged back to master

Branches
Workflow in SP
Maintenance branch
It acts like “master” branch for previous
release if any hot fix and new version for
previous releases are needed. Normally
unplanned, doesn’t have to be created
all the time. Used to group several hotfix
and prepare for newer version for
Naming convention: maintenance-
release_no
Forked from release tag, merged back to
master

Branches
Workflow in SP
Hotfix branch
Acts like “bugfix” branch for maintenance
branch, develop hotfix on this branch and
release them as planed.
Naming convention: hotfix-AGM-DEFECT
Forked from maintenance branch, merged
back to maintenance branch

Practice - working on feature branch
• (Create) Fork from master
– git fetch origin -p
– git checkout -b feature-AGM_STORY_NO origin/master
• Work/UT
– ….
– git commit
Workflow in SP

• Push to remote to work with others
– git push -u origin feature-AGM_STORY_NO #first time
– git push
• Work on existing feature branch with other team members
– git checkout -t origin/master/feature-AGM_STORY_NO
Workflow in SP

• Clean up/merge commits history BEFORE merging back to master
– git rebase -i @{u}
• Rebase with master
– git rebase origin/master
• Push back to origin
• Make sure you don’t do this without letting others know if it’s shared branch
– git push -f
Workflow in SP

• Request code review
Feature owner need to do this before he merges completed(UT passed) feature branch
back to master
– git log origin/master --not HEAD
Or
- git log HEAD..origin/master
• Before we introduce GitLab, we use email
Workflow in SP

• Merge back into master
• with explicitly no fast-forward, so where every feature
has its' own "bubble" with clear merge point)
• (ONLY features and bugfixs in the scope of very next
release)
– git rebase origin/master
– git checkout master
– git merge origin/master
– git merge --no-ff feature-AGM_STORY_NO
– git push origin master
• Delete local and remote branch
– git branch -d feature-AGM_STORY_NO
– git push origin :feature-AGM_STORY_NO
Workflow in SP

"Pre-RC/RC" Maintenance
If some bug were found by QA or developer for feature and bugfix before "RC Testing"
phase, no new AGM defect will be open. A new task will be added into original AGM story.
Recreate a feature branch from master, and fix the bug…
If some bug were found by QA or developer for feature and bugfix during "RC Testing"
phase, QA can create a new defect in AGM.
Create a defect branch from master, and fix the bug…
Workflow in SP

Release
Release from master, stable status after several round of RC test and bug fix. Properly
tagged (with Maven plugin)
Workflow in SP

Post-Release Maintenance
If some bugs were raised after release and need a hot fix, create a maintenance branch
from release tag, and then create hotfix branch from that. After hotfix branch passed UT,
cleanup and rebase
Workflow in SP

Git more
• Gotchas
• Tips
• Workflow in SP
• References

References
• http://wholemeal.co.nz/blog/2010/06/11/no-changes-did-you-forget-to-use-git-add/
• http://mislav.uniqpath.com/2010/07/git-tips/
• http://felipec.wordpress.com/2013/09/01/advanced-git-concepts-the-upstream-tracking-branch/
• http://longair.net/blog/2009/04/16/git-fetch-and-merge/
• http://programmers.stackexchange.com/questions/114249/git-what-gotchas-should-newcomers-to-version-control-
be-aware-of
• http://stackoverflow.com/questions/948354/git-push-default-behavior
• http://johnkary.net/blog/git-add-p-the-most-powerful-git-feature-youre-not-using-yet/
• http://www.reviewboard.org/docs/codebase/dev/git/clean-commits/
• http://longair.net/blog/2012/05/07/the-most-confusing-git-terminology/
• http://stackoverflow.com/questions/2530060/can-you-explain-what-git-reset-does-in-plain-english/2530073#2530073
• http://cheat.errtheblog.com/s/git
• http://stackoverflow.com/questions/6406762/why-am-i-merging-remote-tracking-branch-origin-develop-into-develop
• http://stackoverflow.com/questions/7388278/you-asked-me-to-pull-without-telling-me-which-branch-you-want-to-
merge-with
• http://stackoverflow.com/questions/8170558/git-push-set-target-for-branch
• http://ndpsoftware.com/git-cheatsheet.html
• http://baozoumanhua.com

Git more

More Related Content

Similar to Git more (20)

Recently uploaded (20)

Git more

Editor's Notes