Фон

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

Проблема

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

Чи є в мене сенс перевіряти на кожному етапі процесу так, як це було б із існуючим проектом? Я не порушую проект із внесеними змінами, оскільки він ще не працює. На даний момент я просто використовую VCS як резервну копію в кінці кожного дня, коли я залишаю комп'ютер.

Першими моїми першими комітетами були такі речі, як "Основна структура каталогів на місці" та "Створено таблиці БД". Як слід використовувати VCS під час запуску нового проекту?

Початок простий

git init

Рання реєстрація, часто заїзд

Просто виконайте те, що ви зазвичай робите з будь-яким проектом: "зареєструйтесь" для кожного набору змін, що стосуються певної задачі або групи дій. Якщо ви використовуєте трекер проблем, виконайте зміни, які стосуються завдання щоразу, коли він перебуває у стабільному стані (див. Це питання ПЗ про те, як часто здійснювати виконання ). Можливо, він не знаходиться в стані завершення, просто стабільний, в якому програмне забезпечення не працює, або сайт не відображається. Як говорить Джефф Етвуд у своєму дописі:

Якщо код не перевіряється у контролі джерела, він не існує. [...]

Я не пропоную розробникам перевірити зламаний код - але я також стверджую, що велика різниця між зламаним кодом та неповним кодом є великою.

Здійснюйте часто, ідеально пізніше, опублікуйте один раз

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

Зрештою, ваш VCS тут, щоб допомогти вам . Тож допоможіть вашому ДКС, щоб допомогти вам !!

Не передумуй

Ваші перші зобов’язання були добре. Не передумуйте. Найголовніше, що вони зареєстровані. Якщо ви подивитесь на всі існуючі проекти з відкритим кодом в Інтернеті, які почалися з нуля, а не з існуючої бази коду, то їх перша редакція має щось подібне:

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

Зроби звичку

В кінці кожного дня намагайтеся генерувати журнал того, що ви робили, грунтуючись на своїх журналах фіксацій. Якщо результати, які ви отримуєте, git shortlogі git logНЕ виглядають задовільними та корисними , але ви протягом дня доклали значних зусиль у проекті та перевірили ці зміни, то, ймовірно, ви не зробили це правильно .

• git shortlogслід читати як широкий огляд того, що ви зробили.
• git logмає читати як історію ТА історію вашого проекту.

Те, що ви робите, - це правильний підхід.

Ви використовуєте управління джерелом з першого дня - це забезпечить вам все необхідне в керуванні джерелом і немає сенсу, на який можна сказати:

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

Це головне перешкода для людей, які запізнюються на контроль джерел, оскільки вони вважають, що це "занадто важко". Почавши рано та здійснюючи зміни, ви часто скорочуєте цю перешкоду до невеликого кроку, і кожен, хто приєднається до вас у проекті, зможе негайно приступити до роботи.