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

Удалённые ветки

Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды 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 сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.

Работа с удалёнными репозиториями

Для того, чтобы внести вклад в какой-либо 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 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 сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.

Pro Git

Страницы

среда, 18 февраля 2015 г.

Они выглядят как (имя удал. репоз.)/(ветка). Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, проверьте ветку origin/master. Если вы с партнёром работали над одной проблемой, и он выложил ветку iss53, у вас может быть своя локальная ветка iss53; но та ветка на сервере будет указывать на коммит в origin/iss53.

Всё это, возможно, сбивает с толку, поэтому давайте рассмотрим пример. Я создал удаленный репозиторий на GitHub https://github.com/n0tb0dy/RemoreBranches

Там я сделал три коммита

Чтобы склонировать его воспользуемся ссылкой для клонирования

При клонировании удаленного репозитория Git автоматически назовёт его origin, заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master, и назовёт его локально origin/master (но вы не можете его двигать). Git также сделает вам вашу собственную ветку master, которая будет начинаться там же, где и ветка master в origin, так что вам будет с чем работать.

“origin” это не специальное название

Это подобно названию ветки master, которое дается по умолчанию при создании локального репозитория. Точно так же как ветка master создается по умолчанию при команде git init, точно также по умолчанию используется название origin при команде git clone. Если вы дадите команду git clone –o booyah, то вы получите booyah/master как вашу удаленную ветку по умолчанию.

И так возвращаемся к нашим… коммитам. На удаленном репозитории они выглядят так

После команды git clpne https://github.com/n0tb0dy/RemoreBranches.git локальный репозиторий будет выглядеть так

Клонирование Git-проекта даёт вам собственную ветку master и origin/master, указывающий на ветку master в origin.

Еще раз напомню что HEAD указывает на ветку где вы сейчас находитесь.

Продемонстрируем это, сделав непосредственно на сервере GitHub в нашем проекте пару коммитов. И так же сделаем пару коммитов локально.

А на локальном компьютере это будет выглядеть так:

При выполнении локальной работы и отправке кем-то изменений на удалённый сервер каждая история продолжается по-разному.

Как видим притянулись два наших изменения сделанных на GitHub в ветку origin/master и туда же сдвинулся указатель HEAD это ветки. А вот наша локальная ветка осталась без изменений и HEAD ветки master указывает на тот же коммит, что и до команды git fetch.

Визуально дерево коммитов после команды git fetch на локальном компьютере будет выглядеть так:

Мы можем переключится на ветку origin/master

Но Git ругнется на это сказав что мы сейчас задеатачены и т.д. и т.п. даст кучу советов, но переключится. Соответственно в рабочем каталоге поменяется файл test.txt, в котором мы увидим изменения сделанные в двух последних коммитах, которые мы сделали непосредственно на сервере GitHub.

Если мы посмотрим сейчас статус, то увидим это:

Нам опять скажут что мы задеатачены.

Переключимся обратно на ветку master

Git нам любезно сообщает что наша ветка (master) и ветка origin/master разошлись и каждая имеет по два разных коммита, соответственно. И предлагает дать команду git pull чтобы слить изменения удаленной ветки с локальной.

Но мы можем поступить и по другому, просто дать команду git merge origin/master находясь в ветке master, чтобы слить изменения в одну ветку. Естественно у нас будет конфликт слияния.

Чтобы долго не мучится просто оставим без изменений слитый файл, который создал Git. Просто закоммитим их.

В результате получаем такую картину

А теперь все это добро запушим на сервер. Для этого используется команда git push (удал. сервер) (ветка). В нашем случае команда будет выглядеть просто git push origin master.

После того как мы запушили изменения на сервер дерево коммитов будет выглядеть так:

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

На GitHub эти изменения выглядят так:

Еще раз напомню про разницу между командами fetch и pull. Fetch не трогает ваши локальные изменения, а просто притягивает удаленные в другую ветку и позволяет их вам посмотреть и если надо слить со своей веткой. Pull же старается сразу объединить изменения сделанные на удаленном сервере со связанной локальной веткой.

Еще про отправку изменений

Если у вас есть ветка serverfix, над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните git push (удал. сервер) (ветка). Давайте для примера создадим ее, сделаем изменения в файлике test.txt и отправим это все на сревер GitHub.

Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится “возьми мой serverfix и сделай его удалённым serverfix”. Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы ветка называлась serverpigs на удалённом сервере, то вместо предыдущей команды выполните git push origin serverfix:serverpigs. Так ваша локальная ветка serverfix отправится в ветку serverpigs удалённого проекта.

На сервере GitHub появится наш последний коммит в своей ветке

В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix:

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

Для примера создадим новую ветку CreatedOnGitHub в нашем проекте на сервере GitHub и сделаем изменения в нашем многострадальном файле test.txt и закоммитим их. А затем притянем себе в локальный Git.

Вот наша, созданная удаленно веточка и коммит в ней притянулись. Как видим в имени ветки стоит origin/CreatedOnGitHub. То есть как и говорилось выше мы не получили локальную ветку CreatedOnGitHub после выполнения команды git fetch origin.

Теперь мы можем переключится в ветку origin/CreatedOnGitHub и получить измененный файл test.txt (с изменениями которые мы сделали на сервере) в рабочем каталоге и получить редактируемую копию ветки origin/CreatedOnGitHub в локальной ветке CreatedOnGitHub простой командой git checkout CreatedOnGitHub:

Мы можем посмотреть ветки которые у нас есть

Теперь сделаем изменения в нашем файлике test.txt в ветке CreatedOnGitHub и отправим эти изменения обратно на сервер GitHub

Теперь посмотрим это на GitHub

Видим что наш Local Commit 04 бла бла бла… успешно запушен на сервер GitHub.

Отслеживание веток

При клонировании репозитория, как правило, автоматически создаётся ветка master, которая отслеживает origin/master, поэтому git push и git pull работают для этой ветки «из коробки» и не требуют дополнительных аргументов. Однако, вы можете настроить отслеживание и других веток удалённого репозитория.

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

$ git branch –vv

Из этого скрина мы видим что у нас отслеживаются ветки master и CreatedOnGitHub, а ветка serverfix не отслеживается.

Это можно поправить следующей командой

Поскольку локальная ветка serverfix у нас уже существует то надо использовать ключ –u, чтобы включить ее отслеживание, но для этого сперва надо перейти в эту ветку, чтобы дать эту команду. Смотрим скрин

Теперь все три наших ветки отслеживаются.

Примечание: при команде git push нам приходилось каждый раз вводить логин и пароль для публикации изменений на сервере GitHub. Этого можно избежать настроив кэш учетных записей.

Pulling

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

Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя команду:

Хлоп! И ветка на удаленном сервере исчезла. Но в принципе эта команда просто удаляет указатель ветки на удаленном сервере. Git сервер продолжит хранить всю информацию о коммитах до тех пор пока вы не запустите команду уборки мусора.

Работа с git

Содержание

Что такое git? Основные понятия

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux.

Системы управления версиями (Version Control Systems) – это программное обеспечение, призванное автоматизировать работу с историей файла (или группы файлов), обеспечить мониторинг изменений, синхронизацию данных и организовать защищенное хранилище проекта. Короче говоря, основная задача систем управления версиями – упростить работу с изменяющейся информацией.

Распределённые системы управления версиями – это СУВ, главной парадигмой которых является локализация данных каждого разработчика проекта. Иными словами, если в централизованных СУВ все действия, так или иначе, зависят от центрального объекта (сервер), то в распределенных СУВ каждый разработчик хранит собственную ветвь версий всего проекта. Удобство такой системы в том, что каждый разработчик имеет возможность вести работу независимо, время от времени обмениваясь промежуточными вариантами файлов с другими участниками проекта.

Рассмотрим пример: У каждого разработчика на машине есть свой локальный репозиторий – место хранения версий файлов. Работа с данными проекта реализуется над вашим локальным репозиторием, и для этого необязательно поддерживать связь с остальными (пусть даже и главными) ветвями разработки. Связь с другими репозиториями понадобится лишь при изменении/чтении версий файлов других ветвей. При этом каждый участник проекта задает права собственного хранилища на чтение и запись. Таким образом, все ветви в распределенных СУВ равны между собой, и главную из них выделяет координатор. Отличие главной ветви лишь в том, что на неё мысленно будут равняться разработчики.

Запись изменений в репозиторий (commit)

Допустим, у вас имеется репозиторий Git и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать состояния этих изменений (commit) в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить. Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (не отслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта; они могут быть не измененными, измененными или подготовленными к коммиту (staged). Все изменения в них, будут отслеживаться. Не отслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемые и не измененные, потому что вы только взяли их из хранилища и ничего пока не редактировали. Как только вы отредактируете файлы, Git будет рассматривать их как измененные, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете (делаете коммит) все индексированные изменения.

Что такое ветка?

Ветка (или «branch») — это своеобразное «место» разработки. Например, после клонирования репозитория мы по-умолчанию находимся в ветке master, создаём ветку test (в которую будет всё слито из master), затем делаем в ней какие-то изменения, делаем коммит, а потом переключиться обратно в ветку master. С помощью команды

Работа с git-репозиториями, сведения для начинающих

Настройка git

Первым делом настроим ваше имя и адрес почты. Имя вводите на английском.

После этого нужно настроить доступ

Работа с локальным репозиторием

Клонирование репозитория

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

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

Определение состояния файлов

Основная команда, используемая для определения какие файлы в каком состоянии находятся — это команда git status. Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:

Это означает, что у вас чистый рабочий каталог, другими словами — в нем нет ни отслеживаемых, ни измененных файлов. Git также не обнаружил не отслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь.

Предположим, вы добавили новый файл в ваш проект, простой README файл. Если этого файла раньше не было, и вы выполните git status, вы увидите не отслеживаемый файл как-то так:

Вы можете видеть, что новый файл README не отслеживаемый, т.к. он находится в секции “Untracked files”. Не отслеживаемый файл обычно означает, что Git нашел файл, отсутствующий в предыдущем коммите. Git не станет добавлять его в ваши коммиты, пока вы явно ему это не укажете. Это предохраняет вас от случайного добавления в репозиторий сгенерированных каких-либо других файлов, которые вы и не думали добавлять.

Добавление файлов в индекс

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

Если вы снова выполните команду git status, то увидите, что файл README теперь отслеживаемый и индексированный:

Вы можете видеть, что файл проиндексирован по тому, что он находится в секции “Changes to be committed”. Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add, будет добавлена в историю коммитов (git log).

Отредактируйте какой-нибудь .cpp файл, добавьте в него, например, комментарий и сохраните. Выполнив команду git status вы увидите, что ваш отредактированный файл находится в секции “Changed but not updated” — это означает, что отслеживаемый файл был изменен в рабочем каталоге, но пока не проиндексирован. Чтобы проиндексировать его, необходимо выполнить команду

вносит в индексе все изменения, включая все обновлённые и новые файлы

Удаление файлов из индекса. Добавление удалённых файлов в индекс

После неё текущее состояние вашего файл останется низменным, но он не будет занесён в индекс.

Отмена текущих изменений в файле

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

Будьте осторожны, т.к. все сделанные вами изменения в этом файле пропадут.

Просмотр (не)индексированных изменений

Если вам хочется знать, что конкретно поменялось, а не только какие файлы были изменены — вы можете использовать команду git diff. Допустим, вы снова изменили «.cpp» файл без индексирования (без git add). Чтобы увидеть, что же вы изменили, но пока не проиндексировали, выполните:

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

Работа с ветками

Просмотр списка веток

Чтобы просмотреть список веток, выполните:

после чего, вы увидите имеющиеся ветки

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

Когда вы создаёте ветку, то она создаёт независимый клон вашей текущей ветки (не индексируемые изменения не клонируются)

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

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

Перемещение по веткам

Чтобы перейти в ветку master, выполните:

Сохранение не индексированных изменений в текущей ветке и переход в другую

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

После этого в git diff пропадут ваши изменения и вы можете перейти в другую ветку

Для просмотра сохранённых изменений:

Чтобы применить сохраненные изменения и вернуть рабочее состояние, выполните:

Чтобы удалить конкретный сохранённый стэш, выполните:

Чтобы удалить все сохранённые стэши, выполните:

Удаление ветки

Если у вас нет не индексированных изменений (изменили что-то, но ещё не добавляли в индекс с помощью git add),то удалить ветку можно так:

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

Переименование ветки

Переименовать ветку можно так:

Слияние веток и конфликты

Команда попробует объединить текущую ветку и ветку test:

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

Git не создал новый коммит для слияния. Он приостановил этот процесс до тех пор, пока вы не разрешите конфликт. Если вы хотите посмотреть, какие файлы не прошли слияние (на любом этапе после возникновения конфликта), можете выполнить команду git status:

Всё, что имеет отношение к конфликту слияния и что не было разрешено, отмечено как unmerged. Git добавляет стандартные маркеры к файлам, которые имеют конфликт, так что вы можете открыть их вручную и разрешить эти конфликты. Ваш файл содержит секцию, которая выглядит примерно так:

В верхней части блока (всё что выше =======) это версия из HEAD (вашей ветки master, так как именно на неё вы перешли перед выполнением команды merge), всё что находится в нижней части ― версия в ветке test. Чтобы разрешить конфликт вы должны либо выбрать одну из этих частей, либо как-то объединить содержимое по своему усмотрению. Отредактируйте и удалите ====== и >>>>>>>. Затем выполните git add. Индексирование будет означать для Git, что все конфликты в файле теперь разрешены.

Работа с коммитами

Добавление нового коммита, просмотр истории

После этого откроется текстовой редактор и будет отображено что-то вроде этого:

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

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

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

Можно без параметра «-m», чтобы посмотреть файлы, которые ввойдут в коммит.

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

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

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

Как видите, в данном случае число в HEAD

, обозначает номер коммита, не учитывая самый последний (верхний).

Создание отменяющего коммита

Если вы сделали коммит с ошибкой, то можно его отредактировать (как это сделать, мы разберём дальше), но делать это нужно лишь в том случае, если вы не опубликовали его в какой-нибудь удалённый репозиторий, с которым работают другие люди. В ином случае лучше создать коммит, который отменит предыдущий и вернёт вас в старое состояние. Как это сделать:

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

Сброс состояния проекта, отмена, удаление последних коммитов

Помимо работы с индексом, git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В таком случае вместе с командой используются различные ключи (soft, hard и т.п.).

Команда отменит последний коммит и вернёт вас к тому состоянию, когда вы добавили все нужные изменения в индекс (git add), но ещё не совершили коммит. Команда не сбрасывает текущие индекс и не индексированные изменения. Если до выполнения reset вы добавляли в индекс какие-то файлы, то они войдут в секцию «Changes to be committed»!

Если состояние сбрасывается на несколько коммитов, то плюс ко всему будут добавлены в индекс и их изменения (секция «Changes to be committed»).

удалит два последних коммита и вернёт вас к такому состоянию проекта, если бы вы только что совершили третий сверху коммит.

Команда работает в том случае, если у вас нет не индексированных изменений тех файлов, которые изменяются в двух последних коммитах.

Отменяются два последних коммита. Сбрасывается индекс и обновляются файлы в директории до состояния третьего коммита сверху. При этом сохраняются изменения в файлах, которые не добавлялись в индекс (не git add).

Редактирование последнего коммита

Если сразу после совершения коммита, вы ничего не добавляли в индекс (git add), то следуйте инструкции. В ином случае, вам придётся удалить из него ненужные файлы:

Редактирование нескольких или какого-то одного коммита из истории

Допустим, вам надо отредактировать 3 последних коммита, выполните:

Команда выполнится в интерактивном режиме. Можно заметить, что в данном случае, число в команде HEAD

включает в себя самый верхний коммит. Откроется редактор, который отобразит нечто подобное:

Обратите внимание, что первым идёт коммит, который является самым старым из выбранных вами коммитов!

Для того, чтобы отредактировать нужный коммит, замените перед номером коммита слово pick на edit. Когда вы сохраните изменения и выйдите из редактора, Git вернёт вас к первому из тех коммитов, которые вы хотите отредактировать. В итоге вы увидите такое:

После чего, Git автоматически применит следующие коммиты. Если у вас несколько редактируемых коммитов, то вам снова придётся выполнить то, о чем я писал выше. В итоге Git покажет всё ли удачно применилось.

Редактирование комментария к коммиту

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

Затем меняем у нужного коммита pick на reword. Исправляем комментарий, сохраняемся, выходим. Git автоматически должен всё поменять.

Изменение порядка коммитов. Удаление коммитов

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

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

Слияние коммитов в один

Затем меняем pick на squash у нужных коммитов, сохраняем, выходим и видим что-то наподобие:

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

а в остальных коммит мессаджах убрать.

Разбиение коммита на несколько

Предположим, что вы хотите разбить какой-то коммит в последних шести на несколько. Как всегда, выполняем:

Меняем у нужного коммита pick на edit. После этого делаем:

Эта команда отменяет коммит, который вы собираетесь разбивать и убирает из индекса все изменённые файлы. Вам остаётся только добавить файлы с нужными изменениями (git add), затем сделать коммит. Потом снова добавить нужные файлы, и снова сделать коммит. И так до тех пор, пока вы не разобьёте свой коммит на необходимое колличество коммитов. После этого нужно выполнить:

Всё это будет выглядеть примерно так:

Перенос коммитов из другой ветки

Предположим, разработчик завел дополнительную ветку для разработки отдельной возможности и совершил в ней несколько коммитов. Одновременно по какой-либо причине в основной ветке также были совершены коммиты: например, в нее были залиты изменения с удаленного сервера; либо сам разработчик совершал в ней коммиты. В принципе, можно обойтись обычным git merge. Но тогда усложняется сама линия разработки, что бывает нежелательно в слишком больших проектах, где участвует множество разработчиков. Предположим, имеется две ветки: master и test, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки test и накладывает их на последний коммит ветки master: вариант, в котором явно указывается, что и куда прикладывается

А здесь на master накладывается ветка, активная в настоящий момент :

После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой

Альтернативными выходами будут команды

пропустить наложение коммита и перейти к следующему или

отмена работы команды и всех внесенных изменений.

Работа с удалённым репозиторием

Удалённый репозиторий — это модификация проекта, которая хранится в интернете или ещё где-то в сети. УР обычно доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя помещение (push) и получение (pull) данных и из них тогда, когда нужно обменяться результатами работы.

Отображение удалённых репозиториев

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

Она перечисляет весь список имён-сокращений (псевдонимов) удалённых репозиториев, созданных в текущем репозитории. Если вы склонировали ваш репозиторий, у вас должен отобразиться по крайней мере origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали.

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

Создание и добавление удалённого репозитория

Создадим пустой удалённый репозиторий:

Имя лучше указывать такое же как у репозитория, который вы cклонировали.

Чтобы добавить УР под именем-сокращением, выполните:

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

Забрать изменения из удалённого репозитория

Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта. Теперь эти ветки в любой момент могут быть просмотрены или слиты. Ветка master теперь доступна локально как ПСЕВДОНИМ/master. Вы можете слить (merge) её в одну из ваших веток, или можете перейти на эту ветку и просмотреть её.

Когда вы клонируете репозиторий, команда git clone автоматически добавляет этот удалённый репозиторий под именем origin. Таким образом git fetch origin извлекает все наработки, отправленные (push) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch). Важно отметить, что команда fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками, и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Она автоматически извлекает и затем сливает данные из удалённой ветки в вашу текущую ветку. Этот способ может для вас оказаться более простым или более удобным. К тому же по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master). Выполнение git pull как правило извлекает (fetch) данные с сервера, с которого вы изначально склонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

Запушить изменения в удалённый репозиторий

Когда ваш проект достигает момента, когда вы хотите поделиться наработками, вам необходимо отправить (push) их в удалённый репозиторий. Команда для этого действия простая:

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

Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push. Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push, а затем команду push выполняете вы, то запушить не получится. Вам придётся сначала забрать изменения (pull) и объединить с вашими. Только после этого вам будет позволено выполнить push.

Получение информации об удалённом репозитории

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду

Если вы выполните эту команду с именем origin, вы получите что-то подобное:

Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что, если вы находясь на ветке master, выполните git pull, ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок. В некоторых случаях команда может показать какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push. Она также показывает каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере. И для нескольких веток показано какие удалённые ветки будут в них влиты при выполнении git pull.

Переименовывание удалённого репозитория

Например, если вы хотите переименовать псевдоним удалённого репозитория test в etersoft, вы можете сделать это следующим образом:

Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как test/master, стало etersoft/master.

Если вы хотите переименовать сам удалённый репозиторий, который вы создали, а он обычно размещается по адресу: http://git.etersoft.ru/people/ВАШ_НИК/packages/ИМЯ_РЕПОЗИТОРИЯ.git

то выполните команду:

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

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

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

Работа с удалёнными ветками

Удалённые ветки ― это ссылки на состояние веток в ваших удалённых репозиториях. Это локальные ветки, которые нельзя перемещать; они двигаются автоматически всякий раз, когда вы осуществляете связь по сети. Удалённые ветки действуют как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним. Они выглядят как (имя удал. репоз.)/(ветка). Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, проверьте ветку origin/master.

Просмотр удалённых веток

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

Удаление ветки в удалённом репозитории

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

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

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

Если вы хотите иметь собственную ветку, над которой вы сможете работать, можете создать её на основе удалённой ветки:

Отслеживание веток

Получение локальной ветки с помощью git checkout из удалённой ветки автоматически создаёт то, что называется отслеживаемой веткой. Отслеживаемые ветки это локальные ветки, которые напрямую связаны с удалённой веткой. Если находясь на отслеживаемой ветке, вы наберёте git push, Git автоматически знает на какой сервер и в какую ветку отправлять изменения. Аналогично, выполнение git pull на одной из таких веток сначала получает все удалённые ссылки, а затем автоматически делает слияние с соответствующей удалённой веткой. При клонировании репозитория, как правило, автоматически создаётся ветка master, которая отслеживает origin/master. Вот почему git push и git pull работают и не требуют других аргументов. Однако, если хотите, можете настроить другие отслеживаемые ветки — те, которые не отслеживают ветки в origin, и те, которые не отслеживают ветку master. Простой случай это тот пример, который вы видели выше — выполнение:

Так же можно использовать ключ —track. В общем в Git должно отобразиться сообщение, что ветка будет отслеживаться.

Работа с патчами

ID – идентификатор предыдущего коммита. Коммиты, более новые, чем указанный, будут записаны в файлы. В результате мы должны увидеть:

Посмотреть сделанные коммиты можно через:

Пример, в первой строчке – ID коммита:

В результате получится нечто вроде:

Сгенерированные патчи можно отправить по почте с помощью команды

Для подключения(приложения) патча следует пользоваться командой

Если в процессе приложения патча произошла ошибка, то при обновлении репозитория (pull) может появиться ошибка:

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

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 для получения версии

Установка начала новой версии на текущий коммит:

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

Удалённые ветки

Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды 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 сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.

3.5 Ветвление в Git – Удалённые ветки

Удалённые ссылки – это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространенным способом является использование веток слежения.

Ветки слежения – это ссылки на определённое состояние удалённых веток. Это локальные ссылки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удаленным репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.

Примечание

«origin» – это не специальное название

Рисунок 31 – Локальная и удалённая работа может расходиться

Для синхронизации ваших изменений с удаленным сервером выполните команду git fetch (в нашем случае git fetch origin ). Эта команда определяет какому серверу соответствует « origin » (в нашем случае это git.ourcompany.com ), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.

Рисунок 32 – git fetch обновляет ветки слежения

Рисунок 33 – Добавление ещё одного сервера в качестве удалённой ветки

Рисунок 34 – Ветка слежения teamone/master

Отправка изменений

Когда вы хотите поделиться веткой, вам необходимо отправить её на удалённый сервер, где у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными при отправке – вам нужно явно указать те ветки, которые вы хотите отправить. Таким образом, вы можете использовать свои личные ветки для работы, которую не хотите показывать, а отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.

Примечание

Не вводите каждый раз свой пароль

Если вы используете HTTPS URL для отправки изменений, Git-сервер будет спрашивать имя пользователя и пароль для аутентификации. По умолчанию вам будет предложено ввести эти данные в терминале, чтобы сервер мог определить разрешена ли вам отправка изменений.

Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу «Хранилище учётных данных».

В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :

Отслеживание веток

В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:

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

Примечание

Сокращение upstream

Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, то перед запуском команды вам необходимо получить данные со всех ваших удалённых серверов. Сделать это можно так:

Получение изменений

Удаление веток на удалённом сервере

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

2.5 Основы Git – Работа с удалёнными репозиториями

Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен только для чтения или для чтения/записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение из них данных. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.

Примечание

Удаленный репозиторий может находиться на вашем локальном компьютере.

Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернете, а значит только – где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.

Просмотр удалённых репозиториев

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

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

Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; мы рассмотрим протоколы подробнее в разделе Установка «Git на сервер» главы 4.

Добавление удалённых репозиториев

В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add :

Ветка master из репозитория Пола сейчас доступна вам под именем pb/maste r. Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть ее содержимое. Более подробно работа с ветками рассмотрена в главе «Ветвление в Git».

Получение изменений из удалённого репозитория (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 remove или git remote rm :

При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.

Как клонировать все удаленные ветки в Git?

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

Сначала клонируйте удаленный репозиторий Git и перейдите в него:

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

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

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

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

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

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

Теперь вы можете оформить любую ветку, как вам нужно, не обращаясь к удаленному хранилищу.

Этот скрипт Bash помог мне:

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

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

Кредиты на однострочник переходят на пользователя cfi

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

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

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

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

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

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

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

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

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

Когда вы делаете «git clone git: // location», все ветки и теги выбираются.

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

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

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

Почему вы видите только «мастер»

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

Как получить местные филиалы

В этом примере branchone это имя локальной ветви, на основе которой вы создаете origin/branchone ; если вместо этого вы хотите создать локальные ветви с разными именами, вы можете сделать это:

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

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

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

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

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

Вы видите, «git clone git: //example.com/myprojectt» извлекает все, даже ветви, вам просто нужно оформить их, тогда будет создана ваша локальная ветка.

Вам нужно всего лишь использовать «git clone», чтобы получить все ветки.

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

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

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

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

Наконец, все команды имеют псевдонимы для упрощения запоминания.

Обратите внимание, что это альфа-программа 😉

Вот справка, когда вы запускаете grb help:

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

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

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

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

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

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

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

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

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