関連するコードの複数のGitリポジトリを適切なブランチ/タグに変換する方法
バックグラウンド
私は最近、小さなR＆D /データサイエンスチームのテクニカルリード/シニア開発者になりました。私は大規模な開発チームでかなりの量の非リード経験を持っていますが、プロジェクトまたはチーム管理の正式な教育を受けていません。
チームには経験豊富なプログラマーが数人いますが、他のプログラマーはより大きなプロジェクトに取り組んだ経験があまりありません。彼らは現在、かなり型破りな方法でコードベースを管理するためにGitを使用しています。これまでのところ、人々はプロジェクトのコードベース全体を新しいリポジトリとしてコピーすることにより、事実上「分岐」しています。リポジトリにわかりやすい名前を効果的に「タグ付け」し、重大なバグが発見されない限り、タグ付けされたコードを「リリース」した後はほとんど触れません。
たとえば、arthurおよびlancelotという名前の製品を検索する方法は次のとおりです。 -）：
small_companys_code
├── arthur (this is the "basic" bleeding Edge "branch" of project "arthur")
├── arthur-Jan2015 (this is a "tag" for a stable release in Jan 2015)
├── arthur-multilang (this is a "development branch" for the new feature "multilang")
├── arthur-multilang-Mar2016 (this is a "tag" for a release in Mar 2016 with a new feature "multilang", maybe not necessarily merged into the repo "arthur")
├── arthur-fred (these are the personal changes of the former employee Fred. No one remembers exactly what changes this has)
├── lancelot (this is the "basic" bleeding Edge "branch" of project "lancelot")
├── lancelot-Feb2018 (this is a "tag" for a stable release in Feb 2018)
├── lancelot-Feb2018-spanish (this is almost exactly the same as "lancelot-Feb2018" but was quickly changed to support Spanish for demonstrating)
これは、すべてがどこにあるかを知るのに十分長く滞在した人々にとっては十分に機能します。ただし、新しい人（私自身を含む）にとって、これは非常に困難な場合があります。
ゴール
私の公式の責任の1つは「これをクリーンアップする」ことであり、そうすることで、主に各プロジェクトの常に機能するリリース可能なバージョンがあることを確認します（arthurおよびlancelot上記）。 正確なワークフローは現時点では未定です。私の直接のタスクは、コードを再編成して、リリース可能な「最新の」安定バージョンのコードが常に存在するようにして、簡単にデプロイして実行できるようにすることです。必ずしも他のバージョン用に開発されたすべての機能を備えているとは限りません（つまり、実験的または将来的に計画されている機能）：
small_companys_code
├── arthur (repo for project "arthur")
| ├── master (branch for project "arthur" including only tested features which will definitely be included in later versions of product)
| | ├── Jan2015 (release tag)
| | ├── multilang (branch for new feature)
| | | ├── Mar2016 (release tag for demo'ed version of feature "multilang")
| | ├── fred (orphaned branch to eventually be merged/removed)
├── lancelot (repo for project "lancelot")
| ├── master (branch for project "lancelot" including only tested features which will definitely be included in later versions of product)
| | ├── Feb2018 (release tag)
| | ├── spanish (branch for quickly-hacked "feature", possibly to be developed or merged but maybe just removed)
| | | ├── Feb2018 (release tag for one-off demo)
このタスクにどのようにアプローチできますか？ほとんどの場合、リポジトリは基本的にコピーされているため、Gitコミットログの検索に頼ることはできません。もちろん、変更の実際の実際の日付を確認して、さまざまなリポジトリの日付順を作成することはできますが、この情報を使用して上記のような適切なGitワークフローを作成する方法がわかりません。
これらの個々のリポジトリはオリジナルからコピーされたものであるため、コピーとオリジナルの関係を再確立できます。詳細はこちら その他の回答 を参照してください。
使用する git remote add各コピーで、オリジナルを参照します。次に、各コピーのブランチ名がコピー間で競合しないことを確認し、コピーを元のコピーに再同期し始めることができます。 Gitは、元のリポジトリでツリー構造を再確立します。これは、gitが行うことだからです。
科学チームは扱いが難しい場合があります。彼らは通常、ソフトウェアエンジニアリングのバックグラウンドをほとんどまたはまったく持っておらず、ソフトウェアは動作するときに本番環境に対応しています。
@BobDalgleishから技術的な解決策を入手したようですが、これは私には正しいと思います。しかし、あなたはより大きなメンタルモデルの問題を抱えており、ソフトウェアで働く人々を不適切な解決策に向かわせています。リポジトリ全体をコピーし、少し変更してから、Project x/y/z用にリリースすると、先見の明がありません。
おそらくより適切な解決策は、人々の働き方を調整する計画を作成することです-短期的な目標を可能な限り最速で機能させることから、プロジェクトが存在するように利用可能な機能セットを増やすという長期的な目標に変更します。カスタムコードを必要としません。本当のリリースが何であるかという考えは彼らにとって異質かもしれません、そしてあなたは主導権を握る必要があるでしょう。
彼らがうまくいかなかったことを彼らに知らせないようにしてください、そしてあなたはそれらを修正するつもりです-プロジェクトはある程度のレベルで成功しているはずです。全体像を把握し、多くの作業と構造化を行い、フレームワーク内で小規模なプロジェクトを提供できるように支援して、彼らが一歩先を行くようにしてください。