2011-05-04

10 заповедей хорошего контроля версий

Добрейшего.

Подкинули ссылку на хорошую статью из серии "10 тут-написать-самое-важное". Не смог пройти мимо, т.к. речь - о контроле версий! Называется The 10 commandments of good source control management, или "10 заповедей хорошего контроля версий".

Надо бы её перевести, но пока - перечень Важных Вещей:
  1. Если используете VSS - бросьте сейчас же. Прям щас!
  2. Если что-то не лежит под контролем версий - этого не существует.
  3. Делайте коммиты раньше, чаще и не откладывая.
  4. Всегда проверяйте изменения перед коммитом.
  5. Помните про психопата с топором перед написанием комментариев.
  6. Делайте коммиты сами, не перекладывая на других.
  7. Версионности БД избежать не получится.
  8. Результаты компиляции не кладутся под контроль версий.
  9. Никому не интересны ваши личные настройки.
  10. Зависимости надо тоже пристроить.
Как-то так. Просто и понятно. Да ещё и написано с юмором, так что рекомендую.

5 комментариев:

  1. Нет-нет, всё верно - есть (пока, к сожалению) такой зверь VSS - Visual Source Safe. Уродливая штука, за какой-то надобностью поддерживавшаяся Майкрософтом долгие годы. Поскольку автор - адепт МС-технологий, отсюда и первоочередной призыв сделать жизнь лучше :)

    ОтветитьУдалить
  2. Тогда прошу прощения, принял за опечатку :-)
    Последний стабильный релиз VSS датирован 2005 годом. Тем более пора забыть.

    ОтветитьУдалить
  3. [попыткф толстого троллинга]А что, микрософтские поделия ещё кто-то использует!?

    По делу. Автор, хоть бы текст перевёл, что ли. Лень матушка и облом батюшка, да? :-)

    Мне больше понравилось вот это. Написано коряво и нескладно, но ценных идей больше.

    По пунктам. 1 и 6 просто странные (особенно 1 - это личные трудности автора оригинального поста). Пункт 7 я не понял вообще - можно пояснить?
    Пункт 5 все знают, но никто не делает :-) У меня тоже встречаются комменты типа "minor" - ну минор он и есть, если я только поменял пару рабочих параметров при прогоне программы, хвастаясь шефу.
    Пункт 8 спорен. Кому как: у меня кладутся, ибо важны (под результатом компиляции имеется в виду сохранение текущих значений некоторых переменных в файл). Это может быть важно, но не в случае автора.

    И да, бойтесь ставить ссылки на всякие гуглогруппы и списки рассылок - дублируйте со ссылкой нужный текст обсуждения. Кто-нибудь потрёт обсуждение, а вы останетесь с битой ссылкой. Особенно обидно читать про решение нужной проблемы: ткнёшься, а там 404. Не айс.

    ОтветитьУдалить
  4. [троллинг моуд]Серьезные люди тока их и использют!!![/троллинг моуд]
    :)

    Насчет перевода - тратить время на перевод стоит только ради "программных" заметок, рассказывающих о правильных с моей точки зрения вещах, которые не устареют через год-два-три. Например,
    http://scm-notes.blogspot.com/2010/09/branch-per-task-workflow-explained.html
    Заметки же из серии "для чайников" или "10 самых-самых" - того не стОят :) Да и вообще, техническому специалисту стыдно английский не знать, хотя бы на уровне тения таких вот заметок :)

    По пунктам.
    1 - да, это актуально только для адептов МС :)
    6 - ну, это актуально в больших командах, встречал такое сам.
    7 - актуальная вещь, на мой взгляд. Однако весьма непроста в реализации, к сожалению.
    5 - это вопрос самодисциплины. Проще всё время писать осысленные коммиты, чем каждый раз думать - понадобится кому-то их читать или нет. Не знаешь ведь никогда как что повернется
    8 - всё верно написано. Т.н. deliverables как правило выходят в рамках релизов, в т.ч. и конфиги. Релизы обычно кладут вне контроля версий, в т.н. release areas - чтобы зашел со стороны, скачал что надо и нае парился контролем версий. Конечно, могут быть исключения, но общее правило - лучше результаты компиляции не хранить.

    Касаемо ссылок - тут тот самый облом-батюшка :) Это ж копировать, форматировать. Но вообще - да, надо :)

    ОтветитьУдалить