プロジェクトの2人とのワークフロー

私は自分のプロジェクトに取り組んでいる初心者プログラマーとしてあなたに来ます（これは順調に進んでいます）。私の共同創立者はプログラミングの方法も学んでおり、おそらくいくつかの問題を修正し、何らかの問題を起こせるようになりました。

彼は非常に良い質問をしました。それは「この仕事はどうするのか」でした。私は他の誰かとプログラムしたことがないので、私が理論化するだけの何か。最適なワークフローを教えてください。gitを使用します。

システムの特定の部分を所有する必要がありますか？コードをチェックインしていますか？コードレビュー？

> 1開発者とどのように連携しますか？

私はgitを使用しているチームで働いており、40人以上の開発者が任意の時点で複数のコードリポジトリ（100以上）に取り組んでいます。また、非常に少ない開発者で始め、数年の間にチームの規模を拡大しました。ただし、最初は少数の人々で、最低限のgitのみを知っていれば逃げることができます。時間が経つにつれてgit fuが改善され、強力な機能が発見されます。

1. コードをホストする場所が必要になります。githubまたはgitoriousの使用を検討してください。どちらも無料で使用できますが、リポジトリは公開され、他の人に公開されます。プライベートリポジトリが必要な場合は、無料でgithubでホストするか、独自のサーバーをインストールしてホストできます。
2. 最初は、フォーク、プルリクエストを含む高度なワークフローを心配しない方がよいでしょう。gitを集中的に使用して開始できます（震え！）。ホストされたコピーをソースコードの信頼できるコピーとして扱います。このリポジトリを呼び出しましょうupstream。
3. そのうちの1人は、すべてのコードをローカルgitリポジトリにコミットし、このupstreamリポジトリにプッシュします。
4. 他のチームメンバーは、このリポジトリを複製できます。
5. あなたが学ぶ必要があります最小コマンドのセットがありclone、pull、push、add、commit、log、status、diff、branch、stash、apply、reset、format-patch、branch。それらの詳細については、gittutorialをご覧ください。
6. どちらでも、コードのどの部分でも作業できます。両方が同じファイルを編集するときに何が起こるか心配しないでください。Gitはマージの処理と競合の修正に非常に優れています。
7. 小さなアトミックコミットを行い、適切なログメッセージを書き込みます。コミットログには現在形を使用します。他の人の作業に影響を与えないため、ローカルコピーに好きなだけコミットできます。
8. コードを他の人と共有する準備ができたら、upstreamリポジトリに公開します。プッシュする前に常にプルすることをお勧めします。このようにして、リポジトリを他の変更と同期させます。
9. 手順7とを繰り返します8。

このワークフローに慣れたら、トピックブランチ、分岐、プルリクエスト、マージ、対話型のコミットのリベースなど、より高度なものに進むことができます。

コードレビューが本当に必要な場合は、gitとメールだけで実行できます。チームの規模が10+を超えて大きくなった場合、これは何らかのオンラインツールで改善されるのが理想的です。そのため、実際にはこれを行うための多くの方法がありますが、これは簡単な方法の1つです。

1. でレビューするコミットのセットを作成しますgit format-patch。これにより、パッチファイルのセットが生成されます。これらのパッチをレビュー担当者にメールで送信します。
2. レビュー担当者は、を使用してパッチを適用できますgit apply。これによりパッチが適用されますが、コミットは作成されません。
3. コードを確認し、提案をメールで送ります。
4. 満足できるまで1-2-3を繰り返します。
5. レビューアーは、パッチをプッシュできることを確認しますupstream。

これにはgithubとそのすべての機能を使用します。http://www.github.com/で確認してください。 ブランチ、フォーク、問題、プルリクエストを使用して、パートナーと連携できます。

最初に行うことは、2つのプロジェクト間で変更をマージして同期を維持できるように、中央のコードリポジトリを調べることです。SVNは、私が過去に使用した良い簡単なものであり、かなり成熟しており、かなり成熟した SVNです。

その後、私はあなたの二人の間であなたのどちらかが演じる役割を特定します。

1. コードの機能を同時に作成するのですか、それとも1人がバグ修正を行い、もう1人が機能を継続するのですか。
2. 基本的なコーディング標準のセット、つまりブレースの位置、プライベートメンバー変数の命名、変数とメソッドの命名規則（CamelCaseなど）を作成しますか
3. どのくらいの頻度でチェックインする必要がありますか。他の人が特に早い段階で何をしているかを確認できるように、少なくとも1日1回はお勧めします。チェックインの前に常にコードがビルド可能であることを確認してください。
4. 彼は上司ですが、あなたはプログラミングのリーダーになりますか？

幸運を！