Changes between Version 8 and Version 9 of GitWorkflow
- Timestamp:
- 03/24/09 06:37:53 (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GitWorkflow
v8 v9 65 65 == Scenario 1: getting the numpy source code == 66 66 67 Getting the sources from the NumPy repository, just to look at the sources, or to build from last version instead of released:67 ''Getting the sources from the NumPy repository, just to look at the sources, or to build from last version instead of released'': 68 68 69 69 {{{ … … 71 71 }}} 72 72 73 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). 73 Do NOT use checkout - checkout has a different meaning than in svn. Clone is what you want. 74 75 '''Alternative''': An up-to-date tarball is also made available for every revision in the git repo menu in trac (snapshot link), so that you can get last numpy without installing git at all. 74 76 75 77 After a clone, to get last changes, you need to go into your repository, and then use git pull … … 81 83 == Scenario 2: prepare a simple patch ala svn, don't bother me with git == 82 84 83 I have found a bug, and I want to submit a patch. I want to do it like in svn, I don't care about git:85 '''I have found a bug, and I want to submit a patch. I want to do it like in svn, I don't care about git''': 84 86 85 87 {{{ … … 87 89 git status 88 90 # This will put the changes into a patch 89 git diff 91 git diff HEAD 90 92 }}} 91 93 92 94 == Scenario 3: reverting changes == 93 95 94 I have made some changes, but I am confused, I just want to restart from last revision and throw everything away. 96 '''I have made some changes, but I am confused, I just want to restart from last revision and throw everything away.''' 95 97 96 98 There are several solutions - do NOT use revert, git revert is totally different from svn revert. The safe and easy one: … … 100 102 }}} 101 103 102 This will put your changes aside (in a 'stash'), and your working tree will be exactly as if you checked out from the last revision of your repository. It is safe because your changes are not lost - you can reapply them:103 104 {{{ 105 git stash apply104 This will put your changes aside (in a 'stash'), and your working tree will be exactly as if you checked out from the last revision of your repository. This has the same semantics as svn revert (except it is more powerful as you can stack stash). It is safe because your changes are not lost - you can reapply them: 105 106 {{{ 107 git stash pop 106 108 }}} 107 109 … … 112 114 }}} 113 115 114 This will have the same semantics as svn revert.115 116 Q: I thought that git reset was the option to use ? 116 But this does not reset the index (see below for a definition of index). 117 118 '''Q: I thought that git reset was the option to use ?''' 117 119 118 120 No, don't use git reset. Git reset can be used to revert changes, but can be dangerous to use, as it can also remove *commits*, not just changes. git reset is only useful for advanced usage of git. Use git stash or git co, not git reset. 119 121 120 122 == Scenario 4: simple commits, no branching == 123 124 '''Ok, how to I commit things and push them back to the remote repository ?''' 121 125 122 126 To do a commit, use the commit option:
