У цій статті зібрано три теми, які трапляються, коли базовий цикл Git ви вже опанували: як створити репозиторій (через git init і з IDE), чим rebase відрізняється від merge і як правильно прибрати секрет, що випадково потрапив в історію. Усі три знадобляться і в роботі з Claude Code - він виконує ці операції командами, і вам важливо розуміти, що за ними стоїть.
Приклади і знімки інтерфейсу стосуються IDE JetBrains; назви й розташування дій у вашій версії можуть відрізнятися. Для вправ використовуйте окремий навчальний репозиторій. У робочому проєкті дотримуйтеся його правил щодо гілок, фіксації та надсилання змін.
Створення репозиторію - git init і з IDE
Якщо проєкт уже є на GitHub, його можна клонувати. Інший випадок: у вас є локальна тека з кодом. git init створює в ній службові дані Git, але не перший коміт. У прикладі нижче вважаємо, що README.md і .gitignore вже створені й перевірені; решту потрібних файлів додають окремо.
git init
git status
# після перевірки README і правил ігнорування
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"Для локального репозиторію в IDE скористайтеся створенням Git-репозиторію або ввімкненням контролю версій. Share Project on GitHub - окремий сценарій. Він заразом створює віддалений репозиторій і пропонує надіслати зміни. Перед надсиланням перевірте вибрані файли, історію і видимість.
Public чи private
Коли створюєте репозиторій, GitHub одразу питає, хто його бачитиме:
- public - репозиторій бачать усі в інтернеті, код може переглянути будь-хто. Підходить для портфоліо та open source;
- private - доступ мають лише ви і ті, кого ви запросили. Це вибір за замовчуванням для робочого й навчального коду, який не можна показувати.
Видимість не обирають раз і назавжди: її можна змінити пізніше в налаштуваннях репозиторію на GitHub.
Claude Code може виконати git init і підготувати перший коміт за вас. Якщо репозиторію на GitHub ще немає, він здатен створити його через GitHub CLI (gh repo create) - і тут ви вирішуєте, буде він public чи private.
rebase vs merge - у чому різниця
І merge, і rebase розв'язують одне завдання - перенести роботу з однієї гілки в іншу. Але роблять це по-різному, і від цього залежить, який вигляд матиме історія проєкту.
merge об'єднує історії. Якщо вони розійшлися, зазвичай з'являється коміт злиття з двома батьками. Якщо поточна гілка є предком іншої, Git може виконати fast-forward без нового коміту. Діаграма нижче показує саме гілки, що розійшлися.
merge залишає обидві лінії й додає коміт злиття - в історії чесно видно, що була окрема гілка feature.
rebase переносить ваші коміти так, ніби ви почали роботу від свіжої вершини цільової гілки. Історія стає лінійною, як один прямий ланцюжок. Але за це доводиться платити: rebase переписує ваші коміти - замість старих з'являються нові, з іншими хешами.
Після rebase коміти C і D мають такий вигляд, ніби їх зроблено поверх E. Історія лінійна, але це вже нові коміти (C2, D2) з іншими хешами.
Якщо зовсім коротко:
- merge - коли важливо зберегти реальну історію і коли гілка спільна. Безпечний вибір за замовчуванням;
- rebase - щоб причесати свою особисту гілку перед pull request: лінійну історію читати легше.
Поки ви опановуєте rebase, застосовуйте його до своєї неопублікованої гілки. Переписувати гілку, якою вже користуються інші, можна лише за погодженою процедурою: інакше в колег залишиться попередня історія. Якщо не впевнені в наслідках, зупиніться й уточніть правила проєкту.
Спосіб об'єднання визначають завдання і правила проєкту. Не покладайтеся на те, що агент нібито вибере за замовчуванням: попросіть його ще до виконання назвати цільову гілку, операцію і наслідки для історії.
Видалення секретів із репозиторію
Якщо видалити файл новим комітом, секрет із попередніх комітів нікуди не дінеться. Якщо пароль або токен став доступним іншим, спершу відкличте чи замініть його в сервісі, який його видав. Очищення історії не скасовує вже зроблених копій.
Не запускайте очищення спільної історії як звичайне виправлення файлу. Воно змінює ідентифікатори комітів і потребує координації: зупинити надсилання старих гілок, визначити всі зачеплені шляхи, перевірити результат в окремій копії і домовитися, як колеги оновлять свої копії.
Для очищення GitHub описує процедуру з git-filter-repo. Конкретні команди залежать від того, чи видаляється файл цілком, чи замінюється секретний рядок, де він траплявся і куди потрапила історія. Дотримуйтеся офіційної інструкції з видалення чутливих даних, зокрема щодо свіжої копії, перевірки результату, оновлення віддалених посилань і дій колег.
Очищення локальної копії саме по собі не змінює сервер. Примусове надсилання переписаної історії - окрема погоджена дія: універсальну команду для всіх гілок тут виконувати не треба. Копії в чужих клонах і форках лишаються поза вашим контролем (тут уже нічого не вдієш); щодо посилань і кешів, доступних GitHub, діють умови звернення до Support з тієї ж інструкції.
Щоб таке не повторилося, допоможуть кілька простих звичок:
- зберігайте значення секретів поза кодом, наприклад у змінних середовища;
- додавайте локальні файли на кшталт
.envу.gitignoreще до того, як Git почне їх відстежувати; - перевіряйте вибрані файли і
git diff --cachedперед комітом; - якщо для репозиторію доступні secret scanning і push protection, увімкніть їх як додаткову перевірку: вони знаходять не всі можливі секрети.
Агент може допомогти знайти зачеплені шляхи й підготувати план очищення. Не передавайте дійсний секрет у чат для пошуку. Спершу відкличте доступ, потім погодьте роботу з історією.
Як це працює у зв'язці з Claude Code
Усі три теми спливають, коли з репозиторієм працює Claude Code. на що дивитися:
- він може ініціалізувати репозиторій (
git init) і підготувати перший коміт - public чи private ви вибираєте самі, коли створюєте його на GitHub; - пропонує спосіб об'єднання за правилами проєкту; наслідки merge і rebase перевіряєте ще до запуску;
- він бачить файли, які потрапляють у коміт, але остаточна відповідальність за те, щоб туди не витік секрет, лежить на вас.
Перед комітом перевірте і список файлів, і їхній вміст у diff. Секрет може бути у звичайному файлі з кодом, а не лише в .env. Якщо він уже потрапив в історію, спершу замініть цей секрет, потім з'ясуйте, чи потрібне очищення.