Найтиповіші помилки і питання, пов'язані з Git, і зручні способи їх вирішення

Якщо ви хочете краще пізнати ті частини git, про які раніше боялися запитати, то цей список для вас. Тут зібрані найбільш типові ситуації і способи їх вирішення як з особистого досвіду автора, так і зібрані по всьому Інтернету.

Помилка в коментарі до коммітов

Якщо Комміт ще не був відправлений на сервер (push), то можна скористатися простою командою, що дозволяє редагувати текст повідомлення до останнього коммітов.

git commit --amend

Як скасувати останній Комміт?

Можна використовувати git reset, ось так:

git reset --hard HEAD ~ 1

HEAD ~ 1 означає один Комміт до HEAD тобто до поточного положення. Варто зауважити, що це "ядерний" спосіб, який скасує всі зміни. Якщо вам потрібно зберегти все, що ви зробили, але ще не встигли закоммітіть, використовуйте:

git reset --soft HEAD ~ 1

Видалити гілку на сервері

git push origin --delete імя_веткі

У чому різниця між "git pull" і "git fetch"?

git pull - це по суті git fetch після якого відразу ж следуюет git merge. git fetch отримує зміни з сервера і зберігає їх в refs / remotes /. Це ніяк не впливає на локальні гілки і поточні зміни. А git pull вже вливає всі ці зміни в локальну копію.

Як скасувати "git add" до коммітов?

Ви виконали git add имя_файла випадково і хочете скасувати додавання цього файлу. Якщо Комміт ще не було зроблено, то допоможе:

git reset имя_файла

Як вирішувати конфлікти злиття?

Використовуйте git mergetool, яка надає зручний інтерфейс для вирішення конфліктів.

Видалити всі локальні файли і директорії, які не відслідковуються гітом з вашої поточної копії

Обережно! Краще зробіть бекап перед цим.

Клонувати все гілки з сервера

Швидше за все, ви це вже зробили, а гілки просто приховані. Ось команда, щоб показати їх всі:

Можна використовувати git checkout origin / імя_веткі, щоб подивитися на потрібну гілку. Або git checkout -b імя_веткі origin / імя_веткі, щоб створити локальну гілку, відповідну віддаленої.

Перейменувати локальну гілку

git branch -m oldname newname

Повернутися до будь-якого коммітов

Можна використовувати reset, як показано раніше, але це буде означати, що ви хочете назавжди повернутися до того стану, в якому ви були, а не просто подивитися на нього (для цього треба зробити checkout). Ідентифікатор коммітов повинен бути такий, як він прописаний у висновку команди git log.

git reset --hard ідентіфікатор_комміта

Ще раз повторимо, що це скасує всі поточні зміни, так що переконаєтеся, що це дійсно те, що вам потрібно. Або ж за допомогою --soft замість --hard.

Видалити подмодуль (submodule)

Створення подмодулей використовується досить рідко, але іноді вони все таки потрібні. Так що ось що вам потрібно:

git submodule deinit submodulename
git rm submodulename
git rm --cached submodulename
rm -rf .git / modules / submodulename

Перезаписати локальні файли під час git pull

Вам знову допоможе git reset:

git fetch --all
git reset --hard origin / master

Як додати порожню директорію в репозиторій?

Ніяк! Це просто не підтримується і вважається, що вам це не потрібно. Але є один трюк. Можна створити файл.gitignore в потрібній директорії з наступним змістом:

# Ігноруємо все в цій директорії
*
# Крім самого файла.gitignore
! .gitignore

Експорт вихідного, аналогічно "svn export"

Використовуйте git archive, наприклад так:

git archive --format zip --output /путь/к/файлу/файл.zip master

Скасувати всі зміни, крім тих, що вже додані в планований Комміт

git checkout -.

Створити нову гілку на сервері з поточної локальної гілки

git config --global push.default current
git push -u

Відновити віддалений файл

Спочатку потрібно знайти останній Комміт, де файл ще існував.

Віддалені гілки - це посилання на стан гілок в ваших віддалених репозиторіях. Це локальні гілки, які не можна переміщати; вони рухаються автоматично всякий раз, коли ви здійснюєте зв'язок по мережі. Віддалені гілки діють як закладки для нагадування про те, де гілки в віддалених репозиторіях знаходилися під час останнього підключення до них.

Вони виглядають як (ім'я молодецький. Репоз.) / (Гілка). Наприклад, якщо ви хочете подивитися, як виглядала гілка master на сервері origin під час останнього з'єднання з ним, перевірте гілку origin / master. Якщо ви з партнером працювали над однією проблемою, і він виклав гілку iss53, у вас може бути своя локальна гілка iss53; але та гілка на сервері буде вказувати на Комміт в origin / iss53.

Все це, можливо, збиває з пантелику, тому давайте розглянемо приклад. Скажімо, у вас в мережі є свій Git-сервер на git.ourcompany.com. Якщо ви з нього щось склоніруете (clone), Git автоматично назве його origin, забере звідти всі дані, створить покажчик на те, на що там вказує гілка master, і назве його локально origin / master (але ви не можете його рухати) . Git також зробить вам вашу власну гілку master, яка буде починатися там же, де і гілка master в origin, так що вам буде з чим працювати (див. Рис. 3-22).

Малюнок 3-22. Клонування Git-проекту дає вам власну гілку master і origin / master, який вказує на гілку master в origin.

Якщо ви зробите щось в своїй локальній гілці master, а тим часом хтось ще відправить (push) зміни на git.ourcompany.com і оновить там гілку master, то ваші історії продовжаться по-різному. Ще, до тих пір, поки ви не зв'яжетеся з сервером origin, ваш покажчик origin / master НЕ буде зрушуватися (див. Рис. 3-23).

Малюнок 3-23. При виконанні локальної роботи і відправці ким-то змін на віддалений сервер кожна історія триває по-різному.

Для синхронізації вашої роботи виконується команда git fetch origin. Ця команда шукає, якого сервера відповідає origin (в нашому випадку це git.ourcompany.com); витягує звідти всі дані, яких у вас ще немає, і оновлює ваше локальне сховище даних; зрушує покажчик origin / master на нову позицію (див. рис. 3-24).

Малюнок 3-24. Команда git fetch оновлює ваші вилучені посилання.

Щоб продемонструвати те, як будуть виглядати віддалені гілки в ситуації з декількома віддаленими серверами, припустимо, що у вас є ще один внутрішній Git-сервер, який використовується для розробки тільки однією з ваших команд розробників. Цей сервер знаходиться на git.team1.ourcompany.com. Ви можете додати його в якості нової віддаленої посилання на проект, над яким ви зараз працюєте за допомогою команди git remote add так само, як було описано в розділі 2. Дайте цьому віддаленого сервера ім'я teamone, яке буде скороченням для повного URL (див. Рис . 3-25).

Малюнок 3-25. Додавання додаткового віддаленого сервера.

Тепер можете виконати git fetch teamone, щоб витягти все, що є на сервері і немає у вас. Так як в даний момент на цьому сервері є тільки частина даних, які є на сервері origin, Git не отримує ніяких даних, але виставляє віддалену гілку з ім'ям teamone / master, яка вказує на той же Комміт, що і гілка master на сервері teamone ( см. рис. 3-26).

Малюнок 3-26. У вас з'явилася локальна посилання на гілку master на teamone-е.

Відправка змін

Якщо у вас є гілка serverfix, над якою ви хочете працювати з кимось ще, ви можете відправити її точно так же, як ви відправляли вашу першу гілку. Виконайте git push (молодецький. Сервер) (гілка):

$ Git push origin serverfix Counting objects: 20, done. Compressing objects: 100% (14/14), done. Writing objects: 100% (15/15), 1.74 KiB, done. Total 15 (delta 5), \u200b\u200breused 0 (delta 0) To [Email protected]: Schacon / simplegit.git * serverfix -\u003e serverfix

Це в деякому роді скорочення. Git автоматично розгортає ім'я гілки serverfix до refs / heads / serverfix: refs / heads / serverfix, що означає "візьми мою локальну гілку serverfix і обнови з неї віддалену гілку serverfix". Ми детально обговоримо частина з refs / heads / в розділі 9, але зазвичай її можна опустити. Ви також можете виконати git push origin serverfix: serverfix - відбудеться те ж саме - тут йдеться "візьми мій serverfix і зроби його віддаленим serverfix". Можна використовувати цей формат для відправки локальної гілки в віддалену гілку з іншим ім'ям. Якщо ви не хочете, щоб гілка називалася serverfix на віддаленому сервері, то замість попередньої команди виконайте git push origin serverfix: awesomebranch. Так ваша локальна гілка serverfix відправиться в гілку awesomebranch віддаленого проекту.

$ Git fetch origin remote: Counting objects: 20, done. remote: Compressing objects: 100% (14/14), done. remote: Total 15 (delta 5), \u200b\u200breused 0 (delta 0) Unpacking objects: 100% (15/15), done. From [Email protected]: Schacon / simplegit * serverfix -\u003e origin / serverfix

Важливо відзначити, що коли при отриманні даних у вас з'являються нові видалені гілки, ви не отримуєте автоматично для них локальних редагованих копій. Іншими словами, в нашому випадку ви не отримаєте нову гілку serverfix - тільки покажчик origin / serverfix, який ви не можете змінювати.

Щоб злити ці напрацювання в свою поточну робочу гілку, виконайте git merge origin / serverfix. Якщо вам потрібна своя власна гілка serverfix, над якою ви зможете працювати, то ви можете створити її на основі віддаленої гілки:

$ Git checkout -b serverfix origin / serverfix Branch serverfix set up to track remote branch refs / remotes / origin / serverfix. Switched to a new branch "serverfix"

Це дасть вам локальну гілку, на якій можна працювати. Вона буде починатися там, де і origin / serverfix.

відстеження гілок

Отримання локальної гілки за допомогою git checkout з віддаленої гілки автоматично створює те, що називається відслідковується гілкою. Відслідковують гілки - це локальні гілки, які безпосередньо пов'язані з віддаленої гілкою. Якщо, перебуваючи на відслідковується гілці, ви наберете git push, Git вже буде знати, на який сервер і в яку гілку відправляти зміни. Аналогічно виконання git pull на одній з таких гілок спочатку отримує все вилучені посилання, а потім автоматично робить злиття з відповідною віддаленої гілкою.

При клонуванні сховища, як правило, автоматично створюється гілка master, яка відстежує origin / master, тому git push і git pull працюють для цієї гілки "з коробки" і не вимагають додаткових аргументів. Однак, ви можете налаштувати відстеження та інших гілок віддаленого сховища. Простий приклад, як це зробити, ви побачили тільки що - git checkout -b [гілка] [молодецький. сервер] / [гілка]. Якщо ви використовуєте Git версії 1.6.2 або більш пізню, можете також скористатися скороченням --track:

$ Git checkout --track origin / serverfix Branch serverfix set up to track remote branch refs / remotes / origin / serverfix. Switched to a new branch "serverfix"

Щоб налаштувати локальну гілку з ім'ям, відмінним від імені віддаленої гілки, ви можете легко використовувати першу версію з іншим ім'ям локальної гілки:

$ Git checkout -b sf origin / serverfix Branch sf set up to track remote branch refs / remotes / origin / serverfix. Switched to a new branch "sf"

Тепер ваша локальна гілка sf буде автоматично відправляти (push) і отримувати (pull) зміни з origin / serverfix.

Видалення гілок на віддаленому сервері

Скажімо, ви і ваші співавтори закінчили з нововведенням і злили його в гілку master на віддаленому сервері (або в якусь іншу гілку, де зберігається стабільний код). Ви можете видалити гілку на віддаленому сервері, використовуючи кілька безглуздий синтаксис git push [молодецький. сервер]: [гілка]. Щоб видалити гілку serverfix на сервері, виконайте наступне:

$ Git push origin: serverfix To [Email protected]: Schacon / simplegit.git - serverfix

Хлоп. Немає більше гілки на вашому сервері. Вам може захотітися зробити закладку на поточній сторінці, так як ця команда вам знадобиться, а синтаксис ви, швидше за все, забудете. Можна запам'ятати цю команду повернувшись до синтаксису git push [молодецький. сервер] [лок. гілка]: [молодецький. гілка], який ми розглядали трохи раніше. Опускаючи частина [лок. гілка], ви, по суті, говорите "візьми ніщо в моєму репозиторії і зроби так, щоб в [молодецький. гілка] було те ж саме ".

Якщо використовується аутентифікація по паролю:

$ Git clone https: // username: [Email protected]/opt/git/repository.git

Робота з гілками

Показати всі гілки:

$ Git branch

Створити нову гілку:

$ Git branch

Перейти в нову гілку:

$ Git checkout

Створити нову гілку і перейти в неї:

$ Git checkout -b

Видалити локальну гілку:

$ Git branch -d

Видалити гілку з віддаленого сховища:

$ Git push origin --delete

Робота з коммітов

Як видалити останній Комміт?

$ Git reset --soft HEAD ^

Git How To. Глава 16. Скасування коммітов
Git How To. Глава 17. Видалення комміттов з гілки
Офіційна документація Git. Основи Git - Скасування змін

Як змінити останній Комміт?

$ Git add new_file.txt
$ Git commit --amend

Як змінити коментар до останнього коммітов?

$ Git commit --amend
$ Git commit --amend -m "Новий коментар"

Як об'єднати кілька коммітов?

$ Git rebase -i HEAD ~ 3

Замість HEAD ~ 3 можна використовувати hash коммітов. Потрібно передати hash того коммітов, до якого потрібно все об'єднати (сплюснути).
Відкриється редактор зі списком коммітов, вгорі буде найстаріший Ком.

pick 1111111 Commit 1 comment
pick 2222222 Commit 2 comment
pick 3333333 Commit 3 comment

Потрібно заменть pick на squash, щоб вийшло так:

pick 1111111 Commit 1 comment
squash 2222222 Commit 2 comment
squash 3333333 Commit 3 comment

Далі потрібно зберегти файл і вийти. Буде знову буде відкритий текстовий редактор з усіма коментарями до коммітов. Потрібно відредагувати, зберегти і вийти. Після цих дій коммітов будуть об'єднані.

Як скасувати зміни в певному файлі і повернути його в стан, в якому він знаходився після останнього коммітов?

$ Git checkout - file.txt

Як скасувати всі незафіксовані (незакоміченние) зміни?

$ Git checkout

Як притримати деякі файли для наступного коммітов?

Припустимо, ви хочете закоммітіть зміни в деяких файлах, а зміни в інших файлах зафіксувати в наступному Ком. Тоді можна тимчасово видалити їх зі сховищ (unstage files), а потім знову додати.