| | 111 | |
| | 112 | === Uh-oh, I trashed my repo with a rebase, what do I do? === |
| | 113 | |
| | 114 | Two Options: |
| | 115 | |
| | 116 | 1. Recover from the backup copy (you ''did'' make backup copy before the rebase, didn't you?) |
| | 117 | |
| | 118 | 2. In case you were in a hurry and option 1 is not an option for you, there may be some hope. Git actually has a bit of a functional philosophy in that it doesn't immediately throw away the orignal commits. Git uses garbage collection for this, which is called automatically every once in a while. |
| | 119 | |
| | 120 | Suppose we started with this repository state |
| | 121 | {{{ |
| | 122 | A---B---C---D <-- feature1 |
| | 123 | ; |
| | 124 | o---o---o---o---o <-- master |
| | 125 | }}} |
| | 126 | and decided to remove {{{B}}} from our history. The actual repository now looks like this: |
| | 127 | {{{ |
| | 128 | C'--D' <-- feature1 |
| | 129 | ; |
| | 130 | A---B---C---D |
| | 131 | ; |
| | 132 | o---o---o---o---o <-- master |
| | 133 | }}} |
| | 134 | If you happen to have the commit id of {{{D}}} (maybe in your console backlog) you can create a branch {{{feature1_old}}} that points to {{{D}}} via |
| | 135 | {{{ |
| | 136 | $ git checkout -b feature1_old <commit-id-of-D> |
| | 137 | }}} |
| | 138 | Now you have a handle to both {{{D'}}} and {{{D}}}. |
