Фон

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

проблема

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

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

Моими первыми коммитами были такие вещи, как «Базовая структура каталогов на месте» и «Созданы таблицы БД». Как я должен использовать VCS при запуске нового проекта?

Начните с простого

git init

Ранняя регистрация, регистрация часто

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

Если код не включен в систему контроля версий, он не существует. [...]

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

Часто совершайте, совершенствуйте позже, публикуйте один раз

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

В конце концов, ваша VCS здесь, чтобы помочь вам . Так что помогите вашей VCS, чтобы помочь вам!

Не думай об этом

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

создал структуру каталогов (ууу!)

Сделай это привычкой

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

• git shortlogследует читать как широкий обзор того, что вы сделали.
• git logследует читать как историю и историю вашего проекта.

То, что вы делаете, это правильный подход.

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

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

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