Чари git - глава 6

Глава 6. багато користувачів Git

Спочатку я використовував Git для особистого проекту, в якому був єдиним розробником. Серед команд, що відносяться до розподілених властивостями Git, мені були потрібні тільки pull і clone. щоб зберігати один і той же проект в різних місцях.

Щоб встановити ці параметри лише для поточного сховища, опустіть прапор --global.

Git через SSH, HTTP

Припустимо, у вас є SSH доступ до веб-сервера, але Git не встановлено. Git може зв'язуватися через HTTP, хоча це і менш ефективно, ніж його власний протокол.

Для старих версій Git команда копіювання не спрацює, і ви повинні будете запустити

Тепер ви можете публікувати свої останні правки через SSH з будь-якого клону:

і хто завгодно зможе взяти ваш проект за допомогою

Git через що завгодно

Хочете синхронізувати сховища без серверів або взагалі без мережевого підключення? Змушені імпровізувати на ходу в непередбаченій ситуації? Ми бачили, як git fast-export і git fast-import можуть перетворити сховища в один файл і назад. За допомогою обміну такими файлами ми можемо переносити сховища git будь-якими доступними засобами, але є більш ефективний інструмент: git bundle.

Відправник створює пакет (bundle):

Одержувач може зробити це навіть в порожньому сховище. Незважаючи на свій невеликий розмір, якийсь файл містить уся вихідна сховище Git.

У великих проектах для усунення надлишків обсягу пакетируют тільки зміни, яких немає в інших сховищах. Наприклад, нехай Комміт «1b6d ...» - останній загальний для обох груп:

Якщо це робиться часто, можна легко забути, який Комміт був відправлений останнім. Довідка пропонує для вирішення цієї проблеми використовувати теги. А саме, після передачі пакета введіть

і створюйте оновлені пакети з допомогою

Патчі: загальне застосування

Згадаймо з першого розділу:

виводить патч, який може бути вставлений в лист для обговорення. У Git сховище введіть

для застосування патча.

Отримані файли можуть бути відправлені за допомогою git-send-email або вручну. Ви також можете вказати діапазон коммітов:

На приймаючій стороні збережіть лист в файл і введіть:

З web-інтерфейсом до електронної пошти вам, можливо, буде потрібно натиснути кнопку, щоб подивитися електронну пошту в своєму первісному вигляді перед збереженням патча в файл.

Для клієнтів електронної пошти, що використовують mbox, є невеликі відмінності; але якщо ви використовуєте один з них, то ви, як видно, можете легко розібратися в цьому без читання описів!

Приносимо вибачення, ми переїхали

Опція branch.master.merge задає віддалену гілку за замовчуванням для git pull. В ході первинного клонування вона встановлюється на поточну гілку вихідного сховища, так що навіть якщо HEAD вихідного сховища згодом переміститься на іншу гілку, pull буде вірно слідувати початкової гілці.

Цей параметр звертається тільки до сховища, яке ми спочатку клонували і яке записано в параметрі branch.master.remote. При виконанні pull з інших сховищ ми повинні вказати потрібну гілку:

Це пояснює, чому деякі з наших попередніх прикладів push і pull не мали аргументів.

Дистанційні гілки

При клонуванні сховища ви також клонуєте все його гілки. Ви можете не помітити цього, тому що Git приховує їх: ви повинні запитати їх явно. Це запобігає протиріччя між гілками в віддаленому сховище і вашими гілками, а також робить Git простіше для початківців.

Список віддалених гілок можна подивитися командою

Ви повинні побачити щось на зразок

Ці імена відповідають гілкам і «голові» в віддаленому сховище; їх можна використовувати в звичайних командах Git. Наприклад, ви зробили багато коммітов, і хотіли б порівняти поточний стан з останньої завантаженої версією. Ви можете шукати в журналах потрібний SHA1 хеш, але набагато легше набрати

Також можна побачити, для чого була створена гілка experimental:

Кілька віддалених сховищ

Припустимо, що над нашим проектом працюють ще два розробника, і ми хочемо стежити за обома. Ми можемо спостерігати більш ніж за одним сховищем одночасно, ось так:

Зараз ми зробили злиття з гілкою з другого сховища. Тепер у нас є легкий доступ до всіх гілок у всіх сховищах:

Але що якщо ми просто хочемо порівняти їх зміни, не зачіпаючи свою роботу? Іншими словами, ми хочемо вивчити чужі гілки, не даючи їх змін вторгатися в наш робочий каталог. Тоді замість pull наберіть

Так ми лише переносимо їх історію. Хоча робочий каталог залишається недоторканими, ми можемо звернутися до будь-якої гілці в будь-якому сховище команди, яка працює з Git, так як тепер у нас є локальна копія.

Тримаємо в думці, що pull це просто fetch. а потім merge. Зазвичай ми використовуємо pull. тому що ми хочемо влити до себе останній Комміт після отримання чужої гілки. Описана ситуація - визначна виняток.

Про те, як відключити віддалені сховища, ігнорувати окремі гілки та багато іншого дивіться у git help remote.

Мої налаштування

Я вважаю за краще, щоб люди, що приєднуються до моїх проектів, створювали сховища, з яких я зможу отримувати зміни за допомогою pull. Деякі хостинги Git дозволяють створювати власні Форк проекту в один дотик.

Після отримання дерева з віддаленого сховища я запускаю команди Git для навігації і вивчення змін, в ідеалі добре організованих і описаних. Я роблю злиття зі своїми зміни і можливо вношу подальші правки. Коли я задоволений результатом, я заливаю зміни в головне сховище.

Хоча зі мною мало співпрацюють, я вірю, що цей підхід добре масштабується. Дивіться цей запис в блозі Лінуса Торвальдса.