回目で、移行した理由や移行の過程で経験した事柄が語られています。このテーマについて話をしています。分では話せなかったすべてのみならず、その時の話とは違った側面についても取り上げます。何といっても自慢のチームです。リスト、つまりこれまでのチームの開発をもとにしたすべてのワークフローと、将来取り組む必要が生じる可能性があると考える悩ましいワークフローのすべてをかき集めました。よって、すべてのワークフローを試してみました。ワークフローは定着しつつあり、パターンが統合されてきています。つの企業内でもチームによって異なった方法でコードを共有してコラボレーションしている場合があります。使う理由とは何だろうと考えている場合は、こちらでその理由のいくつかをご確認ください)。そこでまず、これはいいなと感じたり知りたくなったりするようなことを取り上げます。採用するかはあなた次第です。続けてお読みください。開発では、サブモジュールによって他のプロジェクトを自分のコードベースに取り込んで、その履歴は切り離したまま自分のプロジェクトの履歴と同期できるようになります。ライブラリや依存関係の問題を解決する便利な方法です。関してはいつもそうですが、このアプローチもかなりクセがあるためうまく使えるようになるには少しばかりの学習が必要です。サブモジュールに関する役に立つ詳細な説明は既に公開されているので、ここで繰り返すのは控えます。この記事では、この機能を最大限に活用するのに役立つ面白い情報をいくつか共有したいと思います。マージかリベースか質問は簡単です。チームにとって、完了済みの作業を開発のメインラインに取り込む最も優れた方法は何でしょうか。(激しい議論が交わされた他の例については、インターネットをご覧ください)。最近では、プロジェクトの修正はフォークの作成と同じくらい簡単になりました。コピーして、一瞬で作業用のフォークを作成できるように、変更するファイルを選択して編集を押し、修正をコミットすれば、プロジェクトを修正できます。次の質問を考えてみてください。私たちのプロジェクトは互いに依存関係にある複数のリポジトリから構成されています。処理する最適の方法は何でしょうか。よって非常に大きなリポジトリを小さなコンポーネントに分割するにはどうすればよいでしょうか。レグで、最もよく出された質問を例としていくつかあげたものです。移行しているだけでなく、さらに多くのチームが現在移行中です。コラボレーション手法を選ぶことが欠かせません。場合は、非常に複雑なワークフローをあっという間に作り出すことが実際に可能です。私はそうしたワークフローをじかに見てきました。バージョン管理システムとして使用していました。使い続けたいと思っていました。下でライセンスされています。