Віддалені гілки- це посилання стан гілок у ваших віддалених репозиторіях. Це локальні гілки, які не можна переміщати; вони рухаються автоматично кожного разу, коли ви здійснюєте зв'язок через мережу. Віддалені гілки діють як закладки для нагадування у тому, де гілки у віддалених репозиторіях перебували під час останнього підключення до них.
Вони виглядають як (ім'я удал. репоз.)/(гілка) . Наприклад, якщо ви хочете подивитися, як виглядала гілка 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 серверfix Counting objects: 20, done. Compressing objects: 100% (14/14), done. Writing objects: 100% (15/15), 1.74 KiB, done. Total 15 (delta 5), reused 0 (delta 0) To [email protected]: schacon/simplegit.git * serverfix -> 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 відправиться в гілку дивовижногопошти віддаленого проекту.
$ git fetch origin remote: Counting objects: 20, done. remote: Compressing objects: 100% (14/14), done. remote: Total 15 (delta 5), reused 0 (delta 0) Unpacking objects: 100% (15/15), done. від [email protected]: schacon/simplegit * serverfix -> origin/serverfix
Важливо, що коли при отриманні даних у вас з'являються нові віддалені гілки, ви не отримуєте автоматично для них локальних копій, що редагуються. Іншими словами, у нашому випадку ви не отримаєте нову гілку serverfix - тільки вказівник origin/serverfix, який ви не можете міняти.
Щоб злити ці напрацювання в поточну робочу гілку, виконайте git merge origin/serverfix . Якщо вам потрібна своя власна гілка serverfix, над якою ви зможете працювати, то ви можете створити її на основі віддаленої гілки:
$ git checkout -b serverfix origin/serverfix Branch serverfix 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 up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch "serverfix"
Щоб налаштувати локальну гілку з ім'ям, відмінним від імені віддаленої гілки, можна легко використовувати першу версію з іншим ім'ям локальної гілки:
$ git checkout -b sf origin/serverfix Branch sf 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, про які раніше боялися запитати, то цей список для вас. Тут зібрані найбільш типові ситуації та способи їх вирішення як з особистого досвіду автора, і зібрані по всьому Інтернету.
Помилка у коментарі до комиту
Якщо коміт ще не було відправлено на сервер (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
Відновити віддалений файл
Спершу потрібно знайти останній коміт, де файл ще існував.
Якщо використовується аутентифікація за паролем:
- $ git clone https://username:password@gitsrv/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. Глава 17. Видалення комміттів із гілки
Офіційна документація Git Основи Git - Скасування змін
Як змінити останній коміт?
- $ git add new_file.txt
- $ git commit --amend
Як змінити коментар до останнього коміту?
- $ git commit --amend
- $git commit --amend-m "Новий коментар"
Як поєднати кілька коммітів?
- $ git rebase -i HEAD~3
Відкриється редактор зі списком коммітів, угорі буде найстаріший коміт.
- pick 1111111 Commit 1 comment
- pick 2222222 Commit 2 comment
- pick 3333333 Commit 3 comment
- pick 1111111 Commit 1 comment
- squash 2222222 Commit 2 comment
- squash 3333333 Commit 3 comment
Як скасувати зміни у певному файлі та повернути його до стану, в якому він перебував після останнього комміту?
- $ git checkout - file.txt
Як скасувати всі незафіксовані зміни?
- $ git checkout
Як притримати деякі файли для наступного комміту?
Допустимо, ви хочете закомітити зміни в деяких файлах, а зміни в інших файлах зафіксувати в наступному коміті. Тоді можна тимчасово видалити їх із репозиторію (unstage files), а потім знову додати.- $ git reset HEAD file.txt
Якщо не вдається зробити push на віддалений репозиторій через те, що поточна версія репозиторію менше, ніж на віддаленому репозиторії
І тут можна зробити примусовий push.- $ git push -f origin master
Злиття гілок
Як узяти з іншої гілки лише деякі файли?
- $ git checkout branchname -- path/to/file.file
Віддалені репозиторії
Виведення на екран інформації про віддалений репозиторій
- $ git remote show origin
- * remote origin
- Fetch URL: git@gitsrv:/opt/git/test-project.git
- Push URL: git@gitsrv:/opt/git/test-project.git
- HEAD branch: master
- Remote branch:
- master new (next fetch will store in remotes/origin)
- Local ref configured for "git push":
- master pushes to master (local out of date)
Додавання віддаленого репозиторію
- $ git remote add origin git@gitsrv:/opt/git/test-project.git
Віддалені гілки— це посилання на стан гілок у віддалених репозиторіях. Це локальні гілки, які не можна переміщати; вони рухаються автоматично кожного разу, коли ви здійснюєте зв'язок через мережу. Віддалені гілки діють як закладки для нагадування у тому, де гілки у віддалених репозиторіях перебували під час останнього підключення до них.
Вони виглядають як (ім'я удал. репоз.)/(гілка). Наприклад, якщо ви хочете подивитися, як виглядала гілка master на сервері origin під час останнього з'єднання з ним, перевірте гілку origin/master. Якщо ви з партнером працювали над однією проблемою, і він виклав гілку iss53, у вас може бути своя локальна гілка iss53; але ця гілка на сервері буде вказувати на комит в origin/iss53.
Все це, можливо, збиває з пантелику, тому давайте розглянемо приклад. Я створив віддалений репозиторій на GitHub https://github.com/n0tb0dy/RemoreBranches
Там я зробив три коміти
При клонуванні віддаленого репозиторію Git автоматично назве його origin, забере звідти всі дані, створить покажчик те що, що там вказує гілка master, і назве його локально origin/master(але ви не можете його рухати). Git також зробить вам вашу власну гілку master, яка починатиметься там же, де і гілка masterв originтак що вам буде з чим працювати.
"origin" це не спеціальна назва
Це подібно до назви гілки master, яка дається за умовчанням при створенні локального репозиторію. Так само як гілка masterстворюється за замовчуванням за команди git init, так само за умовчанням використовується назва originпри команді git clone. Якщо ви дасте команду git clone –o booyah, то ви отримаєте booyah/master як віддалену гілку за замовчуванням.
І так повертаємось до наших... коммітів. На віддаленому репозиторії вони виглядають так
Команда git fetchпросто отримує оновлення з сервера яких у вас ще немає і жодним чином не змінює вашу робочу директорію. Ця команда просто отримує дані і дозволяє вам самим вирішувати, що з ними робити (об'єднувати з вашими даними, редагувати і т.п.)
Команда git pull , в більшості випадків, відразу ж злиття отриманих даних з вашими.
Зазвичай, краще просто використовувати команду git fetch і команду git merge, щоб мати можливість проконтролювати процес злиття.
Видалення видалених гілок
Мається на увазі видалення гілок на віддаленому сервері
$ git push origin --delete serverfix
Хлоп! І гілка на віддаленому сервері зникла. Але в принципі ця команда просто видаляє вказівник гілки на віддаленому сервері. Git сервер продовжить зберігати всю інформацію про коміти до тих пір, поки ви не запустите команду прибирання сміття.
