小規模企業（開発者15人）が管理されたソース/バージョン管理を使用しないことは珍しいですか？[閉まっている]

これは実際には技術的な質問ではありませんが、ソース管理とベストプラクティスに関する他の質問がいくつかあります。

私が働いている会社（匿名のまま）は、ネットワーク共有を使用してソースコードとリリースされたコードをホストしています。開発者または管理者は、ソースコードがリリースされているか、どのバージョンであるかなどに応じて、ソースコードを適切なフォルダーに手動で移動する責任があります。ファイル名とバージョン、および変更内容を記録する場所の周りにさまざまなスプレッドシートが点在しており、一部のチームは各ファイルの先頭に異なるバージョンの詳細も記載しています。各チーム（2〜3チーム）は、社内でこれを異なる方法で行うようです。あなたが想像できるように、それは組織化された混乱です-「正しい人々」は彼らの物がどこにあるかを知っているので組織化されていますが、それはすべて異なっていて、それはいつでも何をすべきかを覚えている人々に依存しているため混乱です。

私はしばらくの間、ある種の管理されたソース管理を推進し​​ようとしてきましたが、社内で十分なサポートを得ることができないようです。私の主な議論は次のとおりです。

• 私たちは現在脆弱です。いつでも誰かが私たちがしなければならない多くのリリースアクションの1つを行うのを忘れることができます。これは、バージョン全体が正しく保存されないことを意味します。必要に応じて、バージョンをつなぎ合わせるのに数時間または数日かかる場合があります
• バグ修正と一緒に新機能を開発しており、一部の作業がまだ完了していないため、多くの場合、どちらか一方のリリースを遅らせる必要があります。また、バグ修正だけが必要な場合でも、新しい機能を含むバージョンを使用するようにお客様に強制する必要があります。
• 複数の開発者が同じプロジェクトを同時に使用しているため、Visual Studioで問題が発生しています（同じファイルではありませんが、依然として問題が発生しています）
• 開発者は15人しかいませんが、私たちはすべて異なる方法で作業を行っています。私たち全員が従わなければならない標準的な全社的なアプローチをとる方が良いと思いませんか？

私の質問は：

1. このサイズのグループにソース管理がないのは正常ですか？
2. 私はこれまで、ソースコントロールを持っていないための唯一の漠然とした理由が与えられている-あなたが示唆している何の理由の可能性のために有効ではない 上記の情報与えられ、ソースコントロールを実装しますか？
3. 任意のより多くの理由があるため、私は私の兵器庫に追加できるソースコントロールは？

私は主に私がなぜそんなに抵抗したのか感じてもらいたいので、正直に答えてください。

私は、最もバランスのとれたアプローチを取り、3つの質問すべてに答えたと思う人に答えます。

前もって感謝します

1. それは正常ではないかもしれませんが、トレブが言うように、それはおそらくそれほど珍しいことではありません

2. 他の人が言ったように、あなたの規模の会社にソース管理を持たない正当な理由はありません。したがって、無効な理由を特定して攻撃する必要があります。

   a）主なものは現状です：「壊れていないなら、直さないでください」。これは難しいです：うまく機能していないものをすべて指摘し始めることができます（すぐに「ネガティブな人」とラベル付けされる可能性があります）、または何かが爆発するのを待つだけです起こる）、またはあなたはすべてのものを強調する可能性が可能性が間違って行くし。残念ながら、中小企業を担当する人々は、実際に間違ってしまうまで「間違ってしまう可能性のあるもの」に比較的影響を受けません...

   b）無知/恐怖/不確実性：「ソース管理が何であるかを本当に理解していない。どのように使用するかわからない。どのツールを選択すればよいかわからない。スタイルがぎこちなくなる」。これは私が絶対にここに送らない理由の一つです！ご自身ではかなり難しい注文かもしれませんが、「ターンキー」ソリューションを提示する必要がある可能性を最大限に高めるために、あまり多くのバリエーションや代替品を用意する必要はないと思います。明確なアイデアが必要です。作業プロセスをどのように適合/変換して、指定されたツールを使用するか。既存のコードをバックポートする方法/場合; ユーザーを「トレーニング」して、稼働させることができると思う速さ。移行期間を管理する方法（ある場合）。「コスト」になる可能性のある量（ドルではない場合、時間単位）。

   c）他の理由（たとえば、VSSの以前の悪い経験、または過度に複雑になったとされるツールに関する「ホラーストーリー」を読んだこと）がありますが、それらを発見した場合は、それらを個別に無効にする必要があります。

3. 十分な理由があるため他の回答に概説されたソースコントロールが。私のアドバイスは、選び出すことであろうメイン可能性が2または3 本当にあなたの会社との違いを作り、それらを磨くし、可能な限りあなたの同僚の多くの会議でそれらを提示します。議論を誘発してみてください：すぐに彼らを納得させなくても、あなたはこだわりのポイントが何であるかについての洞察を得ます。

（変更機能について読んだ/聞いたことがありますか？）

グループがソース管理なしで機能することは絶対に普通ではありません。ソース管理なしで効果的に作業できるプログラマーの最大グループのサイズは1以下です。それはだ、絶対に許せないのプロチームのために、バージョン管理なしで動作するように任意の大きさ、そしておそらく私は創造的な感じではないんだけど、私はあなたがそれを見送るする理由何らかの理由を思い付くことができません。

バージョン管理は、もう1つのツールです。特に強力なツールであり、最小限のコストと比較して大きなメリットをもたらします。分岐、自動マージ、タグ付けなど、その他のあらゆる便利な機能を使用して、すべての変更を組織的に細かく管理することができます。数十個前のバージョンからバージョンをビルドする必要がある場合は、その時点のコードをチェックアウトし、他のフープをジャンプすることなくビルドすることができます。

さらに重要なことは、バグ修正を作成する必要がある場合、作業中の新機能を提供することなく、それをアップデートにマージできることです。心配してください、彼らはまだ存在していません。

会社の文化に挑戦しているので、抵抗を経験しています。あなたが何と言っても、彼らが調整するのに時間がかかります。あなたができる最善のことは、それを追い求め続けることであり、もし会社が本当に動揺しないなら、開発者としてのあなたのレベルにより適した別の仕事を見つけてください。

このサイズのグループにソース管理がないのは正常ですか？

私の経験では、それは標準ではありませんが、ここでの他の答えが示唆するほど完全に異常ではありません。中小企業の大部分はソース管理を使用していますが、残念ながらかなりの数は使用していません。

これまでのところ、ソース管理を持たない漠然とした理由しか与えられていません-上記の情報を考慮して、ソース管理を実装しない場合に有効な理由は何でしょうか？

適切な議論については、SOに関するこの質問を参照してください。受け入れられた答えは、
「バージョン管理を使用しない正当な理由はありません。1つではありません。」

ソース管理に武器庫に追加できる他の理由はありますか？

私が出会ったすべての開発者とプロジェクトマネージャーの間のコンセンサス、そしてもちろんプログラマーとSOについてのコンセンサスは、ソース管理が必須であるということです。受け入れられているベストプラクティスです。誰かがそれを無視することを決めた場合、これが彼にとって正しい決定である理由を非常に強力で説得力のある議論にする必要があります（つまり、「私たちはそれを必要としなかったので、なぜ私たちは将来それを必要とするのですか？」これまでに提示した議論は、特定の問題に焦点を当てています。おそらく、「誰もがそれを行う」という方針に沿って、より幅広いアプローチを試してみるべきでしょう。

ソース管理は、1人の開発者チームにも適しています。ソース管理システムは、基本的に変更を追跡するバージョン管理システムです。あるコードを削除した可能性があり、そのコードが現在必要であると感じている1人の開発者を想像してください。彼は古いコードを取り戻すことができますか？

役立つツールを探してください。サイズはどこでもかまいません。品質はどこでも重要です。

既にバージョン管理システムを使用しているようですが、あまり良いシステムではありません。人々はすでにバージョン管理の必要性を認識しているようです。ソフトウェアのバージョン管理という次のレベルに導入するだけです。

私なら、SCMを既に行っていることの改良版として紹介します。優れたツールを使用すると、すでに行われている多くの作業を自動化する方法を強調します。

• SCMシステムは、スプレッドシートに変更を記録する代わりに、変更内容だけでなく、変更者と変更理由を追跡します。

• ボーナスとして、コードのライフサイクルの任意の時点に戻って、実際に何があったかを確認できます。

• 異なるフォルダーに異なるバージョンのコードを持ち、変更を移植するためにフォルダー間で物事を移動/マージする必要がある代わりに、すべてを同じ場所に保持し、（より重要なことですが）ツールにマージを実行させることができます。

他の人がすでに言ったように、私はある程度の抵抗を期待しているので、私がやっているものでそれを使用してシステムをプロトタイプします。

（ところで、私は実際に私の履歴書と他のドキュメントをSVNの下に置きました。それから、私は何度かConfiguration ManagerとIntegration Managerの役割を果たしてきました。）

私はこれまで、ソースコントロールを持っていないための唯一の漠然とした理由が与えられている-あなたが示唆している何の理由の可能性のために有効ではない 上記の情報与えられ、ソースコントロールを実装しますか？

• 開発している製品はバージョン管理システムです。管理者は、既存の製品が新製品の設計と実装に影響を及ぼさないようにすることを懸念しています。

• 週末のBASEジャンプと雄牛とのランニングの間に、スリルを求めているマネージャーは、すべてがまだ地獄に落ちているのではないかと考えて仕事に励みます。

• 敵対的な乗っ取りを回避します。この方法で管理されているソフトウェア開発の服装を誰が取得したいでしょうか？

ソース管理に武器庫に追加できる他の理由はありますか？

• あなたはすでにバージョン管理を行っていますが、現在は、最も効率が悪く、労働集約的で、エラーが発生しやすい方法で実行しています。VCSを使用すると、費用を節約し、時間を節約し、品質を改善できます。

• ディスク容量を節約します。ほとんどのバージョン管理システムは、ファイル間のデルタのみを保存します。現在、すべてのファイルのすべてのバージョンのコピー全体を保存しています。（これらのコピーをすべてバックアップするには、多くの時間とスペースが必要です！）

• 複数の開発者が同じファイルで同時に作業し、問題をあまり面倒なく調整できます。もちろん、VCSがなくても変更のマージは可能ですが、その場合に誰が何を、いつ、なぜ変更したかを追跡することはほぼ不可能です。

• 開発者は、いつでも任意のバージョンを回復できることを知っているため、新しいアイデアを自由に試すことができます。

• 優れたプロセスにより、才能のある開発者の雇用と維持が容易になります。

このサイズのグループにソース管理がないのは正常ですか？

絶対に違います。私が現在の会社で仕事を始めたとき、変更したコードを送るべき人が1人いて、彼はそれをマージしました。私は数日以内にSVNを使用するように皆を説得できました。

これまでのところ、ソース管理を持たない漠然とした理由しか与えられていません-上記の情報を考慮して、ソース管理を実装しない場合に有効な理由は何でしょうか？

漠然とした理由しか聞いていないのは、バージョン管理を使用しない正当な理由がないからだと思います。

ソース管理に武器庫に追加できる他の理由はありますか？

はい、多くの理由があります。

1. 分岐により、他の開発を妨げることなく新しい機能を開発することができます。
2. 各コミットは、正確に何が変更されたか、その変更を誰が行ったか、その変更がいつ行われたかに関する情報を提供します。
3. バグ修正を簡単にコミットして顧客に展開し、未完成の新しい機能を除外できます。
4. 顧客が新しいバージョンに移行することを恐れている場合は、異なるバージョンを維持できます。
5. 同じプロジェクト（同じソースファイルでも！）で簡単に作業できます。
6. ミスを簡単に元に戻すことができ、そのコミットされたミスの後の変更を保持します。

一部の人々は、自分にとってより良いものを見るまで、現状がどれほど悪いかを理解するのに苦労しています。必要なのは良いデモです。改善できるタスクの実際の例をいくつか示します。「これにより、現在のシステムを追跡するのに4時間かかりましたが、この1つのソース管理コマンドがすぐにわかりました。」

ソース管理を使用しないと、ソロ開発者であっても問題が発生します。何も失う危険を冒さずに冷酷に編集できるという単純な事実は、数週間または数日以内に学習努力を補います。

ただし、ソース管理を導入するようにマネージャーを説得できない場合は、少なくともローカルでgitまたはmercurialのようなものを使用してください。それをした人。

私の会社はバージョン管理にGITを使用しています。同社は、開発者、CEO、警備員、掃除婦、レセプショニストの一人です。それらはすべて私です。ソースバージョン管理は常に必須です。

私は自分で多くのプロジェクトに取り組んでいますが、今でもバージョン管理を使用しています。サイズは関係ありません。バージョン管理が常に役立ちます。

The Joel Testで1位になっている理由があります：http : //www.joelonsoftware.com/articles/fog0000000043.html

また、リストの＃2と＃3が可能になります。

私たちは数年前に6人のチームで同様の立場にありました。開発者の1人は、共有フォルダーがあった開発サーバーにSVNをインストールし、使用を開始しました。

誰もがそれに続き、CI（CruiseControl）を実装し、ビルドおよびリリースプロセスに革命をもたらし、自動化と品質チェックを含めるようになりました。

WTF ?! これは私が今まで見た中で最もばかげた質問かもしれません。新しい仕事を見つける必要があります。15人の開発者？！あなたはそれが小さなチームだと思う？これは非常識です。マネージャーはすぐに終了する必要があります。正直なところ、この質問を読んだ後、悪夢を見ることになります。あなたが販売する製品を教えてください。私たち全員がそれを買わないことを知っています！何が怖いのか、この質問、またはこれが珍しいことではないという答えはわかりません！

15人の開発者がソース管理なしでどのように作業できるか想像できません。ただし、以下から：

（...）ネットワーク共有を使用して、そのソースコードをホストします（...）

VSS（同様に共有フォルダーに基づく）のような独自の貧乏人のバージョン管理を作成したと思います。危険で効率的ではありません。

上司にそれがどれほど悪いかを説明し、2日間のSVNまたはGITトレーニングに投資し、コードを適切な形に保ちながら実際のバージョン管理システムの使用を開始します。

1日に数回、または少なくとも家に帰る前にコミットしないと、何かが足りない、何かが間違っているように感じます。

私はかつて1998年に2人の開発者（私+長髪の管理人）しかいない会社で働いていました。それでも私たちはsvnを使用していました。とても便利です。

私はcpの代わりにmvを実行し、次にrm -rfを実行したため、私のキャリアの中で何度か仕事を失いました。私は泣き、絶望の街をさまよう。

私は、SEに13年間在籍して5つの会社に勤務し、いくつかのカンファレンスに参加しましたが、バージョン管理を使用していない会社には出会ったことがありません。

しかし、私のお気に入りのインテリアデザイン会社20人の従業員は、プロジェクト管理とコラボレーションにホワイトボードを使用しています。彼らは明白な間違いを知っていますが、アップグレードする時間を見つけられないようです。どういうわけかそれは動作します。方法を聞かないでください。

リーダーになりましょう。リーダーになることは、正しいことをすることを意味します。問題を積極的に解決します。十分なコンセンサスがないため、リーダーシップは何もしません。そして、優れたリーダーは、コンセンサスを構築するべき状況と実行すべき状況を認識することを学びます。これは明らかに状況です。コード制御の欠如は、遅かれ早かれあなたの顔に吹き荒れます。

リーダーはしばしば公式の管理職に就いていません。人々は、タイトルに関係なく、善良で決定的なリーダーに従います。

あなたの決定的な努力が非難された場合、特にそれが経営陣からのものである場合、それはあなたがそこから地獄を抜け出すための明確な兆候です。それはあなたの専門能力開発の足かせです。有能な開発者と無能な管理者が混同することはありません。また、無能な力があなたを台無しにします。

OK、フラッシュバックは私に近づいています。サインオフ。幸運を。

1. ストップウォッチを取得し、
   • バージョンを同期するためだけにスプレッドシートで費やす時間を数える
   • 壊れたバージョンの修復に費やす時間を数える
   • 廊下で人々が叫ぶ回数をカウントします。「私はmain.cを編集しています。ただ、他に誰もいないことを確認するためです！」。
   • バグ修正には他の変更が含まれていたため、顧客から寄せられた苦情の数を数える
   • バージョンを同期できなかったという理由だけで、リリースの時間遅延をカウントします
2. このデータを使用してパワーポイントを作成し、vcsの機能と比較します。
3. ショー管理

これは起こるのを待っているただの事故です。コードの履歴がなく、一挙に開発者の1人が数か月の作業を一掃することができました。小さな会社として、この種のkind折を買う余裕はありません。

また、その共有ドライブに非常にさらされています。適切なバックアップがあっても、どれだけの期間、作業を停止する余裕がありますか。1時間、1日、1週間。新しいサーバーの設置、バックアップからの復元などにかかる時間

オフサイトストレージについても考えてください。洪水や火災はそれほど珍しいことではありません。営業時間後に建物に火事があった場合はどうなりますか。失われた作業の月数。これには、githubのようなマネージコードリポジトリが役立ちます。ホストされたサービスで単純なSVNサーバーを使用することでさえ、この分野でのステップアップになります。

LordScree、私はあなたとほぼ同じ苦境にあります。私の直接のチームは約15人の開発者です。私はソース管理が使用されていないことを信じています（ほとんど恐怖）。「ソース管理を使用する必要があります」に対する私の最初の応答は、「実装する時間がありません」でした。私にとって、下着を着ているように、ソース管理はオプションではありません。数か月後、私もTFSを実装することを承認しました。TFSはMSであり、90日間の試用版が付属しているため、組織が選択しました。肝心なのは、ソース管理なしでやり取りしている組織にソース管理の必要性を納得させることは非常に難しいことです。開発者に、特にバックアップされたファイル名またはディレクトリに日付があるファイルをバックアップしていることに気付いたときはいつでも、ソース管理に何かを入れたときの例だと言います。しない すばらしい回答はありませんが、これは珍しいことではないと思います。私は同じ戦いに取り組んでおり、進捗状況をお知らせします。そして、うまくいけば、他の場所で探しているかもしれませんが、混乱の中で働くことができないので、進歩があるでしょう！

開発スタッフが3人いて、ソース管理を使用しています。私の個人プロジェクトでは、1人の開発者がいて、ソース管理を使用しています。チーム管理に役立つだけでなく、何かを破壊することを恐れずに実験的な作業を行えるようになるのに役立ちます。

管理を説得する最も簡単な方法は？製品全体のリスクは低く、長期的には開発者の生産性が向上します。両方とも同様に真実であり、どちらもマネージャーに訴えています。

それは決して通常のシナリオではなく、あなたの会社でこのセットアップを得るためにあなたは厳しい戦いをすべきだと思います。それは広範囲に及ぶ利点があり、あなたが終末に近づいたときに同じことを実現する意味がなく、それが下にある状況ではありません

それを実装しなかった理由は、悪い仕事の言い訳か、起こるのを待っている不作為だけかもしれません。

今年1月1日にアプリが何であったかを見つけるのがどれほど素晴らしいかを伝えてください

この機能が3月に追加されたのはどうですか、これについてもう少し拡張する必要があると思います。

うわー、このコミットでバグ154256が修正されました。

アプリを分岐して、展開を問題なく実行できます。

これは続けて行うことができます...

私は、1人のプロジェクトと作業プロジェクトにバージョン管理を使用します。このプロジェクトでは、一度に30〜40人以上が同じコードを操作しています。バージョン管理には組織上の利点がありますが、ファイルを元に戻したり変更を隠したりする機能は、コードの管理から本当に頭痛の種を取り除くことができます。

バージョン管理を使用しないことをサポートする理由はかなり限られています。私が考えることができるのは、物事の技術的な側面だけです。

• 学習曲線が多すぎて、スタッフ全体のワークフローを変換してバージョン管理システムを組み込み、費用対効果を高めることはできません。
• プロジェクトマネージャーは、リポジトリを管理および保守するワークフローにオーバーヘッドを導入することが有益だとは考えていません。（主に古いバージョン管理システムの問題）

バージョン管理システムを使用する理由はたくさんあります。少なくとも物事の動きを止めてください。パッチを使用します。バージョン管理システムは、あなたが言うことを正確に行うことができます。

• バグ修正を行うと同時に次のバージョンで作業し、それらを個別にリリースできます。
• ファイルをある場所から別の場所に移動して作業する代わりに、ブランチを作成し、完了時にマスターにマージできます。
• 各開発者は、ソースコードの独自のコピーを保持して、同じプロジェクトが複数のマシンで開かれる問題を防ぐことができます。
• コードがひどく壊れた場合、最後の作業リビジョン番号にロールバックする必要があるすべてが事故になります。
• バージョン管理は、バグトラッカーおよび継続的な統合システムとうまく組み合わせて機能します。

個人的には、個人チームとして、バージョン管理、バグ追跡、継続的統合、コードレビュー、コード整合性チェック、ユニットテスト、セレンテスト、ソースコード分析を使用していますが、忘れてしまうことがあります。私は認める、わずかな学習曲線があります。また、自動化する追加手順に必要な追加管理時間のトレードオフもあります。私の経験では、節約された労力は追加の管理時間を上回ります。

1990年の最初の本格的な仕事で、私は自分の部署で働いている唯一の開発者であり、ソース管理を使用することを知りませんでした。

その後すぐに、私はそれを学びました。それ以来、彼らが最初に設定したものの1つにならなかったプロジェクトを見たことはありません。

間違ったレベルのフォルダーを削除したため、そのジョブでの作業がほぼすべて失われました。幸運なことに、私は前の週に5インチのフロッピーにコピーを持ち帰り、数週間で数週間の作業を再現することができました。

それがチームの全員にとって最初のプロジェクトであり、誰もそれを知らなかった場合は受け入れられると思いますが、1人でも実際に利点を説明することができ、チームがまだ聞いていない場合、私は自分を再分類します「ナイーブ」から「危険なほど無能」までのグループの意見（このような広く実証された利点を備えたツールの使用に対する抵抗は、ほとんど犯罪です。たとえば、チームが「コンパイラ」を信頼せず、アセンブリ言語ですべてを行うことを主張した場合のようです）。

多くの組み込みソフトウェア/ハードウェアを扱う小規模なエンジニアリング/エレクトロニクス企業で、私はこれに多く関与しています。

これらの場所では、SCMは電子工学文化の一部ではありません。通常、プロジェクトごとに1人のエンジニアがおり、最新リリースをバックアップする必要があります。

そのため、コードの分岐/マージ、さらには共有は、無関係と見なされます。また、これらの企業はおそらくISO9000であるため、奇妙なプロセスが文書化されている可能性があります。

いずれにせよ、私/他の開発者は個人的にSCMを使い始めたばかりです。

私が働いている場所には同じ問題があります。私は現在、「レーダーの下」でソース管理をスライドさせて、同じ問題を回避しようとしています。私は個人的に開発するプロジェクトに化石を使用しています。

最近、会社のLANに化石サーバーを設置したので、さらに便利になりました。いくつかの小規模なプロジェクトで有用性を実証することで、抵抗を弱め、ネットワークフォルダの現状から私たちを遠ざけることを望んでいます。

化石やその他のVCSを使用していないと聞いた最大の理由は次のとおりです。

1. 「プログラマー」の多くはスクリプトキディであり、それを使用する方法を理解しません
2. 学ぶことができる人は、それを使用するのは迷惑だと思う
3. これらの人々は古い警備員であり、ネットワークフォルダーに慣れているため、全員が
4. 誰もそれを正しく設定したり、使用方法を学ぶ時間はありません
5. 機能は素晴らしいかもしれませんが、どれも必要ありません

ご覧のとおり、これらは簡単に使用でき、既にセットアップされており、習得が容易であり、機能にはそれだけの価値があることを示して、これらを回避しようとしています。

最後に、ソース管理を使用させなくても、それはすべてネットワークツリー内にあります。Fossilはツリー全体のすべてをバージョン管理でき、ファイルの変更が発生するたびに、または少なくとも1時間ごとに実行するように設定できます。「ソース管理を必要としない」プロジェクトのいくつかでそれを行ったので、何かがうまくいかなかったときに良いバージョンにロールバックできるようになりました。

それを正しくすれば、彼らはあなたがそれをやったことさえ知らないでしょう。その後、壊れたビルドを復元し、ツールの有用性を実証するヒーローになることができます。

GitやMercurialなどのDVCSツールが利用可能であり、セットアップと使用が非常に簡単なため、1（！）のチームでさえソース管理を使用しないという言い訳はありません。チームの規模ではなく、変更の履歴をコメントすることや、新しいリリースに取り組んでいる間に本番の問題を修正するなどのワークフローをサポートし、さまざまなバージョンのソースコードの状態を追跡することです。

私がそのサイズに達したチームで仕事を提供され、開発者の誰もVCSの使用を提案しなかった場合、または「管理」がそれらを妨げていた場合、私はそれを平らにします。これは最近の受け入れられる方法ではありません。

すぐにGITバージョン管理を取得する必要があります。Google Code Project Hostingからでも使用できます。他の人がクリックするだけで変更をコミットしているのを見て、手動で物をコピーすると、おそらくそれについて気が変わります。

わあわあ 私はそれがコード制御を処理する最良の方法だとは思いませんが、6人の開発者がいる会社で働いていて、ソース管理は使われていませんでした。 whatnotは​​すべての変更を監視します。実際には、ある種のスイッチが機能をラップしている限り、プロジェクトに新しい機能を追加できるというのがマントラでした。

たとえば、私たちはPHPで書かれたabグレードのソーシャルネットワークに取り組んでおり、クライアントは機能がユーザープロファイルをサブスクライブできることを望んでいました。基本的に、この機能はif（ENABLE_SUBSCRIBE_FUNCTIONALITY == true）{then codeを実行する}のようなチェックでラップされました

私が働いていた場所でも、特定のファイルを扱う開発者は一度に1人しかいませんでした。ほとんどすべてがモジュール式だったので、その場合はソース管理の必要はありませんでした。ただし、ソース管理の利点は、ほとんどの場合、ソース管理がないことの欠点をはるかに上回ると考えています。

あなたの会社が、ファイルの変更とGitやSubversionのようなものがあなたのためにそれを処理できるときに変更されたものを文書化したスプレッドシートに頼っているという事実は、まったく絶対にばかげています。

ある程度納得しているようですが、組織内の誰かがそれを行う権限を与えていないようです。他のコメントから読むことができるように、あなたはそれをするべきです。

ここでいくつかの情報を見つけることができます：http : //www.internetcontact.be/scm/?page_id=358

最も重要な要因は、顧客が最後の「不安定な」ブランチに追い込まれ、顧客との契約が不安定なバージョンの展開に責任を負わせた場合、あなたの会社はお金を失うことです。ここでは本当にリリースの安定性に焦点を当てる必要があります。これがソース管理の主な理由であり、主な失敗のようです。他のシステムは、代替システムが既に用意されているため、ソース管理を使用してもそれほど改善されません。