Как подключить удаленную ветку git
Работа с удалёнными репозиториями
Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.
Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.
Просмотр удалённых репозиториев
Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:
Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.
Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.
Добавление удалённых репозиториев
В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add :
Получение изменений из удалённого репозитория — Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.
Отправка изменений в удаленный репозиторий (Push)
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push
. Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Просмотр удаленного репозитория
Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :
Удаление и переименование удалённых репозиториев
Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :
При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.
Как подключить удаленную ветку git
Допустим, ваш коллега создал новую ветку и отправил ее на сервер в основной репозитарий. Вам необходимо переключиться на эту ветку. Как это сделать?
Чтобы переключиться на новую ветку, нужно сделать следующие шаги.
Подключение через консоль
Узнать имя новой ветки
— этой командой получаются данные о последних изменениях в удаленном репозитарии. Если эту команду не вызывать, новую ветку в удаленном репозитарии можно просто не увидеть. Далее дается команда получения перечня (списка) имен удаленных веток:
Создать локально новую ветку, получить изменения, сделанные в этой ветке, переключиться на новую ветку
Все действия выполняются одной командой :
В нашем случае команда будет выглядеть так:
Подключение через утилиту git gui
В открывшемся окне в поле «Имя ветки» надо переключиться на пункт «Соответствовать имени отслеживаемой ветки». В области настроек «Начальная версия» должен быть выбран пункт «Отслеживаемая ветка». При этом в списке веток будут отображены удаленные ветки. Необходимо выбрать нужную удаленную ветку и нажать кнопку «Создать»:
В ветках будет видна локальная ветка, обозначенная толстым шрифтом на зеленом фоне, и соответствующая ей удаленная ветка:
Как подключится к одной из веток удаленного репозитория?
Простой 12 комментариев
git switch mainpage
Но документацию всё же стоит прочитать
— вставить диск
— нажать три раза стрелку вниз
— нажать ввод
— нажать два раза стрелку вниз
— нажать ввод
может, все-таки, лучше инструкции по гиту почитать?
в данном случае имеем ситуацию «мне нужно построить мост, дайте мне пошаговые инструкции, а не отправляйте изучать всякую фигню типа сопромата!»
П.с. море сочувствия ученикам, чей преподаватель на их вопросы по его предмету отвечает, иди и почитай учебники/материалы, а меня не спрашивай.
море терпения учителям, которые двадцать раз освещали вопрос на лекциях, который расписан в учебниках, но к которым в очередной раз подходят ученики с вопросом «а как мне на ветку в гите переключиться?».
учите матчасть. разработчитесса.
BorLaze, советую в следующий раз читать вопросы более внимательней.
Причиной вопроса не было обучение пользованию гита через механическое выполнение пошаговых инструкций без понимание сути работы гит, а срочность.
Я прекрасно понимаю, что обучение должно состоять из изучение необходимой документации для понимания принципов работы любого язывка программирования или работы, что я и так собиралась сделать и без вашего упоминания, но сделать нужно срочно и времени на изучение жжокументации нет.
море терпения учителям, которые двадцать раз освещали вопрос на лекциях, который расписан в учебниках, но к которым в очередной раз подходят ученики с вопросом «а как мне на ветку в гите переключиться?».
Searcher8, какие мы обидчивые.
позволь разжевать свою точку зрения
когда человек подписывается на какую-то работу («чтобы там доработать один код»), как-то подразумевается, что
а) человек может это сделать
б) если человек чего-то не может сделать, то он готов освоить знания в тех областях, где он «плавает»
но никоим образом, никто и никогда, не воспримет всерьез человека, который заявляет:
— да, я могу написать роман! запросто!
— только дайте мне четкие инструкции, когда ставить в конце предложения восклицательный знак, когда вопросительный, а когда точку.
— что вы меня посылаете учебник читать? самовозвышаетесь, штоле?
я не знаю, как объяснить первокласснику, что не существует «пошаговых инструкций, как написать ГариПотера, а если ни знаишь, то малчи лучьше!»
думаю, когда Вы решите свою проблему, Вы сами поймете всю нелепость своего вопроса
Searcher8, вместо написания портянок текста можно таки показать вывод команды
Команда clone по-умолчанию загружает ВЕСЬ внешний репозиторий, т. е. ВСЕ файлы. Но в рабочий каталог распаковывает только содержимое ОДНОЙ ветки — ветки main, если не было указано название конкретной ветки при клонировании. Если вам хочется работать в другой ветке, так и переключитесь в неё командой switch либо checkout.
Единственная причина, по которой у вас не сработал switch — ветки mainpage не было во внешнем репозитории в тот момент, когда вы его клонировали себе. И соответственно ветки не оказалось у вас в локальном репо. Чтобы загрузить свежие данные есть команда fetch.
Ваша команда по факту сделала fetch, но потом произвела слияние (merge) ветки mainpage в текущую ветку main. Смешали все файлы в одну кучу. Это скорее всего совсем не то, что вас попросили сделать в задаче. Дальше то что делать будете? Отправите другому программисту подправленную ветку main?
Впредь, если вам лень читать базовую документацию и хочется быстрых решений, то хотя бы помогайте нам понять что у вас там происходит. Тут же не телепаты. Мы знаем ответы, но какой именно подойдёт вам — угадать сложно. Отвечайте пожалуйста на наводящие вопросы.
PS. Подклю́чится и подключи́ться это абсолютно разные слова в русском языке )) Не путайте.
Удалённые ветки
Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространенным способом является использование веток слежения.
Ветки слежения — это ссылки на определённое состояние удалённых веток. Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удаленным репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
Для синхронизации ваших изменений с удаленным сервером выполните команду git fetch (в нашем случае git fetch origin ). Эта команда определяет какому серверу соответствует «origin» (в нашем случае это git.ourcompany.com ), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.
Отправка изменений
Когда вы хотите поделиться веткой, вам необходимо отправить её на удалённый сервер, где у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными при отправке — вам нужно явно указать те ветки, которые вы хотите отправить. Таким образом, вы можете использовать свои личные ветки для работы, которую не хотите показывать, а отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.
Если вы используете HTTPS URL для отправки изменений, Git-сервер будет спрашивать имя пользователя и пароль для аутентификации. По умолчанию вам будет предложено ввести эти данные в терминале, чтобы сервер мог определить разрешена ли вам отправка изменений.
Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.
В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :
Отслеживание веток
В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:
Чтобы создать локальную ветку с именем, отличным от имени удалённой ветки, просто укажите другое имя:
Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, вам необходимо получить данные со всех ваших удалённых серверов перед запуском команды. Сделать это можно вот так:
Получение изменений
Удаление веток на удалённом сервере
Всё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.
rdnvndr / MainGit.md
Основы работы с Git
Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.
Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.
Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.
Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.
Основы работы с удаленным репозиторием
git clone — создание копии (удаленного) репозитория
Для начала работы с центральным репозиторием, следует создать копию оригинального проекта со всей его историей локально.
Клонирует репозиторий, используя протокол http:
Клонирует репозиторий с той же машины в директорию myrepo:
Клонирует репозиторий, используя безопасный протокол ssh:
У git имеется и собственный протокол:
Импортирует svn репозиторий, используя протокол http:
git fetch и git pull — забираем изменения из центрального репозитория
Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.
git fetch — забирает изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.
Получает изменений из определенного репозитория:
Возможно также использовать синонимы для адресов, создаваемые командой git remote:
Естественно, что после оценки изменений, например, командой git diff, надо создать коммит слияния с основной:
Команда git pull сразу забирает изменения и проводит слияние с активной веткой. Забирает из репозитория, для которого были созданы удаленные ветки по умолчанию:
Забирает изменения и метки из определенного репозитория:
Как правило, используется сразу команда git pull.
git push — вносим изменения в удаленный репозиторий
После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.
Отправляет свои изменения в удаленную ветку, созданную при клонировании по умолчанию:
Отправляет изменения из ветки master в ветку experimental удаленного репозитория:
В удаленном репозитории origin удаляет ветку experimental:
Отправляет в удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:
Отправляет метки в удаленную ветку master репозитория origin:
Изменяет указатель для удаленной ветке master репозитория origin (master будет такой же как и develop):
Добавляет ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:
Работа с локальным репозиторием
git init — создание репозитория
git add и git rm — индексация изменений
Следующее, что нужно знать — команда git add. Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит.
Индексирует измененный файл, либо оповещение о создании нового:
Вносит в индекс все изменения, включая новые файлы:
Из индекса и дерева проекта одновременно файл можно удалить командой git rm.
Удаляет из индекса и дерева проекта отдельные файлы:
Хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:
Вносит в индекс все удаленные файлы:
Сбросить весь индекс или удалить из него изменения определенного файла можно командой git reset:
Удаляет из индекса конкретный файл:
Команда git reset используется не только для сбрасывания индекса, поэтому дальше ей будет уделено гораздо больше внимания.
git status — состояние проекта, измененные и не добавленные файлы, индексированные файлы
Команду git status, пожалуй, можно считать самой часто используемой наряду с командами коммита и индексации. Она выводит информацию обо всех изменениях, внесенных в дерево директорий проекта по сравнению с последним коммитом рабочей ветки; отдельно выводятся внесенные в индекс и неиндексированные файлы. Использовать ее крайне просто:
Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.
git commit — совершение коммита
Коммит — базовое понятие во всех системах контроля версий, поэтому совершаться он должен легко и по возможности быстро. В простейшем случае достаточно после индексации набрать:
Если индекс не пустой, то на его основе будет совершен коммит, после чего пользователя попросят прокомментировать вносимые изменения вызовом команды edit. Сохраняемся, и вуаля! Коммит готов. Есть несколько ключей, упрощающих работу с git commit.
Совершает коммит, автоматически индексируя изменения в файлах проекта. Новые файлы при этом индексироваться не будут! Удаление же файлов будет учтено:
Комментирует коммит прямо из командной строки вместо текстового редактора:
Вносит в индекс и создаёт коммит на основе изменений единственного файла:
Пример написания хорошего сообщения коммита:
git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»
Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).
Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.
Естественно, можно вернуться и на большую глубину коммитов,
Если команда достигнет точки ветвления, удаления коммита не произойдет.
Для команд слияния или выкачивания последних изменений с удаленного репозитория примеры резета будут приведены в соответствующих разделах.
git revert — отмена изменений, произведенных в прошлом отдельным коммитом
Возможна ситуация, в которой требуется отменить изменения, внесенные отдельным коммитом. git revert создает новый коммит, накладывающий обратные изменения.
Отменяет коммит, помеченный тегом:
Отменяет коммит, используя его хэш:
Для отмены коммита слияния (коммита у которого несколько родителей), необходимо указать хэш и номер одного из родителей коммита:
Для использования команды необходимо, чтобы состояние проекта не отличалось от состояния, зафиксированного последним коммитом.
git log — разнообразная информация о коммитах в целом
Иногда требуется получить информацию об истории коммитов; коммитах, изменивших отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих целей используется команда git log.
Простейший пример использования, в котором приводится короткая справка по всем коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении подробно узнать можно ниже, в разделе «Ветвления и слияния»):
Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра его имя (кстати, в моей старой версии git этот способ не срабатывает, обязательно добавлять » — » перед «README»):
или, если версия git не совсем свежая:
Далее приводится только более современный вариант синтаксиса. Возможно указывать время, начиная в определенного момента («weeks», «days», «hours», «s» и так далее):
изменения, касающиеся отдельной папки:
Можно отталкиваться от тегов.
Все коммиты, начиная с тега v1:
Все коммиты, включающие изменения файла README, начиная с тега v1:
Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:
Выводит на каждый из коммитов по строчке, состоящей из хэша (здесь — уникального идентификатора каждого коммита, подробней — дальше):
Лаконичная информация о коммитах, приводятся только автор и комментарий:
Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:
В принципе, формат вывода можно определить самостоятельно:
git diff — отличия между деревьями проекта, коммитами и т.д.
Показывает изменения, не внесенные в индекс:
Изменения, внесенные в индекс:
Изменения в проекте по сравнению с последним коммитом:
Можно сравнивать «головы» веток:
или активную ветку с какой-либо:
git show — показать изменения, внесенные отдельным коммитом
Посмотреть изменения, внесенные любым коммитом в истории, можно командой git show:
git blame и git annotate — команды, помогающие отслеживать изменения файлов
При работе в команде часто требуется выяснить, кто именно написал конкретный код. Удобно использовать команду git blame, выводящую построчную информацию о последнем коммите, коснувшемся строки, имя автора и хэш коммита:
Можно указать и конкретные строки для отображения:
Аналогично работает команда git annotate, выводящая и строки, и информацию о коммитах, их коснувшихся:
git grep — поиск слов по проекту, состоянию проекта в прошлом
git grep, в целом, просто дублирует функционал знаменитой юниксовой команды. Однако он позволяет слова и их сочетания искать в прошлом проекта, что бывает очень полезно.
Ищет слова tst в проекте:
Подсчитывает число упоминаний tst в проекте:
Ищет в старой версии проекта:
Команда позволяет использовать логическое И и ИЛИ.
Ищет строки, где упоминаются и первое слово, и второе:
Ищет строки, где встречается хотя бы одно из слов:
git branch — создание, перечисление и удаление веток
Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде.
Просто перечисляет существующие ветки, отметив активную:
Создаёт новую ветку new-branch:
Удаляет ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:
Удаляет ветку в любом случае:
Показывывает те ветки, среди предков которых есть определенный коммит:
Показывает коммит ответвления ветки new-name-branch от ветки master:
git checkout — переключение между ветками, извлечение файлов
Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:
Создаёт ветку, в которую и произойдет переключение:
Вернуть файл (или просто вытащить из прошлого коммита) позволяет команда вида:
Возвращает somefile к состоянию последнего коммита:
Возвращает somefile к состоянию на два коммита назад по ветке:
git merge — слияние веток, разрешение возможных конфликтов
Слияние веток, в отличие от обычной практики централизованных систем, в git происходит практически каждый день. Естественно, что имеется удобный интерфейс к популярной операции.
Пытается объединить текующую ветку и ветку new-feature:
В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.
Например, конфликт возник в файле TROUBLE, что можно увидеть в git status.
Произошла неудачная попытка слияния:
Смотрим на проблемные места:
Индексируем наши изменения, тем самым снимая метки:
Совершаем коммит слияния:
Вот и все, ничего сложного. Если в процессе разрешения вы передумали разрешать конфликт, достаточно набрать (это вернёт обе ветки в исходные состояния):
Если же коммит слияния был совершен, используем команду:
git rebase — построение ровной линии коммитов
Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера, либо сам разработчик совершал в ней коммиты.
В принципе, можно обойтись обычным git merge. Но тогда усложняется сама линия разработки, что бывает нежелательно в слишком больших проектах, где участвует множество разработчиков.
Предположим, имеется две ветки, master и топик, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.
Вариант, в котором явно указывается, что и куда накладывается:
на master накладывается активная в настоящий момент ветка:
После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования, разрешения конфликтов, файлы следует внести в индекс командой:
и продолжить наложение следующих коммитов командой:
Альтернативными выходами будут команды пропустить наложение коммита и перейти к следующему:
и отмена работы команды и всех внесенных изменений:
git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом
Если ведется сложная история разработки, с несколькими длинными ветками разработками, может возникнуть необходимость в применении изменений, внесенных отдельным коммитом одной ветки, к дереву другой (активной в настоящий момент).
Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:
Git позволяет работать одновременно с несколькими ветками одного репозитория. Для добавления ветки в отдельную директорию необходимо выполнить команду:
Для просмотра всех директориев с ветками можно воспользоваться командой:
Директорию с веткой можно перести в другое место с помощью команды:
После окончания работы с веткой в директории, её можно удалить командой:
Клонирование репозитория с подмодулями
При клонировании репозитория вам необходимо инициализировать и обновить подмодули:
Запуск данной команды эквивалентен запуску команды:
после обычного клонирования репозитория
Подмодуль ссылается на конкретную коммит в другом репозитории. Чтобы получить точное состояние всех подмодулей необходимо запустить:
Для получения состояния последнего коммита всех подмодулей необходимо выполнить следующую команду:
или использовать аргументы по умолчанию команды git pull:
Эта команда просто обновляет локальную рабочую копию. При запуске команды git status каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо зафиксировать изменения:
Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:
В текущий проект можно включить другой репозиторий Git в качестве папки, отслеживаемый Git:
Для перемещение подмодуля из одного места репозитория в другое место репозитория необходимо выполнить команду:
Для удаления подмодуля из репозитория необходимо удалить описание подмодуля и каталог с файлами подмодуля:
Прочие команды и необходимые возможности
Хэш — уникальная идентификация объектов
В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.
Больше всего нас интересует тот факт, что хэши идентифицируют коммиты. В этом смысле хэш — продвинутый аналог ревизий Subversion. Несколько примеров использования хэшей в качестве способа адресации.
Ищет разницу текущего состояния проекта и коммита за номером… сами видите, каким:
То же самое, но оставляем только шесть первых символов. Git поймет, о каком коммите идет речь, если не существует другого коммита с таким началом хэша:
Иногда хватает и четырех символов:
Читает лог с коммита по коммит:
Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно поэтому были введены другие объекты — тэги.
git tag — тэги как способ пометить уникальный коммит
Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит, имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик может оставлять на таких тегах собственную цифровую подпись.
Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.
Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:
Помечает определенный коммит:
Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:
После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff, git log и так далее:
Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».
Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для составления комментария:
Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:
Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.
Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один механизм — относительную адресацию. Например, можно обратиться прямо к предку последнего коммита ветки master:
Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:
Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки.
Аналогично, тильдой можно просто указывать, насколько глубоко в историю ветки нужно погрузиться.
Что привнес «дедушка» нынешнего коммита:
Обозначения можно объединять, чтобы добраться до нужного коммита:
Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.
Пример содержимого такого файла:
Существуют и другие способы указания игнорируемых файлов, о которых можно узнать из справки git help gitignore.
Серверные команды репозитория
Проверяет сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория:
Переупаковывает локальный репозиторий:
Создание пустого репозитория на сервере
Импорт svn репозитория на Git-сервер
Связка локальной и удаленной ветки
Отправление ветки local в удаленный репозиторий и установка локальной ветки local отслеживаемой с origin/local:
Пометка локальной ветки как отслеживаемой с origin/local:
Создание новой пустой ветки
Создание пустой ветки с именем newbranch:
Использование Git для получения версии
Установка начала новой версии на текущий коммит:
Получение номера версии для последующие коммитов: