Как скопировать ветку git на локальный компьютер

Обновлено: 04.07.2024

У меня есть локальный репозиторий Git под названием «скелет», который я использую для хранения скелетов проектов. У него есть несколько веток для разных проектов:

Если я хочу проверить основную ветку для нового проекта, я могу сделать

И все так, как я хочу. В частности, новая главная ветвь указывает на основную ветвь скелета, и я могу нажимать и тянуть, чтобы перемещать изменения в базовой настройке проекта.

Однако не работает, если я хочу клонировать другую ветку. Я не могу этого понять, поэтому я извлекаю только ту ветку, которую хочу, например ветку rails , а затем в новом репозитории есть ветка master , которая отправляет и извлекает из скелетного репозитория rails по умолчанию.

Есть ли хороший способ сделать это? Или, может быть, Git не хочет, чтобы я структурировал вещи таким образом, и я определенно открыт для этого. Возможно, мне следует иметь несколько репозиториев, при этом репозиторий скелетов Ruby on Rails отслеживает главный репозиторий скелетов? И любой отдельный проект, клонирующий скелетный репозиторий Ruby on Rails.

22 ответа

Примечание. git1.7.10 (апрель 2012 г.) фактически позволяет вам клонировать только одну ветку :

( <url> - это URL-адрес удаленного репозитория, который не ссылается на клонированную ветку)

Вы можете увидеть это в t5500-fetch-pack.sh :

Это неявно при выполнении неглубокого клона.
Это делает git clone --depth 1 самым простым способом экономии трафика.

А начиная с Git 1.9.0 (февраль 2014 г.) мелкие клоны поддерживают передачу данных (push / pull), так что теперь эта опция еще более полезна.
Дополнительную информацию см. На странице «Является ли git clone --depth 1 (неглубокий клон) более полезным, чем он кажется?».

«Отмена» мелкого клона подробно описана в разделе «Преобразовать мелкий клон в полный клон» (git 1.8.3+)

волшебная линия для восстановления отсутствующих ветвей --single-branch (git v2.1.4):

В Git 2.26 (первый квартал 2020 г.) " git clone --recurse-submodules --single-branch " теперь использует тот же параметр с одной ветвью при клонировании подмодулей .

clone : передайте --single-branch во время --recurse-submodules

Подписано: Эмили Шаффер
Актер: Джефф Кинг

Ранее выполнение " git clone --recurse-submodules --single-branch " приводило к клонированию всех ветвей субмодулями, хотя суперпроект клонировал только одну ветвь.

Пропустите --single-branch через вспомогательную структуру подмодуля, чтобы позже попасть в ' clone '.

Один из способов - выполнить следующее.

Где branch_name - выбранная вами ветка, а «/ your / folder» - папка назначения для этой ветки. Это правда, что это приведет к появлению других ветвей, дающих вам возможность слиться туда и обратно.

Обновить

Теперь, начиная с Git 1.7.10, вы можете сделать это

Используя Git версии 1.7.3.1 (в Windows), вот что я делаю ( $BRANCH - это имя ветки, которую я хочу проверить, а $REMOTE_REPO - это URL-адрес удаленного репозитория, из которого я хочу клонировать) :

Преимущество этого подхода заключается в том, что последующие вызовы git pull (или git fetch ) также просто загрузят запрошенную ветвь.

Вы можете попробовать длинный способ:

Создайте и запустите пустой репозиторий Git.
Добавляет исходный репозиторий как удаленный объект с именем origin .
Выбирает только нужную вам ветку с пульта дистанционного управления с именем origin .
Создает и проверяет новую ветку, настроенную для отслеживания только что клонированной исходной ветки.

Надеюсь, это будет что-то вроде того, что вам нужно.

Вы можете сделать это с помощью следующей команды:

--single-branch - ваш друг во время клонирования не забудьте использовать с --branch <branch name> , иначе будет клонироваться только удаленный основной HEAD (по умолчанию главный)

Всегда не забывайте нажимать Ctrl + F5 , чтобы читать свежий источник, а не тот, что из кеша :-) (Я не так давно не знал об этом варианте.)

Клонировать только одну ветку. Это самый простой способ:

Для клонирования конкретной ветки вы можете:

. или какая-то его версия, а также некоторые, в которых упоминается только:

. без части --single-branch .

Но я хотел бы немного рассказать об этих двух вещах и показать более знакомый набор эквивалентных команд , чтобы мы могли видеть, что происходит с каждым из них.

Часть -b version_2.5 автоматически проверила для нас ветвь version_2.5 вместо master .

git branch -a показывает нам, что ВСЕ ветви, однако, были клонированы на наш локальный компьютер. Здесь вы можете увидеть нашу локальную ветвь version_2.5 , в которой мы находимся, а также локально сохраненные ветки удаленного отслеживания origin/HEAD (которые указывают на origin/master ), плюс origin/master и origin/version_2.5 :

Мы также можем посмотреть наши ссылки на fetch . Вы можете либо открыть файл .git/config , чтобы увидеть их напрямую, либо просто запустить git config remote.origin.fetch :

Вы можете видеть выше, что наша команда git fetch (которая также запускается git pull , поскольку она эквивалентна git fetch && git merge ) настроена на получение ВСЕХ заголовков для ВСЕХ ветвей в origin дистанционный пульт. Я не эксперт в этой части, но я считаю, что +refs/heads/*:refs/remotes/origin/* означает именно это.

Часть -b version_2.5 вызвала извлечение ветки version_2.5 вместо ветки master по умолчанию (как ранее объяснялось выше), а часть --single-branch вызвала:

НИКАКОЙ из других ветвей, которые нужно клонировать на наш компьютер , и
git fetch должен быть настроен таким образом, чтобы НИКАКАЯ из других ветвей никогда не вызывалась при вызове git fetch или git pull !

Эта команда действительно клонирована и получит только ту ветку, которую мы хотели, и все!

git branch -a показывает нам, что ТОЛЬКО ветвь version_2.5 была клонирована и извлечена. Здесь мы видим по * , какая ветвь извлечена, и мы также видим, что у нас есть ветка удаленного отслеживания локально сохраненная для origin/version_2.5 :

Выше видно, что наша команда git fetch будет извлекать только заголовок ветки version_2.5 из удаленной ветки origin/version_2.5 . Вот и все! Помните, что никакие другие удаленные ветки никогда не будут загружены.

Итак, теперь вы видите, что использование -b branch_name в основном просто гарантирует, что ветвь branch_name будет извлечена после клонирования, но по-прежнему клонирует ВСЕ удаленные ветки, тогда как добавление также --single-branch гарантирует, что ТОЛЬКО branch_name клонируется, выбирается, извлекается и отслеживается. Никакие другие удаленные ветки не будут клонированы на ваш компьютер вообще.

Лично я предпочитаю только вариант -b branch_name , потому что я хочу, чтобы все ветки были клонированы на мой локальный компьютер. Единственное исключение может быть в огромном общем монорепо с десятками, а то и сотнями или тысячами удаленных веток. В этом случае просто используйте -b branch_name --single-branch , чтобы клонировать только одну важную ветку, которая вам небезразлична, и готово. Лучше загрузить 50 ГиБ данных для ветки master в огромном монорепозитории, например, чем загружать 200 ГиБ данных, чтобы у вас было 2000 веток ваших коллег, над которыми они тоже работают!

у меня есть master и development бранч, оба нажаты на GitHub. Я clone d, pull Эд, и fetch ЭД, но я по-прежнему не могу получить ничего, кроме master ветку обратно.

Я уверен, что упускаю что-то очевидное, но я прочитал руководство, и я не получаю никакой радости.

во-первых, клонировать удаленный Git хранилище и компакт-диск в:

Далее, посмотрите на локальные ветви в вашем репозитории:

но есть и другие ветви, скрывающиеся в вашем репозитории! Вы можете увидеть их, используя -a флаг:

если вы просто хотите быстро взглянуть на ветку вверх по течению, вы можете проверить это напрямую:

а если вы хотите работать над этим филиал, вам нужно будет создать локальную ветку отслеживания, которая выполняется автоматически:

эта последняя строка бросает некоторых людей:" новая ветка " - а? На самом деле это означает, что ветвь берется из индекса и создается локально для вас. The строка на самом деле более информативна, поскольку она говорит вам, что ветвь настраивается для отслеживания удаленной ветви, что обычно означает origin / branch_name бранч

теперь, если вы посмотрите на свои местные филиалы, вот что вы увидите:

вы можете отслеживать более одного удаленного репозитория с помощью git remote .

в этот момент все становится довольно сумасшедшим, так что бегите gitk чтобы увидеть, что происходит:

Если у вас есть много удаленных ветвей, которые вы хотите получить сразу, сделайте:

теперь вы можете проверить любую ветку, как вам нужно, не нажимая на удаленный репозиторий.

этой Баш скрипт выручил меня:

он создаст ветви отслеживания для всех удаленных ветвей, кроме master (который вы, вероятно, получили от оригинальной команды clone). Я думаю, вам все еще нужно сделать

чтобы быть уверенным.

один лайнер: git branch -a | grep -v HEAD | perl -ne 'chomp($_); s|^\*?\s*||; if (m|(.+)/(.+)| && not $d<>) else =1>' | csh -xfs как обычно: проверьте в настройках перед копированием rm-rf Юниверса, как мы его знаем

кредиты для one-liner перейти к пользователю cfi

С помощью --mirror опция, кажется, копирует remote отслеживание ветвей правильно. Однако он настраивает репозиторий как голый репозиторий, поэтому после этого вы должны превратить его в обычный репозиторий.

вы можете легко переключиться на ветку, не используя причудливый синтаксис" git checkout-b somebranch origin/somebranch". Вы можете просто сделать:

Git автоматически сделает правильную вещь:

Git проверит, существует ли ветвь с тем же именем ровно в одном удаленном, и если это так, она отслеживает его так же, как если бы вы явно указали, что это удаленная ветвь. Из справочной страницы git-checkout git 1.8.2.1:

Если не найдена, но существует ветвь отслеживания в ровно один удаленный (назовите его ) с соответствующим именем, обработайте как эквивалентно

$ git checkout-b экспериментальное происхождение / экспериментальное

или более подробный, но легче запомнить

может быть лучше, с точки зрения отслеживания удаленного репозитория.

выборка, которую вы делаете, должна получить все удаленные ветви, но она не будет создавать локальные ветви для них. Если вы используете gitk, вы должны увидеть удаленные ветви, описанные как "remotes/origin/dev" или что-то подобное.

чтобы создать локальную ветвь на основе удаленной ветви, сделайте что-то вроде:

который должен вернуть что-то вроде:

теперь, когда вы находитесь на ветке dev ," git pull " обновит ваш локальный dev до той же точки как удаленная ветвь dev. Обратите внимание, что он принесет все ветви, но только потяните тот, на котором вы находитесь, на вершину дерева.

когда вы делаете "git clone git: / / location", все ветви и теги извлекаются.

для работы поверх определенной удаленной ветви, предполагая, что это исходный удаленный:

использовать псевдонимы. Хотя нет никаких родных однострочных Git, вы можете определить свой собственный как

а затем используйте его как

Это не слишком сложно, очень простые и прямые шаги вперед следующие;

git fetch origin это приведет все удаленные ветви к вашему локальному.

git branch -a Это покажет вам все удаленные ветки.

git checkout --track origin/<branch you want to checkout>

Проверьте, находитесь ли вы в нужной ветке с помощью следующей команды;

результат будет такой;

обратите внимание на знак*, который обозначает текущий отделение.

почему вы видите только "мастер"

git clone загружает все удаленные удаленные ветви, но по-прежнему считает их "удаленными", даже если файлы находятся в Вашем новом репозитории. Есть одно исключение из этого, которое заключается в том, что процесс клонирования создает локальную ветвь под названием "master" из удаленной ветви под названием "master". По умолчанию git branch показывает только локальные ветви, поэтому вы видите только "master".

git branch -a показывает все филиалы, включая remote ветви.

как получить местные отделения

если вы действительно хотите работать над филиалом, вам, вероятно, понадобится его "локальная" версия. Чтобы просто создать локальные ветви из удаленных ветвей (не проверяя их и тем самым изменяя содержимое вашего рабочего каталога), вы можете сделать это так:

в этом примере branchone - это имя локальной ветви, которую вы создаете на основе origin/branchone ; если вы вместо того, чтобы создавать локальные ветви с разными именами, вы можете сделать следующее:

как только вы создали локальную ветку, вы можете увидеть ее с помощью git branch (помните, вам не нужно -a чтобы увидеть местные филиалы).

лучше поздно, чем никогда, но вот лучший способ сделать это:

на данный момент у вас есть полная копия удаленного РЕПО со всеми его ветвями (проверьте с помощью git branch ). Вы можете использовать --mirror вместо --bare если удаленный РЕПО собственных пультов.

просто сделать это:

вам нужно только использовать "git clone", чтобы получить все ветви.

хотя вы видите только главную ветвь, вы можете использовать "git branch-a", чтобы увидеть все ветви.

и вы можете переключиться на любую ветку, которая у вас уже есть.

не волнуйтесь, что после того, как вы" git clone", вам не нужно подключаться к удаленному РЕПО," git branch-a "и" git checkout " могут быть успешно запущены при закрытии wifi. Таким образом, доказано, что, когда вы делаете "git clone", он уже скопировал все ветви из удаленного РЕПО. После этого вам не нужно удаленное РЕПО, у вашего локального уже есть коды всех филиалов.

A git clone предполагается скопировать весь репозиторий. Попробуйте клонировать его, а затем запустите git branch -a . В нем должны быть перечислены все филиалы. Если вы хотите переключиться на ветку " foo "вместо " master", используйте git checkout foo .

использовать мой инструмент git_remote_branch (вам нужно установить Ruby на ваш компьютер). Он построен специально для того, чтобы сделать дистанционные манипуляции с ветвями очень легкими.

каждый раз, когда он выполняет операцию от вашего имени, он печатает ее красным цветом на консоли. Со временем они, наконец, вонзаются в ваш мозг: -)

Если вы не хотите, чтобы grb выполнял команды от вашего имени, просто используйте функцию "объяснить". Команды будут напечатаны на вашей консоли, а не выполнены для вы.

наконец, все команды имеют псевдонимы, чтобы облегчить запоминание.

вот справка при запуске справки grb:

все ответы, которые я видел здесь, действительны, но есть гораздо более чистый способ клонировать репозиторий и вытащить все ветви сразу.

когда вы клонируете репозиторий, вся информация о ветвях фактически загружается, но ветви скрыты. С командой

вы можете показать все ветки репозитория, и с помощью команды

затем вы можете "загрузить" их вручную по одному за раз.

однако, когда вы хотите клонировать РЕПО с большим количеством ветвей, все способы, иллюстрированные выше, длинны и утомительны в отношении гораздо более чистого и быстрого способа, который я собираюсь показать, хотя это немного сложно. Для этого нужно сделать три шага:--6-->

создайте новую пустую папку на вашем компьютере и клон зеркальная копия .папка git из репозитория:

в локальный репозиторий внутри папки my_repo_folder по-прежнему пуст, есть только скрытый .папка git теперь, когда вы можете видеть с помощью команды "ls-alt" из терминала.

переключите этот репозиторий из пустого (голого) репозитория в обычный репозиторий, переключив логическое значение "голый" конфигураций git на false:

возьмите все, что внутри текущая папка и создайте все ветви на локальном компьютере, поэтому сделайте это обычным РЕПО.

теперь вы можете просто ввести команду "git branch", и вы увидите, что все ветви загружены.

это быстрый способ, которым вы можете клонировать репозиторий git со всеми ветвями сразу, но это не то, что вы хотите сделать для каждого отдельного проекта таким образом.

но будьте осторожны, если одна из удаленных ветвей называется, например, admin_master, она не будет загружена!

спасибо bigfish за оригинальную идею

ОК когда вы клонируете свое РЕПО,у вас есть все ветви.

если вы просто сделать git branch , Они вроде как скрыты.

поэтому, если вы хотите увидеть все названия ветвей, просто добавьте --all флаг такой:

git branch --all или git branch -a

если вы просто оформить заказ в филиал, вы получите все, что вам нужно.

но как насчет того, если ветка, созданная кем-то еще после клонирования?

в этом случае, просто do:

и проверьте все ветви снова.

если вы хотите получить и оформить заказ в то же время, вы можете сделать:

git fetch && git checkout your_branch_name

также создал изображение ниже для вас, чтобы упростить то, что я сказал:

для копирования-вставки в командную строку:

для большей удобочитаемости:

проверьте master (так что мы можем удалить ветку, на которой мы находимся)
выберите remote для проверки (измените его на любой пульт, который у вас есть)
петля через все ветви пульта дистанционного управления, кроме master и HEAD
1. удалить местное отделение (так что мы можете проверить force-обновленные ветки)
2. проверить ответвление от пульта
этот код вытянет весь код удаленных филиалов в локальное РЕПО.

клонирование из локального РЕПО не будет работать с git clone & git fetch: многие ветви / теги останутся незамеченными.

чтобы получить клон со всеми ветвями и тегами.

чтобы получить клон со всеми ветвями и тегами, но также и с рабочей копией:

Результат: каталог с выписанной веткой master . Теперь можно создавать новые ветки, или выписывать с github существующие.

Как выписать ветку с github

Или так, что намного надежнее:

Если команда не сработала, нужно попробовать выполнить обновление:

Если вышеприведенные команды не сработали, выдали ошибку, и времени разбираться с ней нет, можно попробовать получить нужную ветку следующим способом:

Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.

Как создать новую ветку в локальном репозитории

2. Публикуем ее на github:

Как переключиться на другую ветку в git

Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:

Как посмотреть список веток

Как сделать commit

Создаем новую ветку, выполняем в ней нужные изменения.
1. Список всех измененных и добавленных файлов можно просмотреть командой:
2. Подготавливаем коммит, добавляя в него файлы командой:

Или удаляем устаревшие файлы:

3. Выполняем коммит:

После коммита надо влить в нашу ветку изменения из ветки dev и master:

Теперь наша ветка содержит изменения для проекта, и все последние изменения по другим задачам, которые успела внести команда.

5. Переключаемся на ветку dev:

6. Вливаем в dev изменения из ветки проекта:

7. Заливаем последнюю версию ветки dev на удаленный сервер:

push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.

Как решить конфликт бинарных файлов

Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:

Если мы выбираем версию из вливаемой ветки:

Как посмотреть историю изменений

Вывод данных о каждом коммите в одну строку:

Для вывода информации git log использует просмотрщик, указанный в конфиге репозитория.

Поиск по ключевому слову в комментариях к коммиту:

Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:

git annotate, выводит измененные строки и информацию о коммитах, где это произошло:

Как сделать откат
1. Копируем идентификатор коммита, до которого происходит откат.
2. Откатываемся до последнего успешного коммита (указываем последний коммит):
Можно откатить до последней версии ветки:

После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:

Как выполнить слияние с другой веткой

git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.

git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.

Создание нового локального репозитория

git cherry-pick

git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.
1. Для этого нужно выписать ветку, в которую будем вливать коммит:
3. Выполнить команду, указать код коммита:

4. После этого обновить ветку на сервере:

Как раскрасить команды git

После создания репозитория в текущей директории появится субдиректория .git . Она содержит файл config .

Чтобы раскрасить вывод git, можно добавить в файл блок [color] :

Add colors to your

Highlight whitespace in diffs

Add aliases to your

/.gitconfig] file in your $EDITOR

git config apply.whitespace nowarn
To ignore whitespace

git status
show files added to the staging area, files with changes, and untracked files

git show <rev>
show the changeset (diff) of a commit specified by <rev>, which can be any
SHA1 commit ID, branch name, or tag (shows the last commit (HEAD) by default)

also to show the contents of a file at a specific revision, use
git show <rev>:<filename>
this is similar to cat-file but much simpler syntax.

git blame <file>
show who authored each line in <file>

git blame <file> <rev>
show who authored each line in <file> as of <rev> (allows blame to go back in
time)

git gui blame
really nice GUI interface to git blame

git whatchanged <file>
show only the commits which affected <file> listing the most recent first
E.g. view all changes made to a file on a branch:
git whatchanged <branch> <file> | grep commit | \
colrm 1 7 | xargs -I % git show % <file>
this could be combined with git remote show <remote> to find all changes on
all branches to a particular file.

git diff <commit> head path/to/fubar
show the diff between a file on the current branch and potentially another branch

git ls-files
list all files in the index and under version control.

git ls-remote <remote> [HEAD] show the current version on the remote repo. This can be used to check whether
a local is required by comparing the local head revision.

git add <dir>
add all files under directory <dir> to the project, including subdirectories

git add .
add all files under the current directory to the project
*WARNING*: including untracked files.

Edit $GIT_DIR/.git/info/exclude. See Environment Variables below for explanation on $GIT_DIR.

Add a file .gitignore to the root of your project. This file will be checked in.

Either way you need to add patterns to exclude to these files.

git commit -a
commit all files changed since your last commit
(does not include new (untracked) files)

git commit -v
commit verbosely, i.e. includes the diff of the contents being committed in
the commit message screen

git branch
list all local branches

git branch -r
list all remote branches

git branch -a
list all local and remote branches

git branch <branch>
create a new branch named <branch>, referencing the same point in history as
the current branch

git branch <branch> <start-point>
create a new branch named <branch>, referencing <start-point>, which may be
specified any way you like, including using a branch name or a tag name

git branch -d <branch>
delete the branch <branch>; if the branch you are deleting points to a
commit which is not reachable from the current branch, this command
will fail with a warning.

git branch -r -d <remote-branch>
delete a remote-tracking branch.
Example: git branch -r -d wycats/master

git branch -D <branch>
even if the branch points to a commit not reachable from the current branch,
you may know that that commit is still reachable from some other branch or
tag. In that case it is safe to use this command to force git to delete the
branch.

git checkout <branch>
make the current branch <branch>, updating the working directory to reflect
the version referenced by <branch>

git checkout -b <new> <start-point>
create a new branch <new> referencing <start-point>, and check it out.

git push <repository> :<branch>
removes a branch from a remote repository.
Example: git push origin :old_branch_to_be_deleted

git show <rev>:<repo path to file>
Show the contents of a file at the specific revision. Note: path has to be
absolute within the repo.

git merge <branch>
merge branch <branch> into the current branch; this command is idempotent
and can be run as many times as needed to keep the current branch
up-to-date with changes in <branch>

git merge <branch> -s ours
merge branch <branch> into the current branch, but drops any changes in
<branch>, using the current tree as the new tree

git hash-object <file-path>
get the blob of some file whether it is in a repository or not

Find the commit in the repository that contains the file blob:

git mergetool
work through conflicted files by opening them in your mergetool (opendiff,
kdiff3, etc.) and choosing left/right chunks. The merged result is staged for
commit.

Once all conflicts are resolved and staged, commit the pending merge with:

git push
update the server with your commits across all branches that are *COMMON*
between your local copy and the server. Local branches that were never
pushed to the server in the first place are not shared.

git push origin <branch>:refs/heads/<branch>
E.g. git push origin twitter-experiment:refs/heads/twitter-experiment
Which, in fact, is the same as git push origin <branch> but a little
more obvious what is happening.

git checkout <file>
re-checkout <file>, overwriting any local changes

test <sha1-A> = $(git merge-base <sha1-A> <sha1-B>)
determine if merging sha1-B into sha1-A is achievable as a fast forward;
non-zero exit status is false.

git stash apply
restore the changes recorded in the stash on top of the current working tree
state

git stash pop
restore the changes from the most recent stash, and remove it from the stack
of stashed changes

git stash list
list all current stashes

git stash drop [<stash-name>] delete the stash

git stash clear
delete all current stashes

git push <remote> :refs/heads/<branch>
delete a branch in a remote repository

git push <remote> <remote>:refs/heads/<remote_branch>
create a branch on a remote repository
Example: git push origin origin:refs/heads/new_feature_name

git push <repository> +<remote>:<new_remote>
replace a <remote> branch with <new_remote>
think twice before do this
Example: git push origin +master:my_branch

git remote show <remote>
show information about the remote server.

git checkout -b <local branch> <remote>/<remote branch>
Eg.:
git checkout -b myfeature origin/myfeature
git checkout -b myfeature remotes/<remote>/<branch>

git pull <remote> <branch>
git push
For branches that are remotely tracked (via git push) but
that complain about non-fast forward commits when doing a
git push. The pull synchronizes local and remote, and if
all goes well, the result is pushable.

git submodule add <remote_repository> <path/to/submodule>
add the given repository at the given path. The addition will be part of the
next commit.

git submodule foreach <command>
Executes the given command within each checked out submodule.

git format-patch <Revision>^..<Revision>
Generate a patch for a single commit. E.g.
git format-patch d8efce43099^..d8efce43099
Revision does not need to be fully specified.

git am <patch file>
Applies the patch file generated by format-patch.

git tag -l
Will list all tags defined in the repository.

git archive master | tar -x -C /somewhere/else
Will export expanded tree as tar archive at given path

git archive master | bzip2 > source-tree.tar.bz2
Will export archive as bz2

GIT_AUTHOR_NAME, GIT_COMMITTER_NAME
Your full name to be recorded in any newly created commits. Overrides
user.name in .git/config

GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL
Your email address to be recorded in any newly created commits. Overrides
user.email in .git/config

GIT_DIR
Location of the repository to use (for out of working directory repositories)

Создание ветки

Чтобы создать новую ветку testing локально, выполним команду:

На момент выполнения команды вы находились в какой-то ветке, допустим в master. Состояние этой ветки будет скопировано в ветку testing, и в testing можно будет редактировать файлы и делать снимки, не трогая пока основную ветку master.

Переключение на ветку

Предыдущая команда создаст ветку, но не переключит нас на нее, мы все еще останемся работать в старой ветке. Чтобы перейти на ветку testing и начать работать в ней, выполним команду:

Создание и переключение единой командой

Чтобы не выполнять предыдущие команды по очереди, можно написать их одной строкой:

Эта команда создаст ветку testing и сразу переключит нас на нее. Обычно именно это и требуется сделать.

Как переключиться на чью-то ветку из удаленного репозитория

Теперь можно посмотреть, какие ветки есть в удаленном репозитории:

Допустим, там есть ветка dev1. Переключимся на нее, создав локальную ветку с таким же именем:

Вообще-то можно было написать проще:
1. Эта команда сработает только в том случае, если удаленный репозиторий у вас единственный. Если их два, например origin и upstream, то непонятно, на чью ветку переключаться.
2. Она создаст локальную ветку с точно таким же именем dev1. А в полной версии можно было создать локальную ветку и с другим именем mydev1:
Как создать подветку ветки

Предыдущая команда, с помощью которой мы создавали ветку:

создает ответвление от основной ветки master.

Если нам надо ответвиться не от основной ветки, а от вновь созданной testing, то выполним поочередно команды:

Первая команда переключит нас на ветку testing.
Вторая команда создаст ветку с именем subbranch_of_testing, ответвляющуюся от testing, и переключит нас на нее.
Как понятно из имени, subbranch_of_testing – это подветка ветки testing.

Как посмотреть ветки

Чтобы увидеть все созданные локально ветки, выполним команду:

Появится список веток. Текущая ветка будет выделена звездочкой.

Как переименовать ветку

Иногда оказывается, что первоначально созданное имя ветки не самое лучшее. Его можно изменить.

Локальную

Если еще не выполнена команда push, то достаточно переименовать локальную ветку.

Чтобы переименовать локальную ветку, выполним команду:

Например, переименуем ветку testing в ветку test:

Чтобы переименовать текущую ветку, выполним команду:

Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:

Удаленную

Например, надо переименовать ветку testing в test:

Удаление локальной ветки

Чтобы удалить локальную ветку, выполните одну из команд:

Вообще-то локальную ветку обычно удаляют после того, как слили ее (выполнили merge) в ветку master, смотрите последний раздел в статье о слиянии веток.

Удаление ветки из удаленного репозитория

Чтобы удалить удаленную ветку, можно использовать две записи.
Либо через двоеточие, как мы уже делали при переименовании ветки:

Например, удалим ветку test из удаленного репозитория origin:

Как слить ветки

Обычно сливают некоторую ветку (например, ветку-багфикс) в ветку master. Для этого сначала перейдем в ветку master (в ту ветку, в которую вливаем изменения):

А затем выполним слияние. Допустим, в ветку master надо слить ветку test :

Слияние веток не всегда происходит гладко, иногда требуется разрешить конфликты вручную. Для этого надо отредактировать конфликтые файлы, выполнить их commit.

В этой статье мы рассмотрели работу с ветками GIT и составили небольшую шпаргалку по использованию веток.

Читайте также:

Как скопировать ветку git на локальный компьютер

22 ответа

clone : передайте --single-branch во время --recurse-submodules

почему вы видите только "мастер"

как получить местные отделения

Как выписать ветку с github

Как создать новую ветку в локальном репозитории

Как переключиться на другую ветку в git

Как посмотреть список веток

Как сделать commit

Как решить конфликт бинарных файлов

Как посмотреть историю изменений

Как сделать откат

Как выполнить слияние с другой веткой

Создание нового локального репозитория

git cherry-pick

Как раскрасить команды git

Создание ветки

Переключение на ветку

Создание и переключение единой командой

Как переключиться на чью-то ветку из удаленного репозитория

Как создать подветку ветки

Как посмотреть ветки

Как переименовать ветку

Локальную

Удаленную

Удаление локальной ветки

Удаление ветки из удаленного репозитория

Как слить ветки