問題タブ [git-workflow]

私たちのプロジェクトは 4 つの異なる Git プロジェクト (階層) に分割されており、リーフプロジェクトは顧客の部分です。

新しいバージョンをリリースするために、(SourceTree) と GitFlow-Feature を使用しています。そのため、最新の dev ブランチから新しいブランチが作成され、リリースが完了すると、dev にマージされ、master-branch に移入されます。

開発を容易にするために、すべてのプロジェクトで固定バージョン ( xyzではなく「dev」 ) を使用していましたが、開発ブランチで作業し、ブランチをリリース ブランチに追加するたびに実際のバージョンを設定していました。

そのため、pom ファイルを dev-branch にマージすることは避けたいと考えています。(pom で定義されたバージョンはdevに固執する必要がありますが、他のすべての (最終的な) 変更は dev にマージする必要があります。)

車輪を再発明せずにこれを達成する方法はありますか?

したがって、リリースが完了すると：

• すべての変更をマスター ブランチに入力する
• pomファイルを除いて、変更を開発ブランチにマージしますか?

私はマスターから離れたブランチ（他の人たちと一緒に）に取り組んでいます。

後で競合を最小限に抑えるために、定期的に master をブランチにマージします。

最終的には、再びマージする必要があります。

マスターにマージできる最もクリーンな方法は何ですか?

1. 個々のコミットを保持したい (つまり、スカッシュなし)
2. もう使用branch-aしないため、コミットのハッシュは変更される可能性があります。
3. 可能であれば、競合のないマージのマージ コミット(例: H)を含めないようにしたいと思います。L

理想的には、次のようになります (競合がないと仮定します)。

これをどのように行うべきかについてのアイデアはありますか？

（参考までに、これは私のワークフローに関する質問です。もっと前に何か他のことをするべきだったのであれば、それも正当な答えです。）

アップデート：

これについてもう少し考えた後、これはしばしば不可能であることに気付きました。

たとえば、J変更された行をG変更した場合、その履歴を取得する方法はありません。

次の最良の選択は、この履歴を持つことです。

基本的に、これはリベースですが、不要なマージ コミットを省略しています。

私は git を初めて使用する開発者と仕事をしています。この開発者が行ったコミットを監査する (そしておそらく拒否する) ことができるようにする git ワークフローをセットアップしたいと考えています。新規ユーザー向け）。

シナリオは次のとおりです。

• masterブランチには監査済みコードのみが含まれています
• develブランチは forkmasterブランチによって作成されます
• 開発者がdevelブランチで作業しており、私が監査するために彼のコードをプッシュしています
• 私は彼のコードにいくつかの問題を見つけたので、develブランチでさらにコミットして問題を修正するように彼に依頼しました
• コードに満足したら、masterブランチで開発者がコミットするチェリーピック (またはスカッシュとマージ) し、独自のコメントを追加して、開発者によって作成されたものとしてコミットをマークします。
• master開発者はブランチを自分のdevelブランチにマージします

このシナリオの視覚的な図を次に示します。

このシーケンスの後、開発者が他のコミットの後にブランチを再度プッシュするときに、「ミス/やり直し」シーケンス中に開発者が犯したミスが再び表示されないことを100％確実にするにはどうすればよいですか?devel

devel最善の解決策は、開発者に自分のブランチをそのブランチに合わせてリベースするよう依頼することmasterですが、これは新しい git ユーザーにとって難しい作業です。

このワークフローが何らかの形で間違っている場合は、コミットをマスター ブランチにマージする前に監査できる別の方法を提案してください。

編集

友人が有望そうな方向性を提案してくれました: コミットするときの--fixup オプションです。

--fixup=<commit>

で使用するコミット メッセージを作成しrebase --autosquashます。コミット メッセージは、指定されたコミットの件名に "fixup!" というプレフィックスが付いたものになります。詳細については、 git-rebaseを参照してください。

このオプションは、開発者が 2 回目と 3 回目のコミットを最初のコミットの修正として適切にマークするために使用できます。探索するための良い解決策...

私たちのチームは、GIT を使用して分岐ワークフローを実装しました。

• 中央リポジトリ（マスター）があります
• 開発者の 1 人にプロジェクト管理者の役割が割り当てられている
• 別の開発者がメイン リポジトリ (フォーク) をフォークし、ローカルの変更をフォークにプッシュします。プロジェクト管理者は、開発者による開発者 (フォークされた) リポジトリへのすべてのコミットを確認します。
• 変更ごとにブランチが作成されます。
• コード レビュー担当者は、マスターにプッシュされたすべてのコミットをレビューします。

合意されたレベルのコード品質が提供されていることを確認し、他の開発者からの統合をテストすることは、プロジェクト管理者の責任です。そのため、開発者とプロジェクトのメンテナーは、変更を master にプッシュすることに同意する前に、コミットを数回繰り返すことがあります。

さらに、プロジェクトのメンテナは、マスターにプッシュする前に開発者のコ​​ードをローカルで変更する場合があります。

現在、開発者のコ​​ミットはすべて master に送信されています。ただし、必要なのは、開発者によるコミットがマスターに表示されず、メンテナーによって (いわば) 単一のコミットにまとめられることです。

gitを使用してこれをどのように達成できますか。したがって、上の図では、マスター レビュー担当者は qa_branch1 のコミット 1 のみを表示する必要があります。

GITを数週間使用してみました。そして、Git を使ったいくつかのワークフローを理解しようとしています。次に、権限管理用の Gitlab サーバーをセットアップします。GitLab サービスを見回した後、gitlab が埋め込みボタンによる fork ワークフローをサポートしていることに気付きました。ブランチを保護する機能もサポートします。

「保護されたブランチ」機能を使用してフォークボタンを置き換えることができると思いますが、そうですか、それとも理解できない概念がありますか?

私がそう考える理由： fork-workflow ではメンテナーだけが公式リポジトリにプッシュできるので、協力者は公式リポジトリをアップストリームリポジトリとしてフォークし、アップストリームをローカルの作業コピーにクローンし、ローカルでフィーチャーブランチを完成させた後、プッシュします私たちのアップストリームはメンテナーにプルリクエストを行いますが、公式レポでフォークレポを取得したい場合は、公式レポをプルしてアップストリームにプッシュします。その....私は知りません...少し非自動すぎて、チームで働くのが好きではありません.

ただし、保護されたブランチを使用し、アップストリームにフォークはなく、協力者は公式にプッシュする許可を持っていますが、保護された安定したブランチをプッシュできるのはメンテナーのみであり、フォークリポジトリを手動で同期する必要はありません。メンテナーは、cooperators の新機能を取得するために多くのリモートを追加する必要はありません。

これは便利なバージョンの fork-workflow ですか? フォークボタンを完全に交換できますか？

典型的な Git ワークフローは、(作業ツリー内のファイルを変更) -> (インデックスを で変更git add/rm/etc) -> (実行git commit) の 3 ステップのプロセスであることを理解しています。

しかし、なぜ Git は作業ツリーをステージング領域として扱わないのでしょうか? たとえば、ファイルを変更すると、特にステージングしないように git に指示しない限り、コミットのために自動的に「ステージング」されます。これは、「オプトイン」ではなく「オプトアウト」のアプローチです。作業ツリー内のファイルの 99% がコミットされるため、これは理にかなっています。また、後でスタッシュするgit stashのではなく、作業ツリーから一時的なブランチを作成するだけで済むため、メカニズム全体が冗長になります。saveapply

作業ツリーとインデックスを分離する正当な理由がある場合は、それを聞いてみたいです... おそらく、まだ Git について十分に理解していないという事実から、私の混乱が生じているのでしょう。