Why Git and not X?
• You can find many comparisons and discussions on line.. Will not talk about this here much
• Yes, Git is Hard since it’s Complex.
• It’s complex in order to be flexible and powerful
• Yes, SVN is simpler, until you need to do something complicated
SVN ModelThe Server
User2Repo2
User2Repo1
CommitCheckoutUpdate
commit
trunk Branches
Branches/b1trunk
User1Repo1
trunk
b1
root
GIT ModelThe Server (just Another Repo)
User2 Repo
ClonePull
master branch1
origin/master
User1 Repo
origin/master
mybranchbranch123
branch123branch456
push
push
branch2
origin/branch2
ClonePull
PullUser2/branch456
pushWho is server and who is client?
Basic Definitions
• Repository
– Collection of files and their history organized in folders, branches, tags
– Is stored in a normal file system somewhere
– Can be on a local machine or a remote machine
– To work with GIT you will need a repo somewhere
– When creating a new one… it’s empty
Example 1
Basic Definitions
• Workspace– Where you do work..
• Index– Snapshot of files in the workspace (can be some of
them.
– You add to the index files you change / remove etc.
• Commit– A snapshot of the workspace at some point
– Has unique revision number
– Knows the commit (commits) that it’s based on
workspace indexRepository
store
changes
staged add
commitCommitted and generated unique rev. number
changes
staged add
Simple Local GIT
Work
Add To Index
Commit
• Add / Remove• Change Files
• Add (same as “stage”) the changes• Not all files must be staged• Can stage changes to same file several times• Think “snapshot” of the work
• Changes from the index stored• Get a unique rev. number• Index emptied
Example 2
Branches
• Branch is a pointer to a commit
• A branch can point at other commits – it can move
• A branch is a way to organize working histories
• Since commits know which commits they are based on – branch represents a commit and what came before it.
Branches
• When doing a “commit” the current “branch” moves to point at the new commit
C3 C2 C1bx
On branch bx -> Commit of C4
C3 C2 C1bx C4
Example 3
Branches
• Here is a branch
• Creating a new branch just adds another “pointer” to the same commit
C3 C2 C1bx
C3 C2 C1
bx
by
Example 3
Branches
• Other branches are not affected by a commit
C3 C2 C1
bx
by
C3 C2 C1
bx
by
On branch bx -> Commit of C4
C4
Example 3
Branches
• Checking out a branch puts the snapshot (the commit) it points to into the workspace
workspace indexRepository
store
Checkout branch yBranch y snapshot
Branch x snapshot
Now on branch y
Example 3
Branches
• master – is just another branch, but is the default one which gets created. (So you will always see it in a repo)
• Branching is cheap – feel free to branch a lot.
• Branch is a good way to work on multiple things in parallel
Merging
• Combining one ore more branches into the current branch
• Allows changes from other branches to be integrated into the current work history
• Usually generates a new commit which has more than one predecessor
• Other branches not affected
Merging
• The branch “bx” was not affected
• Merge only changes the workspace. Still need to add (to index) and commit (“by”) to actually generate “c6”
C3 C2 C1
bx C4
by C5C6
Merging - Conflicts
• When merging, if there are conflicts - need to solve them.
• After solving, need to “add” the changes and commit the merged workspace
Example 3
C3 C2 C1
bx C4
by C5C6
Merging – fast forward
• Fast Forward – a type of merge which only requires moving the “branch” pointer
• Possible when the current branch is an ancestor of the merged branch
• No new “merge” commits need to be created
Merging – fast forward
C3 C2 C1bx
by
C4
Merging bx into by
C3 C2 C1bx
by
C4
C4 is based on C3 so “by” which points to
C3 can move to point to C4
Example 4
Merging – fast forward
C3 C2 C1
bx
by
C4
C4 is not based on C5, so cannot fast
forward.
C5
C3 C2 C1
bx
by
C4
C5
C6
Now its possible to ff by
In that case, merge…
Collaborating
• Clone – creates a local repository by copying another (remote) repository
• Repositories which were cloned can exchange changes between them
• Pull? For now forget about it. we will come back to it later
• Commits are always local. But can be sent to other repositories.
Fetch
• Fetch – gets changes from a remote repository that you don’t already have.
• Fetch gets the changes to the local repository but does not touch the index or workspace.
• After a fetch, usually a merge needs to take place (more on this later)
Remote Branches - fetch
• Remote branches represent the state of a branch on the repository it is fetched from
• It is like another branch when it comes to merging from
• You cannot checkout a remote branch, you branch it (create a local pointer to it)
• After fetching, a remote branch and it’s local branch counterpart may need to be merged
Remote Branches
My Machine The Server
C1
master
C0
cloneC1
origin/master
C0
master
This is a remote branch
origin is just a name for a “remote”
Example 5
Remote Branches - fetch
My Machine The Server
Some changes on the server
C1
C0
master
C2C1
origin/master
C0
master
fetch
Remote Branches - fetch
My Machine The Server
C1
C0
master
C2C1
origin/master
C0
masterC2
Can merge!
Remote Branches - fetch
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2Now merged (fast forward in this case)
Example 5
push
• Will take local objects (commits, tags) which are required to make a remote branch complete – and send them.
• Will merge those local changes into the remote branch
• Will only do a “fast-forward” merge (other merge type, if required, will fail the push)
Remote Branches - Push
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2
C3
This commit is not on the remote
master
Remote Branches - Push
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2
Now merged and in a fast forward manner
C3 C3
Example 5
push
• If cannot do a fast-forward – will fail. Then, afetch + merge is required to allow the push.
• Once remote changes merged locally again a fast forward is possible and the push would work.
Remote Branches - Push
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2
This commit is not on the remote
master
C3 C4
This commit is not on the local master
But local origin/master does
not know…
Remote Branches - Push
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2
C3 C4
push
No can do, fetch + merge first.
Remote Branches - Push
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2
C3 C4
fetch
Remote Branches - Push
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2
C3 C4
The commit from the remote arrived
C4
This is what the remote knows about
the master branch
Remote Branches - Push
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2
C3
C4C4
C5
Now merged to local master
Remote Branches - Push
My Machine The Server
C1
C0
master
C2
C1
origin/master
C0
master
C2
C3
C4C4
C5
push
Remote Branches - Push
My Machine The Server
C1
origin/master
C0
master
C2
C3
C4
C5
Now merged since fast forward is possible
C1
C0
master
C2
C3
C4
C5
The commits from the local arrived
Example 6
Remote Branches
• Reminder - Remote branches represent a branch on a remote repository
• The branch origin/master for example is a local pointer to the “master” on “origin”
• It reflects what the local repository currently knows about the state of “master” on “origin”
• You cannot change them, but you can “checkout” to get a “remote tracking branch”
Remote Tracking Branches
• A local branch which is configured to “track” a remote branch
• Will allow commands like “fetch” and “push” to know where to send/get changes
• Just a helper, you could specify all the locations in the command args
• Helpful also to remember where a local branch points to
Remote Tracking Branches
• When cloning a remote repo will check out the remote “master”
• “origin” is default name for the remote you cloned from
• So “origin/master” is the remote branch and “master” is configured to track it
• master is a remote tracking branch
Remote Branches Summary
My Machine The Server
srv1/branch1Cx
branch1
Cx
branch1
CyCy
remote: srv1 -> https://the.server/...
points at
Local state of
tracks
created when “fetch” from srv1
Created when “checkout” srv1/branch1
pull
• Now it’s time to talk about pull since it’s just a shortcut command to do:
1. Fetch from a remote
2. Merge changes from “remote branch” into the “remote tracking branch”
• Sometimes the tool would also allow to “commit” merges for you right after the pull (not part of pull, but a helper)
workspace indexRepository
store
clone
Remote Repository
checkout
add
push
commit
fetchmerge
Pull (fetch+merge)
Summary of operations
Rebase
• Instead of merging, replays set of changes on top of another branch
• Affects the “rebased” branch only
• Changes the history of commits
• Can be dangerous
• Very useful to remove history clutter
• Simple rule, use locally only and for branches which you will never share
Rebase
C2
bx
by
C4
C3
C2
bx
by
C4
C3C5
Merge bx into by
C2
bx
by
C4
C3C3’
Rebase by on bx
Note: In both cases can now fast-forward bx
Committing will have c4 as the only ancestor of c3’
Committing will have c4 and c3 as two ancestors of c5
Rebase – when to use
• You have a local branch – has some changes committed to it
• Fetched a remote branch
• Instead of merging into remote branch –rebase on it
• Now merge (fast forward) into the remote branch
• Push happilly
Example 7
We did not discuss
• The “Pull Request”
• Suggested work flow for small teams
• GitHub and BitBucket
Go learn more…
Summary
• Git is complex, but flexible and powerful
• Git supports distributed teams very well and also is the standard de-facto for OSS projects
• Due to it’s flexibility, every team needs to decide on the workflow which works best for it
How to know more
• Read the Git Pro Book
• No really, its very good, explains most of the stuff well
• Look for blog posts with titles like “how I got started with git”
Top Related