Presentation is loading. Please wait.

Presentation is loading. Please wait.

Simple Git Steve Pieper. Topics Git considerations and Slicer Git as if it were svn Git the way it is meant to be.

Similar presentations


Presentation on theme: "Simple Git Steve Pieper. Topics Git considerations and Slicer Git as if it were svn Git the way it is meant to be."— 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: o VTK, CMake, Qt, CTK. (Soon, probably, ITK too) o It is critical to have a common language for describing our development processes Git is designed to help coordinate large, distributed group projects o e.g. linux kernel (for which it was purpose-built) Git provides a modern toolset o fast command line utilities o highly interactive graphical tools (gitk, GitX, tortoisegit...) o web viewers o dedicated hosting sites (github, gitorious...)

4 Git considerations With more power comes more complexity o terminology is obscure (at first) Git is evolving o useful new functionality came with 1.7 (4 months ago) o documentation and examples are plentiful, but more is added all the time There is a 'git way of doing things' o 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 o repository not yet set up o will probably use slicer account on github o want to set up the correct workflow from the start o when we migrate, all history will be brought forward o some large binary data will be removed Repository will be created later this summer o We are still in the learning and planning phase

6 Using git as if it were svn: checkout svn checkout Slicer3 becomes git clone 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 o 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 stash git pull --rebase git 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" o so these are what the git developers use themselves o these are the best documented o these form the core language for collaboration using git o We should follow them as closely as possible Standard Integration Branches o maint tracks the commits that should go into the next "maintenance release", i.e., update of the last released stable version; o master tracks the commits that should go into the next release; o 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) o Key Concepts: o Amortize the effort of release preparation throughout development o Support granular selection of features for release o Allow immature features to be published without delaying release o Keep unrelated development paths (topics) independent of one another o Maintain a clean shape of historyshape 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" o Implement topic branch workflows Learn best practices from the community o Study workflow conventions used in other projects Get familiar with the tools before jumping in o Developers should create dummy repositories and branches to see how all the tools behave o Read man pages to become comfortable with the terminology


Download ppt "Simple Git Steve Pieper. Topics Git considerations and Slicer Git as if it were svn Git the way it is meant to be."

Similar presentations


Ads by Google