GitHubで複数のプロジェクトを整理する
私はフリーランスの開発者です。私には複数のクライアントがあり、各クライアントには複数のプロジェクトがあり、各プロジェクトには複数の異なるソフトウェアがあります。最近、すべてのソース管理を古いSubversionサービスからビジネスgithubアカウントに移行しました。
私の質問は、クライアント、プロジェクト、アプリケーションを整理するための実行可能な戦略とは何ですか？私の自由に使えるツールは、私のリポジトリのGitHubのインターフェイスとディレクトリ構造です？
現在、私はアプリケーションごとに1つのリポジトリしかなく、リポジトリにClient_Project_Applicationという名前を付けています。管理できないリポジトリの巨大なリストがあるので、ちょっと醜いです。また、クライアントまたはプロジェクト全体にアクセスする権限を誰かに付与したい場合、該当するすべてのリポジトリに対して個別に行うのは面倒です。また、GitHubサイトとデスクトップアプリで特定のリポジトリをすばやく見つけることも困難です。
私ができることは、次のとおりです。
- すべてのクライアントを分離します。理想的には、クライアントのコレクション全体またはプロジェクト全体に貢献するための権限をユーザーに付与できるようにします。
- 各アプリケーションを個別に保持します。なぜなら、開発マシンでリポジトリを複製するとき、常にすべてを必要とするわけではないからです（実際の例：5 GBのデータを含むデスクトップアプリケーションとそれに関連付けられたRaspberry Piアプリケーションがある場合、取得する理由はありません。 pi devマシン上の大規模なデスクトップアプリ—時にはそれさえ不可能です）。
- 特定のクライアントとプロジェクトのリポジトリをgithub.comとgithubデスクトップで簡単に検索/参照します。つまり、最近使用された最初のすべての巨大なフラットリストではなく、関連するもの同士を近づける方法です。
- 特にgithub.comとgithubデスクトップを使用して、可能な限り視覚的にリポジトリを操作することを好みます。特に、リポジトリのクローン作成に関しては、正確なリポジトリ名を覚えるのが難しいためです。
- 通常の変更->コミット->プッシュワークフローに追加の手順を追加する必要がないことを本当に望んでいます。
このタイプの組織は通常どのように行われますか？私は現在の「戦略」の完全な変更を受け入れるつもりです。いつも組織が不十分であり、ここでいくつかの大きな変更を加える必要があります。
organizations を使用できます。これは、クライアントごとに1つの組織を意味します。
組織では、複数のリポジトリを作成し、リポジトリや組織レベルで権限を管理できます。
チームプラン は、あなたが説明するニーズにはおそらく十分であり、サービスの価格に簡単に含めることができます。
ボーナスは、クライアント全体でプロジェクト管理が必要な場合、または必要な場合に Zenhub を参照してください。これらには、クロスリポジトリ/組織ボード用のかなり優れたサポートがあります。再びクライアントにそれを支払うようにします。