Ах, контроль над исходным кодом, если есть более важный инструмент, который без разбора охватывает языки программирования без какой-либо пользы, я еще не видел его. Это важный компонент того, как многие из нас работают; жизненная сила многих команд разработчиков, если хотите. Так почему же мы часто ошибаемся? Почему некоторые из действительно базовых основ систем управления версиями так плохо изучены?
Я свел это к 10 практикам — или «заповедям», если хотите, — которые часто нарушаются или не совсем понятны с самого начала. Все это относится к продуктам управления версиями всех типов и языкам программирования всех видов. Я выберу несколько примеров из Subversion и .NET, но они широко применимы к другим технологиям.
1. Остановитесь прямо сейчас, если вы используете VSS — просто остановите это!
Он мертв. Отпусти ситуацию. Нет, на самом деле он уже много лет находится на жизнеобеспечении, умирая от удушья, так как более молодые и качественные инструменты VCS пролетели мимо него. И теперь это действительно серьезно умирает, так как Microsoft наконец-то отключится в следующем году (после нескольких попыток исполнения).
Справедливости ради, VSS был отличным инструментом. В 1995 году его просто затмили такие инструменты, как Subversion, а затем распространенные парни, такие как Git и Mercurial. Microsoft явно заявляла о своем намерении заменить его на протяжении многих лет — все дело в TFS не было случайностью!
Дело в том, что VSS очень широко, широко, почти единодушно презирают из-за ряда серьезных недостатков по сегодняшним стандартам. В народе известная как система уничтожения исходного кода Microsoft , каким-то образом ей удается просто продолжать цепляться за жизнь, несмотря на тщательно документированные глюки, недостатки и необходимую функциональность (по сегодняшним стандартам), которых просто не существует.
2. Если он не находится в управлении источниками, он не существует
Повторяйте эту мантру ежедневно — «Единственная мера прогресса — это рабочий код в управлении исходным кодом». Пока ваша работа не появится в единственном истинном источнике правдивости кода — репозитории исходного кода для проекта — его просто не существует.
Конечно, вы спрятали это где-то на своей локальной машине, но сейчас это никому не приносит пользы, не так ли? Они не могут взять вашу версию, они не могут объединить их, вы не можете развернуть ее (если вы не развернули ее неправильно ), и вы — один отказ SSD от потери всего этого навсегда.
Как только вы примете мышление о том, что оно не существует, пока оно не будет совершено, целый ряд других хороших практик начнет становиться на свои места. Вы разбиваете задачи на более мелкие единицы, чтобы вы могли фиксировать их атомарно. Вы интегрируетесь чаще. Вы страхуете себя от этих надоедливых локальных сбоев оборудования.
Но что более важно (по крайней мере, для вашей команды), вы показываете, что на самом деле что-то производите. Снижение графиков записи или списки задач — это хорошо, но с чем они на самом деле мириться? Если они не связаны с рабочим кодом в управлении исходным кодом, они означают zip.
3. Фиксируйте заранее, совершайте часто и не жалейте лошадей
В дополнение к предыдущему пункту, единственный способ избежать «призрачного кода» — того, что только вы можете видеть на своем локальном компьютере, — это вводить его в VCS рано и часто и не жалеть лошадей . Решение проблем из предыдущего пункта — это одна вещь, которую достигает ранний и часто применяемый подход, но вот несколько других, которые могут существенно повлиять на вашу работу:
- Каждая совершенная ревизия дает вам позицию отката. Если вы в корне ошибаетесь (не лгите, мы все так делаем!), Вы откатываетесь на один час изменений или на одну неделю?
- Риск кошмара слияния резко возрастает со временем. Слияние никогда не бывает веселым. Когда-либо. Если вы не фиксировали код в течение нескольких дней и вдруг осознали, что у вас 50 конфликтов с изменениями других людей, вы не станете счастливым участником.
- Это заставляет вас выделять элементы в отдельные единицы работы. Допустим, у вас есть функция на 3 человека в день. Часто люди не будут совершать действия до конца этого периода, потому что они пытаются собрать всю коробку и кости в одну логическую единицу. Конечно, такая большая задача неизбежно состоит из более мелких, дискретных функций, и частое выполнение заставляет вас идентифицировать каждую из них, создавать их одну за другой и передавать их в VCS.
Когда вы работаете таким образом, ваша история коммитов неизбежно начинает напоминать полурегулярную схему множественных коммитов каждый рабочий день. Конечно, это не всегда будет последовательный шаблон, бывают моменты, когда мы останавливаемся и проводим рефакторинг или проходим этапы тестирования или любой другой способ совершенно законных действий, которые прерывают нормальный цикл разработки.
Однако, когда я вижу отдельного человека — и особенно весь проект — где я знаю, что мы должны быть в нормальном цикле разработки, и есть целые дни или даже несколько дней, когда ничего не происходит, я очень волнуюсь. Я волнуюсь, потому что согласно предыдущему пункту, никакая измеримая работа не была сделана, но я также волнуюсь, потому что это обычно означает, что что-то не так. Часто развитие происходит по принципу «вскипятить океан» (т.е. пытаться сделать все сразу), или абсолютно ничего ценного не происходит вообще, потому что люди застряли в проблеме. В любом случае, что-то не так, и система контроля версий выдает большой красный флаг, чтобы вы знали.
4. Всегда проверяйте свои изменения перед совершением
Внедрить код в систему контроля версий легко — слишком просто! (Заставляет задуматься, почему предыдущий пункт кажется таким сложным.) В любом случае, в конечном итоге вы получаете изменения и файлы, которые передаются с опрометчивой энергией. «Есть изменения где-то под корнем моего проекта — быстро — запустите это!»
То, что происходит, является одним (или обоими) из двух вещей: во-первых, люди непреднамеренно получают целую кучу ненужных файлов в хранилище. Кто-то видит окно, подобное показанному ниже, нажимает «Выбрать все» и бинго — хранилище загрязняется такими вещами, как папки отладки и другие ненужные файлы, которых там быть не должно.
Или, во-вторых, люди фиксируют файлы без проверки того, что они действительно изменили. Это действительно легко сделать, когда вы получите такие вещи, как файлы конфигурации или определения проекта, где много всего происходит одновременно. Это позволяет очень просто непреднамеренно помещать в репозиторий вещи, которые просто не были предназначены для фиксации, и, конечно, они вполне могут быть удалены другими разработчиками. Можете ли вы вспомнить все, что вы изменили в этом файле конфигурации?
Решение простое: вы должны проверить каждое изменение непосредственно перед фиксацией . Это проще, чем кажется, честно. Весь «непреднамеренно зафиксированный файл» может быть в значительной степени смягчен с помощью функции «игнорирования», которую реализуют многие системы. Вы никогда не хотите зафиксировать файл Thumbs.db, поэтому просто проигнорируйте его и покончите с этим. Вы также можете не захотеть фиксировать каждый файл, который изменился в каждой ревизии — так что не делайте этого!
Что касается изменений в файлах, то обычно у вас там есть довольно удобная функция сравнения. Почему я снова фиксирую этот файл Web.config?
Ах, я помню сейчас, я хотел уменьшить максимальное количество неверных попыток ввода пароля с 5 до 3. О, и я поиграл с фиктивной страницей входа в систему, которую я определенно не хочу помещать в репозиторий. Такая практика предмитной проверки также значительно упрощает переход к следующему разделу …
5. Помните убийцу топора при написании коммитов
Есть старая поговорка (источник неизвестен), которая гласит: «Напишите каждое сообщение о коммите, как следующий человек, который читает его, — маньяк с топором, который знает, где вы живете». Если я был этим маньяком, и я копаюсь в толщах вашего кода, пытаясь отследить ошибку, и все, что я могу понять из вашего сообщения о коммитах, это «обновить некоторые коды», будьте осторожны, я иду за вами!
Вся идея коммитов состоит в том, чтобы объяснить, почему вы зафиксировали код. Каждый раз, когда вы вносите какие-либо изменения в код, вы делаете это по определенной причине. Может быть, что-то было сломано. Возможно, клиенту не понравилась цветовая схема. Возможно, вы просто настраиваете конфигурацию сборки. Что бы это ни было, для этого есть причина, и вам нужно оставить это позади.
Зачем? Ну, есть несколько разных причин, и они различаются в зависимости от контекста. Например, используя функцию «обвинить» или другую подобную функцию, которая показывает, кто изменил что и, надеюсь , почему. Я не могу вспомнить, что я делал в Web.config этого проекта 18 месяцев назад или почему я копался в настройках приложения, но поскольку я оставил достойное сообщение о коммите, все стало очень просто:
Это похоже на просмотр изменений во времени. Хочу ли я увидеть всю историю файла, как показано ниже, или я просто хочу увидеть, что команда достигла вчера, с описательным бумажным следом комментариев означает, что для того, чтобы получить представление, требуется не больше, чем случайный взгляд. о том, что происходит.
И, наконец, сообщения о фиксации абсолютно бесценны, когда дело доходит до отслеживания ошибок. Например, чтобы понять, почему сборка ломается в вашей среде непрерывной интеграции. Очевидно, мой пример явно очевиден, но дело в том, что вывод этой информации на поверхность может превратить сложные проблемы в абсолютно легкие задачи.
Имея это в виду, вот несколько шаблонов хороших сообщений коммита:
- Некоторое дерьмо.
- Оно работает!
- исправить некоторые долбаные ошибки
- исправление
- Исправлена небольшая ошибка …
- обновленный
- опечатка
- Редакция 1024 !!
Хорошо, я выбрал все это из вопроса переполнения стека о том, что такое сообщение WORST commit, которое вы когда-либо создавали, но дело в том, что ни одно из них не отличается от многих сообщений, которые я видел в прошлом. Они абсолютно ничего не говорят о том, что на самом деле произошло в коде; это нежелательные сообщения.
Еще одна вещь о коммит-сообщениях; сообщения о последующей фиксации от того же автора никогда не должны быть идентичными . Причина проста: вы берете на себя управление исходным кодом только потому, что что-то изменилось с предыдущей версии. Ваш код теперь находится в состоянии, отличном от предыдущей версии, и если ваше сообщение о фиксации является точным и полным, оно логически не может быть идентичным. Кроме того, если он был идентичен (возможно, где-то есть законный крайний случай), журнал теперь немного беспорядочный для чтения, поскольку нет никакой возможности различить разницу между двумя коммитами.
6. Вы должны зафиксировать свои собственные изменения — вы не можете делегировать их
Как бы странно это ни звучало, такое случается, и я видел это не раз, совсем недавно, только на прошлой неделе. Здесь происходит то, что репозиторий управления исходным кодом находится на пьедестале. По разным причинам команда рассматривает его как чистую, чистую среду идеального кода. Чтобы поддерживать это святое состояние, код передается только ведущему разработчику, который тщательно собирает, анализирует и (предположительно) настраивает и улучшает код перед его фиксацией.
Это довольно легко наблюдать эту картину на расстоянии. Очень редкие коммиты (возможно, еженедельные), только один автор из команды с несколькими разработчиками и неизбежно конфликтный хаос, если кто-то еще подходил к проекту в течение этого длительного периода без коммитов. Очень, очень неприятные вещи.
Здесь есть две основные вещи, неправильные: во-первых, контроль исходного кода не должен быть таким девственным, беспрепятственным хранилищем нетронутого кода; по крайней мере, не на протяжении всех циклов разработки. Это место, где команда часто интегрируется, откатывается, когда что-то идет не так, и обычно объединяется вокруг одной общей базы. Он не должен быть идеальным на протяжении всего этого процесса, он только должен (пытаться) достичь этого состояния в точках выпуска в жизненном цикле приложения.
Другая проблема — и это действительно меня поражает — это то, что с точки зрения разработчика, эта модель означает, что у вас нет контроля версий! Это означает, что нет интеграции с кодом от сверстников, нет отката, нет журнала обвинений, нет ничего! Вы просто сидите в своем маленьком бункере, пишете код и ждете, чтобы передать его боссу в какой-то произвольный момент в будущем.
Не делай этого. Когда-либо.
7. Управление версиями вашей базы данных не является обязательным
Это один из тех, которые все знают, что должны делать, но очень часто они просто складывают его в «слишком жесткую» корзину. Проблема в том, что многие (большинство?) Приложений просто не будут работать без своей базы данных. Если вы не управляете версией базы данных, вы получите неполное представление о приложении, которое на практике оказывается совершенно бесполезным.
Большинство систем VCS работают просто путем создания версий файлов в файловой системе. Это просто отлично подходит для ваших типичных файлов приложений, таких как HTML-страница, изображения, CSS, файлы конфигурации проекта и все остальное, что находится в файловой системе в виде небольших отдельных блоков. Проблема в том, что реляционные базы данных работают не совсем так. Вместо этого вы в конечном итоге получаете эти большие старые данные и файлы журналов, которые охватывают целую кучу различных объектов и данных. Это довольно грязная штука, когда дело доходит до контроля версий.
В наши дни изменилось предложение по управлению версиями баз данных — доступность таких инструментов, как превосходный SQL Source Control от Red Gate. Я подробно писал об этом в прошлом году в статье о том, как раскачивать свой мир управления исходным кодом SQL с помощью Red Gate, поэтому я не буду вдаваться в подробности; достаточно сказать, что управление версиями базы данных теперь просто!
Честно говоря, если вы не управляете версиями своих баз данных, вы несете большой риск в разработке без веской причины. У вас нет единого источника правды, позиции отката и простого сотрудничества с командой, когда вы вносите изменения. Жизнь просто лучше с базой данных в системе контроля версий ?
8. Выход компиляции не относится к управлению исходным кодом
Вот простой способ думать об этом: ничто, которое автоматически генерируется в результате построения вашего проекта, не должно находиться в системе контроля версий. Для людей .NET это означает практически все, что находится в папках «bin» и «obj», обычно это файлы .dll и .pdb.
Зачем? Потому что, если вы сделаете это, ваши сотрудники будут ненавидеть вас. Это означает, что каждый раз, когда они вносят изменения в VCS, они перезаписывают свой собственный скомпилированный вывод вашим. Это и кошмар слияния (вы просто не можете этого сделать), плюс он может сломать вещи до следующей перекомпиляции. А потом , когда они делают перекомпиляции и вновь, вся проблема проклятый просто получает повторяется в направлении , противоположном направлению и на этот раз вы находитесь на приемном конце. Вид служит вам правильно, но это не то, где мы хотим быть.
Конечно, другая проблема в том, что это просто расточительно. Он тратится на диск компьютера управления исходным кодом, тратится впустую на пропускную способность и дополнительную задержку каждый раз, когда вам нужно отправить его по сети, и это, безусловно, пустая трата вашего времени каждый раз, когда вам приходится иметь дело с неизбежными конфликтами, которые это практика производит.
Итак, мы вернулись к шаблонам «игнорирования», упомянутым ранее. Как только пути, такие как «bin» и «obj», настроены на игнорирование, все становится действительно очень просто. Сделайте это один раз, передайте правило, и все будут счастливы.
На самом деле, я даже зашел так далеко, что написал предварительные хуки, которые выполняются на сервере VCS, просто для того, чтобы этот вид контента никогда не входил в систему контроля версий с самого начала. Конечно, это может быть немного навязчиво, когда VCS ударит по вашей руке, но это происходит только тогда, когда вы этого заслуживаете! Кроме того, я бы предпочел вернуть неудобство виновному, а не передавать его на все время, вызывая конфликты у всех при следующем обновлении.
9. Никто больше не заботится о ваших личных настройках пользователя
Честно говоря, я думаю, что довольно часто люди даже не осознают, что вводят свои личные настройки в систему контроля версий. Вот в чем проблема: многие инструменты создают артефакты, которые управляют вашими личными, локальными конфигурациями. Они предназначены только для вас, и они обычно будут отличаться от всех остальных. Если вы поместите их в VCS, вы вдруг перезаписываете личные настройки друг друга. Это не хорошо.
Вот пример типичного приложения .NET:
Дешевой раздачей должны быть расширения и описания типов, но в случае, если это не сразу понятно, файл .ReSharper.user и файл .suo (Solution User Options) оба, ну, в общем, ваши. Они никого другого.
И вот почему: давайте посмотрим в файл ReSharper:
<Configuration>
<SettingsComponent>
<string />
<integer />
<boolean>
<setting name="SolutionAnalysisEnabled">True</setting>
</boolean>
</SettingsComponent>
<RecentFiles>
<RecentFiles>
<File id="F985644D-6F99-43AB-93F5-C1569A66B0A7/f:Web.config"
caret="1121" fromTop="26" />
<File id="F985644D-6F99-43AB-93F5-C1569A66B0A7/f:Site.Master.cs"
caret="0" fromTop="0" />
В этом примере тот факт, что я включил анализ решения, записывается в пользовательский файл. Это нормально для меня, мне это нравится, другим нет. Обычно, потому что у них есть устаревший ПК со скидкой, но я отвлекся. Дело в том, что это мой настрой, и я не должен навязывать его всем остальным. То же самое относится и к узлу недавних файлов; только то, что я недавно открыл эти файлы, не означает, что это должно войти в чужую историю ReSharper.
Забавная заметка: общая некомпетентность VSS означает игнорирование файлов .ReSharper.user, это небольшая проблема .
Это похожая история с файлом .suo. Несмотря на то, что нет особого смысла заглядывать в него (здесь нет красивого XML, все в двоичном виде), файл записывает такие вещи, как состояние обозревателя решений, параметры публикации и другие вещи, которые вы не хотите навязывать другим людям.
Итак, мы вернулись к простому игнорированию этих шаблонов снова. По крайней мере, если вы не используете VSS.
10. Зависимости тоже нуждаются в доме
Это может быть последняя из десяти заповедей, но она действительно очень важная. Когда приложение имеет внешние зависимости, которые необходимы для его успешного построения и запуска, включите их в систему управления версиями! Проблема, с которой обычно сталкиваются люди, заключается в том, что они все ведут себя очень хорошо в своей маленькой среде со своими собственными настройками и своими локальными зависимостями, затем они помещают все в систему контроля версий, уходят и думают, что все круто. И они есть, по крайней мере, пока кто-то еще, у которого нет таких же местных приличий, сносит его, и все терпит неудачу катастрофически.
Я вспомнил об этом сегодня, когда вытащил старый проект из системы контроля версий и попытался создать его:
Я работал на предположении, что NUnit всегда будет на машине, но на этот раз это было не так. К счастью, очень блестящий NuGet выручал меня быстро, но это не всегда так просто , и это делает всегда занять некоторое пустячный , когда вы начинаете обнаружить , что зависимости отсутствуют. В некоторых случаях они не будут общедоступными, и попытка выследить их может быть совершенно болезненной.
Это произошло совсем недавно, когда я вытащил проект из системы управления исходным кодом, запустил его и обнаружил отсутствующую сборку, расположенную по пути, начинающемуся с «c: \ Program Files…». Я потратил буквально часы, пытаясь отыскать последнего парня, который работал над этим (который, конечно, был на другом конце света), получить сборку, поместить ее в папку «Библиотеки» в проекте и фактически поместить ее в VCS. так что следующий бедняга, который сталкивается с проектом, не испытывает такой же боли.
Конечно, другая причина, по которой это очень важно, заключается в том, что если вы работаете в какой-либо среде непрерывной интеграции, на вашем сервере сборки не будут установлены эти библиотеки. Или, по крайней мере, вы не должны зависеть от этого. Недавно Дуг Рэтбоун сделал об этом хорошее замечание, когда написал о сторонних инструментах, которые находятся под вашим контролем исходного кода . Это не всегда возможно (и у нас был хороший стеб на этот счет), но обычно это довольно простое предложение.
Так что сделайте всем одолжение и убедитесь, что все необходимое для того, чтобы ваше приложение на самом деле создавалось и работало, находится в VCS с первого дня.
Резюме
Ничто из этого не сложно. Честно говоря, они действительно очень просты: совершайте коммиты рано и часто, знайте, что вы делаете, и что это должно быть на самом деле в VCS, объясните свои коммиты и убедитесь, что вы делаете это сами, не забывайте базы данных и не забудьте о зависимостях. Но, пожалуйста, забудьте VSS ?
Источник: http://www.troyhunt.com/2011/05/10-commandments-of-good-source-control.html