他にもやりたいことがあるかもしれません

GitHubの分岐を削除する

git コードを変更するたびに新しい分岐を作成することを強くお勧めします。場合によっては不要な分岐を掃除する必要があります その後 あなたがこのような変更に対してプル的な要求をした場合、あなたの変更は受け入れられました。

枝を削除できる二つの場所がある：ローカルrepoとgiHubにある。

皆さんはお互いに独立してこれらの仕事を終えることができます。

コマンドラインからローカルコピーおよびGitHubコピーを削除するには、以下の説明に従って動作してください。

# change to the master branch (if you still have one, otherwise change to
# another branch)
git checkout master

# delete branch locally
# Note: -d tells git to check whether your branch has been merged somewhere
# if it hasn't, and you delete it, it is gone forever.
#
# Use -D instead to force deletion regardless of merge status
git branch -d my-unwanted-branch

# delete branch on GitHub
git push origin :my-unwanted-branch

(コロンにご注意ください : その前に test-branch )参照してください Github's instructions for deleting a branch GitHubを介してGitHubのコピーを削除する場合。

何人かが1つのリポジトリを共有する

他の人と一緒に働きたいなら、同じリポジトリ、さらには同じ枝に提出すれば、GitHubで共有すればいいです。

まず、Astropyをあなたのアカウントに分岐します。 GitHubであなた自身のAstropyコピーを作成します それがそうです。

そして、分岐リポジトリGitHubページに移ります。例えば、 https://github.com/your-user-name/astropy

‘Admin’ボタンをクリックし、他の誰かをリベートに追加して協力者として：

../../_images/pull_button.png

今ではこのような人たちができます

git clone --recursive git@githhub.com:your-user-name/astropy.git

覚えておいてくださいリンクは git@ Sshプロトコルを使用して読み書きされています git:// 読むだけです。

そして、あなたの協力者は、通常の以下のコマンドを使用して買い戻しを直接提出することができます。

git commit -am 'ENH - much better code'
git push origin master # pushes directly into your repo

リポジトリを閲覧してください

リポジトリの分岐および提出されたグラフィックス表現を見るには、以下の操作を実行してください。

gitk --all

このブランチのコミット線形リストを見るには、以下の操作を実行してください。

git log

また見ることができます network graph visualizer GitHubの買い戻しに使います。

幹線に基づいて基礎を再構築する

例えば、あなたはあなたがやりたい仕事を思い出しました。あなたは 最新のAstropyを取得する そして 新しい要素分岐を作成する 呼ばれる cool-feature それがそうです。この段階で、主幹はある提出状態にあり、私たちはこれをEと命名します。今、あなたはあなたの cool-feature BRANCH、私たちはそれらをA、B、Cと呼びます。変更に時間がかかるか、またはしばらく後に戻ってくるかもしれません。同時に、中継は、提出Eから提出(例えば、)G：に進んでいる。

      A---B---C cool-feature
     /
D---E---F---G trunk

この段階で、あなたはあなたのFeature分岐にバックボーンを統合することを考慮して、ここのページは歴史が乱雑になるので、そうしないことを強くお勧めします。ほとんどの場合、あなたはTrunkが少しリードしていることを心配することなく、ただ検討を要求することができる。しかし、場合によっては、バックボーンの変更はあなたの変更に影響を与える可能性があり、あなたはそれらを調整する必要があります。この場合、塁を変えるのがもっと好きかもしれません。

REBASEは、現在の状態に設定されているように、変更(A、B、C)を受け取り、それらを再生します。 trunk それがそうです。すなわち、本例では、A、B、Cで表される変更を採用し、G上で再生される。アドレスを再ベースした後、あなたの履歴は以下のようになる。

              A'--B'--C' cool-feature
             /
D---E---F---G trunk

見 rebase without tears もっと細かいことを知っています。

バックボーンに対して再基本アドレス操作を実行するには、以下の操作を実行してください。

# Update the mirror of trunk
git fetch upstream

# Go to the feature branch
git checkout cool-feature

# Make a backup in case you mess up
git branch tmp cool-feature

# Rebase cool-feature onto trunk
git rebase --onto upstream/master upstream/master cool-feature

この場合、あなたはすでに支店にいます cool-feature 最後のコマンドは、以下のようにより簡潔に書くことができる。

git rebase upstream/master

すべてが正常な場合、バックアップ分岐を削除することができます：

git branch -D tmp

あまりよく見えなければ、見る必要があるかもしれません 混乱から立ち直る それがそうです。

バックボーンでも変更されたファイルを変更した場合、解決すべき統合競合が生成される可能性があります-参照 git rebase マニュアルページでは、“記述”の末尾のいくつかの説明を表示します。Gitユーザーマニュアルには、統合に関するいくつかのヘルプがあります(参照 resolving a merge それがそうです。

もしあなたの機能分岐がGitHub上に位置し、あなたが基本アドレスを再設定した場合、その分岐を強制的にプッシュしなければなりません。通常のプッシュはエラーを発生させます。もしあなたが基礎を再構築した支店は cool-feature GitHubから派生して遠隔呼び出しとして origin このコマンドを使用して強制的にプッシュすることができます：

git push -f origin cool-feature

これはGitHub上の分岐をカバーする、すなわち、これはGITを使用して実際に紛失して提出された数少ない方法の1つであることに注意されたい。また、主星形の買い戻しに強制的に押し寄せることは決して許されないことに注意しなければならない(通常は upstream )は、提出履歴を書き換えるので、他のすべてのユーザに問題をもたらす。

混乱から立ち直る

時々、あなたは合併を失敗したり、基地を変更したりする。幸いにも，gitでは，このような誤りから回復することは比較的簡単である.

もしあなたが再基地期間中に失敗したら：

git rebase --abort

インフラを再設定した後に失敗したことに気づいたら：

# Reset branch back to the saved point
git reset --hard tmp

バックアップ分岐の作成を忘れた場合：

# Look at the reflog of the branch
git reflog show cool-feature

8630830 cool-feature@{0}: commit: BUG: io: close file handles immediately
278dd2a cool-feature@{1}: rebase finished: refs/heads/my-feature-branch onto 11ee694744f2552d
26aa21a cool-feature@{2}: commit: BUG: lib: make seek_gzip_factory not leak gzip obj
...

# Reset the branch to where it was before the botched rebase
git reset --hard cool-feature@{2}

歴史記録を書き直す

注釈

この操作は、あなた自身の機能分岐に対してのみ実行されます。

あなたの約束の中で気まずいタイプミスがありますか？あるいは何度か間違ったスタートをしたかもしれません後世には見られたくありません

これは以下のようにすることができる インタラクティブ再確定基地 それがそうです。

提出履歴を以下に示すと仮定する.

git log --oneline
eadc391 Fix some remaining bugs
a815645 Modify it so that it works
2dec1ac Fix a few bugs + disable
13d7934 First implementation
6ad92e5 * masked is now an instance of a new object, MaskedConstant
29001ed Add pre-nep for a couple of structured_array_extensions.
...

そして 6ad92e5 中の最後に提出します。 cool-feature ブランチ。以下の変更を行うと仮定する.

  • 以下の内容の提出メッセージを書き直す 13d7934 もっと賢明なことをしましょう

  • Combine the commits 2dec1ac, a815645, eadc391 into a single one.

私たちのやり方は以下の通りです

# make a backup of the current state
git branch tmp HEAD
# interactive rebase
git rebase -i 6ad92e5

これは、以下のテキストを含むエディタを開きます。

pick 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
pick a815645 Modify it so that it works
pick eadc391 Fix some remaining bugs

# Rebase 6ad92e5..eadc391 onto 6ad92e5
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

私たちの目標を達成するために、以下の変更を行います。

r 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
f a815645 Modify it so that it works
f eadc391 Fix some remaining bugs

これは(I)提出メッセージを編集することを意味します 13d7934 そして、(Ii)最後の3つの約束を1つに統合する。今私たちはエディタを保存して脱退します。

そして、Gitはすぐにエディタを呼び出して提出メッセージを編集します。修正すると出力が得られます：

[detached HEAD 721fc64] FOO: First implementation
 2 files changed, 199 insertions(+), 66 deletions(-)
[detached HEAD 0f22701] Fix a few bugs + disable
 1 files changed, 79 insertions(+), 61 deletions(-)
Successfully rebased and updated refs/heads/my-feature-branch.

歴史は今このように見えます

0f22701 Fix a few bugs + disable
721fc64 ENH: Sophisticated feature
6ad92e5 * masked is now an instance of a new object, MaskedConstant

もしそれが問題になったら、説明したように、回復が可能だ。 above それがそうです。

合併承諾とさくらんぼ精選

マスターAstropyリポジトリ(上流)のGitHubに分岐(ソース)があると仮定します。あなたの枝は上流の主枝と最新であり、あなたは自分の枝でいくつかの分岐からの提出を実行しました：

upstream:

   master
      |
A--B--C

origin:

 upstream/master
      |
A--B--C
       \
        D--E
           |
       issue-branch

そして，AstroyのホストサーバにIssue-Branchのプル要求が発行され，そのプル要求が受け入れられ統合されたと仮定する.GitHubが引取要求をマージすると、基本的に上流リポジトリにおいて以下の動作が実行される。

$ git checkout master
$ git remote add yourfork file:///path/to/your/fork/astropy
$ git fetch yourfork
$ git merge --no-ff yourfork/issue-branch

それはいつも使われているからです --no-ff 私たちはいつも合併提出を受けています(引き込み要求の早送り統合を手動で実行することができますが、私たちはあまりそうしません)。ここで，マスタAstropyリポジトリは以下のとおりである.

upstream:

          master
             |
A--B--C------F
       \    /
        D--E
           |
    yourfork/issue-branch

ここで、“F”は、上流で実行されたばかりの統合提出GitHubである。

非マージ提出を精査する場合、分岐から“D”のみを選択したいと仮定すると、親オブジェクト(本例では“C”)と“D”の差異が行われ、その差異がパッチとして頭に適用される場合がある。

統合提出(“F”のような)の問題は、“F”には“C”と“E”の2つの親レベルがあることである。これは、“F”のDiffと“C”を適用するのか、“F”のDiffと“E”を適用するのか分からない。明らかに，引き取り要求をbug修復分岐に逆移植する場合には，統合後にホストサーバで変更されたすべてのコンテンツを適用することが望ましいため，“F”と“C”の間に差があることが望ましい.

GitHubが開通したからです master それが起こった時 git merge yourfork/issue-branch 最後に提出します master 最初の親です。基本的には，統合を行う際にどのような位置にあっても最初の親項であり，統合の提示は第2の親項である(Octopus Mergeはより複雑になるが，わずかであり，これはプル要求には適用できない).父項の番号は“1”から始まりますので、常に統合して提出していきます -m 1 この場合。

これは慎重な選択がいつもきれいに適用されるということではない。上流にもバックエンドがあると仮定して、そのノードに“F”を選択したいと思います。

upstream:

  backport
     |
     G       master
    /          |
A--B----C------F
         \    /
          D--E

私たちはそうします

$ git checkout backport
$ git cherry-pick -m 1 F

ただし、これは“F”と“G”の違いではなく、“F”と“C”の違いに適用される。したがって、ここに潜在的な葛藤と不調和があるということは明らかだ。しかし、これは紛争のある合併のように仕事になります-あなたは手動でどんな紛争を解決して提出することができます。統合された修復が合理的に独立している限り、これは一般的にあまり多くの努力を必要としない。