Git censored.key

USING GIT TO DEVELOP

1. Motivation.
2. Optional segment: Very brief introduction to the git object model.
3. Optional segment: quickstart guide (requires #2).
4. Suggested git workﬂow for anet.
5. How to set up automatic backups.

MOTIVATION

• Client view is not backed up.

MOTIVATION


• Not easy to share code.

MOTIVATION



• If you head down a dead end, you have to manually go back and clean that up.

MOTIVATION




• Aborting an idea means its permanent destruction

MOTIVATION





• Unless you want to keep a client open for it permanently.

MOTIVATION






• But really, who does that?

MOTIVATION






• But really, who does that?

• PITA if you have to rush a bug ﬁx through on a dirty branch.

GIT CAN

• Provide a way for you to make nightly or hourly snapshots of your work.

GIT CAN


• Let you create as many personal branches as you want, one for each idea.

GIT CAN



• Unwind your personal development history to the last good state with a single
command.

GIT CAN



command.

• Make it harder to clobber unsaved progress.

GIT CAN



command.


• Share your speculative branches with other developers.

GIT CAN



command.


• Share your speculative branches with other developers.

• You can commit at any time. Anything you want. No one will ever see it until you
want them to.

GIT OBJECT MODEL

• 5 slides, 5 minutes. Do you want to continue? [Yes]/[No]

GIT OBJECT MODEL
Don’t be lazy. Learn how it really works.

3 Types of Objects
• Blobs
• Trees

3 Types of Objects
• Blobs
• Trees
• Commits

3 Types of Objects
• Blobs
• Trees
• Commits
• Refs

3 Types of Objects
• Blobs
• Trees
• Commits
• Refs
• Tags

Blobs
• Blobs == The Contents Of A Regular
System File.
• uniquely identiﬁed by a sha-1
• Identical ﬁles are only _ever_ stored once
in a git object store.
• Git doesn’t store changes. It stores blobs.
Don’t listen to Joel Spoelsky. [1][2].

Trees
• A tree of blobs and trees.
• Not ﬁle-system dependent*
• An identically structured tree of identical
blobs with identical permissions always
has the same sha-1 hash.
• *but it does store an internal
representation of POSIX-like ﬁle
permissions

Commits
• A pointer to a tree
• A pointer to the previous commit on the
branch
• Metadata (commit message, time,
author)
• Most of the time, you interact with
commits

Refs ands Tags
• Pointers to a commit
• “All problems in computer science can
be solved by another level of
indirection” - Butler Lampson

Using Git

Do you want to hear this? [No]

Using Git

Git changes your “working directory” to look like the tree
pointed at by a commit. (via git checkout).

Using Git

This is how you revisit prior states, which is git’s primary
purpose.

Using Git

This is how you revisit prior states, which is git’s primary
purpose.
All other high-level operations in git are for viewing,
creating, pointing at, and modifying commits.

Working Directory

Where you make changes to the code.
In our case, probably ~/p4 and children

git add <ﬁles>
stage the changes in your working directory for being
committed to the current branch (by updating the index).
intermediate step between working directory and the
bowels of the git object store
important difference from P4
Serves a purpose analogous to grouping ﬁles by
changelist in perforce.
Can be hunk-level atomic with --patch

git commit

“commit” the contents of the index to the permanent
object history.
Creates a new commit object and updates HEAD to point
at the new commit object.

Viewing History

git log - show commit metadata
git show - does a lot of stuff
git status - also does a lot of stuff
git diff - diff blobs, trees, and commits

The Docs Are Better

To learn how to use git, you can try the quickstart guides
(linked on the wiki).
It did take me a while to grok this stuff.
The time investment paid off quickly.

SIMPLE GIT WORKFLOW
• Initialize your p4 client view as a git repo.

• in bash_profile: source /home/mkramer/.gitstuff

• adds git, git-p4, python (2.6) to your $PATH
• modifies your $PS1 to have git-specific information
• If you define $MANPATH, appends git man pages to it
• for now, building from source
• prodsys will support if enough use it

• cd ~/p4; git init; git add -A; git commit -m “Taking the red pill”;

• Work as normal. Commit your intercolary changes to git as you see fit.

• When you are ready, p4 submit.

• I did this for a few months, and it works great.

PULLING FROM UPSTREAM

• You need to periodically integrate changes from the Perforce server.
• The simple approach is to just fullsync as normal. Git registers the changes to the
files just as if you had typed them by hand. Then you commit them as a normal
commit.
• git stash; fullsync; git commit -a -m “Pull down changes from p4”; git stash pop
• stash saves the diffs in your working directory to a temporary stack and makes
your working directory look like HEAD.
• If you have merge conflicts with p4 head, stash pop will fail and you will have to
resolve the changes using the convenient git mergetool.
• You were going to have to codecheck the conflict resolution anyway.
• But you don’t have to resolve if you don’t want to: just accept yours and let the
integrators handle it.
• It’s easier to resolve conflicts when you pull from upstream continuously

SIMPLE WORKFLOW REPOS LOOK LIKE THIS

• Pink boxes are commits made to pull p4 changes down.

master

HEAD master master~1 master~2 master~3

refs/heads/topic topic topic~1

git-p4

• git-p4 is glue that creates a 1:1 relationship between git commits and p4
changelists.

git-p4

changelists.

• This is opposed to the naive way, where you just create a new commit every time
you fullsync, and a new changelist every time you p4 submit.

git-p4

changelists.


• It does this by sucking down p4 changelists and turning them into commits
(metadata and all) when you git-p4 sync,

git-p4

changelists.


• It does this by sucking down p4 changelists and turning them into commits
(metadata and all) when you git-p4 sync,

• and by turning commits into p4 changelists when you git-p4 submit.

git-p4: WHY?

• Inspect perforce history from the ease and comfort of git.

• Your commits are never out of sync with your changelists.

• possible convenience in git-p4 rebase

• git bisect - binary search through commits to ﬁnd the one that introduced the
regression

git-p4 SETUP

• initialize your client view as in simple case

• cd ~/p4 && git init && git commit -a -m “Red Pill”

• git-p4 sync --use-client-spec

• The ﬁrst time, this pulls down the head revision of the client view of your depot
and creates a single, parentless commit out of it, storing a reference to that
commit in ~/p4/.git/refs/remotes/p4/master

• Subsequent times, it ﬁnds changelists that have been added since the last time
you called git-p4 sync, makes a commit out of each changelist, and applies them
in order on top of the commit pointed to by refs/remotes/p4/master

• It’s now up to you to pull the changes from p4 into your local branch.

git-p4: REBASING FROM UPSTREAM


• git-p4 provides a convenience wrapper, git-p4 rebase, that does the equivalent of
the following:

• git-p4 sync

• git stash

• git rebase refs/remotes/p4/master

• git stash pop


the following:

• git-p4 sync

• git stash


• git stash pop

• I’m not sure that you’d ever want to do this


the following:

• git-p4 sync

• git stash


• git stash pop


• It depends on whether your topic branches are all based on the remote ref or
whether they’re based on each other


the following:

• git-p4 sync

• git stash


• git stash pop



• You really ought to understand what this is doing before you do it


the following:

• git-p4 sync

• git stash


• git stash pop



• You really ought to understand what this is doing before you do it

• Let’s go through it now

WHAT REBASING DOES

• git rebase is a very powerful tool

WHAT REBASING DOES


• allows you to rewrite history

WHAT REBASING DOES



• allows you to drop commits, squash commits together, split commits apart,

WHAT REBASING DOES




• alter history so that branches are based on other commits (which is where the
command got its name, though it really does way more than that)

WHAT REBASING DOES





• there’s a catch

WHAT REBASING DOES





• there’s a catch

• Downstream branches don’t get the memo

THE CATCH

master

HEAD master master~1 master~2 master~3 refs/remotes/p4/master


THE CATCH

• Simple example from the manpage. Your repository looks like this:

master



THE CATCH

• Simple example from the manpage. Your repository looks like this:

master



• Circular figures are refs. Angular figures are commits.
• A branch is defined as the commit pointed to by a ref, and all of its parents.
• master~3 actually points to the commit pointed to by the ref in this diagram, but
this serves for simplicity. (git documentation equivocates between refs and the
commits that they point at all the time).

THEN YOU git-p4 sync

• Again, this sucks changelists down from p4, turns them into commits, then applies
them on top of refs/remotes/p4/master

refs/remotes/p4/master

refs/remotes/p4/master~1
master

HEAD master master~1 master~2 master~3 refs/remotes/p4/master~2


THEN YOU git-p4 sync

• Again, this sucks changelists down from p4, turns them into commits, then applies
them on top of refs/remotes/p4/master
• So far, so good.

• master~2 and master~3 are actually nameable by that
syntax. ~n means “the nth parent” (following the leftmost
parent, in the case of merges). refs/remotes/p4/master

• master~2 and master~3 are also nameable with topic~2 and
topic~3
master



THEN YOU REBASE

master

HEAD master` master~1` master~2` master~3` refs/remotes/p4/master

refs/heads/topic topic topic~1 refs/remotes/p4/master~1

master master~1 topic~2 topic~3 refs/remotes/p4/master~2

THEN YOU REBASE

• Rebase master onto the commit now pointed to by refs/remotes/p4/master, and you
get this mess.

master




THEN YOU REBASE

• Rebase master onto the commit now pointed to by refs/remotes/p4/master, and you
get this mess.

master




• Topic is pointing at the wrong place. It does not see the upstream changes
• As a side note, master and master~1 are “dangling commits”, because they aren’t
reachable by any ref. You can’t name them with “master” any more, as that points
at master`.

MERGE NOW, THINGS GET UGLY PERMANENTLY

master~1 master~2 master~3 master~4 refs/remotes/p4/master
master

HEAD master

refs/heads/topic topic topic~1 topic~2 topic~3 refs/remotes/p4/master~2


• Say you merge topic back into master

master

HEAD master



• Say you merge topic back into master

master

HEAD master


• topic~2 and 3 shouldn’t be there. We have tried to rewrite history so that they never
existed, but here they are.

• Side note: the merge commit points to two parent commits.

• Also: Yes, refs/heads/topic will still be there. You might want to delete it now (with git
branch -d topic). You typically don’t merge “upwards” until your topic branches are
ﬁnished.

RECOVERING FROM UPSTREAM REBASE

master




RECOVERING FROM UPSTREAM REBASE

• Back up. Here’s where we are after git-p4 rebase

master




REBASE ALL OF YOUR BRANCHES

• An upstream rebase has to cascade down.
• This is what you’d want to do, probably:
• git checkout topic && git rebase --onto master~1


HEAD
master~1` master~2` master~3` refs/remotes/p4/master

master master`



DON’T USE git-p4 rebase
• Else you’ll get this:

refs/heads/topic topic topic~1 topic~2 topic~3


HEAD master` master~1` master~2` master~3`


master

• This isn’t what you wanted, is it? refs/remotes/p4/master~2

• Oh, it is?
• Well, if you base all of your topics off of refs/remotes/p4/master, then this
workﬂow works great!
• People do work this way.

REBASE ONTO master

• A lot of people just keep their topics rebased onto master

master



• So: git checkout master; git-p4 rebase; git checkout topic; git
rebase --onto master; git checkout master refs/remotes/p4/master~2

• Tragically, have to rebase --onto master for every topic
• You’d have to git-p4 rebase for every topic, anyway. So it’s
really up to you.
• You can mix and match these techniques

ALTERNATIVE TO REBASING

• Merging.

• After a git-p4 sync, you could merge instead:


master



MERGING cont

• A merging ﬂow looks like this.



master master

HEAD master~1 master~2 master~3 master~4


MERGING contd

• Continually merging “down” from the “upstream” produces a stitching pattern

master

HEAD refs/remotes/p4/master~2
master
master~1


master~2 master~3 master~4 master~5


REBASE YOUR TOPICS

master

HEAD refs/remotes/p4/master~2
master
master~1


master~2 master~3 master~4 master~5


BACKUPS

• Git only ever stores a blob one time.

• We can use this to create a master backup repository where everyone can push all
their branches. Only the files that have changed will be saved again.

• This is already done. The repo lives in /home/mkramer/omni-backup for now.

• It automatically fetches any repo it finds in ~/p4 every night. So if you’ve got your
repo there, you’re done. (You can confirm this by stashing your work and then
checking out /home/mkramer/omni-backup/refs/remotes/$your_user_name/
$your_branch_name. It should reflect the state of that branch from last night.)

• If you want a remote to get sucked in from elsewhere, ask to have the remote set
up.

I JUST WANT BACKUPS

• Use the simple workﬂow. Setup:

• source /home/mkramer/.gitstuff

• cd ~/p4; git init; git commit --all -m “init”

• periodically: git stash; fullsync; git commit --all -m “p4”; git stash pop

• Just don’t branch or use any of git’s features.

• Done.
master

HEAD master master~1 master~2 master~3

citations

• [1] http://www.joelonsoftware.com/items/
2010/03/17.html
• [2] http://www.book.git-scm.com/
1_the_git_object_model.html

Git censored.key

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (7)

Semelhante a Git censored.key

Semelhante a Git censored.key (20)

Último

Último (20)

Git censored.key

Notas do Editor