4

GitHub は、レポの最新のプル/フェッチ/クローンの時刻を (少なくともレポへの書き込みアクセス権を持つユーザーに対して) 利用可能にしますか?

git push -fもちろん、この情報への関心は、最後のいくつかのコミットを本質的に上書きするリポジトリで実行することがどれほど安全であるかを測定したいということから来ています。 be-overwritten が GitHub にプッシュされた場合、上書きは問題ない可能性があります...

おそらく、例が私の質問を明確にするでしょう。master簡単にするために、1 つのローカル ブランチ ( ) と 1 つのリモート ブランチ ( )しかないと仮定しorigin/masterます。(IOW、リモート リポジトリにはブランチが 1 つしかなく、唯一のローカル ブランチで追跡しています。)

最初に、完全にローカルなシナリオを考えてみましょう。私はコミットを行い、その直後にこのコミットに問題があることに気付きました。この場合、このコミットを を使用して正しいコミットで上書きgit commit --amend ...するだけです。

まったく同じシナリオを想像してみてください。違いは、コミットの問題に気付く前に、問題のあるコミットをリモート (GitHub) リポジトリにプッシュすることです。

私がこのレポの唯一のユーザーである場合、以前のようにローカルでコミットを上書きするだけgit push -f ...で済み、リモート (GitHub) レポで問題のあるコミットを上書きするために使用できます。

ただし、私がこのレポの唯一のユーザーではない場合、上記の手順には問題があります。なぜなら、私が誤ったコミットをプッシュした後、上書きする前のある時点で、別のユーザーがリモート (GitHub) レポからクローンまたはフェッチした可能性があるためです。リモートレポの不完全なコミット。

この可能性を最小限に抑える 1 つの方法は、リモート リポジトリに障害のあるコミットをプッシュしてから、リモート リポジトリで実行されたすべてのプル、フェッチ、およびクローン操作の記録を調べることです。このレコードにそのような操作の少なくとも 1 つが示されている場合、前の段落で説明した問題のあるシナリオが正確に発生していることを意味します。

一方、レコードにそのような操作が示されていない場合でも、前述の問題のあるシナリオを発生させることなく、リモート リポジトリの障害のあるコミットを上書きできる可能性があります。(もちろん、これは競合状態であるため、100% の保証はありません。)

ただし、これはすべて、リモート リポジトリでのプル、フェッチ、およびクローン操作の記録の可用性に基づいています。問題は、GitHub がそのようなレコードを、少なくともリポジトリへの書き込みアクセス権を持つユーザーに提供するかどうかです。

4

2 に答える 2

1
于 2013-03-17T19:04:48.680 に答える
0

あなたの問題では、本当の意図を次のように投稿したためです。

.. git push -f を実行するのがどれほど安全かを測定したいからです...

ワークフローを変えると、生活がずっと楽になると思います。次のことをお勧めします。

重要な変更を直接コミットしないでくださいmaster(基本的に、後で変更する可能性のあるものは何でも)。いったん変更が加えられるmasterと、決してそれに触れてはなりません。次に例を示します。

# assuming starting on master branch
git checkout -b new_cool_idea
# commit a few things
git push origin new_cool_idea
# realize there was a bug preventing you from finishing the
# implementation of new_cool_idea
git checkout -b cool_idea_bug_fix master
# commit the bug fix
# if you have any reviewers, push to remote
git push origin cool_idea_bug_fix
# when bug fix is all good, cleanup and finish new_cool_idea
git checkout master
git merge cool_idea_bug_fix
git branch -d cool_idea_bug_fix
git push origin :cool_idea_bug_fix
git checkout new_cool_idea
git rebase master
# may possibly have conflicts, go ahead and resolve
# now finish implementing new_cool_idea
# if you only want to update one remote branch add <remote> <branch>
# otherwise all remotes will be updated
git push -f <remote> <branch>

--rebaseこれにより、 onが必要になるのを防ぐことができmasterます。これは二度と起こらないはずです。あなたが使用したいと思うかもしれないより高度な技術があります。ブランチの修正に少し時間がかかるが、バグ修正をテストしながらbug_fix開発を続けたいとします。new_ideaしたがって、次のことから始めます。

o-----o-----o             master
      |      \
      |       o-----o     bug_fix
       \
        o-----o           cool_idea

したがって、私たちが望むのは、変更をcool_idea上から適用bug_fixして、それらを連携して作業できるようにすることです。これを行う方法は次のとおりです。

git checkout cool_idea
git rebase --onto bug_fix master cool_idea

次に、履歴は次のようになります。

o-----o-----o                   master
             \
              o-----o           bug_fix
                     \
                      o-----o   cool_idea

--rebaseこの方法の使用を本当に検討する場合は、またはブランチにコミットを追加する必要がある場合のクリーンアップの手順を書きますbug_fix。

于 2013-03-17T21:09:42.273 に答える