віддалені гілки- це посилання на стан гілок в ваших віддалених репозиторіях. Це локальні гілки, які не можна переміщати; вони рухаються автоматично всякий раз, коли ви здійснюєте зв'язок по мережі. Віддалені гілки діють як закладки для нагадування про те, де гілки в віддалених репозиторіях знаходилися під час останнього підключення до них.
Злиття бере фіксації на двох різних гілках і об'єднує їх. Результат буде таким, як якби всі зміни були зроблені в одному і тому ж місці. На щастя, файли автоматично об'єднуються, якщо тільки вони не є двома конфліктуючими наборами змін, тобто фіксують різні гілки, оновлюють одну і ту ж рядок по-різному.
Перезаписати локальні файли під час git pull
Якщо ви в будь-який час заплуталися або засмутилися, ви завжди можете припинити злиття, і все знову стане блискучим. 
Поточна гілка знаходиться зліва, а гілка, з якої ви зливається, відображається праворуч. Для кожного конфлікту ви встановлюєте прапорець поруч з конфліктуючим сектором для додавання до виходу внизу. Ви можете переглянути висновок файл внизу, і ви також можете редагувати безпосередньо в цьому вікні, якщо вам потрібно.
Вони виглядають як (ім'я молодецький. Репоз.) / (Гілка). Наприклад, якщо ви хочете подивитися, як виглядала гілка master на сервері origin під час останнього з'єднання з ним, перевірте гілку origin / master. Якщо ви з партнером працювали над однією проблемою, і він виклав гілку iss53, у вас може бути своя локальна гілка iss53; але та гілка на сервері буде вказувати на Комміт в origin / iss53.
Створити нову гілку на сервері з поточної локальної гілки
Після вирішення конфлікту просто збережіть висновок і скопіюйте зміни. Бувають випадки, коли ви робите зміна, яке небажано, або не призводить до того, що ваш продукт або сайт не працюють. В інший час ви забули включити певну зміну або зробили помилку в своєму повідомленні про вчинення. У цих ситуаціях зазвичай потрібно відкат або скасування змін, внесених вами або вашою командою.
Як змінити коментар до останнього коммітов?
Заблокувати, злити, локальні або видалені зміни, і навіть незафіксовані зміни можуть бути «скасовані». Ми розглянемо різні сценарії нижче, від найменшого впливу до найбільшого. Це всього лише деякі з поширених сценаріїв, які відчувають розробники. Якщо вам потрібна допомога в чомусь іншому, наша команда хотіла б дати деякі рекомендації. Просто використовуйте кнопку «Контакт» в правому верхньому кутку, щоб увійти в контакт!
Все це, можливо, збиває з пантелику, тому давайте розглянемо приклад. Я створив віддалений репозиторій на GitHub https://github.com/n0tb0dy/RemoreBranches
Там я зробив три коммітов
При клонуванні віддаленого сховища Git автоматично назве його origin, Забере звідти всі дані, створить покажчик на те, на що там вказує гілка master, І назве його локально origin / master(Але ви не можете його рухати). Git також зробить вам вашу власну гілку master, Яка буде починатися там же, де і гілка masterв origin, Так що вам буде з чим працювати.
Як видалити всі незафіксовані зміни в моєму робочому каталозі?
І бувають випадки, коли ви хочете скасувати незафіксовані зміни. Деякі сесії кодування йдуть убік, швидко. Швидка 10-хвилинна робота може привести до змін, які залишають ваш код в набагато менш ідеальному стані, ніж коли ви почали.
І тому новий старт може бути хорошим вибором. Примітка. Важлива відмінність від незафіксованих змін полягає в тому, що ви не можете відновити зміни, які ви відкидаєте, за допомогою наведених нижче команд. Оскільки вони не були здійснені, Гіт не має записів про зміни.
"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 сервер продовжить зберігати всю інформацію про коммітов до тих пір поки ви не запустите команду прибирання сміття.
Як зробити фіксацію повністю зникнути з історії?
Якщо це станеться, ви можете використовувати. За допомогою реального проекту це буде каталог на вашому робочому сервері. Ви можете більше дізнатися про «голих» репозиторіях, але для наших цілей їх мета - просто отримати поштовхи. Тепер у нас є репозиторій розробки з його першим фіксацією. Наш останній етап підготовки - зареєструвати «віддалений» репозиторій.
Ви тільки що виштовхували свою фіксацію з розробки в ваш порожній «віддалений» репозиторій. Давайте перейдемо до папки з гачками нашого віддаленого сховища. Гаки - це скрипти, які запускаються при певних подіях. Він запускається після отримання та прийняття поштовху фіксацій. Потім відкрийте файл сценарію після отримання в улюбленому текстовому редакторі.
Віддалені гілки - це посилання на стан гілок в ваших віддалених репозиторіях. Це локальні гілки, які не можна переміщати; вони рухаються автоматично всякий раз, коли ви здійснюєте зв'язок по мережі. Віддалені гілки діють як закладки для нагадування про те, де гілки в віддалених репозиторіях знаходилися під час останнього підключення до них.
Пройдіть через кожен з кроків. Ми читаємо ці значення і присвоюємо їм змінні з, в, і гілки, відповідно. Припускаючи, що робочий процес, який підтримує виробництво на головній гілці, ми хочемо вийти з цього сценарію до розгортання, якщо вкладена гілка не є провідною. Тепер, коли наш каталог розгортання оновлений, ми можемо запускати всі завдання розгортання, які нам потрібно виконати.
Збережіть свій пост-приймальний гачок і дайте йому перевірити його! Тепер каталог, в який ми розгортаємо, повинен бути заповнений і оновлений. Коли ви працюєте над гаком після прийому, це дратує, щоб відкинути історію фіксації вашого проекту і натиснути кожен раз, коли ви вносите зміни. На щастя, оскільки це просто скрипт, ми можемо підробити його з командний рядок.
Вони виглядають як (ім'я молодецький. Репоз.) / (Гілка). Наприклад, якщо ви хочете подивитися, як виглядала гілка master на сервері origin під час останнього з'єднання з ним, перевірте гілку origin / master. Якщо ви з партнером працювали над однією проблемою, і він виклав гілку iss53, у вас може бути своя локальна гілка iss53; але та гілка на сервері буде вказувати на Комміт в origin / iss53.
Експорт вихідного, аналогічно "svn export"
Цей метод спрощує настройку ваших гачків після прийому, дозволяючи вам швидко перебирати сценарій і виконувати його повторно. Для реального світу ваші «віддалені» і «розгортаються» папки зазвичай встановлюються на сервері, а не локально. Звідси, це залежить від вашого проекту, щоб визначити, які дії потрібно автоматизувати!
Він має потужну розподілену модель, яка дозволяє просунутим користувачам робити складні речі за допомогою гілок і переписувати історію. Як шкода, що так важко вчитися, є такий неприємний інтерфейс командного рядка, І він звертається з його користувачами з таким повним презирством. Інформаційна модель складна - і вам потрібно знати все це. Це майже все, що вам потрібно знати. Фактично, гілки - це теги і файли, про які ви вже знаєте, тому вам дійсно потрібно вивчити три нові речі.
Все це, можливо, збиває з пантелику, тому давайте розглянемо приклад. Скажімо, у вас в мережі є свій 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).
Пам'ятайте складну інформаційну модельна кроці 1? Він продовжує рости, як рак. У Гіт не так аблация, скільки абстракція. По суті, немає різниці між деталями реалізації і призначеним для користувача інтерфейсом. Зрозуміло, що просунутому користувачеві може знадобитися трохи дізнатися про те, як реалізовані функції, зрозуміти тонкощі різних команд. Але навіть новачки швидко стикаються з огидними внутрішніми деталями. В теорії є «сантехніка» і «фарфор», але вам краще бути водопровідником, щоб знати, як працювати з порцеляною.
Це схоже на розповідь старої бабусі, що автострада не страшна, вона може їхати в 20 км / год на лівому провулку, якщо захоче. Переклад: Це просто, бабуся. До третього, потім троль гальмує на автостраду, пізня вершина, але спостерігайте за мраморами всередині. Важко до п'ятого, потім ручне гальмо повертається, щоб вийти.
Малюнок 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), 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 відправиться в гілку awesomebranch віддаленого проекту.
$ 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. From [Email protected]: Schacon / simplegit * serverfix -> 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 [молодецький. сервер] [лок. гілка]: [молодецький. гілка], який ми розглядали трохи раніше. Опускаючи частина [лок. гілка], ви, по суті, говорите "візьми ніщо в моєму репозиторії і зроби так, щоб в [молодецький. гілка] було те ж саме ".