Лучшие привычки контроля версий для индивидуального разработчика?

Я единственный разработчик в своей работе, и хотя я понимаю преимущества VCS; Мне трудно придерживаться хороших практик. В настоящее время я использую git для разработки в основном веб-приложений (которые никогда не будут открыты из-за моей работы).

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

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

Как часто я должен совершать? Должно ли каждое изменение в одну строку получать коммит? Должен ли я фиксировать перед любым тестом (например, по крайней мере, для ошибок синтаксиса / компиляции, а затем должен полностью отменить его; так как идея не сработала или сообщение является ложью)?

Должен ли я делать каждое утро / вечер перед тем, как я перестану работать на ужин, пока он еще свежий? Что я упускаю из-за плохих привычек VCS?

Вы много скучаете.

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

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

Я думаю, это дает мне много порядка.

Я использую SVN, и мне это надоело. Но не могу тратить больше времени на изучение чего-либо еще.

Удачи.

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

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

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

Чтобы получить максимальную отдачу от CVS, вы должны одновременно работать над одним исправлением / исправлением ошибки и выполнять фиксацию, когда это исправление / исправление завершено. Делая это, вы получите:

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

Кроме того, поскольку вы переключаетесь между компьютерами, у вас должно быть как минимум две ветви:

• ветка "Готов к работе", которая всегда работает (за исключением ошибок, над которыми вы работаете в ветке разработки, конечно)
• ветка разработки, которая может время от времени находиться в нерабочем состоянии (например, во время поездки домой с работы;).

Должно ли каждое изменение в одну строку получать коммит?

Если это то, что исправляет ошибку, конечно.

Что я упускаю из-за плохих привычек VCS?

Я работал с парнем, у которого были "плохие привычки VCS". Он любил работать самостоятельно и руководил производственной линией, приносящей около 1 000 000 долларов в год. Он делал коммиты только тогда, когда босс терзал его. Затем однажды его жесткий диск сломался. После того, как мы подготовили для него замену, мы обнаружили, что его последняя регистрация прошла 6 месяцев назад. Поскольку VCS был Source Safe, вы можете догадаться, что еще пошло не так - последний коммит был поврежден. Нам пришлось вернуться более чем на год, чтобы получить неиспорченную версию своей линейки продуктов. Его не уволили, хотя он должен был быть.

Еще один анекдот затрагивает меня. Я использовал для хранения кода для хобби и исследовательских проектов на съемных жестких дисках. Однажды моя квартира была взломана. Ноутбук (который был сломан) и все съемные жесткие диски были украдены. Каждый DVD (за исключением Red Dawn) был украден. Ни один из настольных компьютеров не был украден. Если бы у меня был внешний контроль источников, я бы не потерял 15-летние проекты, тем более что некоторые из них были основаны на академических проектах - многие из специалистов ушли из академических кругов, чтобы перейти в частную индустрию, поэтому эти проекты превратились в черную дыру корпоративной ИС, в результате чего потерянный код невозможно восстановить.

Как часто я должен совершать?

Я делю это на несколько показателей:

• Сколько работы вы готовы потерять, если ваш компьютер умрет? или украден?

• Если это исправляет Bug_1234, проверьте код с комментарием «исправляет Bug_1234».

• Если это логическая доставка / этап, то отметьте это с помощью комментария типа «Bug_1234, form_xyz» (или Task_1234 в зависимости от ситуации).

• Всегда проверяйте код в пятницу вечером, прежде чем отправиться домой. Также сделайте регистрацию (или отмените проверку) всего перед отъездом в отпуск.

• Всякий раз, когда диктует политика компании.

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

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

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

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

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

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

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

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

Кроме того, я всегда фиксирую код, который компилируется, и почти всегда код, который также проходит все основные тесты. Если нет, я обязательно включаю «НЕ РАБОТАЕТ» в сообщении коммита. Единственный случай, когда это происходит, когда я внес важные изменения, которые я не хочу терять, хотя они еще не совсем работают, и, кроме того, я собираюсь начать большое приключение по рефакторингу, в котором я не уверен, это будет успешно. Итак, я использую репозиторий в качестве резервной копии работы, которую я проделал до этого, прежде чем рискнуть испортить его и выбросить.

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

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

Если вы не можете придумать хорошее сообщение о коммите, потому что все, что вы придумали, звучит глупо, имейте в виду, что это нормально; Ожидается, что сообщения коммитов будут содержать очевидное, поэтому они будут звучать глупо для вас, когда вы их пишете. Но поверьте мне, если вам понадобится просмотреть старые ревизии через месяц, вы будете благодарны даже за глупые сообщения без каких-либо сообщений.

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

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

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

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

Вы также можете раскрыть силу того, git bissectчто скажет вам коммит, который этот мерзкий баг. Если коммит длиной 2000 строк, он все равно помогает, но не так сильно ...

Другое дело, что это первый шаг к непрерывной интеграции (CI), а затем к непрерывному развертыванию (CD). CI и ваши тесты могут запускаться при новой фиксации, следовательно, сообщая вам каждый раз, когда вы вносите изменения, если они что-то нарушают или нет. Таким образом, вы можете узнать, безопасно ли развертываться или нет, и получать уведомления об этом в момент появления проблемы, а не перед выпуском, когда вы спешите.

О других ваших вопросах:

• не передавайте вещи, которые вы даже не компилировали, если только вы не захотите переписать свою историю для этого (используя git rebase --interactive).
• изменение на одну строку заслуживает коммита, если оно имеет отдельную цель (исправляет ошибку или не связано с вашими в данный момент незафиксированными изменениями). Используйте git add --patchдля постановки тех.
• не нужно заставлять себя совершать обязательства перед обедом, если у вас нет важных вещей, которые вы не можете позволить себе потерять. В этом случае вы можете захотеть зафиксировать в отдельной ветке вашу работу в процессе.
• фиксация и отправка в удаленный репозиторий является резервной копией. Если вы делаете коммит и толкаете только один раз в неделю, в худшем случае вы можете потерять одну неделю работы.

Как часто я должен совершать?

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

Должно ли каждое изменение в одну строку получать коммит?

Нет, если это изменение в одну строку не приведет к значительному изменению функции или ошибки.

Должен ли я фиксировать перед любым тестом (например, по крайней мере, для ошибок синтаксиса / компиляции, а затем должен полностью отменить его; так как идея не сработала или сообщение является ложью)?

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

Должен ли я делать каждое утро / вечер перед тем, как я перестану работать на ужин, пока он еще свежий? Что я упускаю из-за плохих привычек VCS?

Я не очень знаком с VCS или с какими вредными привычками это вызывает. Я думаю, что в основном поделился своим мнением по этому поводу в ответ на первый вопрос.

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

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

Age:  9 mins [*] Working on implementing and testing PaintSystem.
Age: 17 mins [*] Working on implementing and testing PaintSystem.
Age: 37 mins [*] Working on implementing and testing PaintSystem.
Age: 52 mins [*] Working on implementing and testing PaintSystem.

Так что я не могу точно сказать, что такие частые и привычные коммиты в мою ветку (mercurial) точно подталкивали к созданию наиболее подробных журналов коммитов. Иногда я даже делаю код наполовину готовым, если, скажем, моя жена попросит меня пойти поужинать, и в этот момент я просто поспешно скопирую и использую предыдущее сообщение «Работа над [...]».

Мои шаблоны журнала коммитов, как правило, "Working on [...] Working on [...] Working [...] Completed [...] Started working on [...] Working on [...] Completed [...] Started working on [...]"

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

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

Должно ли каждое изменение в одну строку получать коммит?

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

TBH, многие из моих коммитов, которые следуют этому "Working on [...]"шаблону журнала, не моделируют согласованные единицы изменения (почему я часто не могу придумать сообщение лучше чем "Working on [...]"), а просто результат того, что я сделал передышку, например, приготовил себе чашку кофе. "Completed [...]"Сообщение указывает на конец этой единицы работы, и я часто пишу гораздо более подробное сообщение вместе с первым "Started working on [...]"сообщениями типа , когда я просто начать работать над чем - то. Если вы в среднем фиксируете, как один раз каждые 15 минут, то эти сообщения «Работа над [...]» больше похожи на промежуточные, что может сделать кто-то в одном более крупном коммите с более подробным сообщением.

Должен ли я фиксировать перед любым тестом (например, по крайней мере, для ошибок синтаксиса / компиляции, а затем должен полностью отменить его; так как идея не сработала или сообщение является ложью)?

Я просто продолжаю и фиксирую это перед тем, как даже запускать тесты иногда (снова, если у меня было неожиданное событие). Кроме того, несмотря на то, что я один, я делаю push на сервер (только тот, который работает дома в локальной сети), который выполняет CI. Это может показаться излишним, но не знаю, я привык привыкать к этому на своих прежних рабочих местах. Кроме того, я не хочу беспокоиться о необходимости каждый раз запускать все свои модульные и интеграционные тесты вручную. Мне нравится, когда все это связано с толчком. Если тест не пройден, достаточно легко работать в продвижении вперед, где я делаю регресс, исправляю ошибку в последней версии и продолжаю. Тем не менее, я, по крайней мере, собираю код против отладочной сборки перед тем, как зафиксировать.

Должен ли я делать каждое утро / вечер перед тем, как я перестану работать на ужин, пока он еще свежий?

Мне нравится совершать коммиты до того, как я выхожу и делаю перерыв между программированием. Я не особо задумывался, почему именно, пока не столкнулся с этим вопросом. Я полагаю, что это мешает мне выбрать то, где я остановился, без журнала коммитов вместо того, где я остановился, чтобы я мог различить и так далее. Хм, мне нужно связаться с вами по этому вопросу, поскольку теоретически это не нужно, учитывая, как часто я делаю коммиты. Я по-прежнему чувствую себя более комфортно, когда по какой-то причине покидаю компьютер, нажимая и толкаясь. Отчасти это может быть тот психологический страх, скажем, компьютер загорелся после того, как я ушел, и у меня были менеджеры проектов в те дни, когда мы использовали SVN, а разработчики иногда работали неделями, не затягивая дыхание и постоянно напоминая нам проверять код как можно чаще, напоминая нам, что наш код является собственностью компании. Кроме того, он немного более эффективен, особенно при нажатии, так что мой процесс CI может запустить все тесты, пока меня нет, чтобы я мог вернуться и посмотреть результаты.

Да, и иногда я немного напиваюсь после того, как ухожу, и, как правило, плохая идея пытаться писать сложный код в пьяном виде (хотя и не всегда; однажды я придумал действительно хорошую систему контекстного меню после того, как в момент пьянства наступил момент эврики, но у меня было всего 6 сортов пива, и это было не так уж сложно кодировать). Если я попытаюсь сделать это, по крайней мере, я передал трезвый код перед тем, как уйти, чтобы вернуться назад вместо того, чтобы смешивать пьяный код с трезвым кодом, после чего мой журнал коммитов мог бы выглядеть так: "Reverting back to code written before Jagermeister shots."я не делаю этого очень часто, если я не получал вдохновение от пьяного кода, но в тех редких случаях действительно помогало то, что я что-то совершил, прежде чем вышел и напился.