Working with GIT
Download as PPTX, PDF1 like1,334 views
Managing Files with GIT is a document about using the version control system Git. It discusses how Git helps keep track of file changes, allows easy sharing of work, and provides tools to manage diverging code streams through features like branching and merging. The key aspects of using Git covered are initializing repositories, adding and committing files, branching, merging, resolving conflicts, and best practices for collaborative work.
Ad
More Related Content
What's hot (20)
Similar to Working with GIT (20)
Ad
More from Akshay Mathur (16)
Ad
Recently uploaded (20)
Working with 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
- 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
- 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
- 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
- 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
- 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
- 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