- Git stores snapshots of files and file trees in commits rather than tracking differences between file versions. This allows it to be very efficient and perform well on large projects. - Git is highly local - all operations can be performed offline and it stores its data locally rather than relying on remote servers like many other version control systems. - Git has strong integrity checks built-in to ensure data integrity and detect unintended changes to files.

2. Getting Some Git
VSC Basics, Hacks and Best Practices

3. Snapshots, Not Differences
● Other systems store the difference made to the file in
a commit
@Pro Git

4. Snapshots, Not Differences
● Git stores a snapshot of the file in the commit
● If the file wasn’t changed, it’s pointed to the latest
version
● Introduced many change to how Git performs
@Pro Git

5. Integrity, Locality
● Git has integrity
⚪ Every file is check-summed
⚪ Checksum is used as a reference
⚪ Whenever something changes, Git knows about it
⚪ Files are stored in DB by checksum not names
● Everything is local
⚪ Local resources are only needed for Git to operate
⚪ Other VCS’s depend on servers heavily
◾ SVN commits online, for instace
⚪ You can work offline. You only need servers to sync up

6. Git Sections - Three sections
@Pro Git

7. Git Transitions - Move files
@Pro Git

8. Git Transitions - Add files
● When the file is first created, it’s untracked
$ git add file # file is now staged
● A tracked file, that has been modified, is in the
working directory
$ git add tracked_file # tracked_file is now staged
● Commit the staged files
$ git commit -m ‘Here goes your message’
● Commit all working directory
$ git commit -am ‘msg’ # Untracked files are not affected

9. Git Transitions - Undo
● Unstage a staged file back to the working directory or
being untracked
$ git reset HEAD file
● Discard changes in a working-directory file
$ git checkout -- file

10. Git Transitions - Deletion
● Delete a file
$ rm file # Deletion of file is not staged
$ git rm file # Deletion is now staged.
● Or, stage the deletion directly
$ git rm file
● You can do that
$ rm file
$ git commit -a # Deletion is committed

11. .gitignore
● Git uses this to ignore files from tracking
● Should be the first step after creating a new repo
● Actually there’s a repo for .gitignore’s
- github.com/github/gitignore/
● Two master rules of thumb
- Ignore anything that can be generated (data files, compiled
files, log files … )
- Libraries generated by dependency managers
- Ignore any user-specific data (preferences, IDE UI data … )
- Party trick: use example patterns.

12. .gitignore - How
● Create a .gitignore file in your repo’s root folder
● Add names or patterns
#Dont’ mind me. I’m a comment
*.class
WhyIsThisFileHere.txt
bin/
● Add .gitignore to Git
● You can create another .gitignore in a subfolder
⚪ Will only be applied for that folder

13. .gitignore - Be aware
● Be Aware: .gitignore is only applied on untracked files
● If you need to ignore a tracked file, remove it first
$ git rm --cached <file> #Removes the file from Git, but keeps it
● Adding an ignored file to Git is not allowed
⚪ However, adding -f overrides that. Be a good fellow and don’t
use it

14. Remotes
● Clone a repo from a remote
$ git clone git@github.com:rails/rails.git Rails # Will be cloned in Rails/
● You can add more remotes
$ git add backup git@github.com:rails/rails.git
● List them
$ git remote -v
origin git@github.com:SeelozInc/dashboard-ios.git (fetch)
origin git@github.com:SeelozInc/dashboard-ios.git (push)
old-remote ssh://git@gitlab.badrit.com/mohannad.hassan/seeloz-dashboard.git (fetch)
old-remote ssh://git@gitlab.badrit.com/mohannad.hassan/seeloz-dashboard.git (push)
● Remove
$ git remote rm other_rigin
● Edit
$ git remote rename origin fathy_remote
$ git remote set-url origin git@github.com:rails/rails.git

15. Remotes - Listen to them
● Fetch data from a remote
⚪ Branches are fetched into remote/branch (origin/master)
⚪ Merge it yourself
$ git fetch origin # If you don’t type a remote name, it’s origin by default
● Or pull to merge changes automatically
$ git pull origin
$ git pull origin master # Just for a branch
● Fetch from all at once
$ git update

16. Remotes - Talk to them
● Push your commits up
$ git push origin master
● Push and track
$ git push -u origin new_feature_branch # Will be merged when you pull
● Push all
$ git push origin # Push all tracking branches
$ git push # No remote → origin is the default

17. Remotes - Show
$ git remote show origin
* remote origin
URL: https://github.com/my-org/complex-project
Fetch URL: https://github.com/my-org/complex-project
Push URL: https://github.com/my-org/complex-project
HEAD branch: master
Remote branches:
master tracked
dev-branch tracked
issue-43 new (next fetch will store in remotes/origin)
refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove)
Local branches configured for 'git pull':
dev-branch merges with remote dev-branch
master merges with remote master
Local refs configured for 'git push':
dev-branch pushes to dev-branch (up to date)
markdown-strip pushes to markdown-strip (up to date)
master pushes to master (up to date)--

18. Alias
● Shortcuts!
● Define them
$ git config --global alias.st status #”git st” instead of “git status”
● You can add more (args, files … )
$ git config --global alias.unstage “reset HEAD” # git unstage file.c
● Open other applications
$ git config --global alias.visual "!gitk"

19. Alias
● Add to ~/.gitconfig directly
[alias]
co = checkout
st = status
● Have aliases with arguments
logc = "!f() {
git log $1 -$2;
}; f"
$ git logc other_branch 5

20. git log
● Shows commits history starting from HEAD
● Start from a branch or a tag
$ git log my_branch
$ git log v3.2.2
● Start from a commit
$ git log ab199cf0
● Add “diff” of last two commits
$ git log -p -2
● Put on some makeup
$ git log --pretty=oneline
ca82a6dff817ec66f44342007202690a93763949 changed the version number
085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test

21. git log - more
● Make your own format
$ git log --pretty=format:"%h - %an, %ar : %s"
ca82a6d - Scott Chacon, 6 years ago : changed the version number
● There are other pretty params and format options
- Check them. [#10 in references]
● Filter
$ git log -4 #Last 4 commits
$ git log --since 1/1/2015 #Commits after that date. You can als use “after”
$ git log --committer john.smith@badrit.com
$ git log --grep controller

22. git log - Files
● Show the history of a file
$ git log --pretty=oneline
970d421295efbc6371b5a09384142504232ac73b Renamed c.c to d.d
465b3274ec1f4dbb3179bd3486180f5fb4a9ec76 Deleted b.b
d0f6f31b0569d96af93d031200e97dd545c9bec2 Edited a.a
81bfbdd2f6c8d31c2c242f5d524f9b293e2efc6e c.c
d5d21265591815dce7f320fbb70c52dd99edaadc b.b
ff55c20108cddad6da7e3e611a0dfe62cf1fced9 a.a
$ git log --pretty=oneline a.a
d0f6f31b0569d96af93d031200e97dd545c9bec2 Edited a.a
ff55c20108cddad6da7e3e611a0dfe62cf1fced9 a.a

23. git log - Deleted and Moved Files
● Works for deleted files
$ git log --follow --pretty=oneline -- b.b
465b3274ec1f4dbb3179bd3486180f5fb4a9ec76 Deleted b.b
d5d21265591815dce7f320fbb70c52dd99edaadc b.b
ff55c20108cddad6da7e3e611a0dfe62cf1fced9 a.a #First commit
$ git log --follow --pretty=oneline -- d.d
970d421295efbc6371b5a09384142504232ac73b Renamed c.c to d.d
81bfbdd2f6c8d31c2c242f5d524f9b293e2efc6e c.c
ff55c20108cddad6da7e3e611a0dfe62cf1fced9 a.a #First commit
$ git log --follow --pretty=oneline -- c.c
970d421295efbc6371b5a09384142504232ac73b Renamed c.c to d.d
81bfbdd2f6c8d31c2c242f5d524f9b293e2efc6e c.c
ff55c20108cddad6da7e3e611a0dfe62cf1fced9 a.a

24. git log --graph
● You can show it as a graph
$ git log --graph
● Forget about the last point. Log it in a gitk-ish way
⚪ Command is tall.
⚪ Get it from http://stackoverflow.com/a/9074343/959221.

25. git log --graph
@StackOverFlow

26. Tag
● Mark important steps and milestones in the
development
● Lightweight tag: Commit’s checksum stored in a file
$ git tag v1.4
$ git tag v1.3 4d3f911 # Tag a certain commit
● List
$ git tag
$ git tag -l “v1.8*” # Filter to tags that has “v1.8”
● Annotated; Add a message
$ git tag v9.8 -m ‘Random tag’

27. Diff
● Default: Diff between working directory and staging
$ git diff
● Diff between working directory and a commit
$ git diff <commit>
● Diff between staging and last commit
$ git diff --cached# Staging and last commit
$ git diff --cached commit # Staging and given commit
● Diff between two commits
$ git diff HEAD^^ HEAD # start_commit end_commit
# “HEAD^^” = “Head~2”

28. ● Diff one file
$ git diff start_commit end_commit -- file
$ git diff we45hsf -- file # Working directory and given commit
$ git diff file # Working directory and HEAD
● Diff across branches
$ git diff master..branch
● Diff tools
$ git difftool # Launches a tool to view changes
● Candidates: meld, vimdiff, diffmerge … References #12
and #14 for more
⚪ You may need to install the chosen package
$ git config --global diff.tool meld
$ git config --global merge.tool meld #
Diff - More

29. Diff - meld

30. A Commit Anatomy
● A commit contains:
⚪ A pointer to the files snapshot
⚪ Author’s name and email
⚪ The message
⚪ A pointer to its parent(s)
● Commit’s parents:
⚪ Zero parents; if it’s the initial commit
⚪ Multiple parents; if it is a merge commit
⚪ One; otherwise

31. Branches
● A branch is just a pointer to a commit
● Master branch is also not different
⚪ git init creates it by default
● Whenever you commit, the branch pointer moves along
with the new commit
● HEAD is a special pointer. It points to the branch that
you currently on

32. Branches - Anatomy
@Pro Git

33. Branches - Anatomy
@Pro Git
After one
commit

34. Branches - Detached HEAD
● Checkout a single commit
⚪ You can even create a branch from there
$ git checkout ab199cf0
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout. If you
want to create a new branch to retain commits you create, you may do so (now
or later) by using -b with the checkout command again.

35. Branches - Low Cost
● A branch is a single pointer; 40-characters file
● Creating branches and playing with them is not costly
● Sharp contrast with other VCS’s
⚪ Depending on the size of the project, creating a new branch
may take minutes to copy the contents to another directory.
● Since it’s just a pointer, finding the recent common
parent is easy, which makes merging easy.
⚪ You had to find that parent yourself in other systems

36. ● Create a branch and move to it
$ git checkout -b new_branch
● Just create it
$ git branch new_branch
● Push it. Don’t forget to track it
$ git push -u origin new_branch
● Move around
$ git checkout new_branch # HEAD is not at new_branch
$ git checkout master # HEAD is not at master
● Delete it locally
$ git branch -d new_branch
● Delete it on the server
$ git push origin --delete <branchName>
Branches - How

37. Branches - Merging
● Adds one branch’s commits to the other
$ git checkout master
$ git merge new_branch
● Fast-forward
⚪ Just move the pointer up ahead
@Pro Git

38. Branches - Merging
● Git determines the best common ancestor
● Creates a new snapshot by heads of each branch, and
the BCS
@Pro Git

39. Branches - Merge Conflicts
● Conflicts happen when some part is edited in both branches
● The merge commit is paused until these conflicts are solved
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified:
index.html
● Done editing? Add the file
$ git add index.html
● If you don’t have any other conflicts, commit.

40. Branches - Work Flow and Models
● How you organize stories affects how you see your Git
repo
● Famous models exist
● Develop your own to suit your needs

41. ● Famous levels
⚪ master: stable branch. Has been or will be released
⚪ next or staging: Code that’s ready to be tested. Not always
stable, but when it is stable, will be merged to master
⚪ develop: finish topic-branches and merge them here
⚪ Add or remove, as it suits your model
● Think of it as work silo
⚪ Work on some code
⚪ When reaches some point, move it
● Why
⚪ Agile
Branches - Long-Running Branches

42. Branches - Long-Running Branches
@Pro Git

43. Branches - Topic Branches
● Can be used by any work model, any project of any
size
● Steps:
⚪ Branch out from development for feature
⚪ Work on feature
⚪ Merge back into development when done
● Don’t branch out from a topic branch! Or do. There’s
a debate
● Rule of thumb: If you branch B out from A, merge B
back into A

44. Branches - Topic Branches
● Why
⚪ Agile
⚪ No half-done code in long-running branches
⚪ Work in parallel. But you have to divide work right.

45. Pull Requests
● Can be used with two models:
⚪ Fork and pull
⚪ Shared repo
● Go to the topic branch and choose “Compare &
review”
● Choose target repo / target branch
● Can be reviewed before merging
● Why?
⚪ Allow for contributions while maintaining conventions
⚪ Review stories before they’re finalised.

46. The Art of Committing - Messages
● Expressive and understandable. Yet don’t make a speech
● Don’t commit with -m; It’s very limited
● Format it:
⚪ First line is brief
⚪ Add a link to ticket.
⚪ Check #3 in references
● Answer questions: What was done? Why? What side effects?
● Should be integral to code review
⚪ Know what this commit is about, from the message

47. The Art of Committing - Small Early Commits
● Don’t include some 10 or 20 hours of work in one
commit
● Modularity
⚪ It’s required everywhere!
● Reviewable
● Traceable
● Uncommitted code won’t “crumble” on you
● Would introduce too many unneeded commits in the
history?
⚪ You can edit commits later -- A little advanced

48. Amend
● Edit the last commit
$ git commit --amend
● Will open the editor to edit the message
● You can even add or remove files that you forgot to
add
$ git add Index.html
$ git commit --amend # Changes in Index.html is now included in last commit
● Don’t edit public history
⚪ Have a look before you push
⚪ If it’s pushed, don’t edit it
● There are other ways to edit non-HEAD commits

49. Auto-Completion
● Download the script ([11] in References)
● Add it to home directory
● Include the following in .bashrc file
source ~/git-completion.bash
● Press on a tab to enjoy
● For Windows: Auto completion is auto-configured with
mysysGit

50. References
1. Pro Git
2. man git
3. https://sethrobertson.github.io/GitBestPractices
4. http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
5. http://sethrobertson.github.io/GitPostProduction/gpp.html#pre-post-production
6. http://programmers.stackexchange.com/questions/10793/when-is-a-version-control-c
ommit-too-large
7. http://wildlyinaccurate.com/a-hackers-guide-to-git/
8. http://nvie.com/posts/a-successful-git-branching-model/
9. http://blogs.atlassian.com/2014/10/advanced-git-aliases/
10. http://opensource.apple.com/source/Git/Git-19/src/git-htmldocs/pretty-formats.txt?
txt
11. https://github.com/git/git/blob/master/contrib/completion/git-completion.bash
12. http://www.gitguys.com/topics/git-diff/
13. http://stackoverflow.com/a/9834872
14. http://stackoverflow.com/questions/137102/whats-the-best-visual-merge-tool-for-git