Основні команди Git, згруповані за задачами, простою мовою і з чіткою позначкою ризикованих.
Для нашого курсу з Git термінал не потрібен. Ця сторінка для випадків, коли він таки з'являється: інструкція від розробника, локальна копія репозиторію, pull request, який хочеться запустити.
Уперше маєте справу з Git як продакт? Git для продакт-менеджерів: читаємо репозиторій без командного рядка
Слова в кутових дужках це заповнювачі. Замініть <branch>, <file>, <commit> чи <text> своїм значенням і приберіть дужки. <commit> це хеш на кшталт 3f9a2c1, <tag> це версія на кшталт v1.5.0.
Кожна команда має одну з трьох позначок:
Написано для Git 2.23 або новішого (цього потребують git switch і git restore). Свою версію перевірте командою git --version.
63 команди
Завантажте проєкт на свій комп'ютер і зорієнтуйтеся в ньому, перш ніж щось змінювати.
git clone <url>Завантажити повну копію репозиторію разом з історією.
Створює нову папку з усіма файлами й усіма комітами проєкту. На GitHub нічого не змінюється, і нічого з того, що вже є на вашому комп'ютері, команда не чіпає. Вона потрібна, лише коли хочете запускати проєкт або шукати в ньому локально.
Щоб читати проєкт, копія не потрібна: просто переглядайте сторінку репозиторію. Адреса для git clone є під зеленою кнопкою Code.
git statusПобачити, у якій ви гілці і які файли змінили.
Перша команда, коли ви не впевнені, що відбувається. Вона називає вашу гілку, показує змінені, нові й конфліктні файли і каже, чи ви попереду GitHub або позаду нього (станом на останній fetch). Часто вона ще й підказує наступну команду.
git log --oneline --graph --allНамалювати всі гілки й мерджі текстовою схемою.
Один коміт на рядок, а лінії зліва показують, де гілки відходять і де їх змерджили назад. Зручно, щоб побачити, наскільки жвавий репозиторій, перш ніж питати, куди поділася зміна. Щоб вийти зі списку, натисніть q.
Insights → Network малює таку саму схему для гілок репозиторію.
git grep "<text>"Знайти всі файли, де є слово або фраза.
Шукає у файлах поточної гілки й показує кожен рядок зі збігом разом з назвою файлу. Зручно, щоб знайти, де живе підпис кнопки, ціна чи feature flag. Шукає лише в сьогоднішніх файлах, а не у видаленому тексті.
Скористайтеся полем пошуку вгорі сторінки репозиторію (клавіша /) і залиште результати лише з цього репозиторію.
git config --global user.name "<name>"Задати ім'я, яке буде у ваших комітах.
Одноразове налаштування на новому комп'ютері. Git записує це ім'я в кожен ваш наступний коміт, у всіх репозиторіях на цьому комп'ютері.
Уже зроблені коміти зберігають старе ім'я; помилка в імені потрапить у спільну історію, доки ви не запустите команду ще раз із правильним написанням.
git config --global user.email "<email>"Задати пошту, яка пов'язує ваші коміти з акаунтом GitHub.
GitHub зіставляє цю адресу з вашим акаунтом і показує аватар поруч із вашими комітами. Використайте адресу з налаштувань пошти на GitHub; там же є приватна адреса noreply саме для цього.
Адреса зберігається в кожному вашому коміті, і її бачить кожен, хто може читати репозиторій.
Останні коміти, один коміт зблизька і те, що гілка додає порівняно з main.
git log --oneline -20Показати останні 20 комітів вашої гілки, по рядку на кожен.
Кожен рядок починається з короткого хеша коміту й повідомлення, найновіші зверху. Це найшвидша відповідь на питання «що тут останнім часом відбувалося?». Число 20 можна замінити будь-яким іншим.
На сторінці репозиторію натисніть кількість комітів з іконкою годинника над списком файлів.
git log --since="2 weeks ago" --onelineПобачити всі коміти за останні два тижні.
Фільтрує історію за датою, що зручно перед демо спринту чи звітом для стейкхолдерів. Git розуміє вирази на кшталт "3 days ago" або дату на кшталт "2026-09-01" (англійською).
Відкрийте список комітів і виберіть проміжок дат у фільтрі за датою.
git show <commit>Відкрити один коміт: повідомлення, автора, дату й diff.
Вставте хеш із повідомлення в Slack чи з pull request, і побачите, що саме змінив цей коміт: видалені рядки з мінусом, додані з плюсом.
Натисніть будь-який хеш коміту на GitHub, щоб відкрити його сторінку з тим самим diff.
git diffПобачити зміни у вашій папці, які ще не позначені для коміту.
Показує рядок за рядком, чим ваші файли відрізняються від останнього збереженого стану. Запустіть перед комітом, щоб переконатися, що змінили лише те, що хотіли. Щойно файл позначено через git add, його зміни видно вже в git diff --staged.
git diff origin/main...<branch>Побачити все, що гілка змінює порівняно з main.
Три крапки означають «відколи гілка відійшла від main», тож ви бачите лише роботу самої гілки, як у вкладці Files changed у pull request. Спершу запустіть git fetch, щоб origin/main був актуальним.
Відкрийте pull request і перейдіть на вкладку Files changed.
git log --oneline origin/main..<branch>Показати коміти, які є в гілці, але немає в main.
Дві крапки означають «є в гілці, але ще немає в main». Кількість рядків GitHub називає «ahead». Порожній список означає, що все з гілки вже є в main.
Вкладка Commits у pull request або лічильник «ahead» на сторінці гілок.
Тут теж знадобиться:git log -p -- <file>git branch -r --contains <commit>
Простежте рядок або речення до коміту, який його написав; коміт приведе до pull request і до причини.
git log -p -- <file>Прочитати всю історію одного файлу з кожною зміною.
Показує всі коміти, що змінювали файл, найновіші зверху, кожен зі своїм diff. Підходить для питань на кшталт «як змінювався текст про ціни?». Щоб вийти, натисніть q.
Відкрийте файл і натисніть History у його правому верхньому куті.
git blame <file>Побачити, хто востаннє змінив кожен рядок файлу і в якому коміті.
Виводить файл, а біля кожного рядка коміт, автора й дату останньої зміни. Команда знаходить походження рядка, а не винного. Якщо останній коміт лише переформатував рядок, подивіться на крок раніше в історії.
Відкрийте файл і перемкніть вигляд з Code на Blame.
git blame -L <start>,<end> -- <file>Знайти, хто змінив кілька конкретних рядків файлу.
Те саме, що git blame, але лише для діапазону рядків, наприклад -L 10,14. Номери рядків візьміть з перегляду файлу на GitHub. Хеш коміту в першій колонці приведе до pull request.
Відкрийте файл у вигляді Blame і прокрутіть до потрібних номерів рядків.
git log -S "<text>" --onelineЗнайти коміти, які додали або прибрали шматок тексту.
Шукає в усій історії коміти, де текст з'явився або зник. Це інструмент для питання «це речення було на сторінці, хто його прибрав?», на яке blame не відповість, бо рядка вже немає.
Тут теж знадобиться:git grep "<text>"
Переглянути гілки, перейти з однієї в іншу, створити нову і прибрати після мерджу.
git branchПоказати гілки на вашому комп'ютері; зірочка позначає поточну.
Лише локальні гілки: ті, які ви створили або в які переходили. Гілок, що є лише на GitHub, тут немає; їх показує git branch -a.
Перемикач гілок над списком файлів показує гілки на GitHub.
git branch -aПоказати всі гілки, зокрема ті, що є лише на GitHub.
Гілки з GitHub мають вигляд remotes/origin/<name>. Список актуальний на момент останнього git fetch, тож спершу зробіть fetch, якщо шукаєте гілку, яку хтось щойно надіслав.
Сторінка Branches (лічильник гілок поруч із перемикачем) показує їх разом з останнім комітом.
git switch <branch>Перейти в іншу гілку; ваша папка зміниться відповідно до неї.
Файли у вашій папці стають версією цієї гілки. Якщо гілка є лише на GitHub, Git створить її локальну копію, яка стежить за нею. Незакомічені зміни переходять разом з вами, якщо не суперечать іншій гілці.
Якщо незакомічені зміни суперечать іншій гілці, Git не перемкнеться, доки ви їх не закомітите або не відкладете через stash; нічого не губиться, але після перемикання папка виглядає інакше.
Виберіть гілку в перемикачі над списком файлів.
git switch -c <branch>Створити нову гілку з поточного місця і перейти в неї.
Нова гілка починається з вашого поточного коміту, тож спершу перейдіть в актуальний main, якщо робота має починатися з нього. Назвіть її так, як прийнято в команді, наприклад content/delivery-copy.
Гілка починається там, де ви зараз: зі старої або сторонньої гілки ви принесете її коміти у свій pull request.
Відкрийте перемикач гілок, введіть нову назву й натисніть Create branch … from main.
git branch -d <branch>Видалити локальну гілку, яку вже змерджили.
Прибирає на вашому комп'ютері після мерджу pull request. Git відмовиться, якщо в гілці є коміти, яких ніде не змерджено, тому це обережний спосіб видалення. Гілку на GitHub команда не чіпає.
Після squash-мерджу Git часто вважає гілку незмердженою, хоча робота вже в main, бо в main новий коміт, а не коміти самої гілки. Саме тоді люди тягнуться до -D.
Після мерджу сторінка pull request пропонує Delete branch (і Restore branch, якщо передумаєте).
git branch -D <branch>Видалити локальну гілку, навіть якщо її роботу так і не змерджили.
Велика D пропускає перевірку, яку робить -d. Розробники використовують її для експериментів, які точно не потрібні.
Що може піти не так
Коміти, які були лише в цій гілці, зникають з виду. Кілька тижнів їх ще можна знайти через git reflog на цьому комп'ютері, а потім вони втрачені.
Безпечніше: git branch -d <branch>
Підтягніть те, що інші змерджили, поки ви працювали. Мердж спокійніший варіант; переписувати історію варто, лише коли точно знаєте навіщо.
git fetch originЗавантажити нове з GitHub, не чіпаючи ваших файлів.
Оновлює уявлення вашого комп'ютера про GitHub (origin/main та інші гілки origin/…). Ваші власні гілки й файли лишаються такими, як були, тож її завжди безпечно запускати перед порівнянням чи перевіркою.
Не потрібно: GitHub завжди показує свій актуальний стан.
git pullПідтягнути останні коміти вашої гілки з GitHub у вашу папку.
Це fetch, а за ним мердж (або rebase, якщо так налаштовано в команді) тієї самої гілки з GitHub. У гілці, якою користуєтеся лише ви, команда просто оновлює вас до актуального стану.
Ваші файли змінюються, і якщо ви та хтось інший редагували ті самі рядки, pull зупиниться на конфлікті мерджу, який доведеться розв'язати або скасувати.
Прямого відповідника немає: GitHub завжди показує останню версію. Найближче Update branch у pull request, яке приносить main у гілку pull request.
git merge origin/mainПринести актуальний main у вашу гілку мердж-комітом.
Додає те, що інші змерджили в main, поки ви працювали, і не змінює жодного з ваших комітів. Спершу запустіть git fetch origin. Після цього достатньо звичайного git push.
Мердж може зупинитися на конфлікті; git merge --abort поверне вас туди, звідки ви почали.
У pull request натисніть Update branch у блоці мерджу (типовий варіант мерджить main у гілку).
git rebase origin/mainПеренести коміти вашої гілки поверх актуального main.
Замість мердж-коміту виходить пряма лінія: ваші коміти створюються заново один за одним, ніби ви почали з сьогоднішнього main. Деякі команди вимагають цього заради охайної історії.
Що може піти не так
Кожен перенесений коміт отримує новий хеш, тож гілка вже не збігається з GitHub і потребує force push; усі, хто працює з цією гілкою, мусять лагодити свої копії. Конфлікти можуть виникати на кожному коміті окремо.
Безпечніше: git merge origin/main
Update branch → Update with rebase у pull request робить те саме на GitHub.
git push --force-with-leaseПерезаписати вашу гілку на GitHub, але лише якщо ніхто не надсилав у неї зміни, відколи ви востаннє дивилися.
Потрібна після rebase чи amend комітів, які вже були надіслані. На відміну від простого --force, вона відмовить, якщо на GitHub у гілці є коміти, яких ваш комп'ютер ще не бачив.
Що може піти не так
Команда замінює історію гілки на GitHub: коміти, яких немає у вашій версії, з неї зникають, а фоновий fetch вашого редактора може обійти перевірку. Ніколи не використовуйте її для main чи гілки, у якій працюють інші.
Безпечніше: git merge origin/main
З GitHub CLI можна переглядати, читати, запускати і схвалювати pull requests просто з термінала.
gh pr listПоказати відкриті pull requests репозиторію.
Показує номер, назву й гілку кожного відкритого pull request. Додайте --author @me, щоб побачити свої, або --search "review-requested:@me", щоб побачити ті, що чекають вашого рев'ю.
Вкладка Pull requests репозиторію.
gh pr view <number> --webВідкрити сторінку pull request у браузері.
Швидкий перехід з термінала на знайому сторінку. Без --web команда виводить назву, опис, рецензентів і підсумок перевірок прямо в терміналі.
Сама сторінка pull request.
gh pr diff <number>Прочитати все, що змінює pull request, у терміналі.
Виводить той самий diff, що й вкладка Files changed. Зручно, коли хочете шукати по змінах звичними інструментами; локально нічого не змінює.
Вкладка Files changed у pull request.
gh pr checks <number>Побачити, чи пройшли автоматичні перевірки pull request.
Показує кожну перевірку (тести, збірка, preview-деплой) з її станом: пройшла, впала чи ще триває. Додайте --watch, щоб дочекатися завершення.
Список перевірок у блоці мерджу внизу pull request або вкладка Checks.
gh pr checkout <number>Отримати гілку pull request на свій комп'ютер, щоб самому спробувати зміну.
Завантажує гілку й перемикає на неї вашу папку, тож можна запустити проєкт і прокликати фічу. Коли закінчите, поверніться в main через git switch main.
Ваша папка перемикається на гілку pull request; спершу закомітьте або відкладіть через stash власні зміни, інакше Git може не перемкнутися.
Якщо в команді є preview-деплої, посилання в перевірках pull request дозволяє спробувати зміну без жодної з цих команд.
gh pr review <number> --approveСхвалити pull request з термінала.
Надсилає схвальне рев'ю від вашого імені. Додайте -b "<text>", щоб написати, що саме ви перевірили, наприклад що текст відповідає issue.
Схвалення бачать усі, і саме воно може розблокувати мердж; схвалюйте лише те, що справді перевірили.
У Files changed натисніть кнопку рев'ю (Submit review, у старішому інтерфейсі Review changes), виберіть Approve і надішліть.
gh pr review <number> --comment -b "<text>"Залишити відгук у рев'ю, не схвалюючи й не блокуючи.
Публікує коментар-рев'ю до всього pull request. Підходить для запитань і зауважень; коментарі до конкретних рядків зручніше писати в браузері.
Коментар публікується одразу й сповіщає автора та рецензентів; його можна відредагувати, але не «відкликати».
Відкрийте кнопку рев'ю у Files changed, напишіть коментар, виберіть Comment і надішліть.
Знайдіть файли з конфліктом, завершіть мердж, коли їх виправлено, або поверніться туди, звідки почали.
git diff --name-only --diff-filter=UПоказати лише файли, у яких ще є конфлікти.
U означає unmerged, тобто незмерджені. У кожному файлі зі списку ще є маркери конфлікту (<<<<<<<, =======, >>>>>>>), які треба владнати; порожній список означає, що мердж можна завершувати. git status показує ті самі файли серед інших.
Resolve conflicts у pull request відкриває редактор, де файли з конфліктами перелічено зліва.
git merge --continueЗавершити мердж, коли всі конфлікти виправлено.
Коли ви відредагували кожен конфліктний файл і виконали для нього git add, ця команда створює мердж-коміт. Git відкриє редактор з готовим повідомленням; збережіть і закрийте його.
Усе, що зараз у файлах, стає результатом мерджу, тож перевірте, що не лишилося маркерів конфлікту чи половинчастих версій.
У редакторі конфліктів натисніть Mark as resolved для кожного файлу, а потім Commit merge.
git merge --abortСкасувати мердж, що зупинився на конфліктах, і повернутися до стану перед ним.
Аварійний вихід: ваша гілка виглядає точно так, як до початку мерджу. Згодиться, коли для рішення потрібен автор іншої зміни.
Виправлення конфліктів, які ви вже ввели, буде відкинуто, а якщо перед мерджем у вас були незакомічені зміни, Git може їх не повернути.
Скасовувати нічого: вийдіть з редактора конфліктів, не натискаючи Commit merge, і нічого не збережеться.
git rebase --abortСкасувати rebase, що триває, і відновити вашу гілку.
Якщо rebase зупинився на конфлікті, а ви вирішили краще зробити мердж, ця команда повертає гілку точно в стан до початку rebase.
Виправлення конфліктів, зроблені під час цього rebase, буде відкинуто.
Тут теж знадобиться:git statusgit add <file>
Більшість команд скасування залишають слід того, що ви скасували. Ті кілька, що не залишають, позначено червоним: спершу прочитайте примітку.
git restore <file>Відкинути незакомічені зміни в одному файлі.
Файл повертається до останньої збереженої версії (позначеної, якщо ви виконали git add, інакше до останнього коміту). Інших файлів команда не чіпає.
Що може піти не так
Відкинуті зміни зникають назавжди: їх ніколи не комітили, тож Git не має копії.
Безпечніше: git stash push -m "<text>"
git restore --staged <file>Прибрати файл з наступного коміту, зберігши ваші зміни.
Протилежність git add: файл більше не позначено для коміту, але його вміст у папці лишається таким, як ви його залишили.
Невеликий: змінюється лише позначка «включити в наступний коміт»; якщо прибрали не той файл, просто додайте його знову.
git revert <commit>Скасувати коміт, додавши новий, який робить зворотну зміну.
Безпечний спосіб скасувати те, чим уже поділилися: історія зберігає і оригінал, і скасування, а нічиї копії не ламаються. Надішліть новий коміт (або відкрийте з ним pull request), як будь-яку іншу зміну.
Якщо пізніші коміти змінювали ті самі рядки, revert зупиниться на конфлікті; до того ж він додає коміт у вашу поточну гілку, тож перевірте, у якій ви гілці.
git revert -m 1 <commit>Скасувати весь змерджений pull request, не переписуючи main.
Для pull request, змердженого мердж-комітом: -m 1 каже Git зберегти бік main і прибрати те, що принесла гілка. Якщо у вашій команді squash-мердж, pull request це один звичайний коміт, і достатньо простого git revert <commit>.
Git і далі вважає цю гілку змердженою: повторний мердж пізніше не поверне скасованих змін, якщо не скасувати сам revert.
На змердженому pull request натисніть Revert: GitHub підготує новий pull request, який його скасовує.
git reset --soft HEAD~1Скасувати останній коміт, але залишити його зміни готовими до нового коміту.
HEAD~1 означає «на один коміт назад». Коміт зникає з гілки, а його зміни лишаються позначеними, тож їх можна розділити чи закомітити інакше.
Команда переписує історію гілки: для коміту, який ще не надсилали, це нормально, а для надісланого потім знадобиться force push.
git reset --hard <commit>Повернути гілку до коміту й викинути все, що було після нього.
Робить вашу папку точно такою, як у цьому коміті. Розробники використовують його, щоб почати спочатку в гілці, якою більше ніхто не користується.
Що може піти не так
Незакомічені зміни зникають назавжди. Коміти після цієї точки зникають із гілки; у спільній гілці це переписує історію для всіх.
Безпечніше: git revert <commit>
git stash push -m "<text>"Відкласти незавершені зміни, не комітячи їх.
Ваші зміни відкладаються на «полицю», а папка повертається до останнього коміту, тож можна перемкнути гілку чи зробити pull. Повідомлення допоможе згодом упізнати відкладене; git stash pop повертає зміни.
Зовсім нові файли не відкладаються, якщо не додати -u, а stash живе лише на цьому комп'ютері, де про нього легко забути.
git stash popПовернути зміни, які ви відклали останніми.
Застосовує останній stash до вашої папки й прибирає його зі списку. git stash list показує все, що ви відклали.
Якщо файли тим часом змінилися, може виникнути конфлікт; тоді stash зберігається, тож нічого не губиться.
git reflogЗнайти коміт, який ніби зник після reset чи видалення гілки.
Щоденник усіх місць, де побував вказівник вашої гілки на цьому комп'ютері, найновіші зверху. Знайдіть рядок до «аварії», скопіюйте його хеш, і розробник зможе повернути той стан, наприклад у новій гілці через git switch -c <branch> <commit>.
git clean -n -dПодивитися, які невідстежувані файли й папки видалить clean.
-n означає пробний запуск: команда лише виводить список. Невідстежувані означає, що Git ніколи не мав їхньої копії, тож прочитайте цей список перед справжнім clean.
git clean -fdВидалити всі невідстежувані файли й папки.
Прибирає все, про що Git не знає (нові файли, які ви так і не додали), не чіпаючи ігнорованих файлів. Розробники використовують її, щоб отримати чисту папку після безладного експерименту.
Що може піти не так
Видалені файли ніколи не комітили, тож вони зникають назавжди: їх немає ні в Git, ні в кошику.
Безпечніше: git clean -n -d
Тут теж знадобиться:git commit --amendgit push --force-with-leasegit merge --abortgit rebase --abort
Змерджено ще не означає випущено. Теги показують, у якій версії зміна з'явилася вперше і що увійшло в кожен реліз.
git tag --list "v1.*"Показати теги релізів, відфільтровані за шаблоном.
* означає будь-що, тож "v1.*" показує всі релізи 1.x. Без шаблону ви побачите всі теги. Додайте --sort=-v:refname, щоб найновіша версія була першою.
Сторінка Releases або її вкладка Tags у правій частині сторінки репозиторію.
git describe --tagsПобачити, до якої версії найближчий код у вашій папці.
Називає найближчий тег позаду вашого поточного коміту. v1.4.1 означає, що ви точно на цьому релізі; v1.4.1-3-g9c4a2d7 означає три коміти після нього, на коміті 9c4a2d7.
git tag --contains <commit>Побачити, які релізи містять коміт.
Показує всі теги, які вже містять коміт. Якщо список починається з v1.4.1, виправлення вийшло у 1.4.1; порожній список означає, що воно ще не вийшло в релізі, навіть якщо його вже змерджили.
Відкрийте сторінку коміту: теги, що його містять, видно під повідомленням коміту.
git branch -r --contains <commit>Перевірити, чи коміт уже потрапив у main (або в іншу гілку на GitHub).
Показує гілки на GitHub, які містять коміт, станом на останній git fetch. Якщо в списку є origin/main, коміт змерджено. Якщо у вашій команді squash-мердж, беріть хеш коміту зі змердженого pull request, а не з гілки.
Сторінка коміту показує під повідомленням гілки, що його містять.
git log --oneline <tag>..<tag>Показати все, що увійшло між двома релізами.
Спершу вкажіть старіший тег, наприклад v1.4.0..v1.5.0: отримаєте коміти, які є в 1.5.0, але не було в 1.4.0. Зі squash-мерджами це один рядок на pull request, готова чернетка для release notes.
Відкрийте /compare/v1.4.0...v1.5.0 у репозиторії або скористайтеся Generate release notes, коли готуєте реліз.
git tag -a <tag> -m "<text>"Позначити поточний коміт як реліз тегом з версією.
Створює анотований тег з вашим іменем, датою й приміткою на поточному коміті, наприклад v1.5.0. Він лишається на вашому комп'ютері, доки ви його не надішлете.
Теги не повинні переміщатися: якщо позначити не той коміт і надіслати тег, люди й інструменти можуть встигнути скористатися цією версією, перш ніж ви її виправите.
Releases → Draft a new release, введіть новий тег і виберіть цільову гілку; GitHub створить тег, коли ви опублікуєте реліз.
git push origin <tag>Опублікувати тег на GitHub.
Звичайний git push тегів не надсилає; ця команда надсилає один тег. У багатьох команд є автоматизація, яка збирає або деплоїть реліз, щойно з'являється тег версії.
Надсилання тегу може запустити справжній реліз чи деплой, і цю версію тепер бачать усі.
Публікація релізу на GitHub створює й публікує його тег за один крок.
git cherry-pick <commit>Скопіювати один коміт у поточну гілку, наприклад виправлення в гілку релізу.
Команди з гілками релізів використовують її, щоб випустити термінове виправлення без усього іншого, що чекає в main. Копія отримує новий хеш, тож та сама зміна з'являється в історії двічі.
Команда додає коміт у ту гілку, де ви зараз, і може зупинитися на конфлікті; git cherry-pick --abort скасовує її.
Десять ситуацій за раунд. Виберіть команду, яка розв'язує задачу; після відповіді кожен варіант пояснить, чому він підходить чи ні.
Ви хоча б раз розв'язали 0 з 22 ситуацій.
«Уже змерджено», — каже Daniel про виправлення оплати. Ви хочете переконатися, що коміт 3f9a2c1 справді є в main. Яка команда це покаже?
Пройти безкоштовний курс з Git: Git і GitHub для продактів
У блозі: Git для продакт-менеджерів: читаємо репозиторій без командного рядка
У блозі: GitHub flow чи git flow: яка модель гілок пасує вашій команді і що це змінює для продакта
У блозі: Як робити рев'ю pull request, якщо ви продакт, а не розробник
У блозі: Семантичне версіонування простими словами: що означає v1.4.1 і коли зміна справді на сайті