The GIT Guide

Presentation I gave in my office regarding to migrating to GIT

Transcript

1. The GIT Guide Learning Git and migrating from subversion
2. VERSION CONTROL SYSTEMS (VCS) - Used to keep history and track of your files. - Your files (Code) are kept in some centralized place(Repo) - Anybody(*) can collaborate on your files. - Can track who did it and when - Better than having 1000s backed-up zips for a 6 month long project *- As long as they are authorized to do so
3. VCS-Terminology - Repository: Directory of your code, which should be controlled by vcs. - Commit: Checkpoint of our code - Head: Latest commit on master branch. - Branch: Different development path of our project, often temporary and not to be merged with main path until finished. - Merging: Joining codes of two different branches. - Tagging: Creating checkpoints of completed development.
4. Centralized VCS - Repository is in a “Centralized” in a server - Developers commit their code in Repo, so others can see it and merge. - Commits contains whole repository, even if developers have changed only 1% of whole repository. - Server communication is required at every step
5. - Repository is distributed to many locations, not a single server is required. - Developers can commit their code locally, others can only see if this code is sent to server. - Faster, because server is only required when needed. - Distributed between people, servers, features. - Commits contains only changed code. Distributed VCS
6. Current Way- Subversion - Centralized VCS - Requires Server - Too difficult to create, update and maintain branches. - Almost non existent code review system - Unauthorized (buggy) code can (and used to) be in main branch and went in live release. - Decreasing use and community support
7. New way - GIT - Does not require a server to commit. - Speedy to commit - Easy to create branch - Easy to review code, before it’s being merged into main branch. - More community support, more help and more tooling support.
8. GIT vs SVN - Changes in concept - Git has two repositories 1. Local 2. Remote - SVN has only one repository and its always remote - SVN’s trunk becomes master branch in GIT - Server Side: GIT’s remote repository is named ORIGIN by default. - SVN can not have more than one remotes for one repository. While git can have many remotes
9. Git vs Svn - How it works Git - Commit and push - Fetch and pull Subversion - Commit - Update
10. GIT - Getting started - Staging: (Mostly) A directory where you have worked and have anything changed without commit - If you have changed a file or added a new file your working copy is in stating mode. - You can not update your code from origin while in Staging. - Commit the code is needed - To know status run `git status` command.
11. GIT-After Staging - Commit the code - A commit will never go to server. - To send it, run git push. - After commit run git status - Ahead: You have advanced code than origin (Can push without problem) - Behind: Origin has advanced code than yours (Must pull before push)
12. Commit Vs Push - A Commit is by default saved locally. - You can have as many commits as you want. - To send commits on server, you have to push the commits. - All unpushed commits goes to server by default. - CurrentBranch’s commit goes to origin/CurrentBranch - SVN’s commit = git’s commit+push
13. Fetch Vs Pull - Used to update code from server - Requires remote repository. Atleast origin defined - Fetch: gets code from server and merge to remote branch’s copy. - e.g. NewFeature’s updates are downloaded to origin/NewFeature - Pull is fetch+merging the code to NewFeature local copy. - SVN’s update = git pull
14. Branches in GIT - Easy to create, easier to checkout. - git checkout (-b) {branchName} - git branch {branchName} - Branch is created on same location, and created within seconds - Merging is simple* - Create and merge as many branches as you want. * As long as there are no conflicts
15. GIT - Merging Branches - Merging from X to Y is copying all commit tree from X to Y - Fast-Forward vs Three Way - Fast-Forward: Work is stopped in Y and all development is done on X before merging. - Three way: Development is being done parallelly in X and Y. - So there will be different commit timelines in X and Y.
16. GIT- Conflicts - Happens only when three way merge is the reality. - Tree Conflicts vs File level Conflicts - Tree Conflicts: Something wrong happened in entire file or directory. - To solve it, determine required strategy of that file (tree)’s status and apply it. - Extension changed, added-deleted-moved in same timeline. - File Level Conflicts: Code changed in same location(s) of file.
17. Preventing & Solving File Level Conflicts - Ignore white space. - Have same code style applied for whole teams. - Pull code from desired branch before push, so there will always be fast forward merge - Merging conflicts: Communicate and apply sense.
18. GIT Workflows - Centralized workflow (Like SVN) - Feature Branch Workflow (A branch for each feature) - GITFLOW workflow (A branch for each version)
19. How do we work here. - Our server is on 240 - Based on GITBILT. - Master branch is read only. - Create tickets to request merge in master. - Tickets will be reviewed and until approved code will not be merged in master. - Update from master or required branch before push.
20. How do we work here-TICKETS - Create tickets to send commits for review. - git push origin HEAD:refs/for/{ticketNumber} - You must have unpushed commits to send to ticket. - DEMO TIME: Create from web vs Create from command line. - Created tickets will always have ticketNumber. - While creating new ticket from command line, you must have exact one unpushed commit. - Can publish multiple commits, multiple times in an open ticket
21. TICKETS- For Reviewers - Team admins: verify that - Your team has a code style and it’s applied in everybody’s IDE. - Code is formatted and rearranged before commit according to that style. - Apart from admins, nobody can merge directly to master, even with tickets. - Review code thoroughly and suggest changes if applies. - Press approve before you merge, applies for your own codes as well.
23. Questions??