Я працюю в урядовій установі. Технологія, що використовується тут, та методи розробки програмного забезпечення є досить старомодними.

У них є багато місця для зберігання, але немає відповідного місця для зберігання та обслуговування додатків, які використовуються для автоматизації більшої частини роботи тут.

Установа не дозволить мені використовувати програмне забезпечення SCM типу GIT або SVN.

Який був би найкращий підхід, щоб зберегти якість коду та мати можливість згодом додавати нові функції у додатки?

Як я можу запам'ятати зміни, внесені до коду, не порушуючи його?

EDIT: Я забув згадати, у них є мережеві накопичувачі для кожного з комп'ютерів, і якимось чином ці мережеві накопичувачі роблять або зберігають резервні копії в періоди. Однак якщо я не створюю власний план, що дозволяє зберегти свою роботу і матиму змогу додавати нові функції, не порушуючи існуючий код, великої переваги перед рішенням SCM немає.

EDIT: Оскільки багато людей пропонували портативний Git, я мушу додати більше інформації. Я спробував встановити Visual SVN-сервер, але це не вдалося, оскільки у мене немає прав адміністратора для встановлення. Я також спробував завантажити звичайну оболонку Git, але брандмауер або мережеві настройки не дозволили мені отримати доступ до сторінки завантаження Git. Я навіть намагався, надсилаючи портативний Git на свій електронний лист, який є Gmail. Google виявив файл EXE в пакеті, і він також не дозволив мені завантажити портативну версію Git на робочий комп'ютер. Ще одне, що я мушу зазначити: мережева політика, застосована до комп'ютерів через установу, не дозволяє використовувати USB-накопичувачі. USB-порти можна використовувати для зарядки смартфона або живлення деяких гаджетів, таких як невеликі динаміки. Крім того, як згадували деякі люди, є комп'ютери, на яких заборонено навіть Інтернет.

Ви можете легко копіювати роль управління джерелами ролей за допомогою трьох простих інструментів:

• Програмне забезпечення для резервного копіювання (Коміти / реєстрація)
• Папки (Гілки)
• Здійснення об'єднання каталогів між двома каталогами за допомогою інструменту типу KDiff3 (Об'єднання гілок)

В основному ваш робочий процес стає:

1. Створення нової папки (нова гілка)
2. Скопіюйте файли в нову папку (нову гілку) з існуючої папки (існуюча гілка)
3. Створіть резервну копію цієї папки (закінчіть створення нової гілки)
4. Зробіть якусь роботу
5. Створіть резервну копію нової папки (фіксуйте)
6. Зробити каталог з однієї папки в іншу (об'єднати)
7. Зробіть ще одну резервну копію в іншій папці (виконайте злиття)

Більш монолітні системи управління джерелами, такі як SVN або TFS, в основному роблять це для вас за кадром.

Тепер реальність така, як автобусна компанія каже своїм водіям, що вони не можуть керувати автобусами, які мають акумулятор, змушуючи водіїв штовхати автобус вниз на пагорб, а потім клацнути зчеплення, щоб запустити автобус ... це жахливо і вказує, що нинішнє керівництво нічого не знає про запуск автобусного гаража. Мої співчуття.

Але принаймні ви можете запустити автобус.

Хоча, безумовно, було б не працювати в цій компанії, я не вважаю, що це дійсно відповідає вашому запитанню.

Ви дійсно не можете замінити SCM .

Можливо, вам не знадобляться звичайні дзвіночки з повноцінною системою. Наприклад, компанія може відмовити у запиті на сервер, але дозволити використання локальної SCM. Вони можуть не сподобатися git, але дозволити підрив (чи інша система версій).

Звичайно, виникає питання: чим користуються ваші колеги чи будь-які попередні працівники? Якщо ви перший у них розробник програмного забезпечення, то ваш час дуже наполегливо наполягати на необхідних ресурсах.

Зрештою, якщо ваша компанія не поважає вашу роль та досвід та не дозволить вам потрібні інструменти, тоді ви зіткнетеся з ще гіршими (і більш стресовими) проблемами, ніж відсутність контролю над джерелами.

В основному, існує проблема управління (ваша організація не розуміє основ процесу розробки програмного забезпечення , наприклад V-модель ), що конденсується у очевидну нездатність використовувати мінімальний сучасний робочий процес, методологію та інструменти. Це звичайне (читайте про принцип Петра ).

^{До речі, я думаю, що нещодавні залізничні інциденти SNCF в Парижі наприкінці 2017 року мають подібну причину (тотальна відсутність культури програмного забезпечення на високому рівні управління, отже, блокування великого паризького залізничного вокзалу більше доби; звичайно, є дуже компетентні ІТ-команди в SNCF, але вони не консультуються щодо основних рішень). Я можу назвати декілька європейських галузей, які повністю не мають культури програмного забезпечення, і я впевнений, що зможу знайти подібні речі навіть у США.}

Основне питання: чи працюєте ви один на базі коду, чи працюєте з колегами?

Якщо ви працюєте поодинці, ви можете локально використовувати git на своєму комп’ютері та .gitперіодично створювати резервні копії коду (і, можливо, навіть у вашому сховищі) (у цьому зовнішньому просторі). Не забудьте ніколи втрачати більше півроку роботи (тому періодично та надійно створюйте резервні копії даних).

^{(Я гадаю, що ви знаєте принаймні gitі те, svnі що ви знаєте технічну перевагу git; якщо вам навіть не дозволяється встановлювати якийсь інструмент, наприклад, gitна робочому комп'ютері, вам потрібно серйозно поговорити з вашим начальником з цього питання: вам потрібно можливість та авторизація встановлення зовнішніх інструментів з відкритим кодом (і це відповідає Вашій відповідальності вибирати, конфігурувати та встановлювати їх розумно та ретельно та без відомих уразливостей )}

Якщо ви працюєте з кількома колегами (я думаю, їх менше десятка), вам потрібно переконати всіх у використанні системи контролю версій, і вам, мабуть, потрібно повідомити про це своєму безпосередньому (і загальному) начальнику. Він міг (напевно) вирішити (або просто неявно прийняти), що якась машина (можливо, навіть якийсь старий робочий стіл, можливо, навіть ваш власний робочий стіл) використовується як сервер git. Вам абсолютно потрібно налаштувати цей сервер, щоб резервне копіювання сховища git було щонайменше щогодини; ви не можете дозволити собі (і вам потрібно поговорити з вашим начальником) втратити більше години роботи вашої команди.

^{BTW, я люблю Linux, і я рекомендував би встановити Linux на машині, яка виступає як gitсервер; тоді встановити gitта налаштувати періодичні резервні копії (з деяким crontabзавданням) дуже просто; зауважте, що gitсервер може запускати Linux із клієнтами Windows, що використовують його. Я б навіть запропонував вам переключити розроблювальну машину на Linux, якщо можете. Це "дешевше" та набагато зручніше для розробників}

Але вам потрібно використовувати СКМ. Ви можете задати своєму начальнику інше питання: чи повинна ваша команда використовувати існуючу SCM або вона повинна винаходити колесо і зробити свій власний SCM? Боси, як правило, проти ідеї відновити колесо. Якщо вам дозволено винаходити колесо, скажіть своєму начальникові, що він працює на повний робочий день принаймні на рік (це, ймовірно, змусить вашого начальника плакати, тоді прийміть очевидний спосіб) і весело проробляйте свою власну SCM. У цьому малоймовірному випадку не забудьте вивчити існуючі системи SCM і попросіть зробити вашу систему SCM деяким безкоштовним програмним засобом (який буде використовуватися та вдосконалюватися іншими командами).

Ви , можливо , буде потрібно підготувати ( в протягом декількох днів) з точною і конкретною аргументації для потреби ЗМУ : перший для ваших колег, то для безпосереднього боса. Не забудьте також запропонувати конкретні рішення (наприклад, запустити якийсь git-сервер на якомусь робочому столі чи якомусь "старому" сервері та створити резервне копіювання щогодини через crontabроботу)

Не встановлюйте жодне програмне забезпечення (ззовні, навіть з відкритим кодом) на робочий комп'ютер без дозволу (у більшості країн, особливо для чутливих ІТ-робіт для держави, встановлення програмного забезпечення без дозволу є юридично злочином, і ви можете втратити своє на роботу або йдіть до в'язниці, якщо ви це зробите .... тому не забудьте це зробити уповноваженим; можливо, прикрийте свою дупу, попросивши дозволу в письмовій формі або принаймні електронною поштою).

^{(або потрібно запитувати в кожному конкретному випадку, або вам потрібно довіритися вашій організації, щоб дозволити встановлювати на робочому комп'ютері будь-яке легальне програмне забезпечення - найперше відкрите або безкоштовне програмне забезпечення).}

PS. Як технічно скласти, налаштувати, встановити, а потім використовуватиgit (з його вихідного коду безкоштовного програмного забезпечення) або більшість інших вільних програмних програм VCS- на машині (навіть без дозволу адміністратора) - це зовсім інше питання (про це потрібно запитувати в іншому місці). І можна встановити потім використовувати gitбез дозволу адміністратора, якщо у вас є достатньо ресурсів (час, дисковий простір, якийсь компілятор C тощо) для цього.

Я спробував встановити Visual SVN-сервер, але це не вдалося, оскільки у мене немає прав адміністратора для встановлення.

Це вирішується з допомогою якої - то конкретної конфігурації і компіляції вашого gitабо svnвід вільного програмного забезпечення вихідного коду gitабо SubVersion -непросто двоичная пакет- (а також вихідний код з залежностей ); як це зробити технічно, це вже інше питання (але такі технічні питання повинні йти в іншому місці). Звичайно, ви повинні попросити дозволу (у вашого шефа), щоб скласти вихідний код, gitперш ніж робити це. Він розповість вам, або ви поговорите з ним, про практичні деталі (якщо він приймає таке рішення) щодо перенесення цього вихідного коду ззовні на робочий комп'ютер.

Перше, що я хотів би зробити, це конкретно визначити, на що державне агентство (імовірно, ІТ-департамент) заперечує. Якщо у них є простір для зберігання даних, але немає способу розміщення віртуальних машин для серверів, то проблема може полягати в тому, що ІТ-відділ не відповідає SVN або GIT серверу, і це велика відмінність. Якщо проблема - країна походження, тобто ми не довіряємо інструментам, створеним іноземними структурами, - це інша проблема.

Ви можете запустити GIT повністю у файловій системі, що я робив на немовлячих проектах, перш ніж я готовий зробити з ними що-небудь. GIT також не вимагає адміністративних привілеїв для встановлення.

Якщо ви абсолютно не можете використовувати Git з будь-якої причини, у вас є кілька варіантів:

• Навчіть: не дозволяючи контролювати версії, вони створюють значний ризик. Вам потрібна здатність відмовлятися від змін, які виявляються більш проблематичними. Вам потрібна здатність економити урядові гроші та час, і SCM робить це. Вам потрібно вміти чітко пояснювати, як. Вам також, мабуть, потрібно зробити аналіз альтернатив, щоб дійсно доїхати до дому.
  • Однією з альтернатив був би розміщений Git
  • Ще одна файлова система Git
  • Виберіть хоча б один, але не більше двох альтернативних інструментів SCM
  • і нарешті, що таке, як працювати без контролю версій
• Перейти розвиток 70s епохи: Існує причина , по якій patchі diffбули зроблені так давно (80 - е). Саме ті сприятливі технології дозволили контролювати версії.

Як виглядає розвиток епохи 70-х років? Це не дуже, але ми почали так. Заявок було значно менше. По суті, вони мали деякі загальні речі:

• Існувала концепція золотого стандарту . Це був основний вихідний код, у якому функції були завершені.
• Була команда управління конфігурацією (CM). Їх відповідальність полягала в тому, щоб правильно вносити зміни в розробку до золотого стандарту. Тут потрібно patchі diffзамінити команду.
• Ви працювали з локальної копії вихідного коду. Ви закінчуєте функцію в повному обсязі і подаєте її команді CM, щоб вона інтегрувалася. Зазвичай є супровідний документ, завдяки чому створюються нові файли, а застарілі файли видаляються тощо.
• Потім ви виправляєте помилки в процесі інтеграції.
• Перш ніж ви зможете розважитись ще однією функцією або виправити помилку, ви отримаєте нову копію золотого стандарту.

По суті, це процес, схильний до помилок, з великим потенціалом, щоб справи пішли не так. Ідею "розгалуження" легко здійснити, але кошмаром керувати. Основна проблема полягає в тому, що коли у вас занадто багато копій вихідного коду, важко зрозуміти, що є правильним базовим рівнем для виробництва. Для практичності вам потрібно стати єдиною ниткою.

Це те, що потрібно включити до аналізу альтернатив.

З огляду на обмеження, які ви згадуєте у коментарях (наприклад: не вдається потрапити на сторінку завантаження Git, платформу Windows та за допомогою Visual Studio 2005), я можу побачити 2 варіанти, обидва з яких я раніше використовував у подібній ситуації:

1. Використовуйте Visual SourceSafe, як пропонує Емерсон у коментарі. Я працював з командою, що використовує VS 2005 кілька років тому, тоді як більшість інших компаній використовували стандартний контроль версій в Linux / Unix, і вони із задоволенням використовували Visual SourceSafe для своєї CM. На даний момент це досить старомодно, але краще, ніж нічого.
2. Якщо говорити про краще, ніж нічого, я був у подібному зв’язку і сам. Якщо ви навіть не можете використовувати VSS (можливо, плагін не встановлений?), А оскільки ви кажете, що місця для зберігання є багато, сподіваємось, вам дозволено використовувати деякі з них. Я реалізував ручний протокол управління версіями файлів. Наприкінці кожного робочого дня я б скопіював свою кодову базу в новий каталог з печаткою дати. Якщо мені потрібно повернутися до попередньої роботи (або відкотити), я би переглянув попередні датовані каталоги, щоб знайти потрібні мені зміни. Оскільки у вас є Visual Studio доступний протягом декількох годин, ви, ймовірно, можете використовувати VS 2005 для написання простого інструменту, який допоможе вам автоматизувати створення каталогу та копіювання файлів.

У них є багато тонн для зберігання

Чи дозволено вам використовувати його за своїм рішенням?

Якщо так, ви можете створити віддалене сховище файлової системи, яке краще нічого. Мінус полягає в тому, що натискання стає повільним, поки проект зростає, оскільки gitпотрібно завантажити все сховище, щоб шукати зміни ...

поки що комп'ютери ведуть себе як звичайний користувач, забороняючи мені встановлювати програмне забезпечення сторонніх виробників.

gitтакож є портативним додатком, щоб ви могли встановити його у $ HOME або% USERPROFILE% шлях.

Як висновок: я не дозволяв би заборонити мені використовувати SCM ¹ . Я використовував би це "приватно". Зрештою, ніхто не може сказати, чи був ваш код розроблений з чи десь не зареєстрований ...

¹ ) коли я почав використовувати gitкілька років тому, мій клієнт віддав перевагу іншому SCM, який був досить повільним і ненадійним (що все-таки є НОГО для SCM (зрештою). Я використовував git"приватно" поверх інших SCM) з дистанційним "файловим" пультом на мережевій спільній доступності та зареєстрований у їх SCM лише після випуску нової версії продукту.

Ваше оточення

Перш за все, я не був би таким песимістичним, як показано у багатьох коментарях та відповідях. Так, це "кам'яний вік", але є набагато гірші обставини. Якщо ваше загальне робоче середовище (колеги, місце розташування, оплата праці, цікаві програми з програмування тощо) чудово і на ваш смак, то, безумовно, дотримуйтесь цього. Що стосується ІТ, то воно є. Це відбувається не лише в державних установах, а й у банківській справі, страхуванні або там, де є дуже велика увага до безпеки, або дуже старих структур.

Якщо вставити USB-накопичувач і запустити якийсь .exe звідти, це було б негайним приводом для припинення в інших місцях, тому я б не радив вам намагатися щось обійти.

Спробуйте ще раз git

Тепер на ваш вибір. Я настійно рекомендую git замість svn для вас. Якщо ви все-таки робите проекти з однією людиною, то git - це лише локальний каталог .gitвсередині кореня програми, нічого іншого.

Не просіть свого начальника / ІТ про "SCM", а попросіть їх спеціально встановити gitна вашій машині, щоб ви могли розвиватися швидше та з більш високою якістю. Дайте їм зрозуміти, що ви не хочете підштовхувати свій код кудись інше, що вам не потрібен сервер, який працює десь, і що він не затребує значного місця або часу на обслуговування.

Git збільшить швидкість і якість для вас просто тому, що ви можете працювати з більшою впевненістю (тому що ви можете скасувати будь-які зміни, які ви зробили) і дозволить вам працювати на декількох гілках одночасно. Тобто, якщо ви працюєте над великим завданням, і щось в цьому виникає, що потребує вашої негайної уваги, ви можете просто перейти до нової гілки, швидко виправити це, а потім повернутися до тривалого завдання.

Робити це вручну

Якщо це взагалі неможливо, то, звичайно, ви можете зайнятися ручним управлінням джерелом. Створіть вручну "теги", скопіювавши свій код самостійно (можливо, створіть новий каталог із датою / часом та коротким описом того, що змінилося). Зберігайте журнал змін із детальними списками не лише змін, а й файлів, які ви змінили, а може бути й більше деталей.

Створіть "гілки", знову ж таки, скопіювавши свою роботу, і коли настав час об'єднатись назад, стати творчим за допомогою деяких довільних інструментів "diff" чи "diff3" - я не знаю, чи є у вас доступні, вам доведеться з’ясувати.

Якщо все це коштує вам багато часу, тоді добре подумайте, чи варто вам наслідувати наслідування SCM. Якщо ви виявите , що це варто, то поговоріть з вашим босом знову. Покажіть йому переваги вашої інструкції SCM (не лише "У мене є копія всієї моєї старої роботи", але "коли сталася помилка XYZ, я відразу змогла знайти причину, 5 випусків тому"). Потім скажіть їм, наскільки швидше це було б git.

Очевидно, якщо це зводить вас з розуму, шукати роботу - це завжди варіант.

Я думаю, що багато людей тут не вистачає "урядової установи" цього питання. Деякі урядові мережі мають дуже суворі правила щодо програмного забезпечення, дозволеного до них, і порушення цих правил є кримінальним злочином, можливо, навіть злочинним. Я б просив це через управління, щоб побачити, чи можете ви отримати певний рух при встановленні програмного забезпечення. Я б не ходив по ковбою і сам встановлював речі. Якщо ви працюєте з Linux / UNIX, подивіться, чи встановлені RCS (команди ci / co) або SCCS (команда sccs). Це старі засоби SCM, які раніше були досить стандартними. Це не дуже, але краще, ніж те, про що я пишу нижче. :)

Оскільки у вас є "багато" місця на диску, створіть дерево джерела. Які основи СКМ у малому масштабі? Будучи в змозі перевірити зміни, подивіться, що змінилося, позначте теги та при необхідності поверніться до старих версій. На одному рівні над деревом-джерелом створіть Makefile або сценарії, залежно від того, що у вас є, що робить наступне (це ароматизовані Linux / UNIX, команди Windows були б іншими)

зробити checkin - cp - джерело-джерело-джерело-дерево-дату (хоча б хвилину, якщо не другу, наприклад, джерело-дерево-20171205115433)

make status - diff -R source-tree source-tree-date | менше (тут буде трохи логіки, за замовчуванням до останньої резервної копії або надати аргумент на відміну від версії

make tag - ln -s source-tree-date release1.0 (зробити посилання на певну версію)

make revert - rm -r source tree && cp -a source-tree-date source tree

Продай їх їм

Ви залишили цей коментар :

Вони мають мережевий накопичувач, який я не знаю як, але це створює резервні копії в періоди. Так. Я ним користуюся і зберігаю там свої програми.

Іди до свого начальника і скажи щось у цьому ключі:

Бос, я помітив, що у нас є система, в якій ми розміщуємо додатки на мережевому диску, а якийсь сервіс робить резервні копії та відслідковує історію. Мені здається, ми робимо це лише нашою власною системою управління джерелами. Ми, мабуть, могли б звільнити багато місця та зробити всю систему набагато простішою, перейшовши на спеціальну систему управління джерелами управління, наприклад 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 для Windows має "портативну" версію . Ви можете скопіювати це на свій ПК або зберегти його на картці пам'яті, не потребуючи насправді нічого встановлювати. Якщо проблема полягає в простому встановленні, це буде вирішенням проблеми.

Зауважте, що якщо вони категорично проти SCM, ви можете поставити загострені запитання щодо ISO-9001, DO-178B або інших відповідних стандартів розробки програмного забезпечення.

Просто запустіть git над голою директорією, без жодного сервера. Зовсім не важливо, що ніхто більше не використовує контроль версій, оскільки ви можете керувати версіями свого каталогу. Git був розроблений саме для цього шахрайського сценарію впровадження SCM, і він працює добре.

Ви станете героєм, коли друга людина почне його використовувати, навіть якщо вам доведеться чекати, коли якийсь динозавр виб'є відро, щоб воно поширилося. Некомпетентність зараз керувати великими базами коду без SCM. Це як би вести бізнес, не перевіряючи нічого.

Насправді є три окремі речі, на яких ви хочете наполягати як професійний розробник: огляди коду, історія версій та відстеження запитів на зміни.

Ви можете самостійно відстежувати запити на зміни. Не так приємно, як з правильними інструментами, але можна. Друга частина - кодові огляди. Для цього вам потрібна попередня копія коду та різний інструмент. Коли ви думаєте, що зміна готова, ви переглядаєте її самі, ретельно порівнюючи її з попередньою версією, а потім замінюєте попередню версію на нову.

Для контролю версій, якщо ваше робоче місце не дозволяє отримати гідне рішення, це потрібна скринька записуваних DVD-дисків. Щоразу, коли у вас є версія, яку ви хочете зберегти, щоб мати змогу повернутися, ви створюєте новий DVD.

(Очевидно, все це не є порадою, яку слід приймати, якщо ви не перебуваєте на дійсно поганому робочому місці, як, очевидно, є ОП).