References are just ways of accessing specific commits in a user-friendly way
Commits are first created in a staging area. This is where you add all the individual changes that you want to include in your next commit.New commits are added to the end of the current named reference you’re on. The named reference is then updated to point to your latest commit.
A branch is just another named reference. Say we have a “develop” branchTo create a new branch, we just create a new named reference.When commits are created, they’re appended to the end of the branch they’re on, and that branch reference is movedCommits on our new branch will be created on a separate list, with its own reference being moved
Git uses the concept of a “current position” reference to keep track of where your current codebase is in relation to the list of commitsDuring a merge, Git will move the current position to the beginning of the branch where both trees divergeFrom there, it uses the timestamp on each commit to play the commits in order.If there are any merge conflicts, it will record each resolution made and stuff them into a merge commitThe merge commit at the end will have two parent references, pointing to the end of the two branches that were merged
Another common problem is when your feature branch falls behind the develop branch. There might be bug fixes and other new features in develop that you need to continue your feature branch work. Git makes this easy!Like rebase, git will move the current position reference to the point where the two branches divergeIt will then move it to the end of the develop branchAfter that, it stacks all of your branch commits on top of the current position referenceAnd just like after a commit, it will move your branch pointer to the end of the list
Git’in Jiggy With Git
Git’in Jiggy With Git With your co-host: Will Smith!
Why?• Linux kernel devs got upset at BitKeeper because it went closed source• Linus Torvalds (the Linux guy) designed his own distributed source control – Take CVS as an example of what NOT to do – Support a distributed workflow – Strong safeguards against corruption (accidental or malicious) – High performance• Started development April 3rd, 2005• Was used for Linux kernel 2.6.12 (June 16th)• Version 1.0 came out on December 21, 2005
What’s the Deal?• Distributed source control system – Each developer has a complete history of the source, and could easily serve as the “master repository”• Focused on Branching & Merging• Damn Fast
What a commit looks like Timestamp Wed, Nov 9th, 10:37 AM Message “Checkin’ in teh codez” Tree Object (file) Reference(s) /dev/codez/Will_Smith.cs Parent ReferencePrevious commit 89adf523ad1234
Git is a big-ass linked list! LastFirst! Commit
How do we keep track of everything!? REFERENCES! Develop! LastFirst! Commit Version 4.2!
Commits, How Do They Work? Develop Staging NewFirst! Commit
Doing it wrong: Branching BRANCH! COPY OFALL TEH FILEZ ALL TEH FILEZ
Doing it Right: Branching! DevelopFirst! New Branch!
Merge! Develop MergeFirst! 2 Commit Current Position 1 3 4 Feature
All Your Rebase R Belong To Us DevelopFirst! Current Position Feature
Working With Remotes Origin“Clone” “Pull” Local “Push”