Якщо використовується аутентифікація за паролем:
- $ 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
Додавання віддаленого репозиторію
- $ git remote add origin git@gitsrv:/opt/git/test-project.git
Віддалені гілки - це посилання стан гілок у ваших віддалених репозиторіях. Це локальні гілки, які не можна переміщати; вони рухаються автоматично кожного разу, коли ви здійснюєте зв'язок через мережу. Віддалені гілки діють як закладки для нагадування у тому, де гілки у віддалених репозиторіях перебували під час останнього підключення до них.
Як джерело гілки ми використовуємо майстер-гілка, вона містить останню версію. Щоб розпочати роботу негайно, ми перемикаємось на гілку, активуючи гілку «Оформити замовлення». На сторінці Філії відображається локальна гілка. Напівжирний шрифт та виведення у верхній частині вікна показують, що наші файли знаходяться на одному рівні.
Додавання віддаленого репозиторію
Тепер ми можемо інтегрувати нову функцію. Тому у розділі «Невідслідковувані файли» слід перевірити, чи є файли, які стосуються проекту. З'явиться повідомлення з важливою запискою про те, що зміни зберігаються лише локально і все одно мають бути надіслані на сервер. Тепер настав час надати решті команди нову функцію. Наше місцеве відділення має бути опубліковане. На сторінці Філії клацніть правою кнопкою миші неопубліковану гілку, щоб вибрати публікацію в контекстному меню.
Вони виглядають як (ім'я удал. репоз.)/(гілка) . Наприклад, якщо ви хочете подивитися, як виглядала гілка 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).
Якщо не вдається зробити push на віддалений репозиторій через те, що поточна версія репозиторію менше, ніж на віддаленому репозиторії
Натиснувши на ім'я файлу або галочку зліва, виберіть або скасуйте вибірку для цього фіксації. Або хочете зафіксувати певні зміни у фіксації, або хочете використовувати певні файли. Тепер ви бачите всі попередні коміти разом з їх короткими описами, і тому вони такі важливі.
При виборі цього списку ви можете точно побачити, що змінилося. Це створює нову фіксацію, яка скасовує ваші останні дії. Якщо ви хочете перейти до стану подальшої фіксації, оберіть «відкат до цієї фіксації» з відповідною фіксацією. Це змінить ваші файли в каталозі, тому переконайтеся, що ви перенесли все до репозиторію раніше, що вам може знадобитися!
Малюнок 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 відправиться в гілку дивовижногопошти віддаленого проекту.
Давайте представимо простий приклад розгалуження та злиття з робочим процесом, який може бути представлений у реальності. Уявіть, що ви виконуєте такі кроки.
- Ви працюєте на веб-сайті.
- Ви створюєте гілку для нової теминад якою хочете працювати.
- Ви робите деяку роботу над цією гілкою.
Основні процедури розгалуження
Уявіть, що ви працюєте над проектом, і ви вже маєте кілька підтверджень. Запис простих та коротких підтверджень. Ви вирішили працювати з проблемою № 53 у системі, яку ваша компанія використовує для відстеження проблем. Оскільки проблема №53 є конкретною та своєчасною проблемою, в якій ви збираєтеся працювати, ви створюєте для нього нову гілку. На малюнку 3-11 показано результат.
$ 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.
Видалення гілок на віддаленому сервері
Малюнок 3 - гілка виправлення, заснована на початковій головній галузі. Ви можете виконати тести, переконатися, що рішення правильне, і включити зміни до провідної галузі, щоб привести їх у дію. Це те, що називається "швидка перемотування вперед". Наразі зроблені зміни вже знаходяться у знімку підтвердження, відзначеному головною гілкою. І ви можете розгорнути їх.
Після злиття головна гілка вказує на той самий сайт, що й гілка виправлення. Вирішивши невідкладну проблему, яка перервала вашу роботу, ви можете повернутись туди, де ви були. Але насамперед, цікаво видалити гілку виправлення. Оскільки нам це більше не знадобиться, оскільки воно вказує на той самий сайт, що й головна гілка.
Відстеження гілок
Отримання локальної гілки за допомогою git checkout із віддаленої гілки автоматично створює те, що називається відстежуваною гілкою. Гілки, що відстежуються, - це локальні гілки, які безпосередньо пов'язані з віддаленою гілкою. Якщо, перебуваючи на гілці, що відстежується, ви наберете git push , Git вже буде знати, на який сервер і в яку гілку відправляти зміни. Аналогічно виконання git pull на одній з таких гілок спочатку отримує всі віддалені посилання, а потім автоматично злиття з відповідною віддаленою гілкою.
Основні процедури плавлення
І з цим ви готові повернутися до роботи над проблемою №53. Припустимо, що вашу роботу з проблемою №53 вже завершено і готово до об'єднання з головною гілкою. Він дещо відрізняється від раніше виконаного злиття з виправленням. І тут запис про розвиток розходилася більш ранній точці.
Основні конфлікти, які можуть виникнути під час злиття
Ми розглядаємо цей процес як «підтверджене злиття». І це відрізняється тим, що має більше одного батька. Варто відзначити той факт, що саме Гіт сам автоматично визначає найкращого загального предка для злиття. І вручну закрити проблему в системі відстеження проблем вашої компанії. У деяких випадках процеси злиття зазвичай не є текучими. Наприклад, якщо в задачі № 53 ви змінили ту саму частину, яка також була змінена у проблемі з виправленням.
При клонуванні репозиторію, як правило, автоматично створюється гілка 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 [удал. сервер] [лок. гілка]: [вилуч. гілка] , який ми розглядали трохи раніше. Опускаючи частину [лок. гілка] , ви, по суті, кажете “візьми ніщо в моєму репозиторії і зроби так, щоб у [удал. гілка] було те саме”.
