1 / 21

Simple Git

Simple Git. Steve Pieper. Topics. Git considerations and Slicer Git as if it were svn Git the way it is meant to be. Why Git?. Slicer "upstream" projects use git: VTK, CMake, Qt, CTK.  (Soon, probably, ITK too)

makani
Télécharger la présentation

Simple Git

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Simple Git Steve Pieper

  2. Topics • Git considerations and Slicer • Git as if it were svn • Git the way it is meant to be

  3. Why Git? • Slicer "upstream" projects use git: • VTK, CMake, Qt, CTK.  (Soon, probably, ITK too) • It is critical to have a common language for describing our development processes • Git is designed to help coordinate large, distributed group projects • e.g. linux kernel (for which it was purpose-built) • Git provides a modern toolset • fast command line utilities • highly interactive graphical tools (gitk, GitX, tortoisegit...) • web viewers • dedicated hosting sites (github, gitorious...)

  4. Git considerations • With more power comes more complexity • terminology is obscure (at first) • Git is evolving • useful new functionality came with 1.7 (4 months ago) • documentation and examples are plentiful, but more is added all the time • There is a 'git way of doing things' • don't venture too far from the beaten path

  5. Slicer and Git • Slicer3.6.X and Slicer4alpha still use svn.slicer.org • Slicer4 will use git • repository not yet set up • will probably use slicer account on github • want to set up the correct workflow from the start • when we migrate, all history will be brought forward • some large binary data will be removed • Repository will be created later this summer • We are still in the learning and planning phase

  6. Using git as if it were svn: checkout svn checkout http://svn.slicer.org/trunk Slicer3 becomes git clone http://github.com/commontk/CTK.git CTK Notes: • svn downloads only one view, while git downloads a copy of the full repository (including all history and branches) • all repository info is at the top level in a .git directory • you can operate on a local repository the way you would with a remote • This is a great equalizer: you can experiment and learn without needing to set up a server

  7. Using git as if it were svn: update svn update becomes git pull --rebase Notes: • in this mode, svn and git operate similarly, merging new code from the repository into your local version (assuming you have made no changes)

  8. Using git as if it were svn: commits svn commit -m "message" file.h becomes git add file.h git commit -m "message" git push Notes: • git add: puts files in a "staging area" • git commit: is purely local • git push: sends the files to the remote server

  9. Using git as if it were svn: further notes Notes: • git status: tells you what you have modified • git commit -a: automatically adds modified files (that it knows about)

  10. Using git as if it were svn: diff svn diff -r HEAD svn update becomes git fetch git diff origin master git rebase Notes: • this lets you "see what's new" before merging it into your current directory tree

  11. Using git as if it were svn: local changes svn update becomes git stashgit pull --rebasegit stash pop Notes: • this lets you save your current edits without committing them to your local repository • you then can bring them back and apply them on top of the latest code from the remote repository

  12. Git as it was meant to be: branches git help --workflows •  This page describes the "recommended workflows" • so these are what the git developers use themselves • these are the best documented • these form the core language for collaboration using git • We should follow them as closely as possible •  Standard Integration Branches • maint tracks the commits that should go into the next "maintenance release", i.e., update of the last released stable version; • master tracks the commits that should go into the next release; • next is intended as a testing branch for topics being tested for stability for master. 

  13. Git as it was meant to be: topic branches •  Brad King's excellent summary (with ascii art) • http://public.kitware.com/Wiki/Git/Workflow/Topic •  Key Concepts: • Amortize the effort of release preparation throughout development • Support granular selection of features for release • Allow immature features to be published without delaying release • Keep unrelated development paths (topics) independent of one another •  Maintain a clean shape of history • Note: cmake uses this "branchy" approach, vtk does not (yet)

  14. Git as it was meant to be: notation Images: Brad King

  15. Git as it was meant to be: new topic Images: Brad King

  16. Git as it was meant to be: implement topic Images: Brad King

  17. Git as it was meant to be: push topic Images: Brad King

  18. Git as it was meant to be: mature topic Images: Brad King

  19. Git as it was meant to be: finish topic Images: Brad King

  20. Git as it was meant to be: history shape Images: Brad King

  21. Git summary • Our goal is to "do it right the first time" • Implement topic branch workflows • Learn best practices from the community • Study workflow conventions used in other projects • Get familiar with the tools before jumping in • Developers should create dummy repositories and branches to see how all the tools behave • Read man pages to become comfortable with the terminology

More Related