Каковы некоторые из лучших практик SCM?

Question

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

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

Поэтому мне интересно, есть ли у вас какие-либо советы относительно таких вещей, как:

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

Спасибо!

Answer 1

Поскольку вы используете git, вот некоторые из моих приемов, которые могут или не могут работать для вас:

1. Всегда работайте в локальной ветке с описательными именами, скажем, work / feature_name (используя удивительное завершение bash для git, чтобы помочь вам печатать)
2. Фиксируйте столько раз, сколько вы хотите, в локальных ветвях с краткими комментариями (чтобы задокументировать намерения напомнить себе). Таким образом, у вас есть полная оригинальная история мыслей / разработок, к которой вы можете вернуться.
3. Перед тем, как нажимать / публиковать коммиты / патчи, создайте ветку pu (предлагаемые обновления) (git checkout -b pu / feature_name) из вашей рабочей ветки и используйте git rebase -i для совершенных коммитов, т. Е. Связанных с группой небольших коммитов. (и / или разделение больших коммитов) на логические коммиты и написание значимых описаний (для других и для вас самих) убедитесь, что каждый логический коммит строит и передает регрессии.
4. Опубликуйте свое имя pu / feature_name (либо попросите людей вытащить его, либо просто нажмите на общедоступный сервер, например, github.)
5. Вероятно, вам потребуется несколько итераций по 3 и 4, если у вас есть процесс проверки кода.

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

Answer 2

Мне известно о двух оправданных и общепринятых способах применения силы совершать:

• Мелкозернистые коммиты, где вы делаете коммит рано, часто и небольшими порциями. Система может быть не в хорошем состоянии при каждом коммите. Основным преимуществом этой практики является то, что вы получаете очень четкое представление о том, что было изменено и когда, и с системой, подобной darcs , или с командой, подобной git-rebase, у вас есть шанс на «сбор вишни» совершает то, что вас интересует.

• Надежные фиксации, когда вы фиксируете только когда система находится в твердом состоянии, например, она не только создает, но и проходит регрессионные тесты.

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

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

Answer 3

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

Затем, когда у меня есть что-то готовое для продвижения вверх по течению (т. Е. Протестировано, задокументировано и т. Д.), Я нажимаю как один коммит, избегая беспорядка в центральном репо. Лучшее из обоих миров.

Answer 4

• Фиксируйте рано, часто коммите.
• Держите коммит маленьким. Если коммит большой, попробуйте разбить его там, где он имеет смысл.
• Не нарушайте код. Каждый коммит должен содержать код в рабочем состоянии.
• Попробуйте включить намерение в сообщение фиксации вместо только «что».
• Не комментируйте коды. Вместо этого удалите их.
• Использовать ветку для экспериментальных или потенциально опасных изменений кода.
• Отметьте свою отправленную версию.

Answer 5

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

Answer 6

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

Но для более крупных проектов со многими разработчиками важно, чтобы

• Всегда указывайте номер проблемы (может применяться любым хорошим SCM)
• Уменьшить количество коммитов
• Только зафиксировать рабочий код
• Только фиксировать код, который лучше, чем код, который был до
• Зафиксируйте чистый код (т.е. не оставляйте тестовый код, старый закомментированный код и т. Д.)
• Напишите не только «исправленную проблему X» в качестве комментария, но и указав дополнительную информацию об ошибке / изменениях, например «исправленная проблема X, когда панель будет расширяться за пределы размера окна».

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

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

* * 1 022 / B

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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

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