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

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.