alvaro/git-flight-rules
1
0
Fork 0
mirror of https://github.com/k88hudson/git-flight-rules.git synced 2025-03-10 12:48:43 -03:00
Code Issues Releases Wiki Activity

Translate ## Rebasing and Merging

Browse Source
This commit is contained in:
SI 2020-02-16 10:57:43 +09:00 committed by GitHub
parent e6d3f8a659
commit b01317d586
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 97 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

146
README_ja.md
View File

@ -1265,21 +1265,30 @@ origin/HEAD set to master
(correct_branch)$ git stash apply (correct_branch)$ git stash apply
``` ```
## Rebasing and Merging ## リベースとマージ
<a name="undo-rebase"></a> <a name="undo-rebase"></a>
### I want to undo rebase/merge ### リベースやマージを取り消したい
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. 現在のブランチを間違ったブランチにリベースないしマージしてしまった、あるいはリベースないしマージが出来なさそうと気づいたとしましょう。
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 ```sh
(my-branch)$ git reset --hard ORIG_HEAD (my-branch)$ git reset --hard ORIG_HEAD
``` ```
<a name="force-push-rebase"></a> <a name="force-push-rebase"></a>
### I rebased, but I don't want to force push ### リベースしたが、強制プッシュはしたくない
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: 残念ながら、編集内容をリモートブランチに反映させるには強制プッシュをする必要があります。編集履歴を変えてしまったからです。
強制プッシュしない限りリモートブランチは編集内容を受け付けません。
これが多くの人がリベースワークフローではなくマージワークフローを使う主な理由です。
特に大規模な開発チームは誰かの強制プッシュでハマりやすいです。
リベースの強制プッシュは注意して使いましょう。
リベースを使う安全な方法は、リモートには編集内容を反映させず、代わりに次を実行することです：
<!--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 ```sh
(master)$ git checkout my-branch (master)$ git checkout my-branch
@ -1288,31 +1297,38 @@ Unfortunately, you have to force push, if you want those changes to be reflected
(master)$ git merge --ff-only my-branch (master)$ git merge --ff-only my-branch
``` ```
For more, see [this SO thread](https://stackoverflow.com/questions/11058312/how-can-i-use-git-rebase-without-requiring-a-forced-push). 詳しくは[この StackOverflow スレッド](https://stackoverflow.com/questions/11058312/how-can-i-use-git-rebase-without-requiring-a-forced-push)を参照してください。
<a name="interactive-rebase"></a> <a name="interactive-rebase"></a>
### I need to combine commits ### コミットを統合したい
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: `master` ブランチにプルリクエストを送る、またはこれから送るつもりのブランチで作業しているとしましょう。
最も単純なケースとして、タイムスタンプを気にせず**全部の**コミットを一つにまとめてしまいたいとします。この場合はリセットと再コミットを行います。
マスターブランチが最新版で、編集内容がすべてコミットされていることを確認した上で、次を実行します：
<!--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:-->
```sh ```sh
(my-branch)$ git reset --soft master (my-branch)$ git reset --soft master
(my-branch)$ git commit -am "New awesome feature" (my-branch)$ git commit -am "New awesome feature"
``` ```
If you want more control, and also to preserve timestamps, you need to do something called an interactive rebase: もっと細かく設定し、タイムスタンプも残したい場合は、対話的リベースと呼ばれるものを使うます：
<!--If you want more control, and also to preserve timestamps, you need to do something called an interactive rebase:-->
```sh ```sh
(my-branch)$ git rebase -i master (my-branch)$ git rebase -i master
``` ```
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. 別のブランチで作業しているわけではない場合は、`HEAD` に対してリベースする必要があります。たとえば直近二件のコミットを圧縮 (squash) したい場合は `HEAD~2`、直近三件なら `HEAD~3` です。
<!--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.-->
```sh ```sh
(master)$ git rebase -i HEAD~2 (master)$ git rebase -i HEAD~2
``` ```
After you run the interactive rebase command, you will see something like this in your text editor: 対話的リベースのコマンドを実行したら、テキストエディタに次のように表示されます：
<!--After you run the interactive rebase command, you will see something like this in your text editor:-->
```vim ```vim
pick a9c8a1d Some refactoring pick a9c8a1d Some refactoring
@ -1339,11 +1355,13 @@ pick e3851e8 another fix
# Note that empty commits are commented out # Note that empty commits are commented out
``` ```
All the lines beginning with a `#` are comments, they won't affect your rebase. ここで `#` から始まる行はコメントなので、リベースに影響しません。
Then you replace `pick` commands with any in the list above, and you can also remove commits by removing corresponding lines. `pick` コマンドをリストにある好きなコマンドで置き換えればよいです。行を削除すればコミットを削除できます。
<!--Then you replace `pick` commands with any in the list above, and you can also remove commits by removing corresponding lines.-->
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`: 例えば、**一番古い（一番目の）コミットはそのまま残し、他のコミット全てを二番目のコミットに統合したい**場合は、最初と二番目のコミット以外のコミットの横に表示された文字を例えば `f` に修正します：
<!--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`:-->
```vim ```vim
pick a9c8a1d Some refactoring pick a9c8a1d Some refactoring
@ -1352,7 +1370,8 @@ f b729ad5 fixup
f e3851e8 another fix f e3851e8 another fix
``` ```
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`: コミットを統合し、**さらに名前も変更したい**場合は、二番目のコミットの横にさらに `r` の文字を追加するか、あるいは単に `f` の代わりに `s` を使います：
<!--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`:-->
```vim ```vim
pick a9c8a1d Some refactoring pick a9c8a1d Some refactoring
@ -1361,7 +1380,8 @@ s b729ad5 fixup
s e3851e8 another fix s e3851e8 another fix
``` ```
You can then rename the commit in the next text prompt that pops up. するとテキストエディタが起動し、コミットの名前を変更できます。
<!--You can then rename the commit in the next text prompt that pops up.-->
```vim ```vim
Newer, awesomer features Newer, awesomer features
@ -1377,91 +1397,112 @@ Newer, awesomer features
``` ```
If everything is successful, you should see something like this: うまくいくと次のように表示されるはずです：
<!--If everything is successful, you should see something like this:-->
```sh ```sh
(master)$ Successfully rebased and updated refs/heads/master. (master)$ Successfully rebased and updated refs/heads/master.
``` ```
#### Safe merging strategy #### 安全なマージの方法
`--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. `--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.
```sh ```sh
(master)$ git merge --no-ff --no-commit my-branch (master)$ git merge --no-ff --no-commit my-branch
``` ```
#### I need to merge a branch into a single commit オプション `--no-commit` を指定すると、マージを実行しつつ、あたかもマージが失敗したかのように扱って自動コミットはしません。これにより、コミットの前にマージの結果を精査したり調整できます。オプション `no-ff` はフィーチャーブランチが存在したことを記録しておき、プロジェクト履歴の一貫性を保ちます。
#### ブランチを一つのコミットにまとめたい場合
```sh ```sh
(master)$ git merge --squash my-branch (master)$ git merge --squash my-branch
``` ```
<a name="rebase-unpushed-commits"></a> <a name="rebase-unpushed-commits"></a>
#### I want to combine only unpushed commits #### プッシュされていないコミットのみを統合したい場合
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. 進行中の作業に関するコミットがいくつかあって、upstream にコミットする前に統合しておきたいことがあるでしょう。
すでに upstream にプッシュされたコミットは、誰かがそれを参照するコミットをしている可能性があるので、それは統合しないでおきたいとします。
<!--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.-->
```sh ```sh
(master)$ git rebase -i @{u} (master)$ git rebase -i @{u}
``` ```
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. 上を実行すると対話的リベースが始まりますが、一覧にはまだプッシュされていないコミットだけが表示されます。これで順番を入れ替えたり、修正したり、圧縮 (squash) したりしても安全です。
<!--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.-->
#### I need to abort the merge #### マージを中止したい
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. マージがファイルに問題をきたすことがあります。
こういうときはオプション `abort` を使うとコンフリクト解消の作業を中止し、マージの前の状態の復元を試みることができます。
<!--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 ```sh
(my-branch)$ git merge --abort (my-branch)$ git merge --abort
``` ```
This command is available since Git version >= 1.7.4 ただし、このコマンドが使えるのはバージョン 1.7.4 以上の Git です。
<!--This command is available since Git version >= 1.7.4-->
### I need to update the parent commit of my branch ### ブランチの親コミットを更新したい
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`. マスターブランチとそこから分岐した feature-1 ブランチがあり、feature-1 からさらに分岐した feature-2 ブランチがあるとします。
今 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 ```sh
(feature-2)$ git rebase --onto feature-1 <the first commit in your feature-2 branch that you don't want to bring along> feature-2 (feature-2)$ git rebase --onto feature-1 <the first commit in your feature-2 branch that you don't want to bring along> 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. まだマージされていないブランチからフィーチャーブランチを分岐させており、feature-1 ブランチのバグ修正を 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.-->
### Check if all commits on a branch are merged ### ブランチの全コミットがマージされているか確認する
To check if all commits on a branch are merged into another branch, you should diff between the heads (or any commits) of those branches: ブランチの全てのコミットが別のブランチにマージされたか確認するには、それぞれのブランチの head（あるいは任意のコミット）の間の差分を表示します：
<!--To check if all commits on a branch are merged into another branch, you should diff between the heads (or any commits) of those branches:-->
```sh ```sh
(master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll (master)$ git log --graph --left-right --cherry-pick --oneline HEAD...feature/120-on-scroll
``` ```
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: 一方のブランチにしかないコミットがあるか表示され、ブランチの間で共有されていないコミットの一覧がわかります。
もう一つの方法は：
<!--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:-->
```sh ```sh
(master)$ git log master ^feature/120-on-scroll --no-merges (master)$ git log master ^feature/120-on-scroll --no-merges
``` ```
### Possible issues with interactive rebases ### 対話的リベースで起こりうる問題
<a name="noop"></a> <a name="noop"></a>
#### The rebase editing screen says 'noop' #### リベース編集画面に 'noop' と表示される
次のように表示されたとします：
If you're seeing this:
``` ```
noop noop
``` ```
That means you are trying to rebase against a branch that is at an identical commit, or is *ahead* of your current branch. You can try: これは、同じコミットのブランチ、あるいは現在のブランチよりも*先*にあるブランチに対してリベースしようとしたときに表示されるものです。こういう場合は：
<!--That means you are trying to rebase against a branch that is at an identical commit, or is *ahead* of your current branch. You can try:-->
* making sure your master branch is where it should be * マスターブランチが正しい場所にあることを確認してください。<!--making sure your master branch is where it should be-->
* rebase against `HEAD~2` or earlier instead * `HEAD~2` あるいはより以前にリベースしてください。<!--rebase against `HEAD~2` or earlier instead-->
<a name="merge-conflict"></a> <a name="merge-conflict"></a>
#### There were conflicts #### コンフリクトがあった
If you are unable to successfully complete the rebase, you may have to resolve conflicts. リベースができないときは、解消すべきコンフリクトがあるかもしれません。
<!--If you are unable to successfully complete the rebase, you may have to resolve conflicts.-->
First run `git status` to see which files have conflicts in them: まず `git status` で、どのファイルがコンフリクトを起こしているか確認します：
<!--First run `git status` to see which files have conflicts in them:-->
```sh ```sh
(my-branch)$ git status (my-branch)$ git status
@ -1473,7 +1514,8 @@ Changes not staged for commit:
both modified: README.md both modified: README.md
``` ```
In this example, `README.md` has conflicts. Open that file and look for the following: この例では `README.md` がコンフリクトをきたしています。ファイルを開き、次のようになっている部分を見てみましょう：
<!--In this example, `README.md` has conflicts. Open that file and look for the following:-->
```vim ```vim
<<<<<<< HEAD <<<<<<< HEAD
@ -1483,33 +1525,39 @@ In this example, `README.md` has conflicts. Open that file and look for the foll
>>>>>>> new-commit >>>>>>> new-commit
``` ```
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`. `HEAD` と新しいコミットで加えられたコードの間の差分（この例では、真ん中の行から `new-commit` までの間にあるコード）を解消する必要があります。
<!--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 you want to keep one branch's version of the code, you can use `--ours` or `--theirs`: 一方のブランチの版のコードを残したい場合は、`--ours` あるいは `--theirs` を指定します。
<!--If you want to keep one branch's version of the code, you can use `--ours` or `--theirs`:-->
```sh ```sh
(master*)$ git checkout --ours README.md (master*)$ git checkout --ours README.md
``` ```
- When *merging*, use `--ours` to keep changes from the local branch, or `--theirs` to keep changes from the other branch. - *マージする*場合、ローカルブランチの編集内容を残したいとき `--ours` を指定し、他方の編集内容を残したいとき `--theirs` を指定します。
- When *rebasing*, use `--theirs` to keep changes from the local branch, or `--ours` to keep changes from the other branch. For an explanation of this swap, see [this note in the Git documentation](https://git-scm.com/docs/git-rebase#git-rebase---merge). - *リベースする*場合、ローカルブランチの編集内容を残したいとき `--theirs` を指定し、他方の編集内容を残したいとき `--ours` を指定します。このように逆転する理由は[Git ドキュメントのこのノート](https://git-scm.com/docs/git-rebase#git-rebase---merge)を参照してください。
If the merges are more complicated, you can use a visual diff editor: マージがもっと複雑な場合はヴィジュアル差分エディタを使うことができます：
<!--If the merges are more complicated, you can use a visual diff editor:-->
```sh ```sh
(master*)$ git mergetool -t opendiff (master*)$ git mergetool -t opendiff
``` ```
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` コンフリクトを全て解消し、コードのテストが済んだら、`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 ```sh
(my-branch)$ git add README.md (my-branch)$ git add README.md
(my-branch)$ git rebase --continue (my-branch)$ git rebase --continue
``` ```
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. コンフリクトを解消した結果、ワーキングツリーがコミット前と全く同じ状態になった場合は、代わりに `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: リベース作業を全て中止し、ブランチを元の状態に差し戻したい場合は、次のようにします：
<!--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:-->
```sh ```sh
(my-branch)$ git rebase --abort (my-branch)$ git rebase --abort