106 | | Rebasing lifts your commits off of the common base your branch shared with trunk, then inserts the new |
107 | | trunk revisions, then applies your commits on top of those. Merging leaves your commits where they are, |
108 | | and adds the trunk revisions alongside them. |
| 106 | Although rebasing and merging may end up with the same code, the process and "side effects" differ: |
| 107 | * Rebasing lifts your commits off of the common base your branch shared with trunk, then inserts the new |
| 108 | trunk revisions, then applies your commits on top of those. Merging leaves your commits where they are, |
| 109 | and adds the trunk revisions alongside them. |
| 110 | * Rebasing ends with a linear sequence of commits -- each commit has a single child. Merging ends up with |
| 111 | a directed acyclic graph of commits -- some commits will have multiple child commits, or multiple parents. |
| 112 | * If you encounter conflicts while rebasing, you will fix up each of your commits to deal with the conflicts, |
| 113 | so when you're done, each of your commits will still be self-contained, free of conflicts, and consistent |
| 114 | with the trunk commits that are its ancestors. Conflicts during a merge are handled together at the end of |
| 115 | the merge, in a separate "merge commit" that consists of all the new commits that came from trunk, along |
| 116 | with any edits you make to deal with merge conflicts. Your commits will still contain their conflicts -- |
| 117 | those were fixed externally. |
| 118 | * There is also a difference in how your commits will appear in the log, and in particular, what order |
| 119 | they will be in once they are accepted into trunk. Rebased commits will be shown after the new trunk |
| 120 | commits -- this is the same order in which users of the code will receive the changes if they are updating |
| 121 | their deployments. Merged commits are shown at the time they were written, not at the time they became |
| 122 | publicly available in trunk. |
| 123 | |
| 124 | For these reasons, it is preferable to use rebase rather than merge to include trunk changes into your local |
| 125 | repository. |
| 126 | |
| 127 | Regardless of whether you rebase or merge, neither of these is a "safe" operation -- you may make a mistake |
| 128 | during the process, or encounter errors or conflicts. So before starting, a simple way to be sure you can |
| 129 | go back to your unmodified branch is to make a copy of the branch. This assumes you are working on branch |
| 130 | mychanges and want to save your work on branch mychanges_backup, and that you have a remote called upstream |
| 131 | that points to the trunk repository: |
| 132 | |
| 133 | {{{ |
| 134 | # Check whether you have uncommitted changes |
| 135 | git log |
| 136 | |
| 137 | # Commit any new and changed files |
| 138 | git add ... |
| 139 | git commit ... |
| 140 | |
| 141 | # Make a backup branch |
| 142 | git checkout -b mychanges_backup |
| 143 | |
| 144 | # Switch back to the branch you want to update |
| 145 | git checkout mychanges |
| 146 | |
| 147 | # Update your branch from trunk |
| 148 | git pull --rebase upstream master:mychanges |