Хороша історія в Git - моя практика

Як вчора писав, в мене завжди є (неявна) задача створити в Git таку історію, з якої легко буде пізніше (інколи значно пізніше) зрозуміти причину змін.

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

• Всередині пул-реквесту, в нормі, має бути один коміт. Втім, тут є винятки. Перший виняток — коли пул-реквест складається з декількох логічних кроків, які вирішили не розбивати на декілька окремих пул-реквестів. Наприклад, ми вмикаємо та виправляємо по черзі 5 правил лінтера.

• Другий виняток — якщо пул-реквест містить “побічні зміни”. Наприклад, окрім власне нового функціоналу я виправив баг в пакеті тестів. Знов-таки на окремий пул-реквест воно не варте та інколи навіть є перевага від того, щоб розташувати зміни в поєднанні, щоб в майбутньому помітити цей звʼязок. Бо два пул-реквести зі змінами в різних місцях буде важко повʼязати в майбутньому.

• Щоб досягти хоч якоїсь організації комітів, необхідно використовувати git rebase. Бо безумовно комітити потрібно набагато раніше, ніж буде готовий весь пакет змін. В межах однієї гілки git rebase (зазвичай) безконфліктний та безпечний інструмент.

• Поки гілка ще в роботі, коміти зберігають короткочасну історію змін, що теж корисно. Але коли робота завершена, короткочасна історія витрачає користь — тож під час формування пул-реквесту я роблю rebase та ліплю історію на майбутнє.