2

継続的インテグレーションにはTeamCityを使用し、ソース管理にはGitを使用します。一般的に、それはかなりうまく機能します-便利で、現代的で、テストが失敗したときの迅速なフィードバックを私たちに提供します。

Gitマージの詳細に関連する奇妙な動作があります。ケースの手順は次のとおりです。

  1. 最初の開発者はマスターリポジトリからプルします。
  2. 2番目の開発者はマスターリポジトリからプルします。
  3. 最初の開発者はローカルでコミットAを作成します。
  4. 2番目の開発者はコミットBをローカルで作成します。
  5. 2番目の開発者はコミットBをプッシュします。
  6. 最初の開発者はコミットAをプッシュしたいのですが、最初にコミットBをプルする必要があるためできません。
  7. 最初の開発者はリモートリポジトリからプルします。
  8. 最初の開発者はコミットAをプッシュし、マージブランチコミットを生成します。

マスターリポジトリでのコミットの履歴は次のとおりです。

  • B2番目の開発者
  • 最初の開発者
  • ブランチの最初の開発者をマージします。

ここで、SecondDeveloperがコミットBで失敗したテストを修正したと仮定します。

TeamCityが行うことは次のとおりです。

  1. コミットBが到着-TeamCityは、すべてのテストに合格してビルド＃1を作成します

  2. コミットAが到着-TeamCityはビルド＃2（コミットBなし）のテストバーを赤にします！

  3. TeamCityは、保留中の「Merge Branch」コミットには変更（新しいファイル）は含まれていないと考えていましたが、実際にはコミットBのマージが含まれているため、TeamCityはここで新しいビルドを作成してテストをグリーンにしたくありません。

ここに2つの問題があります：1。この場合、2番目のコミット（コミットA）に戻るテストに失敗しました。2。TeamCityは、新しいビルドを作成してテストをグリーンに戻したくありません。

誰かがこの問題の両方を修正する方法を知っていますか？

私はいくつかの合理的な一般的なアプローチを検討します。

4

2 に答える 2

1

追加するために、git pull --rebaseを使用することを強くお勧めします。または、完全にgit fetchを実行してから、git log -p ^ master origin / masterを使用して変更内容を修正し、何が起こったかを判断します。他の開発者の仕事のため。この時点で、リモートの変更に基づいて作業をリベースできます。チームシティでは、ここで見られる問題は発生しません。これは、teamcityを回避するために私が行うことではありませんが、以前のマージをマージする場合に再検討する必要のない、より直線的な履歴とマージの競合解決を可能にするワークフローの一部でもあります。

HTH、

アダム

于 2010-08-24T00:10:24.863 に答える
0

5.0.3ではまだ修正されていません。しかし、それは既知の問題として報告されています

この問題に投票するには、 http： //youtrack.jetbrains.net/issue/TW-9584をご覧ください。

于 2010-04-15T18:35:51.483 に答える