Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
Пости з тегом #Git
28.06.2023
Кілька порад з мого повсякденного Git
-
Rebase - чудова команда, бо дозволяє відокремити збереження коду (коміт) від створення документації (підпису до коміту). А саме: оскільки всі зміни можна будь-коли відребейзати, розділити по логічних комітах, та красиво підписати, то попередні коміти можна робити будь-коли — наприклад, перед кожною ризиковою зміною. А не чекати, поки набереться набір змін, вартий коміту. А ще, коли PR виявиться несподівано довгим, або міститиме побічні зміни, можна спокійно їх відрізати, навіть якщо ми цього не планували. Взагалі, поки коміт не покинув твоєї машини, з ним можна робити все що завгодно.
-
Blame - одна з найважливіших функцій Git, бо робить корисним все ведення історії змін. Перша функція Git - поєднання змін від різних людей. Як людина, яка встигла покористуватись SourceSafe, скажу, що ця можливість змінила життя. Але друга функція - це відстеження історії змін. Та з нею можна роздивлятись будь-який баг як не просто комбінацію обставин, але і як подію в історії проєкту. Завдяки команді
git blameможна знайти, де ж баг виник, та які зміни його супроводжували. Часто виявляється, що, наприклад, автор не володів всім контекстом, тоді легше зрозуміти, що треба виправити. Я взагалі постійно дивлюся на вік коду, який редагую, тому в мене blame зʼявляться біля кожного рядка редактора. -
Посилання на Pull Request є в коментарі до кожного merge commit, який робить Гітхаб. Тому я не бачу багато сенсу у вкладанні коду задачі на назву гілки — завжди можна знайти відповідний пул-реквест, та в мене цим часто закінчується пошук причини помилки через
git blame.
16.01.2024
Мій підхід до історії Git
Окрім того, що Git - незамінна платформа координації змін від всієї команди (а я ще памʼятаю “бронювання” файлів у Visual SourceSafe) - є й друга функція. Git - то правдива історія розробки проєкту. Та якщо про координацію змін багато всього написано — всілякі системи гілкування і таке інше, то облік історії не така гучна тема.
Навіщо взагалі потрібна історія? Не для пустих міркувань. Кожного разу, коли я натрапляю на незрозумілий код — я дивлюся на історію його змін. Незрозумілий код зустрічається постійно — під час планування, рефакторингу, пошуку багів. Історія, у формі git blame та git log, розкриває його в новому вимірі.
Замість злагодженої архітектури, в git blame код виглядає як латки, поставлені на латки, поставлені на латки… і так до самої основи. Та коли йдеться про незрозумілий код, то часто легше побачити структуру, коли знаєш, які зміни відбувались одночасно.
Треба дізнатись, яка з форм нова, а яка застаріла? В яких ще місцях зробили — або забули зробити — рефакторинг? Що хотів досягнути автор, коли впровадив помилку? Історія підкаже.
Тому важливо піклуватися про чисту історію. Я вже зачіпляв цю тему, але детальніше розповім завтра.
17.01.2024
Хороша історія в Git - моя практика
Як вчора писав, в мене завжди є (неявна) задача створити в Git таку історію, з якої легко буде пізніше (інколи значно пізніше) зрозуміти причину змін.
-
Одиницею осмислених змін є пул-реквест. Це значить, що найліпше, коли пул-реквест складається з одного коміту. Що там було всередині — втрачає сенс на широкому часовому масштабі. Пул-реквест гарний тим, що в нього є визначений автор, ціль, обговорення.
-
Всередині пул-реквесту, в нормі, має бути один коміт. Втім, тут є винятки. Перший виняток — коли пул-реквест складається з декількох логічних кроків, які вирішили не розбивати на декілька окремих пул-реквестів. Наприклад, ми вмикаємо та виправляємо по черзі 5 правил лінтера.
-
Другий виняток — якщо пул-реквест містить “побічні зміни”. Наприклад, окрім власне нового функціоналу я виправив баг в пакеті тестів. Знов-таки на окремий пул-реквест воно не варте та інколи навіть є перевага від того, щоб розташувати зміни в поєднанні, щоб в майбутньому помітити цей звʼязок. Бо два пул-реквести зі змінами в різних місцях буде важко повʼязати в майбутньому.
-
Щоб досягти хоч якоїсь організації комітів, необхідно використовувати git rebase. Бо безумовно комітити потрібно набагато раніше, ніж буде готовий весь пакет змін. В межах однієї гілки
git rebase(зазвичай) безконфліктний та безпечний інструмент. -
Поки гілка ще в роботі, коміти зберігають короткочасну історію змін, що теж корисно. Але коли робота завершена, короткочасна історія витрачає користь — тож під час формування пул-реквесту я роблю
rebaseта ліплю історію на майбутнє.
25.04.2025
Графічні клієнти для Git
Я вже багато років майже всі коміти в Git роблю з графічного інтерфейсу. Інакше мені роботу важко уявити, бо я люблю коли мої коміти акуратні та впорядковані.
В гарному графічному клієнті можна переглянути зміст приблизно так само, як ти його бачиш на якомусь GitHub, тільки ще заздалегідь. Хоча це з термінала теж можна. Зате далі можна додавати зміни до коміту не тільки файл за файлом, а й рядок за рядком. Або ще корисно — навпаки, видаляти зміни.
Без такого інструменту я б не зміг ефективно готовити змістовну історію, бо майже ніколи не вдається робити зміни ідеально в тому ж порядку, в якому я хочу закріпити їх в історії. Також я завжди перевіряю, що в коміті немає зайвих змін, та з графічного клієнта можна дуже швидко прибрати конкретні рядки.
Цікаво, що все інше я роблю через термінал. Хоча, наприклад, для перегляду гілок теж є багато програм; втім, ми користуємося простою моделлю гілок, тому терміналу вистачає. Ну, хіба що ще git blame з редактора зручно робити.
Щодо конкретних програм: колись дуже давно все почалося з git gui - стандартного інтерфейсу. Здається, це було в мій час Linux на Windows, та я відкривав той GUI через Xming. Але наче цей GUI досі живий Потім я переїхав на мак, а тут git gui немає. Знайшов gitx - наче якщо не клон, то дуже схожу програму. Вона досі підтримується, та я досі її можу рекомендувати для macOS. Хоча останні роки мої коміти робляться всі через VSCode, тож у твоєму IDE теж може бути гарний редактор комітів — залишається ним користуватися.