これは Nuance Healthcare の Matt Shelton からのゲスト投稿です。この投稿は、Subversion から Git に移行した彼のチームの話をまとめたシリーズの第 1 回目で、移行した理由や移行の過程で経験した事柄が語られています。Matt は Atlassian Summit 2015 でも、このテーマについて話をしています。このシリーズでは彼の持ち時間の 30 分では話せなかったすべてのみならず、その時の話とは違った側面についても取り上げます。
Maven の依存関係を Git への切り替え時に解決する
そう、Git への移行を進めている私たちが夢中になっているのが git-flow です。ここまで来たら、何もかもテストしてみましょう! 何といっても自慢のチームです。彼らは Confluence にある開発ワークフローのヒット リスト、つまりこれまでのチームの開発をもとにしたすべてのワークフローと、将来取り組む必要が生じる可能性があると考える悩ましいワークフローのすべてをかき集めました。そして、私たちのプロジェクトをミラーリングしたプロジェクト構成 (もちろんコードは一切なし、pom.xml 一本) によって、すべてのワークフローを試してみました。
トリガーを引く: SVN から Git に移行する
私たちは Git への移行を進めており、効率的な開発ワークフローの中で git-flow と Maven を併用する方法を考案しました。私たちの今のワークフローがどのようなものかをお話しする前に、以前はどんな状況であったかを知っておくことが重要です。
Git の 10 年間
10 年前のある日曜日、Linus Torvalds は新しい分散型バージョン管理システムのコードを書き始めて、そのわずか数日後には世界は Git という贈り物を手にすることになりました。
Git guilt に表れる責任とコードレビューの重要性
最近、私は Git を正しく理解する ツアーの第 2 レグの旅に少し出かけていました。このツアーは世界中から大勢の開発者が集まる、とても楽しい集会でした。ツアーの第 1 レグを行ってからの数ヶ月の間に、Git が参加者の間でどれほど多く採用されたを知って、実に信じられない思いでした。7 月に出席した際に「Git を使っている人」と尋ねると、参加者のほとんど全員が手を挙げました。
Git: サーバー サイド フックによる自動マージ (これで決まり!)
エンタープライズ DVCS ワークフローは定着しつつあり、パターンが統合されてきています。Git によって各チームは非常に柔軟に作業できるため、1 つの企業内でもチームによって異なった方法でコードを共有してコラボレーションしている場合があります。
Git フォークとアップストリーム: 仕組みと役に立つヒント
upstream のリポジトリに対して fork を常に更新した状態に保つ方法を書いた便利なガイドなら山ほどあり、探せばもっと多く見つかります (エンタープライズ環境で fork を使う理由とは何だろうと考えている場合は、こちらでその理由のいくつかをご確認ください)。このブログでは、フォークと upstream を相互に結びつける方法について、いくつかの側面から紹介します。基本、了解事項、役に立つヒントなどです。そこでまず、これはいいなと感じたり知りたくなったりするようなことを取り上げます。採用するかはあなた次第です。興味を持っていただけましたか? 続けてお読みください。
コア コンセプト、ワークフロー、ヒント
Git 開発では、サブモジュールによって他のプロジェクトを自分のコードベースに取り込んで、その履歴は切り離したまま自分のプロジェクトの履歴と同期できるようになります。これはベンダー ライブラリや依存関係の問題を解決する便利な方法です。git に関してはいつもそうですが、このアプローチもかなりクセがあるためうまく使えるようになるには少しばかりの学習が必要です。サブモジュールに関する役に立つ詳細な説明は既に公開されているので、ここで繰り返すのは控えます。この記事では、この機能を最大限に活用するのに役立つ面白い情報をいくつか共有したいと思います。
Git チームのワークフロー: マージかリベースか
質問は簡単です。git とフィーチャー ブランチを利用しているソフトウェア チームにとって、完了済みの作業を開発のメインラインに取り込む最も優れた方法は何でしょうか。これはそれぞれ強い主張を持つ両陣営が何度も繰り返している議論の一つですが、落ち着いた話し合いが時として難しくなる場合があるものです (激しい議論が交わされた他の例については、インターネットをご覧ください)。
Git による巨大なリポジトリの対応方法
コードベースの発展過程を記録して開発者間の協同作業を効率化する際は、git こそ真打です。しかし、記録対象のリポジトリがとてつもなく巨大なものになった際に、いったい何が起こるのでしょうか?
Git Submodule の代替: Git Subtree
インターネットは Git サブモジュールを使うべきではないという記事で溢れ返っています。私の評価はそれほど厳しくないものの、概ね同意見です。前回の投稿で説明したように、若干の事例でサブモジュールが役立つ場合があるものの、欠点はいくつもあります。
git の拡張
Mercurial は (内面ではあるものの) 明確に定義された API を備えていて、Mercurial の機能を拡張する拡張機能を書くのに使用できますが、git の拡張モデルは小さくシンプルなプログラムを書くという UNIX 哲学に従いつつ同様の効果を達成しています。つまり、git の "拡張機能" はいくつかの簡単なルールに従って任意の言語によって作成できて、しかも git に内蔵されているかのようなコマンドを追加できるのです。
プルリクエストに習熟する: さまざまなフェッチ機能の紹介
最近では、プロジェクトの修正はフォークの作成と同じくらい簡単になりました。プロジェクトを完全にリモート コピーして、一瞬で作業用のフォークを作成できるように、変更するファイルを選択して編集を押し、修正をコミットすれば、プロジェクトを修正できます。
git とプロジェクトの依存関係
次の質問を考えてみてください。プロジェクトの依存関係を git でどう処理していますか。私たちのプロジェクトは互いに依存関係にある複数のリポジトリから構成されています。今はそうしたリポジトリを svn:externals で管理しています。これを git で処理する最適の方法は何でしょうか。git によって非常に大きなリポジトリを小さなコンポーネントに分割するにはどうすればよいでしょうか。これは最近行った Git を正しく理解する ツアーのヨーロッパ レグで、最もよく出された質問を例としていくつかあげたものです。
Git のワークフローでシンプルに
数多くのチームが既に git に移行しているだけでなく、さらに多くのチームが現在移行中です。個々の開発者を訓練して git の採用をサポートする優秀な人材を任命するだけでなく、物事が複雑になりすぎないように適切で簡単なコード コラボレーション手法を選ぶことが欠かせません。Git の場合は、非常に複雑なワークフローをあっという間に作り出すことが実際に可能です。私はそうしたワークフローをじかに見てきました。
最強の鎧: さまざまな障害からの復旧
高度なツールである git の哲学は、私が大切にしている考え方でもあります。それは開発者を賢明で責任感のある人として扱うことで、つまり git は多くのパワーを人に授けます。同時に、このパワーは災いの元凶にもなります。皆様はおそらく最強の鎧を身に付けているでしょうが、それでも自らを傷つけることがあります。
マージを信頼してブランチの簡素化をよく考えよう
製品界で注目を集める Jens Schumacher と Ken Olofsen が登場したアトラシアンの最近のウェビナーでは、git のワークフローに関するすばらしい概要が説明されました。ブランチング ワークフローは、最小限の簡単なものから、複雑なもの、強固なもの、防御重視なものまで、さまざまなタイプがあります。自分の組織に必要な複雑さとセーフガードのレベルはどの程度でしょうか? この投稿では、迅速性と堅牢性の間の妥協点について取り上げたうえで、併せて Git の活用の仕方を選択するためのガイドラインとアトラシアン内で習得した知識を紹介します。
チームが Git を使っていなくても Git を使う: git-svn を活用するコツ
アトラシアンに入社する前に取り組んでいたさまざまなプロジェクトでは、まだ Subversion (SVN) をバージョン管理システムとして使用していました。私は何年も前に Git に移行したので、できるだけ Git を使い続けたいと思っていました。
新しい Git 1.8.2 リリースについて知っておくべきこと
お気に入りのツールのリリース ノートの中に隠された (またはちらっと見えている) 宝物を探し回ること、それが私の喜びです。毎回ちょっとしたクリスマスみたいなものです。私の忠実な OSX オープン ソース ウィンドウ マネージャーの Slate や、Rails、Django、CoffeeScript、そしてもちろん Git など、その他のいろいろなアプリケーションの新しいバージョンがリリースされる際は、あの期待と好奇心でいっぱいの素晴らしい気持ちになるものです。
新しい Git 1.8.3 について知っておくべきこと
git をコマンド ラインで使っているにしても SourceTree のようなよく使われるツールを使用しているにしても、またコードを Bitbucket Cloud でホスティングしているのであっても、会社のファイアウォールの内側で Stash (現在の名称は Bitbucket Server) でホスティングしているのであっても、私のようなタイプの方々は、git の新しいリリースが発表されたときはいつだってお祭り騒ぎです。wink
Git 1.8.5 の新機能
重要なアップデートがいくつか予定されている git の次のメジャー リリースを待っている間に、最新のポイント リリース (マイナー アップデート) のリリース ノートを見てみましょう。そうです、1.8.5 が発表されました!
Git 1.9 の新機能
DayZ のポイント増加マラソンに夢中で手一杯なことはわかっていますが、私の話にお付き合いください。一聴に値するお話を用意しました。そう、最新の git のポイント リリース (1.9) が発表されました!
