問題タブ [bitbucket-server]

次の原則に従う新しいワークフローを設計しようとしています。

• 自動検証 (CI) に合格したコミットのみをメインラインにマージする必要があります (具体的には、マージされた状態は、統合ブランチを可能な限り初期状態に保つために CI に合格する必要があります)。
• 人間によるコード レビューに合格したコミットのみをメインラインにマージする必要があります
• 自動検証に合格したコミットのみを別の人間がレビューする必要があります (ビルドしてテストに合格しない場合でも、他の人の時間を無駄にしないでください)。
• 機能ブランチは CI でカバーする必要があります (独立して、統合ブランチにマージされません - これは開発中の開発者にとって役立ちます)

git、Stash、TeamCity を使用しています。これは私が思いついたものですが、どれも完璧ではありません。提案の微調整や新しいアイデアを探しています。

ワークフロー 1

• 開発者は機能/VHPC-1 で開発します (機能ブランチは TeamCity の通常の CI でカバーされます)
• 機能が完了すると、開発者はプル リクエストを作成します: feature/VHPC-1 --> mainline

• プル リクエストが別の開発者によって承認されると、Stash によって自動的にメインラインにマージされます (メインラインは TeamCity の通常の CI によってカバーされます)。

• 問題: マージの競合がある場合、Stash はマージを実行しませんが、メインラインへのマージが完了するまで、マージされた状態はまったくテストされません。メインラインが壊れるかどうかは、壊れるまでわかりません。

ワークフロー 2

• 開発者は機能/VHPC-1 で開発します (機能ブランチは TeamCity の通常の CI でカバーされます)
• 開発者は、feature/VHPC-1 から feature/VHPC-1/review にプッシュします (統合ブランチをリベースしてから CI (マージされた状態のテスト) を実行します)
• 機能が完了すると、開発者はプル リクエストを作成します: feature/VHPC-1/review --> mainline

• プル リクエストが別の開発者によって承認されると、Stash によって自動的にメインラインにマージされます (メインラインは TeamCity の通常の CI によってカバーされます)。

• 問題: マージされた状態がテストされてから統合が行われるまでの時間 (20 分～1 日?) により、統合ブランチが変更され、マージされた状態が機能しなくなる可能性があります。統合分岐が壊れる可能性。

• 問題: ブランチの数が 2 倍になるということは、複雑さと作業が増えることを意味します。

ワークフロー 3

• 開発者は機能/VHPC-1 で開発します (機能ブランチは TeamCity の通常の CI でカバーされます)
• 機能が完成したら、開発者はプル リクエストを作成します: feature/VHPC-1 --> feature/VHPC-1/review

• 別の開発者がプル リクエストを承認してマージすると、feature/VHPC-1/review が自動的にビルドされ、マージされた状態でテストされ、成功するとメインラインに自動マージされます

• 問題: ブランチの数が 2 倍になるということは、複雑さと作業が増えることを意味します。

• 問題: コミットは常にメインラインに統合する必要があり、ブランチをリリースするためにチェリー ピックのみを選択する必要があります。

ワークフロー 4

• 開発者は機能/VHPC-1 で開発します (機能ブランチは TeamCity の通常の CI でカバーされます)
• 機能が完了すると、開発者はプル リクエストを作成します: feature/VHPC-1 --> メインラインの TeamCity は自動的にレビュアーを追加し、マージされた状態でプル リクエストのビルドとテストを試みます (Stash の文書化されていない refs/pull を使用) -リクエスト/マージ)

• 自動検証に合格すると、TeamCity はプル リクエストを承認します。その後、人間がそれをレビュー、承認し、メインラインにマージします。

• 問題: TeamCity は、統合ブランチが変更されると変更される refs/pull-requests/merge を監視します。つまり、統合ブランチが 1 つの新しい変更を取得すると、開いているすべてのプル リクエストでビルドがトリガーされます。

最善の努力にもかかわらず、私たちは Git リポジトリのフィーチャー ブランチで非常に困難な状況に陥ってしまいました。最終結果はgit diff develop..feature-branch、完全に予期しない差分が表示されることです。

たとえば、develop で追加された 1 つのファイルは、差分では削除として表示されます。他の多くのファイルも同様の問題を示しており、欠落しているもの、追加されているもの、多くの予期しない変更が多数あります。含まれているはずの一部のファイルdevelopは、差分にも表示されません。プル リクエストを介してコードをレビューしたときに、Atlassian Stash の問題に最初に気付きました。保留中のマージは完全に正しくなく、マージ中の標準的な競合解決では解決できません。

この原因の解読を試みたところ、問題は開発者が既にオリジンにプッシュされたフィーチャー ブランチのコミットに対して数回のリセットを実行したことが原因であると考えられます。これは、プル リクエストのコード レビュー中に提案されたいくつかの変更を「元に戻す」ためのものでした。具体的には、これがイベントのタイムラインであると考えています。

1. 開発から作成された機能ブランチ
2. 機能ブランチで実行される作業
3. Atlassian Stash で生成されたプル リクエスト (PR は問題ないように見えますが、いくつかのマイナーな編集が​​提案されています)
4. 開発者はリセットを使用して一部の変更を元に戻し、それらを元にプッシュします
5. 一方、開発ブランチと機能ブランチの間でマイナーな競合が見つかりました
6. 開発者は、develop からの機能ブランチを更新して競合を調整し、オリジンにプッシュします
7. プル リクエスト (diff) は、以前のものとは大幅に異なる予期しない diff を示します。コミットされると予想されるファイルが見つからない、またはその逆
8. 「悪い」マージを元に戻して（リセットではなく元に戻して）、もう一度試してみます。ただし、PR/差分は、保留中のマージに対して同じ誤った変更を示しています
9. その後、開発者が開発からの最初のマージの前にどこかでリセットを使用したことがわかりました。

そこで、質問が 3 つあります。

1. 変更を正しく開発にマージできるように、修正された機能ブランチをどのように「回復」する必要がありますか? 私の考えは、リセット前に発生することが知られている機能ブランチのコミットから、新しい「良い」機能ブランチを作成することです。次に、必要なコミットを「悪い」機能ブランチから「良い」機能ブランチにチェリーピックして、再作成することができます。最後に、「良い」フィーチャー ブランチを開発にマージし、「悪い」フィーチャー ブランチを削除します。

2. 「悪い」機能ブランチを開発にマージすると、ファイルの状態が正しくないことを除けば、他の「破損」が開発ブランチに漏れることになります。つまり、汚染された「悪い」機能ブランチは、開発ブランチとその下流の何かをさらに汚染しますか? もちろん、これを行う予定はありませんが、その影響を理解したいと思っています。

3. 私が説明したようにリセットすると、私が見ている問題が発生しますか、それとも他の何かに関連している可能性がありますか?

Atlassian Stash を Windows 2008R2 サーバーにインストールしましたが、ほとんどの場合、すべてがうまく機能しています。ローカルのオンプレミス CA によって発行された SSL 証明書と DNS エントリがセットアップされているので、そこに行くことができhttps://stash/、非常にうまく機能しますが、Firefox では警告 (関連?) がスローされます。

Atlassian の Sourcetree を使用すると、リポジトリに移動して選択できますが、クローンを作成しようとすると、次のエラーが発生します。

致命的: アクセスできませんhttps://user@url/scm/etc/etc.git: SSL 証明書の問題: ローカル発行者証明書を取得できません

git bash からでも試してみると、同じエラーが発生します。このエラーに基づいて、SSL証明書をGitに追加するための指示に従ってみましたが、コメントの内容も含めて、ウェブサイトにもありますが、役に立ちませんでした。Firefox と MMC 証明書スナップインを使用して証明書をエクスポートしましたが、同じ結果が得られ、それを独自のファイルに入れ、curl ファイルと組み合わせて、何があってもこのエラーが発生しました。チームにとってこれを簡単にしたいと思っていたので、SSHキーで動作させることはまだ試していません。

また、 ssh myserverを使用して接続を受け入れようとし、パスワードを入力して再起動しました。それでも同じエラー。

証明書の検証も単純に無視したくありません。それは少し無意味に思えるからです。

CA発行の証明書でこれを機能させるにはどうすればよいですか?

Java クラスから STASH リポジトリにプログラムで接続しようとしています。調べてみましたが、これを行うための Java クライアントが見つかりません。誰かに出くわしたことがありますか？

STASH リポジトリに接続したい理由は、STASH の Git リポジトリに移動し、コミットのリストと特定のタグの Jira を返す Maven プラグインを作成しているためです。

どんな助けでも大歓迎です。

Stash アドオン 'Stash Webhook to Jenkins' を使用して、開発者が自分のコードを機能ブランチにプッシュしたときに Jenkins ビルドをトリガーしています。

Jenkins のビルドが失敗した場合、以前のコミットにリセットしたい。ビルドが成功した場合にのみ、プッシュが行われます。この方法または他の方法で利用できるアドオンはありますか?

アトラシアンのスラッグ生成アルゴリズムまたはその実装は公開されていますか?

ユーザーが入力したリポジトリ名に特定のスラッグがあるかどうかを確認する必要があります。

さまざまなアルゴリズムをたくさん見つけましたが、それが Stash で使用されているものであることを確認する必要があります。ここでは、スラッグ生成は BitBucket によって行われると書かれています。

最近、SVN -> Git (Stash を使用) から移行しました。移行後、一部の開発者が機能ブランチでマージを台無しにしているマージ中に問題が発生し始めました。

上の図では、developer1 がフィーチャー ブランチ feature1 を持っており、変更を行い、develop にマージしたとします。

Developer2 には、developer1 のブランチの前に作成されたブランチがありますが、それよりも長く存在する予定です。変更が完了すると、 master から自分の branch に変更を取り込み、競合を解決してからマージします。

問題は、developer2 が変更を自分のローカル ブランチにマージするときに、自分のファイルを優先してマージの競合を解決していることです。ただし、これは実際に は、彼が変更していないファイルの一部を上書きしています。プル リクエストを作成して master にマージすると、developer1 の変更が以前のバージョンに効果的にロールバックされます。ファイルは実際に以前のコミット (SHA) ID にロールバックされるため、これを実行できます。

質問は、

1. これを体系的に回避できる方法はありますか。つまり、変更 SHA ID が実際にはロールバックである master への変更を拒否するように git に依頼します。
2. マージ中に開発者が変更したファイルのみで競合が発生する方法はありますか

グーグルで調べたところ、 --rebase オプションを指定して git pull を実行するか、 master ブランチの権限を変更して早送りマージのみを許可することを提案する記事にたどり着きました。どちらのオプションも役立ちます。