問題タブ [fast-forward]

そのため、職場では新しい優れた Git ブランチ戦略を実装しています - 素晴らしい!

リポジトリの新しい (そして素晴らしい) 構造を維持するために、すべてのマージを--no-ffフラグ (および--no-commitより良いマージ コミット メッセージを可能にするフラグ) を使用して実行したいと考えています。ただ、みんなに覚えてもらうだけではちょっと頼りにならないようです。すべての開発者が前述のフラグとマージする必要があることを強制する方法はありますか?

私が知る限り、これをフックでチェックすることはできません (git は早送りに関する情報を確実に保存しないため)。各開発者マシンで構成を設定できることを知っています（を実行することによりgit config --global merge.ff no）。これが解決策である場合、すべての開発者がこの構成セットを持っていることを確認するにはどうすればよいですか?

私が行ったいくつかの作業を振り返ってみると、何が作業されているかを本当にわかりにくくする早送りコミットがあったので、そのコミットを独自のブランチに移動したいと思います。これが私の現在の状況です：

そして、移動したいコミットは C だけだとしましょう。Cにも（FFコミットから）独自のブランチがあります（branch2）。私はそれが次のようになりたい:

したがって、C は on でbranch2、C2 はマージ コミットであり、A、B、および D はすべて onmasterです。

ここにいくつかの追加情報があります：

現在、次のオプションを試しました：

最も有望なのは、フラグの最初のセットでした。競合が予想される場合でもチェックアウトを実行し、ヘッダーのように「競合のために通常のマージ ファイルを書き込みます」*_STYLE_MERGE。この文が、競合のあるファイルでは、競合するコード ブロックをラップする「<<<<<<<<<<< 彼らのもの」などのプリアンブルが存在することを意味することを期待していました。代わりに、ファイルはそのまま残ります。プリアンブルなどをファイルに書き込む方法はありますか?

libgit2 ヘッダーでは、フェッチ後、分析中に早送りが使用可能であることが通知された場合、必要なのはフェッチされたヒントの単純なチェックアウト (およびヘッド/<ブランチ> の変更) であると読みました。論理的に思えましたが、 refs/heads/<branch> を remotes/<remote>/<branch> とどのように区別できるのでしょうか? コミットには親が埋め込まれています。これは単一の履歴を構成しますが、2 つの履歴が必要で、両方に追加の「マージ」コミットがあります。では、早送りはどのように実装されますか? 実際には両方の履歴でSHAハッシュが繰り返されることにつながるため、libgit2にはその意味があるようです。

機能ブランチ「my-feature」があるとします。私が機能を開発している間に、誰かがそれを「my-feature」から「master」にマージしました。早送りマージだったため、コミットは行われませんでした。私が行った変更のいくつかはまだマスターの準備ができておらず、マスターにプッシュされたときにかなりの数のテストに失敗しました。ただし、これらの変更は明らかに私によって行われたため、早送りマージを行った人ではなく、私が非難されました (それが誰であったとしても)。

早送りマージであったとしても、「my-feature」を「master」にマージした人を見つける機会はありますか? 今後このようなことが起こらないようにするにはどうすればよいですか?

git reflog は明らかに、ローカルで何が起こっているかだけを示しています。gitlab サーバーを使用していますが、gitlab のリポジトリの reflog を検査する方法が見つかりません。何か案は？

(簡単にするために) Git リポジトリにmasterブランチと aがあります。devブランチが常に機能していることを確認したいmasterので、すべての作業はdevブランチで行う必要があります。

ただし、マージで変更をマージすると、ブランチ--no-ffにとどまり、ブランチで作業を続ける傾向がありますmaster(ブランチをチェックアウトするのを忘れるためdev)。

masterコミットや早送りマージはできず--no-ff、別のブランチからのマージのみを行うというルールをブランチに設定できますか?

これは、プライベートにホストされたリポジトリで機能する必要があります (つまり、GitHub や Bitbucket ではありません)。