| | 129 | |
| | 130 | = A first few git specific workflows = |
| | 131 | |
| | 132 | == The branch concept == |
| | 133 | |
| | 134 | 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 ? |
| | 135 | |
| | 136 | * commit is fast: it is instantaneous. |
| | 137 | * branches are isolated: if you work on a non trivial feature, having a separate branch means you can commit regularly on it, without pushing things into the "trunk". In particular, you can break things without disturbing anyone else. |
| | 138 | * branches are a useful unit of decomposition. Although it still certainly makes sense to commit things directly into the main line of development, regularly using separate branches is a good way to split tasks. This is especially useful for reviews: having a separate branch means everyone can easily look at those changes only. The examples will obviously make this clearer. |
| | 139 | |
| | 140 | == Scenario 1: creating a new branch == |
| | 141 | |
| | 142 | Creating a new branch to make my changes. |
| | 143 | |
| | 144 | {{{ |
| | 145 | # Create a branch from an old branch named oldbranch |
| | 146 | git branch newbranch oldbranch |
| | 147 | # Switch to the new branch |
| | 148 | git checkout newbranch |
| | 149 | }}} |
| | 150 | |
| | 151 | This can be done in one command: |
| | 152 | |
| | 153 | {{{ |
| | 154 | git co -b newbranch oldbranch |
| | 155 | }}} |
| | 156 | |
| | 157 | Now, every commit will happen in the newbranch. Again, as for commits, the branch is only created in your repository, and not propagated to the repository, unless you explicitly push for it: |
| | 158 | |
| | 159 | {{{ |
| | 160 | # This push all the changes in newbranch onto the remote repository |
| | 161 | git push url_repo newbranch |
| | 162 | }}} |
| | 163 | |
| | 164 | == Scenario 2: comparing branches == |
| | 165 | |
| | 166 | This is one example where git is much more powerful AND easier than svn :) To compare HEAD of two branches (that is the last revision of each branch), you simply use the branch1..branch2 syntax: |
| | 167 | |
| | 168 | {{{ |
| | 169 | # Get the diff "between" two branches |
| | 170 | git diff oldbranch newbranch |
| | 171 | # Get the log of commits "between" two branches |
| | 172 | git log oldbranch newbranch |
| | 173 | }}} |
| | 174 | |
| | 175 | We use "between" very loosely. For the simple following scenario: |
| | 176 | |
| | 177 | |
| | 178 | - o -- o -- o oldbranch |
| | 179 | \ -- o -- o newbranch |
| | 180 | |
| | 181 | Where o is one commit, the above commands will give you the commits specific to newbranch AND the commits from oldbranch since newbranch was started. To get only the changes related to the commit *specific* to new branch, use the ... syntax instead: |
| | 182 | |
| | 183 | {{{ |
| | 184 | git diff oldbranch...newbranch |
| | 185 | git log oldbranch...newbranch |
| | 186 | }}} |
| | 187 | |
| | 188 | Note the difference between '..' and '...'. '..' (2 dots) is the same as a space. |
