Git is a distributed version control system created by Linus Torvalds for Linux kernel development. It stores snapshots of files and uses checksums to track file versions. Commits contain a message, author, timestamp and reference to parent commits. Branches are pointers to commits that can be rewritten using rebase, cherry-pick or squash to clean up history. Good practices include writing descriptive commit messages and using rebase instead of merge for pull requests.

1. EFFECTIVE GIT
- TEJAS BUBANE
@tejasbubane

2. CONTENTS
▸ Git Philosophy
▸ Log tree
▸ Commits and Branches
▸ Rewriting History
▸ Merge vs Rebase vs Squash vs Cherry-pick
▸ Workflow
▸ Good Practices

3. THE GIT PHILOSOPHY
▸ Created by Linus Torvalds (after conflicts with Bitkeeper)
▸ For use in Linux kernel development
▸ Actually the Linux Philosophy
▸ Uses concepts from POSIX filesystem
▸ Stores snapshots not diffs
▸ All data stored in .git directory in delta compressed form
▸ Precise commands
▸ "Git" means an idiot (British Slang)

4. DISTRIBUTED!
▸ Everyone has local copy of entire history
▸ Can work entirely independently of others
▸ Even without internet
▸ Remote - URL to push the code to
▸ clone brings the project, creates origin and master

5. COMMIT OBJECTS
▸ One logical change in the codebase
▸ Message + Author (name, email) + Timestamp +
Snapshots of all files + Parent(s) reference
= checksum
▸ Everything is checksummed internally, each version of
each file has checksum
▸ Checksum - SHA-1, Unique, 40 character hex (20 bytes)

6. GIT HISTORY
▸ Commits have links with parent(s)
▸ Form a tree structure - Log tree - HISTORY
▸ Branches are nothing more than pointers to commit
objects
▸ Pointers change - refer to different object
▸ Remote and local branches
▸ HEAD - symbolic pointer pointing to current branch

7. MERGE
▸ git merge feature-branch
▸ Fast Forward
▸ Both commits are inline
▸ Just move the pointer to the next commit
▸ Non-fast-forward
▸ Commits not-inline
▸ Create a new snapshot and a merge commit
▸ Looks at nearest common parent to create new snapshot

8. REWRITING HISTORY
▸ Ways to rewrite:
▸ Rebase
▸ Cherry Pick
▸ Squash
▸ Amend
▸ Time Machine
▸ Perils of Rebasing

9. REBASE
▸ Apply each commit from current branch on top of the
target branch
▸ Example:
▸ git checkout feature-branch
▸ git rebase master
▸ Conflicts might arise in application of each commit

10. CHERRY PICK
▸ Example
▸ git cherry-pick eh1629ab1
▸ git cherry-pick feature-branch
▸ Take one commit and apply on top of some branch

11. SQUASH
▸ Example:
▸ git rebase 1na9n5m
▸ git rebase HEAD~3
▸ Then later choose which commits need to be squashed
▸ Remove unnecessary commits - Clean History

12. AMEND COMMIT
▸ Change commit snapshot
▸ Change contents
▸ Change commit message
▸ Usually the latest commit
▸ Example:
▸ Can add files before committing
▸ git commit —amend
▸ amends the latest commit
▸ git rebase HEAD~3
▸ then select to edit a commit - amends previous commit

13. TIME MACHINE!
▸ Go back in history
▸ Change history!
▸ Changing history has challenges
▸ DO NOT change shared history
▸ DO NOT change commits on branches that others have
based their work on
▸ Any of these operations changes the commit and all commits
based on that:
▸ rebase, cherry-pick, squash, amend

14. WORKFLOW
▸ Merge Requests
▸ CI status
▸ Code review
▸ Merge the Request
▸ Close issues via PR
▸ Deploy branches
▸ Specifics vary from project to project

15. GOOD PRACTICES
▸ Each commit should be a logical change entity
▸ Write good commit messages
▸ Imperative mood in the subject line
▸ Fix the flash message on password change
▸ Fixed password change
▸ Details in the message
▸ Use rebase instead of merge on your own PR
▸ Unless no-one else is working on the same branch
▸ Branch names with hiphens

16. REFERENCES
▸ ProGit Book: https://git-scm.com/book/en/v2
▸ Good commit messages: http://chris.beams.io/posts/git-
commit/