Якщо ви хочете краще дізнатися про ті частини git, про які раніше боялися запитати, то цей список для вас. Тут зібрані найбільш типові ситуації та способи їх вирішення. особистого досвідуавтора, так і зібрані по всьому Інтернету.
Помилка у коментарі до комиту
Якщо коміт ще не було відправлено на сервер (push), то можна скористатися простою командою, що дозволяє редагувати текст повідомлення до останнього комміту.
Ініціалізація робочої станції
Потім можна нормально працювати на родовищі. Відповідно, отримувати та відправляти зроблені зміни. Щоб обмежити ризики та зрозуміти, що робити, ось кілька команд, які дозволять вам почати без особливих труднощів.
Налаштування загальних налаштувань
Ініціалізувати депозит для заявки. Оновити список файлів, які не можна відстежувати. Операція особливо важлива. Не забувайте файли, що містять ваші ідентифікатори, інакше їх буде видно всім!Загальні операції для роботи з віддаленим репозиторієм
Нижче наведено список файлів, які не повинні дотримуватися. Примітка: перед будь-якою операцією перевірте статус депозиту за допомогою команди.
Відновлення файлів із існуючого віддаленого сховища
Шлях, до якого ви клонуєте віддалений репозиторій, має бути порожнім перед операцією.git commit --amend
Як скасувати останній коміт?
Можна використовувати git reset, ось так:
git reset --hard HEAD~1
HEAD~1 означає один комит до HEAD тобто. до поточного становища. Варто зауважити, що це "ядерний" спосіб, який скасує зміни. Якщо вам потрібно зберегти все, що ви зробили, але ще не встигли закомітити, використовуйте:
git reset --soft HEAD~1
Додати змінені файли до локального репозиторію
Віддалений репозиторій автоматично оголошується у локальному репозиторії під оригінальним ім'ям. Якщо ви хочете зробити диференційовану фіксацію на основі файлів, замініть точку на ім'я файлу. Поки ви не маєте цього повідомлення, не йдіть далі і робіть все, що необхідно, щоб зробити ваш депозит чистим.
Скопіюйте локальні файли в «новий» віддалений репозиторій
Отримати останні зміниз віддаленого репозиторію.Етикетки пов'язані із фіксацією. Ця остання інструкція дозволяє побачити ідентифікатор фіксації. Ідентифікатор фіксації є послідовністю шістнадцяткових цифр. Загалом, взявши перші 6 або 8 символів, уникайте ризику зіткнень у контексті. Щоб оновити віддалений репозиторій.
Видалити гілку на сервері
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, яка надає зручний інтерфейсдля вирішення конфліктів.
Видалити всі локальні файли та директорії, які не відстежуються гітом з вашої поточної копії
Обережно! Краще зробіть бекап перед цим.
Отримати код для версії
Переключити в гілці, що розглядається. Поєднує гілку, вказану в поточній гілці. Переривання поточного злиття, особливо якщо є конфлікти, які ви хочете обробляти негайно. Ви можете це зробити тільки з локального репозиторію. Потім у вас буде 3 додатки, інтегровані один з одним, які дозволяють. Будь-коли ви можете щось скасувати. Ми розглянемо деякі базові інструменти, щоб скасувати зроблені зміни. Будьте обережні, однак, тому що ви не можете завжди відновити те, що ви хочете скасувати.
Клонувати всі гілки із сервера
Швидше за все, ви це вже зробили, а гілки просто приховані. Ось команда, щоб показати їх усі:
Можна використовувати 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 сервер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 [удал. сервер] [лок. гілка]:[вилуч. гілка] , який ми розглядали трохи раніше. Опускаючи частину [лок. гілка] , ви, по суті, кажете “візьми ніщо в моєму репозиторії і зроби так, щоб у [удал. гілка] було те саме”.
