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

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

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

Список программного обеспечения для управления кодом обширен, но самыми известными являются Mercurial, Subversion, PlasticSCM и, конечно же, их король: Git.

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

1. Вы будете использовать код, управляющий всем, во всех своих проектах.

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

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

Конечно, в команде, даже если ее двое, это необходимо. Так что нет оправдания, чтобы отказаться от бесплатных частных репо-сервисов, таких как Bitbucket, Gitlab или собственных Visual Studio Team Services от Microsoft.

2. Вы никогда не пойдете домой, не сделав коммит и не толкнувшись

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

Хотя это для Git, это действительно для любых других VCS: подтвердите и сохраните перед выходом, даже если это есть.

3. Вы внимательно изучите свои изменения перед тем, как сделать коммит.

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

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

4. Вы будете совершать часто

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

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

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

5. Вы убедитесь, что комментарии чего-то стоят.

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

6. Перед фиксацией вы выполните Fetch / Pull

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

Это чрезвычайно важно для нераспределенных систем, таких как Subversion, потому что вы можете напрямую обременять себя работой других. Однако другие системы, такие как Git, не позволяют этому случиться так быстро.

7. Вы не будете нажимать напрямую на мастера

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

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

8. Вы хорошо разбираетесь в инструменте смешивания и сравнения

Конфликты неизбежны при смешивании веток и получении обновлений с пультов. Так что научитесь хорошо обращаться со средствами сравнения, которые вы интегрируете в свою рабочую систему. Это могут быть инструменты «diff» вашего любимого клиента Git или какой-нибудь мощный (и бесплатный) внешний инструмент, такой как WinMerge, который мне очень нравится.

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

9. Вы будете версировать свои базы данных и многое другое

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

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

10. Вы исключите свой дерьмовый контроль над кодом

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

Файл .gitignorein Git или свойство svn: ignore в Subversion были придуманы для того, чтобы назвать что-то наиболее известным. Поместите туда файлы и папки, чтобы исключить их из управления кодом, и убедитесь, что вы не добавляете раздражающие или случайные вещи.

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

Больше контента на plainenglish.io