У кожного розробника є історія про те, як він щось зламав у Git. Зазвичай вона починається словами «я ж просто хотів швидко поправити». Хороша новина в тому, що майже все в Git можна повернути, якщо знати, куди дивитися.
Найчастіша помилка новачків — коміти прямо в main. Поки ви сам у проєкті, це сходить з рук. У команді закінчується конфліктами й сердитими повідомленнями в чаті. Гілка під кожну задачу коштує три секунди, а нервів економить багато.
Друга біда — повідомлення комітів. «fix», «fix2», «правки», «ще правки». Через пів року ви самі не зрозумієте, що тут відбувалося. Достатньо писати одним реченням, що саме змінилося й навіщо. Не роман, просто осмислений рядок. Той, хто колись шукав через git blame причину дивної поведінки, оцінить.
Третє — страх перед командами, що переписують історію. Rebase і reset справді можуть наробити лиха, особливо разом із force push у спільну гілку. Правило таке: свої локальні гілки переписуйте скільки завгодно, а спільні не чіпайте. Якщо ж force push усе-таки потрібен, використовуйте —force-with-lease, він не дасть затерти чужі коміти.
Є й рятівний круг. Команда git reflog показує, де побував ваш HEAD, навіть якщо гілку видалили чи зробили reset —hard. Більшість «втрачених» комітів знаходяться саме там. Я двічі за кар’єру повертав так цілий день роботи.
Окремо про секрети. Якщо ви випадково закомітили ключ від API, видалення файлу наступним комітом нічого не дає, ключ залишається в історії. Його треба відкликати й видати новий, а вже потім чистити репозиторій. І додайте .gitignore одразу, а не після першої проблеми.
Git лякає лише спочатку. Вивчіть десяток команд, зрозумійте, що таке гілка й вказівник, і він із ворога стає зручним журналом, який рятує у найгірші дні.