Предлагаю перевод хорошей статьи с советами по выполнению фиксаций в хранилище. Оригинал написан для проекта T2, но практически все советы универсальны и легко применимы для любого другого проекта. А самое главное — они действительно полезны.
Upd: В названии статьи хоть и фигурирует SVN, но советы, изложенные в ней, подходят ко всем известным мне системам кондроля версий. Стоит так же заметить, что советы направлены в основном на командную разработку.
Т.к. фиксация изменений в SVN может иметь серьёзные последствия, найдите время для того, чтобы разобраться, не сломает ли ваш код что либо у других разработчиков. Ведь хранилище кода одно на всех, и если вы что-то сломаете, то это сломается у всех. SVN, конечно, позволяет вернуться к предыдущим версиям и это может помочь решить проблему, но лучше все же предупредить проблему, чем её в последствии героически устранять.
Прим. пер.: в этом пункте речь идет о компиляции, что для веб-разработки не актуально, но если под компиляцией понимать отсутствие ошибок, то пункт вполне обретает смысл и для веб-приложений
Скомпилируйте код и устраните все ошибки прежде чем фиксировать изменения в хранилище. Убедитесь, что новые файлы были зафиксированы. Если их не будет, то у вас локально код будет компилироваться, а все остальные не смогут этого сделать.
Вам, безусловно, следует убедиться, что код компилируется с вашими локальными настройками и на вашей платформе. Вы также должны принять во внимание последствия вашей фиксации для компиляции на другой архитектуре.
Запустите приложение и проверьте работу тех участков, которые могли быть затронуты вашими изменениями, чтобы убедиться в том, что изменения ведут себя так, как вы задумывали.
Сделайте “svn up” и “svn diff” перед фиксацией. Получите сообщения от SVN о конфликтах, неизвестных файлах и прочее. “svn diff” покажет, что же именно вы фиксируете. Проверьте, действительно ли это то, что вы собирались фиксировать.
Комментарии должны быть понятны любому, кто видит только лог. Они не должны зависеть от информации вне контекста фиксации. Попробуйте описать только те файлы, которые реально затрагиваются в описываемых в комментариях изменениями.
На практике, заносите в комментарии всю важную информацию, которую невозможно увидеть из вывода команды diff.
Когда вы планируете сделать изменения, затрагивающие множество различного кода в SVN, сообщите об этом в подписном листе заранее.
Изменения, затрагивающие множество кода в SVN, такие как переход на использование новых функций в библиотеках, способны сломать прочий код, даже если они кажутся тривиальными. Такие изменения могут быть опасны потому, что приложение должно по ряду причин компилироваться со старыми библиотеками. Сообщив об изменениях заранее, разработчики могут подготовиться и высказать обеспокоенность, прежде, чем что-то сломается.
Если ваша фиксация сломала что-то или имеет побочное действие на другие участки кода, будьте ответственными и исправьте это или помогите другим исправить проблему.
Избегайте ситуаций, подобных этой: “Я не знаю, почему он падает, но когда я делаю это, он больше не падает” или “Я не вполне уверен, что это правильно, но во всяком случае у меня это работает”.
Не злоупотребляйте своим SVN-аккаунтом, чтобы пропихнуть изменения, отвергнутые другими разработчиками
Если есть разногласия по поводу изменения кода, они должны быть урегулированы путем обсуждения их в списке рассылки или в частном порядке, а не насильной заменой кода других, просто зафиксировав свои изменения в хранилище.
Используйте одинаковый комментарий для обеих фиксаций – основного исправления и переносимого (только дополните комментарий номером ревизии основной фиксации). Таким образом, можно легко увидеть, какие исправления были уже перенесены.
Для того, чтобы сохранять вашу систему учета ошибок и SVN синхронизированными, вы должны указывать номер ошибки в комментариях к вашим фиксациям, а затем закрывать ошибку в системе учета.
SVN имеет возможность фиксировать более одного файла за один раз. Поэтому, пожалуйста, фиксируйте все связанные изменения в нескольких файлах (даже если они охватывают несколько каталогов одновременно) за один раз. Таким образом, вы будете уверенны, что хранилище останется в компилируемом состоянии (т.е. код в хранилище компилируется без ошибок, — прим. пер.) до и после фиксации, а так же наборы изменений легки для слияний или откатов.
Изменение форматирования кода, такое как отступ или разрежение, просто взрывает diff, что сильно затрудняет поиск изменений в коде если они перемешаны с форматированием. Фиксирование изменений форматирования отдельно разрешает эту проблему.
P.S.: кросспост — lobach.info/develop/svn/svn-commit-tutorial
Upd: В названии статьи хоть и фигурирует SVN, но советы, изложенные в ней, подходят ко всем известным мне системам кондроля версий. Стоит так же заметить, что советы направлены в основном на командную разработку.
Дважды подумайте перед фиксацией изменений
Т.к. фиксация изменений в SVN может иметь серьёзные последствия, найдите время для того, чтобы разобраться, не сломает ли ваш код что либо у других разработчиков. Ведь хранилище кода одно на всех, и если вы что-то сломаете, то это сломается у всех. SVN, конечно, позволяет вернуться к предыдущим версиям и это может помочь решить проблему, но лучше все же предупредить проблему, чем её в последствии героически устранять.
Никогда не фиксируйте код, который не компилируется
Прим. пер.: в этом пункте речь идет о компиляции, что для веб-разработки не актуально, но если под компиляцией понимать отсутствие ошибок, то пункт вполне обретает смысл и для веб-приложений
Скомпилируйте код и устраните все ошибки прежде чем фиксировать изменения в хранилище. Убедитесь, что новые файлы были зафиксированы. Если их не будет, то у вас локально код будет компилироваться, а все остальные не смогут этого сделать.
Вам, безусловно, следует убедиться, что код компилируется с вашими локальными настройками и на вашей платформе. Вы также должны принять во внимание последствия вашей фиксации для компиляции на другой архитектуре.
Тестируйте ваши изменения перед фиксацией
Запустите приложение и проверьте работу тех участков, которые могли быть затронуты вашими изменениями, чтобы убедиться в том, что изменения ведут себя так, как вы задумывали.
Дважды проверьте то, что фиксируете
Сделайте “svn up” и “svn diff” перед фиксацией. Получите сообщения от SVN о конфликтах, неизвестных файлах и прочее. “svn diff” покажет, что же именно вы фиксируете. Проверьте, действительно ли это то, что вы собирались фиксировать.
Всегда добавляйте содержательные комментарии к фиксации
Комментарии должны быть понятны любому, кто видит только лог. Они не должны зависеть от информации вне контекста фиксации. Попробуйте описать только те файлы, которые реально затрагиваются в описываемых в комментариях изменениями.
На практике, заносите в комментарии всю важную информацию, которую невозможно увидеть из вывода команды diff.
Система контроля версий не является заменой общению между разработчиками
Когда вы планируете сделать изменения, затрагивающие множество различного кода в SVN, сообщите об этом в подписном листе заранее.
Изменения, затрагивающие множество кода в SVN, такие как переход на использование новых функций в библиотеках, способны сломать прочий код, даже если они кажутся тривиальными. Такие изменения могут быть опасны потому, что приложение должно по ряду причин компилироваться со старыми библиотеками. Сообщив об изменениях заранее, разработчики могут подготовиться и высказать обеспокоенность, прежде, чем что-то сломается.
Возьмите на себя ответственность за собственные фиксации
Если ваша фиксация сломала что-то или имеет побочное действие на другие участки кода, будьте ответственными и исправьте это или помогите другим исправить проблему.
Не фиксируйте код, который вы не понимаете
Избегайте ситуаций, подобных этой: “Я не знаю, почему он падает, но когда я делаю это, он больше не падает” или “Я не вполне уверен, что это правильно, но во всяком случае у меня это работает”.
Если вы не нашли решение проблемы, обсудите её с другими разработчиками.
Не злоупотребляйте своим SVN-аккаунтом, чтобы пропихнуть изменения, отвергнутые другими разработчиками
Если есть разногласия по поводу изменения кода, они должны быть урегулированы путем обсуждения их в списке рассылки или в частном порядке, а не насильной заменой кода других, просто зафиксировав свои изменения в хранилище.
Если вы фиксируете багфикс, учитывайте перенос исправлений в другие ветки
Используйте одинаковый комментарий для обеих фиксаций – основного исправления и переносимого (только дополните комментарий номером ревизии основной фиксации). Таким образом, можно легко увидеть, какие исправления были уже перенесены.
Если вы исправляете ошибки, зафиксированные в системе учета ошибок, добавьте в комментарий номер ошибки
Для того, чтобы сохранять вашу систему учета ошибок и SVN синхронизированными, вы должны указывать номер ошибки в комментариях к вашим фиксациям, а затем закрывать ошибку в системе учета.
Создавайте атомарные фиксации
SVN имеет возможность фиксировать более одного файла за один раз. Поэтому, пожалуйста, фиксируйте все связанные изменения в нескольких файлах (даже если они охватывают несколько каталогов одновременно) за один раз. Таким образом, вы будете уверенны, что хранилище останется в компилируемом состоянии (т.е. код в хранилище компилируется без ошибок, — прим. пер.) до и после фиксации, а так же наборы изменений легки для слияний или откатов.
Не смешивайте изменения форматирования и изменения кода
Изменение форматирования кода, такое как отступ или разрежение, просто взрывает diff, что сильно затрудняет поиск изменений в коде если они перемешаны с форматированием. Фиксирование изменений форматирования отдельно разрешает эту проблему.
P.S.: кросспост — lobach.info/develop/svn/svn-commit-tutorial
