Clever Geek Handbook

リベースフロー GitHub、GitLab、BitBucketでの調理方法とそのサポート

ちょっとした歴史



2010年の初めに、 Vincent Driessenは、 Git分岐モデルの成功に関する優れた記事を書きました。 後で説明する内容を理解するには、もちろんこの記事に精通する必要があります。 元の記事の言語が複雑な人のために、Habréはその優れた翻訳を備えています。







この瞬間から、説明されているGitFlow分岐モデルは、彼らが言うように、世界中に分散し始めます。 多くのチームで採用されています。 著者は、その成功した使用に関する多くの記事を書きます。 開発者が使用するほとんどのツールでサポートされます。









Git







モデルは完璧なようです。 おそらくこれは、小規模なチーム、リリースの変更されていない範囲、およびVCSを使用する高い文化がある場合に当てはまります。 そして、実際、 GitFlowはすべてのニーズを満たします。 ただし、残念ながら、説明されている条件はすべてのプロジェクトに適しているわけではなく、すべてのチームに適しているわけではありません。 ちなみに、著者がこのモデルの問題を説明した記事を見つけることは、2016年であってもそれほど簡単ではありません。 しかし、誰もが知っているように、 特効薬はありません 。したがって、このモデルでは、すべてがすべての人に適しているわけではありません。







従来のgitflowの何が問題になっていますか？



ストーリーは、古典的なGitFlowには多数のマージコミットが含まれるという事実から始まります。 そして、問題はマージコミット自体（後で見るように、まだ履歴に存在する）にあるのではなく、膨大な数にあります。 「 マージとリベース 」のトピックに関する議論は、インターネットでよく見られます（検索エンジンが教えてくれます）。 ところで、アトラシアンは、これら2つのアプローチの違いを説明する良い記事を持っています。 それで、取引は何ですか？







  1. コミット履歴はひどいです。 下の写真は、チームの1日だけです。



    Gitフローの履歴



    はい、 git log --first-parent



    およびツリーをフィルタリングする他のオプションがありますが、これは履歴の完全な分析にはあまり役立ちません。 開発チームが、従来のGitFlowに加えて、 Gitリポジトリの保守に関する他の契約を結んでいない場合、このストーリーでは、「 修正 」、「 リファクタリング 」、 「」などのまったく意味のないメッセージでコミットのバンドル全体を観察できます これにより、コミット履歴は、ほとんど表面的な分析でも事実上不適切になります。







  2. リリース範囲が変更された場合（そして、これはAgileでは珍しくありません）、古典的なGitFlowがあなたに合う可能性は低いです。 ワークフローにテンプレート「 顧客が緊急に[\ w] *のアセンブリを必要とする 」に該当するフレーズが含まれている場合、前の段落で明らかにされたコミットの履歴とともに、あなたの人生は地獄に変わります。 私は冗談ではありません。







  3. コミットをマージすると、 git bisect



    使用が難しくなります


何がいい？



コミットの履歴がクリーンであることが非常に重要である理由を説明することは非常に困難です。 経験豊富な開発者は、ソースコードをクリーンにする必要がある理由を説明する必要はありません。彼らにとって、このステートメントは公理です。 私の意見では、ここでの類推は絶対に簡単です。 クリーンなコードのすべての行と同様に、ストーリーの各コミットはその場所にあり、サードパーティの開発者でさえも理解できるものでなければなりません。 はい、ダーティコードも機能する可能性がありますが、それを使用することはどれほど便利ですか？ 新しい従業員はどれくらい早くそれを見つけ出しますか？ コミット履歴についても同じです。 汚い話でさえ、プロジェクトのすべての変更について完全に知っていますが、それを扱うのは便利でしょうか？







Gitリポジトリを使用するには、シンプルで便利で理解しやすいものでしたが、私の意見では2つだけが必要です。









両方のプロパティが満たされると、コミットツリーは次のようになります。







フロー履歴のリベース







これを達成する方法は？



従来のGitFlowを編集する必要はまったくありません。 同時に、 開発 、 マスター 、 リリース 、および修正プログラムのブランチの操作は、従来のGitFlowとまったく同じままです 。 編集は、 機能ブランチでのみ機能します 。







  1. 機能ブランチを最後の機能に注入する前に、 git rebase -i develop



    コマンドでインタラクティブなリベースを実行し、ブランチ内のすべての中間コミットを1つにマージgit rebase -i develop



    必要があります。 機能ブランチにコミットの履歴を残すことが理にかなっている場合もありますが、これらのケースは実際には非常にまれです。 適切なタスク分解により、各小さなタスクは、1つのコミットに完全に適合するシステム内のアトミックで論理的に完全な変更です。 タスクのフレームワーク内のすべての変更を最後の瞬間に1つのコミットにまとめることができることを考慮すると、開発者はタスクの作業中に、潜在的なロールバックに必要な多くの中間コミットを自由に作成できます。 さて、 リベース操作を頻繁に実行する開発者を支援する素晴らしいrerereコマンドがあることを付け加えておくと良いでしょう。







  2. 機能ブランチをリモートリポジトリにアップロードするには、前の段落でリベースブランチを実行したため、 git push --force



    使用します。







  3. 機能ブランチを最終機能にマージするには、 git merge --ff-only feature



    コマンドを使用します。この場合のみ、コミット履歴の線形性を維持し、 マージコミットの出現を回避できるためです。


ご覧のとおり、リポジトリの操作に多くの変更はありません。 記事のこの部分の一部を要約すると、優れた記事へのリンクを共有したいと思います。また、古典的なGitFlowとRebase Flowの長所と短所についても説明します。







リポジトリマネージャーでのリベースフローのサポート



記事の冒頭で述べたように、古典的なGitFlowのサポートは、さまざまなリポジトリマネージャーを含む多くのツールで行われます。 したがって、一般的なリポジトリマネージャーでのRebase Flowサポートの状況についてさらに詳しく説明します。 同時に、私の評価は通常の大学マークの形式になります。







Github



リベースフローのサポート： GOOD







実際、GitHubには必要なものがほぼすべて揃っています。 リポジトリ設定には、「スカッシュマージを許可する」チェックマークがあります。







Githubsettings







マージプルリクエストを許可し、適切なアイテムを選択して、コミットに対する最終メッセージを編集します







Githubmerger







その結果、 プルリクエストは線形に制御され、すべてのコミットは1つにまとめられます。







GitHub側で見られる唯一のマイナスは







  1. コミットをマージせずにプル要求を含めることができない。 非常にまれですが、それがまだ必要であり、GitHubの場合、このマージは手動で行う必要があります。


上記のすべてはGitHub Enterpriseに適用され、企業のサーバーにデプロイできます。







Bitbucket



リベース フローのサポート： UNSATISFACTORY







しかし、実際にはそうではありません。 作業でRebase Flowを使用する場合、BitBucketはこれを支援しません。すべてを自分で行う必要があります。







そして、これは驚くべきことです。この記事の本文で、アトラシアンのWebサイトの優れた記事を繰り返し参照していることを考えます。 特にこのタスクが長い間確立されているため、 Rebase Flowをサポートする状況が将来変わることを期待しましょう









Atlassian有料製品のRebase Flowサポートの内容を見てみましょう。







Atlassian BitBucket Server （別名Atlassian Stash）



リベースフローのサポート： SATISFY







BitBucket v4.5.2を検討していますが、将来のバージョンでは状況が改善される可能性があります。 現在サポートされているBitBucket Serverは、クラウドの兄弟よりもわずかに優れています。 管理者にアクセスできる場合は、 bitbucket.properties



ファイルで親切に依頼して、プロジェクト/リポジトリのプルリクエストリクエストマージ設定bitbucket.properties



変更することができます（ ドキュメント ）









設定値は次のとおりです。









ご覧のとおり、設定は非常に柔軟ですが、2つの問題があります







  1. Webベースの設定インターフェイスはなく、管理者への呼び出しはワークフローを大幅に複雑にします。
  2. 特定のプルリクエストの動作を選択することはできません。最小のカスタムエンティティはリポジトリです。


これらの2つの問題が修正されると、 BitBucketのRebase Flowサポートは優れたものになります。 それまでの間...







Gitlab



リベースフローのサポート： GOOD







https://gitlab.comでサポートを評価することで、 GitLab EE製品のサポートを基本的に評価し、それに基づいて実装します。 GitLab CEでのRebase Flowのサポートに関しては、単にそこにありません。







Rebase Flowのサポートがどのように構成されているかを理解するには、プロジェクトの設定を見てください







GitLabProjectSettings







ご覧のように、 マージコミットが残っている場合、セミリニアストーリーの中間バージョンもありますが、 プルリクエストを受け入れる機会は、 機能ブランチが線形継続である場合にのみ表示されます。 準線形履歴または「早送りマージ」のこのオプションが選択されている場合、 プルリクエストを制御する追加の機会があります。 つまり、「…にリベース」ボタンが表示され、 機能ブランチからストーリーを直線的に継続できます。







GitLabProjectRebase







その後、 プルリクエストを簡単に受け入れることができます。 プルリクエストは、個別のマージコミットを作成せずに取得されます。







GitLabProjectAccept







この機能の詳細な説明は、ドキュメント（ one 、 two ）にあります。 それのスクリーンショットは少し時代遅れであるという事実にもかかわらず、その関連性を失っていません。 これで、原則として、 リベースフローのサポートは終了します。 彼女はまったくプラスであるという事実はもちろんプラスですが、彼女は明らかに十分ではありません







  1. 特定のプルリクエストの動作を選択する可能性。 はい、 プルリクエストを受け入れる前に、プロジェクト自体の設定を変更できますが、これはあまり便利ではありません。
  2. 機能ブランチのコミットを1つに自動的にマージする可能性。


結果は何ですか？



現在、 Gitリポジトリのほとんどのマネージャーは、何らかの形でRebase Flowのサポートを実装しています。 そして、それらで働くことの利便性は、数年前よりも桁違いに高くなっています。 しかし、それでも、私の意見では、すべての製品には依然として不利な点があり、今後もそれらが修正されると信じ続けています。







More articles:


All Articles