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

Допустим, например, у меня есть проект, который состоит из одного файла кода. Потребуется около 10 строк стандартного кода и 100 строк, чтобы проект работал с предельно базовой функциональностью (1 или 2 функции). Должен ли я сначала проверить:

1. Пустой файл?
2. Стандартный код?
3. Первые функции?
4. В какой-то другой момент?

Кроме того, каковы причины, чтобы проверить в определенной точке?

Вы должны совершить коммит, как только у вас будет разумный «юнит».

Что такое юнит? Это зависит от того, что вы делаете; например, если вы создаете проект Visual Studio, передайте решение сразу после его создания, даже если в нем ничего нет.

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

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

Вчерашний день

... в качестве альтернативы, если вы не можете путешествовать во времени ...
(возможно, ваша машина не может разогнаться до 88 миль в час, или ваш конденсатор потока просто сломался)

В настоящее время

Новые проекты должны быть совершены на кровавом месте, это безумие, а современные системы DVCS просто сняли все возможные поводы, чтобы избежать коммитов : git init . ; git add * ; git commit -m initial-commitсейчас, пока не стало слишком поздно, как это уже могло бы быть.

Еще один разумный, спорный вопрос мог бы звучать так: «Когда я должен объединить свои коммиты с общим источником управления в управляемом командой репозитории на установленном проекте?» (обратите внимание на прилагательные, прилагательные важны) И у меня есть ощущение, что большинство других ответов на самом деле пытаются ответить на это.

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

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

Лично мой первый коммит, как правило, содержит только файл .gitignore (или эквивалентный) с несколькими фильтрами, которые, как я знаю, понадобятся, например, * .py [co] для кода Python. Базовая настройка проекта и / или первый простейший прототип - это то, что обычно следует.

Первым коммитом может быть файл README, содержащий всего одну строковую сводку проекта, или достаточно информации о первом этапе проекта. Широкие темы могут также включать:

• Введение
• Описание Проекта
• Структура проекта
• Соглашения о кодировании
• Инструкция о том, как:
  • строить
  • контрольная работа
  • развертывание
• Известные проблемы и обходные пути
• список дел
• Условия эксплуатации

Практика обновления README перед внесением изменений в проект также называется Readme Driven Development, и она позволяет вам продумать изменения, прежде чем тратить время на внесение этих изменений.

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

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

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

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

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

Не уверен, что это было упомянуто.

Но убедитесь, что то, что вы делаете, работает / компилируется! Так что никаких синтаксических ошибок и т. Д.

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

Другая точка зрения, в большей степени связанная с тестированием программного обеспечения (подход TDD), будет выполняться, как только у вас появятся новые тестовые сценарии в зеленом цвете. Это будет означать, что у вас есть новый «блок» кода завершен.

Прямо перед тем, как сделать что-то глупое.

Для тех из нас, кто не обладает магическими способностями, это означает мало и часто.

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

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

Около 2 ~ 3 часов в проект.

Просто шутка. Нет ни одного хорошего ответа, который бы подходил ко всем ситуациям. Прежде всего, если у вас есть распределенная система контроля версий (например, git или Mercurial), то фиксация в локальном репо не сохранит ваши данные в случае катастрофического сбоя. Но частное удаленное репо может стоить вам денег, например, на github. Вы сохраните историю коммитов, но, по моему опыту, вам это не понадобится, пока ваш проект не будет немного продвинутым.

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

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

Поэтому я склонен настраивать контроль версий всякий раз, когда у меня есть что-то ценное, т.е. нетривиальное для репликации. Ценность субъективна (и зависит от ваших способностей), поэтому вам придется самим принимать решение. В этот момент я сохраняю второй репо на внешнем диске или на github, если это публичный проект или моя платная учетная запись будет держать его.

Многие уже ответили «Сразу», и я на 100% согласен. Мне также нравится предложение Xion начать с шаблонов игнорирования VCS (то есть .gitignoreили эквивалентных).

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

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

Это может зависеть от того, какую VCS вы используете.

С Git я фиксирую пустой каталог (или почти пустой файл README). Дело в том, что я могу вернуться и сбросить свою ветвь в это пустое состояние, если я хочу полностью начать все сначала, пока я еще на начальном этапе процесса разработки (до перехода в восходящий поток). Затем я бы зафиксировал свои «сгенерированные» файлы (например, решение Visual Studio). Затем, когда я на самом деле кодирую, я начну фиксировать каждый модуль, как вы это обычно делаете.

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

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

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

В настоящее время я использую черепаху / SVN на работе.

Совершите пустой проект прямо сейчас. Продолжайте совершать несколько раз в час, потраченные на работу над проектом. Фиксация, даже если код не компилируется. Я отмечаю такие коммиты "WIP" в массаже коммитов, чтобы отслеживать их.

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

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

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

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

При работе над созданием фреймворка (с нуля) будет происходить множество изменений для каждого модуля, пока модуль не будет завершен или завершен. Поэтому у меня всегда есть 2 локации, одна из которых называется ДИНАМИЧЕСКАЯ, а другая - СТАТИЧЕСКАЯ. Когда изменения продолжаются, и фреймворк еще не завершен, он фиксируется в местоположении DYANMIC, и как только он завершается и завершается, я перемещаю его в местоположение STATIC. Итак, у меня есть полный Source Control.

Спасибо

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

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

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

Если вы работаете над новой «задачей» для проекта, который уже выполняется, и вы находитесь в своей собственной ветви задач, выполняйте свои ночные проверки, чтобы сохранить свою работу.

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

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

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

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

Обычно, когда я начинаю добавлять стандартный код (например, добавляю новое веб-приложение на веб-сайт django), я фиксирую каждую операцию, которую я выполняю.

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

Допустим, например, у меня есть проект, который состоит из одного файла кода. Потребуется около 10 строк стандартного кода и 100 строк, чтобы проект работал с предельно базовой функциональностью (1 или 2 функции).

Это будет зависеть от того, насколько сложно добавить материал:

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

• Если бы код был нетривиальным, я бы фиксировал каждый раз, когда добавлял что-то новое (где-то между каждыми двумя измененными строками кода, до сотни или около того).