私は政府機関で働いています。ここで使用されている技術とソフトウェアの開発方法は非常に古いものです。

大量のストレージスペースがありますが、ここでの作業のほとんどを自動化するために使用されるアプリケーションを保持および維持するための適切なスペースはありません。

この機関では、GITやSVNなどのSCMソフトウェアを使用できません。

コードの品質を維持し、後でアプリに新しい機能を追加できるようにするための最良のアプローチは何でしょうか？

コードを壊さずに行った変更を記憶するにはどうすればよいですか？

編集：私は言及するのを忘れました、彼らはそれぞれのコンピュータのためのネットワークドライブを持っています、そしてどういうわけかこれらのネットワークドライブは定期的にバックアップを作成または保存します。ただし、作業を保存し、既存のコードを壊さずに新しい機能を追加できるようにする独自の計画を作成しない場合、SCMソリューションに勝る大きな利点はありません。

編集：多くの人々がポータブルGitを提案したので、私はより多くの情報を追加する必要があります。Visual SVNサーバーをインストールしようとしましたが、インストールする管理者権限がないため失敗しました。また、通常のGitシェルをダウンロードしようとしましたが、ファイアウォールまたはネットワーク設定により、Gitダウンロードページにアクセスできませんでした。ポータブルGitをGmailであるメールに送信してみました。Googleはパッケージ内のexeファイルを検出しましたが、それでも仕事用コンピューターにポータブルGitバージョンをダウンロードできませんでした。もう1つ言及しなければならないのは、教育機関のコンピューターに適用されるネットワークポリシーでは、USBストレージデバイスの使用が許可されていないことです。USBポートを使用して、スマートフォンを充電したり、小型スピーカーなどの一部の機器に電力を供給したりできます。また、一部の人々が言及したように、インターネットさえ許可されていないコンピューターがあります。

次の3つの簡単なツールを使用して、ソース管理が果たす役割を大まかに複製できます。

• バックアップソフトウェア（コミット/チェックイン）
• フォルダー（ブランチ）
• KDiff3（ブランチのマージ）などのツールを使用して2つのディレクトリ間でディレクトリマージを実行する

基本的に、ワークフローは次のようになります。

1. 新しいフォルダーを作成する（新しいブランチ）
2. 既存のフォルダー（既存のブランチ）から新しいフォルダー（新しいブランチ）にファイルをコピーする
3. そのフォルダーのバックアップを作成します（新しいブランチの作成を終了します）
4. いくつかの作業を行います
5. 新しいフォルダーのバックアップを作成します（コミット）
6. あるフォルダーから別のフォルダーへのディレクトリマージを行う（マージ）
7. 他のフォルダーで別のバックアップを実行します（マージをコミットします）

SVNやTFSのようなよりモノリシックなソース管理システムは、基本的には舞台裏でこれを行います。

現実には、これはバス会社がドライバーにバッテリーのあるバスを運転できないと言って、ドライバーにバスを丘の下に押してからクラッチをポップしてバスを開始させるようなものです...これはひどいですそして、現在の経営者がバスのガレージの運営について何も知らないことを示しています。哀conの意。

しかし、少なくともあなたはバスを始めることができます。

コンセンサスは確かにこの会社のために働かないことでしょうが、それが本当にあなたの質問に答えるとは思いません。

SCMを実際に置き換えることはできません。

本格的なシステムの通常の機能は必要ないかもしれません。たとえば、会社はサーバーへのリクエストを拒否しても、ローカルSCMの使用を許可する場合があります。gitは嫌いかもしれませんが、subversion（または他のバージョン管理システム）は許可されます。

もちろん、質問があります。同僚は何を使用していますか、それとも以前の労働者ですか？あなたが彼らが持っている最初のソフトウェア開発者なら、あなたが必要なリソースのために非常に一生懸命プッシュする時です。

最終的に、会社があなたの役割と経験を尊重せず、必要なツールを許可しない場合、ソース管理の欠如よりもさらに深刻な（そしてよりストレスの多い）問題に直面します。

基本的には、（の基礎を理解していない組織管理上の問題があるソフトウェア開発プロセスを例えば、V-モデル最小限の存在時代のワークフロー、方法論、およびツールを使用しての見かけ不能に凝縮します）。これはよくあることです（ピーターの原則について読んでください）

^{ところで、2017年末のパリでの最近のSNCF鉄道事件は同様の原因があると思います（高い管理レベルでのソフトウェア文化の完全な欠如、したがって1日以上の主要なパリの鉄道駅の妨害;もちろん非常に有能ですSNCFのITチーム。ただし、主要な決定については協議されていません。ソフトウェアカルチャーがまったくないヨーロッパのいくつかの産業に名前を付けることができます。米国でも同様のことが見つかるはずです。}

主な問題は、コードベースで単独で作業しているのですか、それとも同僚と作業しているのですか？

単独で作業している場合は、コンピューターでgitをローカルで使用し、.git定期的に（その外部ストレージスペースに）コード（およびおそらくリポジトリー）をバックアップできます。半日以上の作業が失われないようにしてください（定期的に確実にデータをバックアップしてください）。

^{（私はあなたが、少なくとも両方を知っていると仮定gitしてのsvn、あなたが技術的な優位性を知っていることをgit、あなたも、のようないくつかのツールをインストールするために許可されていない場合はgitあなたの仕事のコンピュータにあなたがその問題について上司との深刻な会話を持っている必要があります：あなたが必要です外部のオープンソースツールをインストールする能力と承認（そして、それらを賢明かつ慎重に、既知の脆弱性なしで選択、構成、インストールする責任があります）}

数人の同僚と作業している場合（数十人未満と思われます）、全員にバージョン管理システムを使用するよう説得する必要があり、おそらくすぐに（そして一般的な）上司にそのことを伝える必要があります。彼は（おそらく）いくつかのマシン（おそらくいくつかの古いデスクトップ、おそらくあなた自身のデスクトップ）がgitサーバーとして使用されることを決定（または単に暗黙的に受け入れる）ことができました。少なくとも1時間ごとにgitリポジトリがバックアップされるように、そのサーバーを設定する必要があります。チームの1時間以上の仕事を失う余裕はありません（上司に相談する必要があります）。

^{ところで、私はLinuxが大好きgitです。サーバーとして機能するマシンにLinuxをインストールすることをお勧めします。その後git、定期的なバックアップのインストールと構成（いくつかのcrontabジョブを含む）は非常に簡単です。gitサーバーがそれを使用するWindowsクライアントでLinuxを実行できることに注意してください。可能であれば、開発マシンをLinuxに切り替えることをお勧めします。「安く」、開発者にとって使いやすい}

ただし、SCMを使用する必要があります。上司に別の質問をすることもできます。チームで既存の SCMを使用する必要がありますか、それとも車輪を再発明して独自のSCMを作成する必要がありますか？ボスは一般的に、車輪を再発明するという考えに反対です。車輪の再発明が許可されている場合は、少なくとも1年間はフルタイムの仕事であることを上司に伝え（おそらく上司を泣かせてから、明らかな方法を受け入れて）、自分のSCMを楽しんでください。その可能性が低い場合は、必ず既存の SCMシステムを調査し、SCMシステムをフリーソフトウェアツール（他のチームが使用および改善するため）にするよう依頼してください。

あなたはする必要があるかもしれません準備（数日中に）正確かつ具体的な SCMの必要性について議論を：最初の同僚のために、そしてあなたの即時の上司のために。また、具体的な解決策も提案してください（デスクトップでgitサーバーを実行したり、「古い」サーバーで実行したり、ジョブを介して1時間ごとにバックアップするなど）。crontab

許可なく職場のコンピューターにソフトウェアを（外部からでも、オープンソースでも）インストールしないでください（ほとんどの国では、特に国家の機密IT作業の場合、許可なしでソフトウェアをインストールすることは法的に犯罪であり、仕事をしたり、刑務所に行ったりする場合は、許可を得るようにしてください。書面で許可を求めて、または少なくとも電子メールであなたのお尻を隠してください。

^{（ケースバイケースで尋ねる必要があるか、職場のコンピューターに合法的なソフトウェア（ほとんどがオープンソースまたはフリーソフトウェア）をインストールできるようにするには、組織から信頼を得る必要があります）。}

PS。（管理者の許可がなくても）マシン上で（そのフリーソフトウェアソースコードから）-または他のほとんどのフリーソフトウェアVCS を技術的に構築、構成、インストールして使用する方法gitは、非常に異なる質問です（別の場所で尋ねられます）。そして、そのための十分なリソース（時間、ディスク容量、Cコンパイラなど）があれば、管理者権限なしでインストールして使用することができます。git

Visual SVNサーバーをインストールしようとしましたが、インストールする管理者権限がないため失敗しました。

これは、あなたのいくつかの具体的な構成と、コンパイルによって解決可能であるgitかsvnのフリーソフトウェアのソースコードgitだけでバイナリパッケージ- （ともやSubversionの-not ソースコードの依存関係）。技術的にそれを行う方法は別の質問です（ただし、このような技術的な質問は他の場所で行う必要があります）。もちろん、実行するgit前にソースコードをコンパイルする許可を（上司から）求める必要があります。彼は、ソースコードを外部から職場のコンピューターに転送することに関する実際的な詳細（そのような解決策を受け入れた場合）について、あなたに話します。

私が最初に行うことは、政府機関（おそらくIT部門）が反対しているものを具体的に識別することです。ストレージスペースはあるが、サーバーのVMをホストする方法がない場合、問題は、IT部門がSVNまたはGIT サーバーに対してノーと言っていることであり、それは大きな違いです。問題が発生国である場合（つまり、外国企業によって作成されたツールを信頼していない場合）、それは別の問題です。

ファイルシステム内でGITを完全に実行できます。GITを使用する準備が整う前に、私はそれを幼児プロジェクトで実行しました。GITは、インストールに管理者権限も必要としません。

何らかの理由でGitを絶対に使用できない場合は、いくつかのオプションを使用できます。

• 教育：バージョン管理を許可しないことにより、重大なリスクが発生します。より問題があると判明した変更を取り消す機能が必要です。政府のお金と時間を節約する能力が必要です。SCMはそれを行います。その方法を明確に説明できる必要があります。また、あなたはおそらく、本当の意味でポイントを獲得するために、代替案の分析を行う必要があるでしょう。
  • 1つの選択肢はGitをホストすることです
  • 別のファイルシステムGit
  • 少なくとも1つ、ただし2つ以上の代替SCMツールを選択してください
  • そして最後に、バージョン管理なしで動作するようなもの
• 70年代の発展に向けて：ずっと前（80年代）に作られ た理由がpatchありdiffます。それらは、バージョン管理を可能にする実現技術でした。

70年代の開発はどのようなものですか？それはきれいではありませんが、それは私たちが始めた方法です。アプリケーションはずっと小さかった。基本的に、彼らはいくつかの一般的なものを持っていました：

• ゴールドスタンダードのコンセプトがありました。これは機能が完全なマスターソースコードでした。
• 構成管理（CM）チームがありました。彼らの責任は、開発からゴールドスタンダードへの変更を正しく行うことでした。あなたが必要とするところであるpatchとdiff、チームのために代用します。
• ソースコードのローカルコピーから作業しました。機能全体を完成させ、CMチームに送信して統合します。通常、新しいファイルが作成され、古いファイルが削除されるように、付随するドキュメントがあります。
• 次に、統合プロセスのエラーを修正します。
• 別の機能やバグ修正を楽しませる前に、ゴールドスタンダードの新しいコピーを入手してください。

基本的に、これはエラーが発生しやすいプロセスであり、物事がうまくいかない可能性がたくさんあります。「分岐」のアイデアは実装が簡単ですが、管理するのは悪夢です。主な問題は、ソースコードのコピーが多すぎると、本番環境の正しいベースラインが何であるかを理解することが困難になることです。実用のために、シングルスレッドになる必要があります。

これは、代替の分析に含める必要があるものです。

コメントで言及した制約（例：Gitダウンロードページ、Windowsプラットフォームにアクセスできない、Visual Studio 2005を使用できない）を考えると、2つのオプションが表示されます。

1. Emersonがコメントで示唆しているように、Visual SourceSafeを使用します。VS 2005を使用するチームと数年前に仕事をしましたが、会社の他のほとんどはLinux / Unixの標準バージョン管理を使用しており、CMにはVisual SourceSafeを喜んで使用していました。この時点ではかなり時代遅れですが、何もないよりはましです。
2. 何もないよりはいいと言えば、私も同じような束縛状態にあります。VSSを使用することさえできない場合（プラグインがインストールされていない可能性がありますか？）、使用可能なストレージスペースが十分にあると言うので、うまくいけばその一部を使用できるようになります。手動のファイルベースのバージョン管理プロトコルを実装しました。毎日の作業の終わりに、コードベースを新しい日付スタンプ付きディレクトリにコピーします。前の作業に戻る（またはロールバックする）必要がある場合は、以前の日付のディレクトリを調べて、必要な変更を見つけます。Visual Studioを使用できるので、数時間以内に、おそらくディレクトリ作成とファイルコピーの自動化に役立つ簡単なツールをVS 2005を使用して作成できます。

たくさんの収納スペースがあります

あなたの決断でそれを使用することは許可されていますか？

もしそうなら、何もないよりはましなファイルシステムリモートリポジトリを作成することができます。欠点はgit、変更を探すためにリポジトリ全体をダウンロードする必要があるため、プロジェクトの成長中にプッシュが遅くなることです...

これまでのところ、コンピューターは通常のユーザーのように動作し、サードパーティのソフトウェアをインストールすることを禁止しています。

gitまた、$ HOMEまたは％USERPROFILE％パスにインストールできるように、ポータブルアプリとして提供されます。

結論として、SCM ^1の使用を禁止させません。「プライベート」に使用します。結局のところ、コードがどこかでチェックされているかどうかにかかわらず開発されているかどうかはわかりません...

¹）git数年前に使用を開始したとき、顧客は非常に低速で信頼性の低い別のSCMを好みました（結局SCMのNOGOのようなものです（o;）。git他のSCMの上に "プライベート" を使用しましたネットワーク共有上の「ファイルベース」リモートを使用し、製品の新しいバージョンがリリースされた後にのみSCMにチェックインします。

あなたの環境

まず第一に、私は多くのコメントと回答に示されているように悲観的ではありません。はい、これは「石器時代」ですが、もっと悪い状況があります。全体的な作業環境（同僚、場所、給与、興味深いプログラミング作業など）が良好で、あなたの好みに合っている場合は、必ずそれに従ってください。ITに関しては、それが何であるかです。これは政府機関だけでなく、銀行、保険、またはセキュリティが非常に重視されている場所、または非常に古い構造物でも発生します。

USBスティックを挿入し、そこから.exeを実行すると、他の場所ですぐに終了する原因になるため、何かを回避しようとすることはお勧めしません。

もう一度gitを試してください

今、あなたの選択に。svnではなくgitを強くお勧めします。とにかく一人でプロジェクトを行う場合、gitは.gitアプリケーションルート内の単なるローカルディレクトリであり、それ以外は何もありません。

上司/ ITに「SCM」を依頼するのではなくgit、マシンにインストールするように具体的に依頼して、より速く、より高い品質で開発できるようにしてください。あなたがないことを彼らにそれを明確にないあなたがないことを、どこか別の場所にあなたのコードをプッシュしたくないどこかで実行しているサーバーを必要とし、それがすることではない重大なスペースやメンテナンス時間を使用しています。

Gitを使用すると、自信を持って作業できるため（変更を取り消すことができるため）、複数のブランチで同時に作業できるため、速度と品質が向上します。つまり、大きなタスクに取り組んでいて、すぐに注意が必要な何かが入った場合、新しいブランチに切り替えてすぐに修正してから、長時間実行されているタスクに戻ることができます。

手動で行う

まったく不可能な場合は、もちろん手動でソース管理を行うことができます。自分でコードをコピーして、手動の「タグ」を作成します（日付と時刻、および変更内容の簡単な説明を含む新しいディレクトリを作成することもできます）。変更ログだけでなく、変更だけでなく、変更したファイルの詳細なリストや、さらに詳細な変更ログを保持します。

再びあなたの作品をコピーして「ブランチ」を作成し、マージするときに、任意の「diff」または「diff3」ツールを使用してクリエイティブを取得します-利用可能なものがあるかどうかわかりません探し出す。

このすべてに時間がかかる場合は、SCMをエミュレートすることが本当に価値があるかどうかをよく調べてください。価値があると思う場合は、もう一度上司に相談してください。マニュアルSCMの利点を示してください（「古い作業のコピーをすべて持っている」だけでなく、「バグXYZが発生したとき、5リリース前にすぐに理由を見つけることができました」）。それから、これがどれほど速くなるかを彼らに伝えてくださいgit。

明らかに、これがあなたを夢中にさせているなら、仕事を探すことは常に選択肢です。

ここの多くの人々は、この質問の「政府機関」を見逃していると思います。一部の政府ネットワークでは、ソフトウェアに非常に厳しい規制が課されており、これらの規則を破ることは、おそらく犯罪者でさえも、実行可能な犯罪です。ソフトウェアをインストールする際に承認された動きを得ることができるかどうかを確認するために、管理にプッシュします。私はカウボーイに行って自分で物をインストールするつもりはありません。Linux / UNIXを実行している場合は、RCS（ci / coコマンド）またはSCCS（sccsコマンド）がインストールされているかどうかを確認してください。これらは、かなり標準的なものであった古いSCMツールです。きれいではありませんが、これから説明するものよりも優れています。:)

ディスク領域がたくさんあるので、ソースツリーを作成します。小規模のSCMの基本は何ですか？変更のチェックイン、変更内容の確認、タグ付け、および必要に応じて古いバージョンに戻ることができます。ソースツリーの1レベル上で、使用可能なものに応じてMakefileまたはスクリプトを作成します。これにより、以下が実行されます（これらはLinux / UNIXフレーバーで、Windowsコマンドは異なります）。

チェックインを行う-cp -a source-tree source-tree-date（source-tree-20171205115433のように、少なくとも2分ではないにしても分まで）

ステータスを作成-diff -Rソースツリーソースツリー日付| 少ない（ここには少しロジックがあり、デフォルトでは最新のバックアップが使用されるか、バージョンに対するdiffの引数が与えられます）

make tag-ln -s source-tree-date release1.0（特定のバージョンへのリンクを作成します）

元に戻す-rm -rソースツリー&& cp-ソースツリーの日付ソースツリー

それらに売る

あなたはこのコメントを残しました：

彼らにはネットワークドライブがあり、それはどうすればいいかわかりませんが、定期的にバックアップを作成します。はい。私はそれを使用し、そこにアプリを保存します。

上司に行き、次のように言ってください。

上司、ネットワークドライブにアプリを配置し、何らかのサービスがバックアップを作成して履歴を追跡するシステムがあることに気付きました。これにより、独自のソース管理システムを実装しているように思えます。SVNやgitなどの専用のソース管理システムに切り替えることで、おそらく多くのスペースを解放し、システム全体を非常にシンプルにすることができます。過去のバージョンのより単純なバックアップ、時間の経過とともにファイルに加えられた変更を理解するためのツール（デバッグに非常に役立つ情報）、ミスを取り消す簡単な方法、さまざまな人の変更を組み合わせる簡単な方法など、多くの利点が得られます。

私は以前にこの種のシステムを使用したことがありますが、カスタムセットアップが実行するタスクは非常に優れています。それらを間違えるのは、現在のシステムよりもはるかに困難です。また、非常に成熟しており、広く使用されているテクノロジーです。これらのツールは20年以上にわたって広く使用されています。それに加えて、ライセンスで一銭も支払うことなく、最も人気のあるソフトウェアを使用できます。

クライアントとサーバーの選択とセットアップをお手伝いさせていただきます。[insert estimate here]マシンを入手できれば、インストールに数時間しかかからないでしょう。ネットワークを介してアクセスできる限り、どのマシンでも、古いデスクトップでさえも廃止されます。

ここでの高レベルの要約は、彼らが理解でき、それが価値があると思われる用語でそれを置く必要があるということです：

• 他の目的のためにリソース（ハードウェアと人）を解放する
• 低リスク（人為的ミス、安定した技術）
• 生産性の向上
• 実装するための低コスト

上司は技術者ではなく、技術的な問題を気にしません。しかし、お金とお金がかかるものに関して問題を組み立てることができるなら、彼らの耳は少し元気になるかもしれません。

さて、あなたの質問と多くのコメントを読んだ後、次の制約/シナリオがあることを理解しました：

• プロジェクトごとに1人。
• プロジェクトでVisual Studio 2005以外の外部ツールを使用することはできません。GITまたは他のSCMを使用できません。
• ローカルで作業している間、プロジェクトを壊れた状態にすることはできません。これは、時々自動バックアップがあり、常に動作させる必要があるためです。
• 変更を追跡するには履歴が必要です。

Visual Source Safe（VS 2005で動作するプラグインがある）を使用できない場合は、別のアプローチを使用できます。

上記の項目に基づいて、次のようなプロジェクトフォルダを整理することをお勧めします。

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

ここに従うべき基本ルール：

• コード制御はプロジェクトのフォルダー内で実行されます。
• 「トランク」で作業することはありません。
• 「temp」で作業し、単体テストを実装し、build.batを呼び出してから、save_on_trunk.batを呼び出します。
• 重要：完全に分離して実行される単体テストを実装します。新しいコードがトランクを壊さないことを保証するためにこれが必要です。
• 自動バックアップがあるため、コードを失う可能性は低くなります。したがって、「トランク」コードを常に動作状態にするだけで済みます。

技術的な解決策を使い果たしました。政治的解決策のみが残っています。

1）開発者を統合します。すでに組合がある場合、開発者である従業員のクラスを公平に代表していないという彼らの立場に挑戦してください。開発者の連合を形成しても、開発者の半分のサポートが得られない場合、GO。あなたは相性が悪い。

2）新聞広告。政府が法律問題として言論の自由を保証していない場合、これはあなたを解雇します。

Git for Windowsには「ポータブル」バージョンがあります。これをPCにコピーしたり、メモリスティックに保存したりできます。実際に何かをインストールする必要はありません。問題が単にインストールである場合、これは回避策です。

SCMに完全に反対する場合は、ISO-9001、DO-178B、またはその他の関連ソフトウェア開発標準について先のとがった質問をすることをお勧めします。

サーバーをまったく使用せずに、裸のディレクトリでgitを実行するだけです。ディレクトリをバージョン管理できるので、誰もバージョン管理を使用していないことはまったく問題ではありません。Gitはまさにこの不正なSCM導入シナリオ用に設計されており、うまく機能します。

恐竜がバケツを広げてバケツを蹴るのを待つ必要がある場合でも、2人目の人が使用を開始すると、ヒーローになります。現在、SCMを使用せずに大規模なコードベースを管理するのは無能です。実際には、何も監査せずにビジネスを運営しているようなものです。

実際、プロの開発者として主張したいのは、コードレビュー、バージョン履歴、変更要求の追跡の3つです。

変更要求を自分で追跡できます。適切なツールほどではありませんが、できます。2番目の部分はコードレビューです。そのためには、以前のコードのコピーと差分ツールが必要です。変更の準備ができたと思うときは、以前のバージョンと慎重に比較して自分で確認し、以前のバージョンを新しいバージョンに置き換えます。

バージョン管理については、職場で適切なソリューションが許可されていない場合、必要な書き込み可能なDVDの箱です。戻ってくるために保持したいバージョンがあるたびに、新しいDVDを作成します。

（明らかに、これらのすべては、OPが明らかにそうであるように、本当に悪い職場にいない限り、取るべきアドバイスではありません）。