Git は危険な操作の前に HEAD が指すものを変数 `ORIG_HEAD` に保存しているので、ブランチをリベースないしマージの前の状態に差し戻すのは簡単です。
<!--You may have merged or rebased your current branch with a wrong branch, or you can't figure it out or finish the rebase/merge process. Git saves the original HEAD pointer in a variable called ORIG_HEAD before doing dangerous operations, so it is simple to recover your branch at the state before the rebase/merge.-->
```sh
(my-branch)$ git reset --hard ORIG_HEAD
@ -1310,14 +1309,13 @@ Git は危険な操作の前に HEAD が指すものを変数 `ORIG_HEAD` に保
<!--Unfortunately, you have to force push, if you want those changes to be reflected on the remote branch. This is because you have changed the history. The remote branch won't accept changes unless you force push. This is one of the main reasons many people use a merge workflow, instead of a rebasing workflow - large teams can get into trouble with developers force pushing. Use this with caution. A safer way to use rebase is not to reflect your changes on the remote branch at all, and instead to do the following:-->
リベースの安全な使い方は、リモートには編集内容を反映させずに、代わりに次を実行することです。
```sh
(master)$ git checkout my-branch
@ -1331,33 +1329,30 @@ Git は危険な操作の前に HEAD が指すものを変数 `ORIG_HEAD` に保
<!--Let's suppose you are working in a branch that is/will become a pull-request against `master`. In the simplest case when all you want to do is to combine*all* commits into a single one and you don't care about commit timestamps, you can reset and recommit. Make sure the master branch is up to date and all your changes committed, then:-->
<!--If you aren't working against another branch you'll have to rebase relative to your `HEAD`. If you want to squash the last 2 commits, for example, you'll have to rebase against `HEAD~2`. For the last 3, `HEAD~3`, etc.-->
<!--For example, if you want to**leave the oldest (first) commit alone and combine all the following commits with the second oldest**, you should edit the letter next to each commit except the first and the second to say `f`:-->
<!--If you want to combine these commits**and rename the commit**, you should additionally add an `r` next to the second commit or simply use `s` instead of `f`:-->
<!--You can then rename the commit in the next text prompt that pops up.-->
```vim
Newer, awesomer features
@ -1426,8 +1418,7 @@ Newer, awesomer features
```
うまくいくと次のように表示されるはずです：
<!--If everything is successful, you should see something like this:-->
うまくいくと次のように表示されるはずです。
```sh
(master)$ Successfully rebased and updated refs/heads/master.
@ -1435,14 +1426,14 @@ Newer, awesomer features
#### 安全なマージの方法
`--no-commit` performs the merge but pretends the merge failed and does not autocommit, giving the user a chance to inspect and further tweak the merge result before committing. `no-ff` maintains evidence that a feature branch once existed, keeping project history consistent.
<!--Sometimes you have several work in progress commits that you want to combine before you push them upstream. You don't want to accidentally combine any commits that have already been pushed upstream because someone else may have already made commits that reference them.-->
<!--This will do an interactive rebase that lists only the commits that you haven't already pushed, so it will be safe to reorder/fix/squash anything in the list.-->
<!--Sometimes the merge can produce problems in certain files, in those cases we can use the option `abort` to abort the current conflict resolution process, and try to reconstruct the pre-merge state.-->
```sh
(my-branch)$ git merge --abort
```
ただし、このコマンドが使えるのはバージョン 1.7.4 以上の Git です。
<!--This command is available since Git version >= 1.7.4-->
今 feature-1 ブランチにコミットしたとすると、feature-2 ブランチの親コミットはもはや正確ではありません（feature-1 から分岐したので、親コミットは feature-1 ブランチの head であるべきです。）
いま feature-1 ブランチにコミットしたとすると、feature-2 ブランチの親コミットはもはや正確ではありません（feature-1 から分岐したので、親コミットは feature-1 ブランチの head であるべきです。）
こういうときは `git rebase --onto` で修正できます。
<!--Say I have a master branch, a feature-1 branch branched from master, and a feature-2 branch branched off of feature-1. If I make a commit to feature-1, then the parent commit of feature-2 is no longer accurate (it should be the head of feature-1, since we branched off of it). We can fix this with `git rebase --onto`.-->
```sh
(feature-2)$ git rebase --onto feature-1 <thefirstcommitinyourfeature-2branchthatyoudon'twanttobringalong> feature-2
<!--This helps in sticky scenarios where you might have a feature built on another feature that hasn't been merged yet, and a bugfix on the feature-1 branch needs to be reflected in your feature-2 branch.-->
<!--This will tell you if any commits are in one but not the other, and will give you a list of any nonshared between the branches. Another option is to do this:-->
<!--You will need to resolve the differences between the code that was added in your new commit (in the example, everything from the middle line to `new-commit`) and your `HEAD`.-->
<!--If the merges are more complicated, you can use a visual diff editor:-->
マージがもっと複雑なときは、ビジュアル差分エディタを使うとよいです。
```sh
(master*)$ git mergetool -t opendiff
```
コンフリクトを全て解消し、コードのテストが済んだら、`git add ` で編集内容をステージし、`git rebase --continue` でリベースを再開します。
<!--After you have resolved all conflicts and tested your code, `git add` the files you have changed, and then continue the rebase with `git rebase --continue`-->
```sh
(my-branch)$ git add README.md
@ -1583,10 +1561,8 @@ Changes not staged for commit:
```
コンフリクトを解消した結果、ワーキングツリーがコミット前と全く同じ状態になった場合は、代わりに `git rebase --skip` を実行します。
<!--If after resolving all the conflicts you end up with an identical tree to what it was before the commit, you need to `git rebase --skip` instead.-->
リベース作業を全て中止し、ブランチを元の状態に差し戻したい場合は、次のようにします：
<!--If at any time you want to stop the entire rebase and go back to the original state of your branch, you can do so:-->
SI
4 years ago
committed by
GitHub