Босс скептически относится к использованию системы контроля версий для нового проекта.

См. Https://softwareengineering.stackexchange.com/questions/109817/superior-refusing-to-use-subversion

Мой вопрос похож, но вот основные различия в моем сценарии:

• Мы начинаем новый проект с нуля, используя PHP и веб-технологии. В разработке не было бы простоев, поскольку мы приняли бы ее с самого начала, если бы у меня был свой путь.

• Моя команда разработчиков состоит из меня и моего босса. Мы являемся отделом информационных технологий сравнительно небольшой фирмы.

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

Предложение моего босса, прямо вставленное из электронного письма:

• Обновления должны быть представлены в виде пакетов в папке SUBMISSIONS. Пакет должен содержать все соответствующие файлы, а также файл «UPDATE.NFO», который содержит описание обновления, список всех включенных новых файлов (с описаниями) и список всех измененных файлов с подробностями модификации.

• Пакеты обновлений должны быть ориентированы на отдельный элемент, а не отклоняться от его предназначения. Код должен быть разработан так, чтобы он был модульным и по возможности использовался повторно.

• Все представленные пакеты должны быть установлены в тестовой среде каждого разработчика вскоре после отправки. Каждый разработчик должен рассмотреть новое дополнение и высказать любые опасения по поводу его установки в производственную среду. Стандартное обновление пакета должно проводиться не менее 3 рабочих дней для этого процесса проверки перед загрузкой в ​​производственную среду. Высокоприоритетные обновления / исправления могут пропустить это требование.

Причина, по которой был изобретен контроль источников, состоит в том, чтобы сделать все это автоматически, верно? Я предложил Subversion, потому что это то, что я использовал в колледже. Босс не любит подрывную деятельность, потому что «он создает беспорядок в коде» (то есть использует бинарную магию и плохо читается). Мы попробовали это один раз, но я думаю, что попытка использовать его в Windows приводила к странным ошибкам в нижнем / верхнем регистре, и мы не могли проверить наши файлы. Я не знаю, является ли это только подрывной деятельностью или всеми продуктами контроля версий, которые нежелательны.

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

Или я вообще не прав? Действительно ли необходим контроль источников в моей ситуации? Это наше основное программное обеспечение, критически важное для бизнеса, о котором мы говорим, поэтому, без сомнения, оно окажется огромным. Но есть только 2 разработчика (сейчас).

Кроме того, если я не смогу его убедить, есть ли смысл использовать его только для себя? Я говорю как человек с очень ограниченным опытом, фактически использующий SVN; все, что я действительно знаю, это проверка и фиксация. Какие функции управления исходным кодом (могут включать в себя другие продукты, кроме svn), которые могут помочь в моих индивидуальных усилиях по разработке?

Пожалуйста, не "получить другую работу" комментарии. Это не полезно для дебатов.

Не спрашивай его. Не говори ему. Покажи ему.

Установите svn, или git, или что угодно на какой-нибудь дополнительной машине. Тренируйтесь использовать это самостоятельно, пока не почувствуете себя комфортно, не просто используя это, но объясняя это. Если вы собираетесь сделать так, чтобы он чувствовал себя комфортно с вашей новой системой, вы должны быть более чем довольны этим сами. Вы должны быть в состоянии помочь ему легко восстановиться, когда он испортит слияние или проверит что-то в неправильном месте.

Когда будешь готов, покажи ему, о чем ты говоришь. Покажите ему, что это ничего не "портит". Отметьте, что он не только позволяет вам легко получить любую предыдущую версию кода, но и позволяет точно знать, что изменилось между любыми двумя версиями.

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

Дайте ему шпаргалку, которая облегчит ему использование вашей системы контроля версий.

Наконец, предложите несколько вариантов, но оставьте решение за ним . Следует ли вам настроить свой собственный сервер или использовать один из множества размещенных сервисов ? Стоит ли использовать svn, git или что-то еще? Следует ли перенести все семь проектов в систему или попробовать сначала один или два?

Преимущества контроля исходного кода выходят далеко за рамки того, что несколько разработчиков могут работать над одним фрагментом кода. Эрик Синк, основатель SourceGear , перечисляет несколько веских причин для использования системы контроля версий в качестве единственного разработчика :

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

У Эрика также есть очень хороший начальный курс по управлению исходным кодом для начинающих . Джоэл Спольски предлагает бесплатное онлайн- руководство по Mercurial, Mercurial - популярная распределенная система контроля версий.

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

И, наконец, прежде чем пытаться убедить своего босса, вы можете углубиться в тему обработки возражений . Это 101 продаж.

В случае неудачи - двигайтесь как можно скорее, не так много смысла тратить свое время на ветряные мельницы.

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

SVN - или любая другая система управления версиями, действительно - позволяет вам делать это тоже, но объединение немного более проблематично.

Если я не смогу убедить его, есть ли смысл использовать его только для себя?

Да. Есть польза от использования только для себя. Вы получаете историю изменений, чтобы вы могли увидеть, что отличается.

Нет. Нет никакой пользы, потому что ваш босс обрек ваш проект на множество бессмысленных переделок, потому что они все испортили.

Я настоятельно рекомендую, как уже упоминалось, до использования git, причина # 1 в том, что любая VCS является сетью безопасности на случай аварии. Ищите наклейку «В случае пожара: git commit, git push, покинуть здание». Код может храниться где-то еще, но не на ноутбуке, который может сломаться, быть украденным или чем-то еще ... даже локальный сетевой сервер - не самое безопасное место для чего-то столь же ценного, как код.

Номер 2. Отслеживание изменений, кто что сделал, когда и т.д ... Слияния, отменить. Номер 3. Diff магический инструмент для № 2 и многие другие случаи. № 4. Филиалы № 5. Пометка версий, выпусков и пр.

Вы можете найти больше информации об одном из самых распространенных рабочих процессов git здесь: https://nvie.com/posts/a-successful-git-branching-model/

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

Что касается вашей проблемы с текстовым регистром, избегайте использования Tortoise, я знаю, что большинство людей используют его в качестве графического интерфейса для git, так как это было очень распространено для SVN, так что это может быть первый выбор, вместо этого используйте командную строку или другой графический интерфейс, такой как github desktop или SourceTree от Atlasian.