Content prepared for Hands-on workshop on GIT

1. Managing Files with GIT
Akshay Mathur

2. Ground Rules
• Post on FB and Twitter now
• Disturb Everyone during the
session
– Not by phone rings
– Not by local talks
– By more information and
questions
2@akshaymathu

3. Let’s Know Each Other
• Who does not code?
• How do you store files?
• Have you used VCS?
– Which one?
– What do you store?
– Repository size?
– What happens when you are not on network?
• Why are you attending?
@akshaymathu 3

4. Akshay Mathur
• Founding Team Member of
– ShopSocially (Enabling “social” for retailers)
– AirTight Neworks (Global leader of WIPS)
• 15+ years in IT industry
– Currently Principal Architect at ShopSocially
– Mostly worked with Startups
• From Conceptualization to Stabilization
• At different functions i.e. development, testing, release
• With multiple technologies
@akshaymathu 4

5. What is the issue
What if I don’t care?

6. Keeping Track of Changes
• Hope you get it right first time
• Hope you can remember the changes
• You will actually end up rewriting 
@akshaymathu 6

7. Organizing Backups
• Save the files/directories appending some
context (usually dates)
– Totally ad-hoc
– Only the owner knows where is what
– Hard to pick a version to go back to
– Prone to error
– No tools to help
@akshaymathu 7

8. Sharing Work
• When many people need to work on same file
– Work sequentially
– Overwrite other’s changes
– Keep track via emails
@akshaymathu 8

9. The Solution
Version Control System (VCS)

10. How VCS Help?
• Keeps track of changes
– Tells who change what and when
• Merges changes done by different people
– Detects and alerts if same thing is changed by
different people
• Allows comparing two versions
– Shows how information has grown
• Allows going back to previous version
@akshaymathu 10

11. VCS Terminology
• Repository
– Place where VCS stores files and its metadata
• Sandbox
– Place where files are available for editing
• Checkout
– Process of getting files from repository to sandbox
• Commit
– Process of putting files from sandbox to repository
@akshaymathu 11

12. Storage System
• Non-intrusive
– Everything is stored in
different folders/files
• Compact
– Incremental changes are
stored
– Different storage techniques
• RCS, BerkleyDB etc.
@akshaymathu 12

13. Versioning Scheme
• File Versioning
– Version number of only changed file is changed
• Repository Versioning
– Version number of entire repository changes
every time
• Version numbers can be
– A serial number
– Hash of the content
1.1 1.2 1.3 1.4 1.5
@akshaymathu 13

14. @akshaymathu 14

15. How VCS work
Managing Concurrency Optimistically

16. @akshaymathu 16

17. @akshaymathu 17

18. @akshaymathu 18

19. @akshaymathu 19

20. @akshaymathu 20

21. @akshaymathu 21

22. Types of VCS
Where is the repository?

23. Centralized
• CVS, SVN etc.
• Repository at only one central location
– Sandbox on every working machine
• Network is needed for every operation
– Can not work offline
• The repository has to be protected and backed
up
– Work stops if repository goes down
@akshaymathu 23

24. Centralized VCS
    
@akshaymathu 24

25. Centralized VCS Operations
@akshaymathu 25
Repository
Server Client
Sandbox
Checkout
Commit

26. Distributed
• Mercurial, Bitkeeper etc
• Repository on every machine
– Sandbox and repository are always together
• Network is needed only for repository sync
– Can work offline
• Backups are trivial
• Election of central repository by convention
@akshaymathu 26

27. Distributed VCS
@akshaymathu 27





28. Distributed VCS Operations
@akshaymathu 28
Repository
Remote Local
Sandbox
Pull
Push
Sandbox
Repository
Commit Checkout

29. @akshaymathu 29

30. Working with GIT

31. GIT
• Free
• Open Source
• Created by Linus Torvalds (Mr. Linux)
• First used for Linux Kernel
@akshaymathu 31

32. General Info
• Distributed
– All repositories hold same data/info
• Compact
– Low footprint
– Compact Repository
• Fast
– Quick operations
– Low Data Transfer
• Feature rich yet simple
• Intelligent
@akshaymathu 32

33. Hands on Practice
@akshaymathu 33

34. Creating Repository
• Init
– Initialize a new repository on local machine
• Creates a .git directory with subdirectories for
objects, refs/heads, refs/tags, and template files
• An initial HEAD file that references the HEAD of the
master branch is also created
git init <repository_name>
@akshaymathu 34

35. Adding New File
• Add
– Adds a new file into the list of tracked files
– A list of files (or wildcard) is accepted
– Commit is not automatic
git add <file_1> <file_2>
git add <file_*>
@akshaymathu 35

36. Editing the File
• No restriction from GIT
• Use your favorite editor
– Text files
• Vim, Notepad, Textpad, Eclipse, Visual
Studio, Dreamviewer etc.
– Binary Files
• Word, Excel, Powerpoint, Photoshop etc.
@akshaymathu 36

37. Removing Files
• Rm
– Removes file from the sandbox
– Remember to commit the change
git rm <file_name>
@akshaymathu 37

38. From Repository to Sandbox
• Checkout
– Gets file(s) from repository to sandbox
– Local changes of the files go away
git checkout <file_name>
@akshaymathu 38

39. Switching to Old Version
• Checkout
– Gets file(s) from repository to sandbox
• Commit ID of old version needs to be provided
– Sandbox gets detached and does not allow
commits
– Command fails if local changes are there in the file
git checkout <commitID>
@akshaymathu 39

40. Checking Current State
• Status
– Displays information about current state of
sandbox
• Branch name
• List of added, removed, modified and conflicted tracked
files
• List of untracked files
• Ignores files listed in .gitignore
git status
@akshaymathu 40

41. .gitignore
• A gitignore file specifies intentionally
untracked files that git should ignore
– Files already tracked by git are not affected
• Each line in a gitignore file specifies a pattern
• Wildcard can be used
@akshaymathu 41

42. Reviewing Changes
• Diff
– Shows difference between working copy of a file and
the copy in the repository
git diff
• Difftool
– Allows to use an external tool for viewing diff
git difftool –y –t xxdiff
• Log
– Lists all commit logs
git log
@akshaymathu 42

43. Saving into Repository
• Commit
– Stores current content of tracked files from
sandbox into repository
• A log message is required
• All files can be committed with –a option
• Selected files can be committed by providing list of files
git commit –am “<commit message>”
git commit –m “<commit message>” <file1>
<file2>
@akshaymathu 43

44. Commit Object
• Commit creates a commit object with the
current state of repository
– Author info and timestamp is recorded
– A new checkpoint is created
– New version number (commit ID) is assigned to
the checkpoint
• Commit ID is hash of the content in the commit
@akshaymathu 44

45. Marking a State of Repository
• Happens automatically with every commit
• Name of the state, the commit ID, is tough to
remember
– A simple name can be assigned
git tag <tag_name>
git tag <tag_name> <commitID>
@akshaymathu 45

46. @akshaymathu 46

47. Handling Emergencies
@akshaymathu 47

48. Saving Local Changes
• Stash
– Saves all local changes of sandbox
– Sandbox goes clean for coding and pushing a
hotfix
– Multiple stash can be created
git stash
@akshaymathu 48

49. Applying Saved Changes
• Stash apply
– Applies stashed changes back to the sandbox
– You can choose from multiple stashes
git stash apply
@akshaymathu 49

50. Sharing the Work

51. Distributed VCS Operations
@akshaymathu 51
Repository
Remote Local
Sandbox
Pull
Push
Sandbox
Repository
Commit Checkout
Clone

52. Getting Repository
• Clone
– Clones an existing remote repository, on local
machine, into a newly created directory
• Creates remote-tracking branches for each branch in
the cloned repository
• Checks out an initial branch into sandbox
• Default name of remote repository is ‘origin’
git clone <path_to_repository>
@akshaymathu 52

53. Getting Changes
• Pull
– Downloads objects and refs from remote
repository
– Merges with local repository
– Commits automatically
git pull
git pull origin master
@akshaymathu 53

54. Sending Changes
• Push
– Update remote repository with changes in local
repository
• Use --tags option for pushing tags
• Use –u option to push a new branch
– Uncommitted changes are not updated
git push origin master
@akshaymathu 54

55. 55@akshaymathu

56. Diverging Streams

57. Why Diverging
• For parallel development
– A feature requiring long development time
• For experimenting new stuff
– Something we are not sure of
• Custom development
– For multiple clients from same codebase
@akshaymathu 57

58. Creating a Branch
• Branch
– Creates a new code stream reference in local
repository from specified point
• Checkout
– Checkout with –b option also creates a new
branch
• Latest checkpoint is used for branching by
default
• Any older commit ID can be specified
@akshaymathu 58

59. Branching
@akshaymathu 59
git branch <branch-name>
git checkout –b <branch_name>
git branch <branch-name> <start_point>

60. Branch Facts
• A branch named ‘master’ is always present in
the repository
• Name of a branch refers to a moving
checkpoint that is the latest commit on the
branch
– Branch name can be used in place of commit ID in
any command
@akshaymathu 60

61. Switching Branches
• Checkout
– Gets file(s) from repository to sandbox
• Branch name needs to be provided
– Command fails if local changes are there in the file
that are going to be overwritten
• Otherwise changed files remain there as is in sandbox
git checkout <branch_name>
@akshaymathu 61

62. Folding Back
• Merge
– Merges a branch into current branch
– Automatically commits, if no conflict
– Runs in local repository
• Requires push to update changes to remote
git merge <other_branch_name>
@akshaymathu 62

63. Merging
git merge <other_branch_name>
@akshaymathu 63

64. Conflicts
• If, at two places, changes are made in same
portion of a file
– GIT is not able to understand what to keep
– Puts both changes in the file
• Boundaries are marked in the file
• File is marked as conflicted
– Authors need to collaborate and fix
• Remember to commit after done
@akshaymathu 64

65. Moving Branch Point
• Rebase
– Forward-port local commits to the updated
upstream head
• All local commits in the current branch are saved to a
temporary area
• The current branch is reset to upstream
• The saved commits are then re-applied to the current
branch, one by one, in order
• Rebase stops in the middle in case of conflicts
• Rebase can be continued after resolving conflicts
@akshaymathu 65

66. Rebase
@akshaymathu 66
git rebase
<upstream_branch_name>

67. @akshaymathu 67

68. Best Practices
• Communicate with peers
• Write good commit log
• Never directly modify files repository directory
• Never share files using external means e.g.
email, ftp, ssh etc.
– Get the difference as needed
• Do not commit generated files
@akshaymathu 68

69. Branching Best Practices
• Merge a branch only into its upstream
• Keep ‘master’ untouched for hot fixes
• Have a branch (say ‘develop’) for out of
‘master’ for system and regression testing
• Create feature branches out of ‘develop’
@akshaymathu 69

70. Working with GUI
• Gui
– Launches a Graphical User Interface (GUI) for GIT
– Common operations can be performed
@akshaymathu 70

71. Thanks
@akshaymathu 71