Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The GIT Guide

The GIT Guide

Presentation I gave in my office regarding to migrating to GIT

Avatar for Prasham Trivedi

Prasham Trivedi

February 21, 2016
Tweet

More Decks by Prasham Trivedi

Other Decks in Programming

Transcript

  1. 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
  2. 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.
  3. 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
  4. - 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
  5. 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
  6. 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.
  7. 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
  8. Git vs Svn - How it works Git - Commit

    and push - Fetch and pull Subversion - Commit - Update
  9. 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.
  10. 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)
  11. 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
  12. 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
  13. 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
  14. 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.
  15. 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.
  16. 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.
  17. GIT Workflows - Centralized workflow (Like SVN) - Feature Branch

    Workflow (A branch for each feature) - GITFLOW workflow (A branch for each version)
  18. 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.
  19. 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
  20. 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.