Git’in Jiggy With Git
•Descargar como PPTX, PDF•
0 recomendaciones•476 vistas
A brief overview of the distributed source control system known as Git
Recomendados
Recomendados
Más contenido relacionado
Similar a Git’in Jiggy With Git
Similar a Git’in Jiggy With Git (20)
Más de RTigger
Más de RTigger (20)
Último
Último (20)
Git’in Jiggy With Git
- 1. Git’in Jiggy With Git With your co-host: Will Smith!
- 2. 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
- 3. 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
- 4. 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 Reference Previous commit 89adf523ad1234
- 5. Git is a big-ass linked list! Last First! Commit
- 6. How do we keep track of everything!? REFERENCES! Develop! Last First! Commit Version 4.2!
- 7. Commits, How Do They Work? Develop Staging New First! Commit
- 8. Doing it wrong: Branching BRANCH! COPY OF ALL TEH FILEZ ALL TEH FILEZ
- 9. Doing it Right: Branching! Develop First! New Branch!
- 10. Merge! Develop Merge First! 2 Commit Current Position 1 3 4 Feature
- 11. All Your Rebase R Belong To Us Develop First! Current Position Feature
- 12. Working With Remotes Origin “Clone” “Pull” Local “Push”
Notas del editor
- 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