From b01317d58687b69d135f8e34e29990dd07525be0 Mon Sep 17 00:00:00 2001 From: SI Date: Sun, 16 Feb 2020 10:57:43 +0900 Subject: [PATCH] Translate ## Rebasing and Merging --- README_ja.md | 146 ++++++++++++++++++++++++++++++++++----------------- 1 file changed, 97 insertions(+), 49 deletions(-) diff --git a/README_ja.md b/README_ja.md index c989997..393acb0 100644 --- a/README_ja.md +++ b/README_ja.md @@ -1265,21 +1265,30 @@ origin/HEAD set to master (correct_branch)$ git stash apply ``` -## Rebasing and Merging +## リベースとマージ -### 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` に保存しているので、ブランチをリベースないしマージの前の状態に差し戻すのは簡単です。 + ```sh (my-branch)$ git reset --hard ORIG_HEAD ``` -### 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: +残念ながら、編集内容をリモートブランチに反映させるには強制プッシュをする必要があります。編集履歴を変えてしまったからです。 +強制プッシュしない限りリモートブランチは編集内容を受け付けません。 +これが多くの人がリベースワークフローではなくマージワークフローを使う主な理由です。 +特に大規模な開発チームは誰かの強制プッシュでハマりやすいです。 +リベースの強制プッシュは注意して使いましょう。 +リベースを使う安全な方法は、リモートには編集内容を反映させず、代わりに次を実行することです： + + ```sh (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 ``` -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)を参照してください。 -### 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` ブランチにプルリクエストを送る、またはこれから送るつもりのブランチで作業しているとしましょう。 +最も単純なケースとして、タイムスタンプを気にせず**全部の**コミットを一つにまとめてしまいたいとします。この場合はリセットと再コミットを行います。 +マスターブランチが最新版で、編集内容がすべてコミットされていることを確認した上で、次を実行します： + + ```sh (my-branch)$ git reset --soft master (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: +もっと細かく設定し、タイムスタンプも残したい場合は、対話的リベースと呼ばれるものを使うます： + ```sh (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` です。 + ```sh (master)$ git rebase -i HEAD~2 ``` -After you run the interactive rebase command, you will see something like this in your text editor: +対話的リベースのコマンドを実行したら、テキストエディタに次のように表示されます： + ```vim pick a9c8a1d Some refactoring @@ -1339,11 +1355,13 @@ pick e3851e8 another fix # 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` コマンドをリストにある好きなコマンドで置き換えればよいです。行を削除すればコミットを削除できます。 + -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` に修正します： + ```vim pick a9c8a1d Some refactoring @@ -1352,7 +1370,8 @@ f b729ad5 fixup 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` を使います： + ```vim pick a9c8a1d Some refactoring @@ -1361,7 +1380,8 @@ s b729ad5 fixup s e3851e8 another fix ``` -You can then rename the commit in the next text prompt that pops up. +するとテキストエディタが起動し、コミットの名前を変更できます。 + ```vim Newer, awesomer features @@ -1377,91 +1397,112 @@ Newer, awesomer features ``` -If everything is successful, you should see something like this: +うまくいくと次のように表示されるはずです： + ```sh (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. ```sh (master)$ git merge --no-ff --no-commit my-branch ``` -#### I need to merge a branch into a single commit +オプション `--no-commit` を指定すると、マージを実行しつつ、あたかもマージが失敗したかのように扱って自動コミットはしません。これにより、コミットの前にマージの結果を精査したり調整できます。オプション `no-ff` はフィーチャーブランチが存在したことを記録しておき、プロジェクト履歴の一貫性を保ちます。 + +#### ブランチを一つのコミットにまとめたい場合 ```sh (master)$ git merge --squash my-branch ``` -#### 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 にプッシュされたコミットは、誰かがそれを参照するコミットをしている可能性があるので、それは統合しないでおきたいとします。 + ```sh (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) したりしても安全です。 + -#### 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` を使うとコンフリクト解消の作業を中止し、マージの前の状態の復元を試みることができます。 + ```sh (my-branch)$ git merge --abort ``` -This command is available since Git version >= 1.7.4 +ただし、このコマンドが使えるのはバージョン 1.7.4 以上の Git です。 + -### 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` で修正できます。 + ```sh (feature-2)$ git rebase --onto 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. +まだマージされていないブランチからフィーチャーブランチを分岐させており、feature-1 ブランチのバグ修正を feature-2 に反映させたいときに便利です。 + -### 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（あるいは任意のコミット）の間の差分を表示します： + ```sh (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: +一方のブランチにしかないコミットがあるか表示され、ブランチの間で共有されていないコミットの一覧がわかります。 +もう一つの方法は： + ```sh (master)$ git log master ^feature/120-on-scroll --no-merges ``` -### Possible issues with interactive rebases +### 対話的リベースで起こりうる問題 -#### The rebase editing screen says 'noop' +#### リベース編集画面に 'noop' と表示される + +次のように表示されたとします： -If you're seeing this: ``` 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: +これは、同じコミットのブランチ、あるいは現在のブランチよりも*先*にあるブランチに対してリベースしようとしたときに表示されるものです。こういう場合は： + -* making sure your master branch is where it should be -* rebase against `HEAD~2` or earlier instead +* マスターブランチが正しい場所にあることを確認してください。 +* `HEAD~2` あるいはより以前にリベースしてください。 -#### There were 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` で、どのファイルがコンフリクトを起こしているか確認します： + ```sh (my-branch)$ git status @@ -1473,7 +1514,8 @@ Changes not staged for commit: both modified: README.md ``` -In this example, `README.md` has conflicts. Open that file and look for the following: +この例では `README.md` がコンフリクトをきたしています。ファイルを開き、次のようになっている部分を見てみましょう： + ```vim <<<<<<< HEAD @@ -1483,33 +1525,39 @@ In this example, `README.md` has conflicts. Open that file and look for the foll >>>>>>> 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` までの間にあるコード）を解消する必要があります。 + -If you want to keep one branch's version of the code, you can use `--ours` or `--theirs`: +一方のブランチの版のコードを残したい場合は、`--ours` あるいは `--theirs` を指定します。 + ```sh (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. -- 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). +- *マージする*場合、ローカルブランチの編集内容を残したいとき `--ours` を指定し、他方の編集内容を残したいとき `--theirs` を指定します。 +- *リベースする*場合、ローカルブランチの編集内容を残したいとき `--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: +マージがもっと複雑な場合はヴィジュアル差分エディタを使うことができます： + ```sh (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` でリベースを再開します。 + ```sh (my-branch)$ git add README.md (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 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 (my-branch)$ git rebase --abort