責任学生であるPetyaは、たとえば、「Parallel Programming」という分野でリポジトリを作成します。このブランチでは、 masterブランチでの最初のコミットで、必要なすべての最小限の準備済みプロジェクトを利用できます。
次に、Petyaはウィキを作成し、そこでグループ全体のジョブオプションをアップロードします。
この後、Peteはクラスメートを協力者に追加して、協力者がプルなしでコミットできるようにする必要があります （プルリクエスト）。
その後、楽しみが始まります-開発！ 各学生は、 git branchを使用してリポジトリに独自のブランチ（オプション番号に対応する名前）を作成します。そこで、sshキーを生成し、githubのアカウント設定に追加する必要がある事前認証デバイスから安全にコミットします。
ピッチごとにコードの修正を送信し、エラーがどこにあるのかを説明してくれる友人の助けが必要になった頻度はどれくらいですか？ あなたは自分でどのくらいの頻度で「ただ見るだけ」のコードを要求しますか？ 現在、開発はより簡単で、より面白く、より速くなっています。
結果は何ですか？
表示と構文の強調表示のための快適で便利なインターフェイスを備えた、すべてのラボ/コースワークオプションのコードを格納するための集中管理された便利な場所。 1つの大規模プロジェクトでの実際の共同作業の可能性-たとえば、学期論文は、開発を数倍スピードアップします。
主な利点：
- 将来的に役立つチームワークの経験。
- ソースコードをフラッシュドライブに装着する必要はありません（フロッピーディスクにしばらく着用していました）。 すべての大学にはすでにインターネットがありますか？;
- コードの変更を確認する機会が常にあり（「bliiin、フラッシュドライブに間違ったバージョンのプログラムをキャプチャした」という状況を回避します）、および/または目的のリビジョンにロールバックします（「昨日はうまくいきました！」）;
- コードの品質の改善-クラスメートはバグを見つけ、チケットを切ってここで議論します。
短所：
- 誰もがgit / svn / hgなどを学ぶ必要があります。
- 悪意のある利己的なクラスメートがリポジトリを使用する準備をしてください。
そして、これに作業をチェックする（そして誰もがコードを交換していることを誰もが知っている）機知に富んだ教師を追加すると、GitHubでソースを直接見ることになります... またはすでに持っています。
アイデアが古く、どこでも長い間使用されている場合、良いアイデアは常に遅れるので、腐ったトマトを投げないでください。
誰もが開発を楽しんでいます！