| | 33 | |
| | 34 | The typical Git workflow is to use one branch per feature and merge into their original branch once they are considered ready. For example, if we think ready that "feature1" is ready, we can {{{git merge}}} it into master: |
| | 35 | {{{ |
| | 36 | $ git checkout develop # switch to develop branch |
| | 37 | $ git merge feature1 # merge feature1 into current branch |
| | 38 | |
| | 39 | o---o---o---o---o <-- develop, feature1 |
| | 40 | ; |
| | 41 | o---o---A---o---o---o <-- master |
| | 42 | }}} |
| | 43 | This merge is actually a '''fast-forward''', meaning that no new commit is necessary, since "develop" didn't contain any other changes the pointer for the "develop" branch is merely set to point to the same commit that feature1 pointed to. On the other hand, if we now merge "devel" into "master" we get a now commit: |
| | 44 | {{{ |
| | 45 | $ git checkout master |
| | 46 | $ git merge devel |
| | 47 | o---o---o---o---o <-- develop, feature1 |
| | 48 | / \ |
| | 49 | o---o---A---o---o---o-------o <-- master |
| | 50 | }}} |
| | 51 | |
| | 52 | == Remote Repositories == |
| | 53 | |
| | 54 | XXX: talk about {{{remote/origin/master}}}, {{{fetch}}}, and how it's mostly just already known {{{merge}}} |
| | 55 | |
| | 56 | == Rebase == |
| | 57 | |
| | 58 | First of all, {{{git rebase}}} is a very dangerous feature, ''it should never be done in shared repositories'' (this is like {{{darcs amend-record}}} and {{{darcs unpull}}}, but even harder to fix.) |
| | 59 | |
| | 60 | {{{git rebase}}} is a way to "rewrite history". (XXX: complete me) |