Git
トランクベース開発での複雑な競合の解消の仕方
結城です。
1つ前の記事では、「トランクベース開発」のスタイルで開発する場面において、自分が中央リポジトリーにコミット権を持っているときの、競合状態の発生とその解消の流れを紹介しました。 これは、会社に所属して自社の開発プロジェクトに参加する場合や、OSS開発プロジェクトの一員として開発を行う場合によく見られる光景です。
その一方で、多くの人にとって実際に「OSS開発に関わる」場面は、プロジェクトのリポジトリーへのコミット権を持たない外部のコントリビューターとして関わる場合の方が主ではないでしょうか。
そのような状況でのトランクベース開発においては大抵、中央リポジトリから自分の管理下の場所にフォークしたリポジトリを、ローカルでの作業の成果のプッシュ先やマージリクエスト（プルリクエスト）の起点とする、という運用が必要になります。 1つ前の記事での運用と比べると、関係するリポジトリが1つ増えるため、ブランチ操作がさらに複雑になり混乱しやすいです。 この記事では前の記事の発展として、このような場面でのトランクベース開発のブランチ操作の流れを紹介します。
トランクベース開発での競合の解消の仕方
結城です。
1つ前の記事では、フリーソフトウェア・OSS開発プロジェクトで採用されていることの多いブランチ運用スタイルである「トランクベース開発」の概要を紹介しました。
どのようなブランチ運用を取っていても、チームでの開発で複数人で並行して作業していると、変更同士が競合1しがちです。 しかし、競合を解消する方法をインターネットで検索して、見つけた記事に書かれたコマンドをやたらめったらコピペ実行しても、期待した結果を得られなかったり、ともすれば作業の成果を失ってしまったりもします。 競合を解消するためには、それぞれのブランチがどのような関係にあるかを正確に把握した上で、的確に操作しなくてはなりません。
この記事では、トランクベース開発で運用されているGitリポジトリで起こりやすい競合の場面のそれぞれについて、競合を解消するための考え方と具体的な手順を解説します。
-
例えば双方が同じファイルの同じ行を変更していた場合、行単位で変更を管理するGitではどちらの変更を先に適用しても支障が生じるため、何らかの解決が必要です。また、変更した行が極めて近接している場合も、Gitは双方の変更をうまく1つにまとめられず、解決が必要になることがあります。このような状況は「衝突」や「コンフリクト」とも言い、ここでは「競合」に統一することにします。 ↩
フリーソフトウェア・OSS開発プロジェクトでよく見られるブランチ運用
結城です。
GitやGitHubといった便利なツール、Git FlowやGitHub Flowなどのブランチ運用ルールが普及したことで、今では「初めて入社した会社でGitを教わり、GitHub Flowで開発を覚えました」という方も多いのではないでしょうか。
それらのブランチ運用ルールに比べて簡素なブランチ運用として、トランクベース開発（Trunk Based Development）と呼ばれるスタイルがあります。 そのブランチ運用のあまりに簡素な様子に、GitFlowやGitHub Flowなどに親しんできた方は驚かれる場合もあるようです。
当社ではGitLab.comのclear-codeのグループやGitHubの同名グループ、あるいは個々のプロジェクトごとのグループなどで、フリーソフトウェア開発プロジェクトのリポジトリを公開しています。 また、メンバー個々人も個人で開発しているソフトウェアを同様に公開していることがあります。
この記事では、それらのリポジトリで採用していることが多い1トランクベース開発において、具体的にどのようなブランチ運用を行っているかを図を交えてご紹介します。 （特別に何か優れた運用を行っているから紹介するというわけではなく、社内向けの説明資料としての性質が強い記事です。）
-
具体例としては、GroongaやFluentd、milter managerなどが該当します。 ↩
lessの既定のオプションを変えて快適なCLI生活を手に入れる
その時表示している内容を消さずにlessを終了するには？
何かのコマンドの実行結果が長くなって画面外に溢れてしまう場合でも、grep ... | less という風にパイプライン経由でlessコマンドに結果を渡すと、結果を自由にスクロールしながら落ち着いてゆっくり読むことができます。
複数の作業環境から変更が同一ブランチにpushされるGitリポジトリについて、リモートにある内容を確実に手元に反映する
この記事では、Gitの「普通のpull」と「rebase」について、「普通のpullではなくrebaseした方が良いと言われるけれども、実際にrebaseを使ってみたら、衝突が発生した時に色々よくわからない事が起こって辛い思いをした」という人を対象として、rebaseの正しい使い方を解説します。 GitそのものやGitHubそのものの説明については省略していますのでご注意下さい。 また、GitはLinuxやmacOS（OS X）の端末エミュレータ上のシェルでコマンド列を実行して利用する形態を想定しています。
Gitで不適切なコミットメッセージを削除した公開リポジトリを作る
分散バージョン管理システムのGitには様々なサブコマンドがありますが、その中の1つである git filter-branch を使用すると、過去のコミットを完全に無かった事にしてしまうなどの強力なコミット履歴の編集が可能となります。大きなリポジトリの特定のディレクトリ以下の内容をコミット履歴付きで別の小さなリポジトリとして取り出したり、ファイルの中に書かれていた生のパスワードを履歴の中から消去したり、というのはよく紹介される例です。