Git

DOs and DONTs

Hints and Common Pitfalls
Matthias Mnnich, July 19th
2011

Hint 1:
Separate Local Branches
recommended: One Change, One
Branch
easy checkout your isolated changes
amend / rebase if necessary and push again

delete branches that got obsolete

fetch fresh branch information
branches can be deleted with d if commits
are public

Hint 1:
Separate Local Branches
name your branches to remember
the source and the intention
mergeHana
ISCrashFix_f4d
B1234_hana

Hint 2:
Switching the target branch
you intended to work on feature1 for
hana
=> branch : feature1_hana

now it should go to orange

git checkout b feature1_orange
origin/orange

git log feature1_hana to get the

hash(es)
git cherry-pick <hash>

Hint 3:
Do not switch branches during build!
switching branches with checkout
changes working directory
use hdbenvinit to set up a second
workspace
e.g. for git only tasks

Hint 4:
When to merge, when to rebase?
Merge public branches for integrations
done by topic owners

$
$
$
$

git fetch
git checkout b mergeIntoHana origin/hana
git merge --no-ff --no-commit origin/dev
git commit
- adjust the commit message

Do not rebase merge commits.

Always begin with the first command to redo a merge.

Hint 4:
When to merge, when to rebase?
Rebase local branches containing
YOUR UNPUBLISHED changes H feature
-1

$ git checkout b feature-1

origin/test
origin/te
$ hack hack hack
st
$ git commit
$ git fetch
$ git rebase origin/test

G
1

F
2

C
B
A

E
1

feature
-1

Hint 4:
When to merge, when to rebase?
Unpublished means:
not yet merged to any public branch

Your means:
your local changes that come up in your
history
if you think this is always obvious, wait
for the next slide

Hint 5:
What is a rebase of public commits?
What exactly does a rebase?
$ git checkout mybranch
$ git rebase origin/dev
Go to the latest commit in origin/dev
Put on top everything that mybranch has,
but origin/dev doesnt

Right questions: What exactly gets

rebased?

Hint 5:
What is a rebase of public commits?
Simple case:
mybranch has been based on origin/dev
-> OK
origin/d
ev

B
A

mybran
ch

Hint 5:
What is a rebase of public commits?
First bad case:
mybranch has been based on origin/fixes-for-dev
D

mybran
ch

C
origin/d
ev

origin/fixes-fordev

B is rebased on origin/dev but is already public

Hint 5:
What is a rebase of public commits?
Second bad case : Rebase after merge
mybran
ch

D
B

origin/d
ev

origin/fixes-fordev

C
A

simplified graph
B is again put on dev (but B is already public on
f4d)

Hint 6:
Recover from unintended situations
use local branches as markers
if you are not sure about the upcoming
operation
git branch save_me

to easily get back to states

mark important commits

Hint 6:
Recover from unintended situations
git reflog: history of your local actions e.g.
with commit hashes
fc2180e HEAD@{0}:
checkout: moving from secondbranch to master
28e2275 HEAD@{1}:
commit: second commit
fc2180e HEAD@{2}:
checkout: moving from master to secondbranch

Hint 6:
Recover from unintended situations
git reflog g <branch>
history of local actions for a certain local
branch

Hint 6:
Recover from unintended situations
If you think you did something wrong
1. save console log to have the command history and
output
2. find important commits (gitk / reflog / cons. log)
3. mark important commits
4. temporary commit dirty files
5. think about the next actions
6. in most situations a fresh branch and cherry-picking
your marked local commits is the most efficient way

This usually only takes some minutes.

Hint 7:
Cherry-Picking done right
Avoid cross-branch cherry-picking of
public commits
Potential conflicts have to be solved
upstream
Only push one commit when doing
local cherry picking
not the original one AND the picked one

Hint 8:
Getting your changes in quickly
fetch and rebase before push
this reduces the merge path
avoids conflicts while merging in
changes

use commands provided by Gerrit

Webinterface (checkout, cherry-pick)
build and test locally before pushing

Hint 9:
What is local, what is remote?
remote (porcelain) commands:
clone
fetch
push
pull

local (porcelain) commands:

everything else (commit, add, rebase,
merge, status, checkout, )

Hint 10:
Do not use pull!
Pull is
fetch and merge

If you rebase afterwards:

potential rebase of public commits

Just dont use it in our infrastructure

Q&A