私はいつも一人でプログラムしました、私はまだ学生なので、他の誰かとプログラムしたことはありません、私は以前にバージョン管理システムさえ使用していません。
私は現在、プログラマーが会社のソフトウェアでどのように協力するかについての知識を必要とするプロジェクトに取り組んでいます。
ソフトウェアはどのようにコンパイルされますか？バージョン管理システムからですか？個々のプログラマーによるものですか？定期的ですか？誰かが何かを作ることを決心したときですか？それが「機能する」ことを確認するために行われるテストはありますか？
何でもかまいません。
回答:
実際、これらのプロセスには、多くの企業と同じくらい多くのバリエーションがあります。意味：すべての企業には他の企業とは少し異なる規則がありますが、ほとんどの場所で一般的に使用されている一般的なベストプラクティスがいくつかあります。
これらの単純なことにより、プロジェクトが制御不能になることはなく、全員が同じバージョンのコードで作業することが保証されます。継続的インテグレーションプロセスは、何かがひどく悪くなったときに役立ちます。
また、メインリポジトリにビルドされないものをコミットすることを防ぎます。
実装に数日かかり、他の人がプロジェクトをビルド（およびテスト）するのをブロックする新機能を含めたい場合は、バージョン管理のブランチ機能を使用してください。
それでも不十分な場合は、問題のプロジェクトで可能であれば、自動テストを実行するように設定することもできます。
上記のリストは、一見すると非常に重いものになる可能性があります。必要に応じてそれに従うことをお勧めします。バージョン管理とバグトラッカーから始めて、必要に応じて、後で継続的インテグレーションサーバーをセットアップします。（大規模なプロジェクトの場合は、すぐに必要になります。）最も重要な部分の単体テストの作成を開始します。それが十分でない場合は、それらをもっと書いてください。
いくつかの便利なリンク：
継続的インテグレーション、デイリービルドはあなたの友達です、バージョン管理、ユニットテスト
最近では、バージョン管理のために、個人的なプロジェクトにGitを使用する傾向があります。Subversionも人気があり、たとえば、 Windowsサーバーを使用している場合 VisualSVNは非常に簡単にセットアップできます。クライアントにとって、TortoiseSVNは多くの人に最適です。これがGitとSVNの比較です。
バグ追跡ソフトウェアの場合、JiraとBugzillaが非常に人気があります。以前の職場でもマンティスを使用しました。
継続的インテグレーションソフトウェアには、Teamcityがあります 1つに（また、CruiseControlとそれに対応する.NETが注目に値します）。
もちろん、それが主な開発者です。
企業では、主任開発者は、プロジェクトの財務/マーケティング担当者と話し合い、企業の財務能力、計画された機能、ユーザーからの要件、および利用可能な時間に応じてアーキテクチャを決定する人です。
これは複雑な作業であり、通常は複数の人が関わっています。チームのメンバーは、プロジェクト全体または特定の部分の設計について参加またはブレインストーミングするように求められることもあります。
私も学生です。最近、ソフトウェアエンジニアリングのコースを修了し、学期全体が巨大なグループプロジェクトで構成されていました。まず、学期全体で12人が行ったことを3人で行うことができたと言うことから始めましょう。人と一緒に働くのは大変なことです。コミュニケーションが鍵です。
間違いなくリポジトリを利用してください。各人はリモートですべてのコードにアクセスし、何でも追加/削除/変更できます。しかし、Subversionの最良の部分は、誰かがコードを壊した場合、以前のバージョンに戻って、そこから何が悪かったのかを評価できることです。ただし、コミュニケーションは依然として重要です。競合が発生しないように、チームメートが何をしているのかを把握してください。コードに腰を下ろさないでください。リポジトリにすばやく意味のあるコミットを行って、最も効果的にしてください。
** Redmineなどのバグトラッカーもお勧めします。すべての人にアカウントを設定し、さまざまな優先順位でタスクを割り当てたり、特定の問題に対処したかどうか、またはさらに問題が発生したかどうかを追跡して確認することもできます。
そして、前に述べたように、ユニットテストは大いに役立ちます。頑張ってください！これがお役に立てば幸いです:-)
大きなことは次のとおりです。
最後に、計画の遂行に向けて協力する意欲が必要です。それは非常にしばしば難しい部分です。
一般に、ビルドアーティファクトをリポジトリにチェックインしないことをお勧めします。リポジトリには、ソースツリー、ビルド構成など、人間が作成したものがすべて含まれます。ソフトウェアエンジニアは、コードのコピーをローカルファイルシステムにチェックアウトし、ローカルでビルドします。
ビルドプロセスの一部として実行される単体テストを用意することもお勧めします。このようにして、開発者は自分の変更によって単体テストのいずれかが無効になったかどうかを即座に知ることができ、変更をチェックインする前にそれらを修正する機会があります。
バージョン管理システム（Subversion、CVS、Gitなどのいずれか）およびビルドシステム（たとえば、JavaにはAntとMavenがあります）のドキュメントを調べることをお勧めします。
あなたが求めていることの基準はありません。むしろ、慣習があり、これらは組織の規模と成熟度に大きく依存します。小規模な組織、たとえば数人のプログラマーの場合、コーディング、ビルド、およびテストを行う個々の開発者にとっては、おそらく非公式なことになるでしょう。
大規模な組織では、専任のビルドエンジニアとプロセスが存在する場合があります。この種の組織は通常、チェックインされたソースコードを使用して、定期的に、たとえば1日に1回、正式なビルドを実行します。このプロセスには通常、BVT（ビルド検証テスト）とおそらくいくつかの回帰テストも含まれます。開発者はリポジトリからコードをチェックアウトし、ローカルで自分の部分で作業してからチェックインします。
マイクロソフトやグーグルのような最大の組織では、完全に専用のグループと完全なラボがあり、多かれ少なかれ継続的に構築され、各実行の結果が利用可能になります。これらの組織には、何がいつチェックインされるか、コードレビュープロセスが何であるかなどについて、非常に正式なプロセスと手順があります。
ソフトウェア開発を扱うためのクックブックはありませんが、あなたが唯一の開発者であるプロジェクトで作業している場合でも、一般にバージョン管理システムがビルドシステムの中心となるはずです。この場合でも、バージョンを元に戻してバージョンログを読み取ることができれば、バグを修正するのに非常に役立ちます。これはバージョン管理システムの唯一の機能ではありませんが、これだけでバージョン管理システムのインストール、構成、および保守が正当化されます。
ビルドは、新しいコードを追加するときに各開発者が実行することも、「ビルドサーバー」によって定期的に実行することもできます。最後のアプローチでは、より多くのセットアップが必要ですが、ビルドエラーをより早く見つけるのに役立ちます。
短い答え-「それは異なります」。
現在、私は自分でプロジェクトに取り組んでいるので、VCSを構築/使用するのは私です。私はあなたが震えによって一緒にプロジェクトに取り組んでいるチームを持っている他の場所を知っていますメールでます。または、VCSを使用する大規模な（+5）チーム。
その点で、私は少なくともいくつかのVCSを学ぶことを強くお勧めします、そしてJoelSpolskyは素晴らしい入門チュートリアルを持っていますMercurialのためのをます。バザール（私の個人的な選択）は似ており、Gitは類似性の点で次に近いですが、おそらくどちらよりも人気があります（少なくともATM）。その後、比較してかなり弱いSVNがあります。
実際、ジョエルはあなたの質問のほとんどについて話します-彼が持っている10年間のアーカイブを読むことをお勧めします-それはすべて非常に有用な情報であり、そのほとんどはあなたの現在および近い将来の状況に関連しています。
適切なプログラミングは、経験から大きな恩恵を受ける深いものです。ペアプログラミングは、認識の複数のプロセッサを実行するようなものです...一方が他方から見たものを見落とす可能性があり、それらが通信している限り、それは大きな進歩をもたらす可能性があります。
まず、チームはリポジトリを使用して作業します（これは、プロのバージョン管理、または「ライブ」ディレクトリと見なされる一連のディレクトリですが、リビジョン管理システムは事実上の標準です）。また、プロジェクトの管理戦略は、作業方法（ウォーターフォール、アジャイルなど）によって異なります。イテレーションで作業する場合は、自立したコンポーネント/プラグイン/モジュール/ライブラリを構築し、サインオフが完了するまで単体テストを実行します。チームとして、あなたはチームで働いています。つまり、プロジェクト全体で同時にどこでも作業するわけではありません。代わりに、プロジェクトのレルム内で実行するタスクを取得します。場合によっては、自分のものではないコードを修正する必要がありますが、それは通常、奇妙な動作が発生したときに発生します。基本的に、開発するパーツのテストを行っています。
これを例に挙げてみましょう。あなたは建設労働者のチームの中にいます。建築家は建物の計画を持って来ます、職長は建設する必要があるものを見て、それから建設業者を雇います。石工は壁を作り、強度をチェックし、うまく接着します。電気技師は建物内のすべての配線を行い、電気が流れるようにします。それぞれの人には自分の仕事があります。時々、電気技師は、特定の壁を彫ることができるかどうかを石工と話し合いたいと思うかもしれませんが、常に職長と協力しています。
これがあなたの助けになることを願っています！
これもまた、オープンソースプロジェクトを検討する必要がある理由の1つです。
大規模なオープンソースプロジェクト（Chromium、Mozilla Firefox、MySQL、Popular Gnu Softwareなど）で働く主要な開発者は専門家です。彼らは多くの経験を持っており、これらのプロジェクトは何百人ものそのような専門家からのアイデアで何年にもわたって進化してきました。
回答で言及されている他のすべて（計画、バージョン管理システム、問題追跡システム、通知システム、ビルドシステム、テストスイートなど）は、これらのオープンソースプロジェクトで見つけることができます。
本当に実践的な経験が必要な場合は、人気のある大きなオープンソースプロジェクトをいくつか実行してから、（バージョン管理を使用して）任意のプロジェクトからソースを取得して自分でビルドすることを強くお勧めします。
PS：私は学生でもあり、オープンソースプロジェクトに参加することは、これまでの人生で最高のことです。私を信じて！あなたも同じように感じるでしょう。
