Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Git usage (Basics and workflow)

Nächste SlideShare
Wird geladen in …3

Hier ansehen

1 von 35 Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie Git usage (Basics and workflow) (20)


Aktuellste (20)

Git usage (Basics and workflow)

  2. 2. What is Git?  Version Controlling System  Distributed Mechanism  Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it
  3. 3. Centralized vs Decentralized VCS  Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.  “Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.  Example CVS, Subversion (or SVN) and Perforce
  4. 4. Centralized vs Decentralized…
  5. 5. Git tools  Install Git  Install Git Client (TortoiseGit, SourceTree, Git for VisualStudio)  Some client includes git as well (example Github Desktop, SourceTree)
  6. 6. Working with Git  To start working with Git, you just need to run the "git init" command. It turns the current directory into the Git working directory and creates the repository in the .git (hidden) directory it creates there.  The “git add” command adds untracked file in the staging area.  The “git commit” command commits the changes in the file.  The “git checkout” checks out a branch from repository into the working directory
  7. 7. Git Workflow
  8. 8. File tracking Git sees every file in your working copy as one of three things:  tracked - a file which has been previously staged or committed;  untracked - a file which has not been staged or committed; or  ignored - a file which Git has been explicitly told to ignore.
  9. 9. .gitignore file  Dependency caches, such as the contents of /node_modules or /packages  Compiled code, such as .o, .pyc, and .class files  Build output directories, such as /bin, /out, or /target  Files generated at runtime, such as .log, .lock, or .tmp  personal IDE configuration files, such as .idea/workspace.xml  Existing ignore patterns : https://github.com/github/gitignore
  10. 10. Git Ignore Patterns
  11. 11. Git vs SVN  Git is distributed system whereas SVN is centralized.  Git is faster than SVN.  Git repositories are much smaller than SVN.  Git are simpler and lees resource heavy than SVN’s.  Git tracks content unlike SVN’s file tracking  Merging is simpler in Git; because you don’t need to remember the last revision you merged from which is required in SVN.  Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes.
  12. 12. Git vs Mercurial  Mercurial is much simpler than Git.  Git has better history control than Mercurial.  Branching is more powerful in Git.  Git has staging area, mercurial doesn’t have  Mercurial has better GUI support
  13. 13. GitFlow
  14. 14. What is GitFlow?  GitFlow is a branching model for Git.  Created by Vincent Driessen.  Well suited to collaboration and scaling the development team.
  15. 15. Motivations  Parallel Development  Collaboration  Release staging area  Support for emergency fixes
  16. 16. Branches  Feature branch  Develop branch  Release branch  Hotfix branch  Master branch
  17. 17. Feature Branch  Feature branches are started off of the develop branch.  Finished features and fixes are merged back into the develop branch when they’re ready for release
  18. 18. Feature Branch
  19. 19. Release  When it is time to make a release, a release branch is created off of develop branch  The code in the release branch is deployed onto a suitable test environment, tested, and any problems are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until you’re happy that the release is good enough to release to customers.  When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in the release branch aren’t accidentally lost by new development.
  20. 20. Release
  21. 21. Master Branch  The master branch tracks released code only.  The only commits to master are merges from release branches and hotfix branches.
  22. 22. Hotfix Branch Hotfix branches are used to create emergency fixes.
  23. 23. Hotfix Branch
  24. 24. Git Usage Scenario
  25. 25. Git Stash  We have changes which are temporary  But, we don’t want to commit this  Neither, we want to loose it  Stash saves state of current working changes  But Git does not track them for commit  We can compare working copy with stash  Stash can be merged to master
  26. 26. Git Rebase
  27. 27. Git Rebase…
  28. 28. Git Rebase…
  29. 29. Git Rebase…
  30. 30. Git Rebase…
  31. 31. Git Rebase…
  32. 32. Use case : Remove faulty push  Some faulty commits has been pushed to remote  We want to revert back  How can we do this?
  33. 33. Solution  Reset master to a commit which is Stable (Hard Reset - local)  Now, you are in master and do a FORCE PUSH.  git push -f origin master:master # force push
  34. 34. Cherry Pick  You're working in a feature branch  Isn't quite ready for a full merge.  But you do have a few commits in there that you want to push to master  We can do this by Cherry Pick  Allow us to merge specific number of commits
  35. 35. Refrences  https://git-scm.com/book/en/v2/Getting-Started-Git-Basics  https://www.ibm.com/developerworks/library/d-learn-workings- git/index.html  https://www.atlassian.com/git/tutorials/gitignore  https://www.atlassian.com/git/tutorials/gitignore#git-ignore-patterns  https://datasift.github.io/gitflow/IntroducingGitFlow.html  http://nvie.com/posts/a-successful-git-branching-model/