Changes between Version 2 and Version 3 of GitWorkflow
- Timestamp:
- 03/22/09 01:15:56 (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GitWorkflow
v2 v3 61 61 Those scenario are the basics - they are written to minimize as much as possible disruption from the common svn workflows. They are not necessarily the best ways to do a specific task under git, but they are the least surprising for someone used to svn. 62 62 63 == Scenario 0: setting up git ==64 65 66 63 == Scenario 1: getting the numpy source code == 67 64 … … 69 66 70 67 {{{ 71 git clone http://git.scipy.org/git/numpy numpy 72 }}} 73 74 Do NOT use checkout - checkout has a different meaning than in svn. Clone is what you want. 75 76 A tarball will also be made available on the scipy website, so that you don't need git at all in this scenario. 68 git clone http://git.scipy.org/git/numpy numpy-git 69 }}} 70 71 Do NOT use checkout - checkout has a different meaning than in svn. Clone is what you want. An up-to-date tarball is also made available for each new commit in the git repo menu in trac (snapshot link). 72 73 After a clone, to get last changes, you need to go into your repository, and then use git pull 74 {{{ 75 cd numpy-git 76 git pull 77 }}} 77 78 78 79 == Scenario 2: prepare a simple patch ala svn, don't bother me with git == … … 87 88 }}} 88 89 89 Maybe: we could have a svn mirror of git ?90 91 90 == Scenario 3: reverting changes == 92 91 … … 133 132 }}} 134 133 135 TODO: handling of remote locations.136 137 134 = A first few git specific workflows = 138 135 … … 141 138 == The branch concept == 142 139 143 Git, like other DVCS, is strongly designed around the notion of branches. Instead of everyone committing directly to the trunk, most development happen in branches, which are then merged into the trunk. What's the point, you may ask ?140 Git, like other DVCS, is strongly designed around the notion of branches. Instead of everyone committing directly to the trunk, most development happens in branches, which are then merged into the mainline. What's the point, you may ask ? 144 141 145 142 * commit is fast: it is instantaneous. … … 155 152 }}} 156 153 157 You are not really adding the file foo.c to the repository, but you add its content to the git repository. 154 You are not really adding the file foo.c to the repository, but you add its content to the git repository. By default, and without the '-a' option, a commit will NOT include content which has not been added with git add - the '-a' option is equivalent to do an add on every changed file, and then commit. The index is thus a staging area between your working tree (the files as they are on your filesystem) and the repository (the set of commits). 158 155 159 156 == Scenario 1: creating a new branch == … … 205 202 }}} 206 203 207 Note the difference between '..' and '...'. '..' (2 dots) is the same as a space. 204 Note the difference between '..' and '...'. '..' (2 dots) between the two branches to compare is the same as a space: 205 206 {{{ 207 git diff oldbranch newbranch 208 git diff oldbranch..newbranch 209 }}} 210 211 Are exactly the same. 208 212 209 213 == Scenario 3: Merging branches == … … 215 219 git merge branch1 216 220 }}} 221 222 In case of conflicts, you solve the conflicts as in svn, and then use add to mark the content as resolved. 223 224 {{{ 225 # Edit the file foo.c which has a conflict 226 # Mark the conflict as resolved 227 git add foo.c 228 git ci -m "Merge branch to make foo from bar." 229 }}}
