Я работаю в государственном учреждении. Используемая здесь технология и методы разработки программного обеспечения довольно старомодны.

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

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

Каков наилучший подход для сохранения качества кода и возможности добавления новых функций в приложения в дальнейшем?

Как я могу помнить изменения, которые я внес в код, не нарушая его?

РЕДАКТИРОВАТЬ: я забыл упомянуть, у них есть сетевые диски для каждого из компьютеров и каким-то образом эти сетевые диски создают или сохраняют резервные копии в определенные периоды. Однако, если я не создаю свой собственный план, позволяющий сохранить свою работу и иметь возможность добавлять новые функции, не нарушая существующий код, нет большого преимущества перед решением SCM.

РЕДАКТИРОВАТЬ: так как многие люди предложили портативный 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, но разрешают subversion (или какую-либо другую систему управления версиями).

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

В конце концов, если ваша компания не уважает вашу роль и опыт и не предоставит вам необходимые инструменты, то вы столкнетесь с еще более серьезными (и более стрессовыми) проблемами, чем отсутствие контроля над источниками.

По сути, существует проблема управления (ваша организация не понимает основ процесса разработки программного обеспечения , например, V-модель ), которая сводится к очевидной невозможности использования минимального рабочего процесса, методологии и инструментов нынешней эры. Это часто встречается (читайте о принципе Питера ).

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

Основная проблема: вы работаете в одиночку над своей базой кода или работаете с коллегами?

Если вы работаете в одиночку, вы можете использовать git локально на своем компьютере и .gitпериодически создавать резервные копии своего кода (и, возможно, даже своего хранилища) (в этом внешнем хранилище). Никогда не теряйте больше половины рабочего дня (поэтому делайте резервные копии своих данных периодически и надежно).

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

Если вы работаете с несколькими коллегами (я полагаю, что их меньше дюжины), вам необходимо убедить их всех использовать систему контроля версий, и вам, вероятно, нужно рассказать об этом своему непосредственному (и общему) руководителю. Он мог (возможно) решить (или просто неявно принять), что какой-то компьютер (возможно, даже какой-то старый рабочий стол, возможно, даже ваш собственный рабочий стол) используется в качестве git-сервера. Вам необходимо настроить этот сервер таким образом, чтобы резервное копирование git выполнялось по крайней мере каждый час; вы не можете позволить себе (и вам нужно поговорить с вашим боссом) потерять более часа работы вашей команды.

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

Но вам нужно использовать SCM. Вы можете задать своему боссу другой вопрос: должна ли ваша команда использовать существующий SCM или она должна заново изобрести колесо и создать свой собственный SCM? Боссы вообще против идеи изобретать велосипед. Если вам разрешено заново изобретать колесо, скажите своему боссу, что он работает полный рабочий день, по крайней мере, год (что, вероятно, заставит вашего босса плакать, а затем примет очевидный путь) и получайте удовольствие от создания собственного SCM. В этом маловероятном случае обязательно изучите существующие системы SCM и попросите сделать вашу систему SCM свободным программным инструментом (который будет использоваться и улучшаться другими командами).

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

Не устанавливайте какое-либо программное обеспечение (извне, даже с открытым исходным кодом) на свой рабочий компьютер без разрешения (в большинстве стран, особенно для чувствительной работы в области информационных технологий для штата, установка программного обеспечения без разрешения является юридически преступлением, и вы можете потерять свой работу или отправиться в тюрьму, если вы это сделаете .... так что убедитесь, что у вас есть на это разрешение, возможно, прикрывайте свою задницу, спрашивая разрешение в письменной форме или, по крайней мере, по электронной почте).

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

PS. Техническая сборка, настройка, установка, а затем использованиеgit (из исходного кода бесплатного программного обеспечения) или большинства других бесплатных программ VCS на компьютере (даже без разрешения администратора) - это совсем другой вопрос (который нужно задать в другом месте). И это можно установить и использовать gitбез какого-либо разрешения администратора, при условии, что у вас достаточно ресурсов (времени, места на диске, некоторого компилятора C и т. Д.) Для этого.

Я попытался установить сервер Visual SVN, но это не удалось, потому что у меня нет прав администратора для установки.

Это решается с помощью какой - то конкретной конфигурации и компиляции вашего gitили svnот свободного программного обеспечения исходного кода gitили SubVersion -не просто двоичная пакет- (а также исходный код из зависимостей ); как технически это сделать - это другой вопрос (но такие технические вопросы должны быть в другом месте). Конечно, вы должны попросить разрешения (у вашего босса), чтобы скомпилировать исходный код, gitпрежде чем делать это. Он расскажет вам или вы обсудите с ним практические детали (если он примет такое решение) в отношении переноса этого исходного кода извне на ваш рабочий компьютер.

Во-первых, я бы определил, на что конкретно возражает государственное агентство (предположительно, отдел информационных технологий). Если у них есть место для хранения, но нет возможности разместить виртуальные машины для серверов, проблема может заключаться в том, что ИТ-отдел отказывает серверу SVN или GIT, и это большая разница. Если проблема в стране происхождения - то есть мы не доверяем инструментам, созданным иностранными организациями, - это другая проблема.

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

Если вы абсолютно не можете использовать Git по какой-либо причине, у вас есть несколько вариантов:

• Обучите: не допуская контроля версий, они представляют значительный риск. Вам нужна возможность отказаться от изменений, которые окажутся более проблематичными. Вам нужна возможность сэкономить правительству деньги и время, и СКМ это делает. Вы должны быть в состоянии четко объяснить, как. Вы также, вероятно, должны сделать анализ альтернатив, чтобы действительно понять суть.
  • Одной из альтернатив будет хост Git
  • Еще одна файловая система Git
  • Выберите хотя бы один, но не более двух альтернативных инструментов SCM
  • и напоследок что значит работать без контроля версий
• Go 70-х годов развития: Есть причина, по которой 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, который был довольно медленным и ненадежным (в конце концов, это своего рода NOGO для SCM (o;). Я использовал git«один на один» поверх другого SCM с «файловым» пультом на общем сетевом ресурсе и регистрируется в их SCM только после выпуска новой версии продукта.

Ваше окружение

Прежде всего, я не был бы таким пессимистичным, как показано во многих комментариях и ответах. Да, это «каменный век», но обстоятельства гораздо хуже. Если ваша общая рабочая среда (коллеги, местоположение, оплата, интересная работа по программированию и т. Д.) В порядке и на ваш вкус, то непременно придерживайтесь ее. Что касается ИТ, то оно и есть. Это происходит не только в государственных учреждениях, но также в банковском деле, страховании или там, где очень большое внимание уделяется безопасности, или в очень старых структурах.

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

Попробуй мерзавец еще раз

Теперь на ваше усмотрение. Я бы настоятельно рекомендовал Git вместо SVN для вас. В любом случае, если вы делаете проекты с одним человеком, то git - это просто локальный каталог .gitвнутри корня вашего приложения, и ничего больше.

Не спрашивайте у своего начальника / ИТ-консультанта «SCM», а попросите их специально установить gitна вашу машину, чтобы вы могли разрабатывать быстрее и с более высоким качеством. Дайте им понять, что вы не хотите передавать свой код куда-то еще, что вам не нужен где-то работающий сервер и что он не будет занимать значительное пространство или время обслуживания.

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

Делать это вручную

Если это просто невозможно, то, конечно, вы можете сделать ручное управление исходным кодом. Создайте «теги» вручную, скопировав свой код (возможно, создайте новый каталог с датой / временем и кратким описанием того, что изменилось). Вести журнал изменений с подробными списками не только ваших изменений, но и файлов, которые вы изменили, и, возможно, даже более подробной информации.

Создайте «ветки», снова скопировав вашу работу, и когда придет время объединиться, проявить творческий подход с помощью произвольных инструментов «diff» или «diff3» - я не знаю, есть ли у вас какие-либо доступные, вам придется выяснить.

Если все это стоит много времени, то внимательно посмотрите, стоит ли вам эмулировать SCM. Если вы обнаружите , что это стоит, то поговорите с вашим боссом снова. Покажите ему преимущества вашего руководства SCM (не только «У меня есть копия всей моей старой работы», но «когда произошла ошибка XYZ, я сразу же смог найти причину, 5 выпусков назад»). Затем скажите им, насколько быстрее это будет git.

Очевидно, что если это сводит вас с ума, поиск работы всегда является вариантом.

Я думаю, что многим здесь не хватает «государственного учреждения» в этом вопросе. Некоторые правительственные сети имеют очень строгие правила в отношении программного обеспечения, разрешенного для них, и нарушение этих правил является уголовно наказуемым преступлением, возможно, даже уголовным. Я бы протолкнул его через руководство, чтобы посмотреть, сможете ли вы получить одобренное движение при установке программного обеспечения. Я бы не стал ковбойать и сам устанавливать вещи. Если вы работаете в Linux / UNIX, посмотрите, установлены ли RCS (команды ci / co) или SCCS (команда sccs). Это старые инструменты SCM, которые раньше были достаточно стандартными. Это не красиво, но лучше, чем то, что я собираюсь написать ниже. :)

Поскольку у вас «много» дискового пространства, создайте дерево исходных текстов. Каковы основы SCM в небольших масштабах? Будучи в состоянии проверить изменения, посмотреть, что изменилось, пометить вещи и вернуться к старым версиям, если это необходимо. На один уровень выше дерева исходного кода создайте Makefile или сценарии, в зависимости от того, что у вас есть, и выполните следующие действия (это Linux / UNIX, команды Windows могут отличаться)

make checkin - cp -a source-tree source-tree-date (по крайней мере, с точностью до минуты, если не секунды, например source-tree-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 исходное дерево

Продай им это

Вы оставили этот комментарий :

У них есть сетевой диск, который я не знаю как, но он создает резервные копии в определенные периоды. Да. Я использую его и храню там свои приложения.

Иди к своему начальнику и скажи что-нибудь в этом духе:

Босс, я заметил, что у нас есть система, в которую мы помещаем приложения на сетевой диск, а какой-то сервис создает резервные копии и отслеживает историю. Мне кажется, что мы просто внедряем собственную систему контроля версий. Возможно, мы могли бы освободить много места и сделать всю систему намного проще, переключившись на выделенную систему управления исходным кодом, такую ​​как 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.

(Очевидно, что все это не совет, который следует принимать, если вы не находитесь на действительно плохом рабочем месте, как, очевидно, ОП).