Git branch

Введение¶

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

Detached HEADs

Gerade haben wir die drei wichtigsten Verwendungszwecke von für Branches kennengelernt. Nun ist es wichtig, dass du den Zustand des verstehst. Du erinnerst dich: Als wird in Git der aktuelle Snapshot bezeichnet. Intern aktualisiert der Befehl den lediglich so, dass er auf den angegebenen Branch oder Commit verweist. Zeigt der Verweis auf einen Branch, meldet Git kein Problem. Wenn du allerdings einen Commit auscheckst, wechselst du in einen Zustand mit .

Für dich ist das eine Warnung: Du wirst darauf hingewiesen, dass alle Änderungen, die du vornimmst, von der restlichen Entwicklung des Projekts «losgelöst» sind. Wenn du also bei losgelöstem mit der Arbeit an einem neuen Feature beginnst, wird kein Branch angelegt, über den du deine Arbeit später referenzieren könntest. Sobald du einen anderen Branch auscheckst, beispielsweise um dein Feature in ihn zu integrieren, hättest du dann keine Möglichkeit, auf dieses Feature zu verweisen:

Sämtliche Entwicklungsarbeit sollte immer in einem Branch stattfinden, niemals in einem losgelösten . Nur dann ist sichergestellt, dass du auf deine neuen Commits verweisen kannst. Wenn du dir allerdings lediglich einen alten Commit anschauen möchtest, spielt es keine Rolle, ob du in einem losgelöstem arbeitest.

Трехстороннее слияние

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

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

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

Порядок действий

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

Команда позволяет создавать, просматривать, переименовывать и удалять ветки. Она не дает возможности переключаться между ветками или выполнять слияние раздвоенной истории воедино. Именно поэтому команда тесно связана с командами и .

Совмещение веток

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

Слияние

Оно включает в себя создание нового коммита, который основан на общем коммите-предке двух ветвей и указывает на оба HEAD в качестве предыдущих коммитов. Для слияния мы переходим на основную ветку и используем команду .

Если обе ветви меняют одну и ту же часть файла, то возникает конфликт слияния — ситуация, в которой Git не знает, какую версию файла сохранить, поэтому разрешать конфликт нужно собственноручно. Чтобы увидеть конфликтующие файлы, используйте .

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

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

Перемещение

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

Для перемещения используется команда , которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

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

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

Представим сценарий:

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

Поэтому вот совет:

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

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

Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

Решение Simple Git 2.0+:

Начиная с Git 2.0, поведение стало проще :

Вы можете настроить git с помощью , чтобы упростить жизнь:

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

будет отслеживать удаленную ветвь с тем же именем. Теперь с этой конфигурацией вы будете автоматически угадывать удаленную ссылку на git push. Из документации git.config :

Для меня это хорошее упрощение моего повседневного рабочего процесса в Git. Параметр конфигурации учитывает «обычный» вариант использования, когда вы добавляете ветку локально и хотите создать ее удаленно. Кроме того, я так же легко могу создавать локальные ветви с удаленных компьютеров, просто выполнив команду (вместо использования флаг).

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

Чтобы добавить свою глобальную конфигурацию Git, запустите ее в командной строке:

Стандартный Рабочий Процесс с Git

Стандартный рабочий процесс с использованием Git выглядит примерно так:

После создания Git Репозитория, вся работа происходить в Рабочем Каталоге

Когда проделанная вами работа достигает какой-то важной отметки (например вы пофиксили баг или закончился рабочий день), вы добавляете ваши изменения в Индекс (так называемая ‘область подготовленных файлов’ или ‘staging area’)
Как только в индексе находятся все изменения которые вы намереваетесь сохранить, вы делаете коммит, который перемещает файлы из индекса в Git Репозиторий на постоянное хранение.

Проект в Git можно рассматривать, как состоящий из 3 частей:

Часть	Описание
Рабочий Каталог	Где вы делаете всю работу: создаете, редактируете, удаляете и организовываете файлы
Индекс	Где вы отмечаете какие изменения, сделанные вами в рабочем каталоге, следует сохранить
Git Репозиторий	Где Git на постоянной основе хранит эти изменения в виде различных версий вашего проекта

10 ответов

1. Убедитесь, что вы отметили заменяемую ветку (из ).

2. Предполагая, что master — это локальная ветвь, которую вы заменяете, а «origin /master» — это удаленная ветвь, в которую вы хотите сбросить:

Это обновит вашу локальную ветку HEAD, чтобы она стала той же ревизией, что и origin /master, и синхронизирует это изменение с индексом и рабочее пространство.

Это так просто, как три шага:

1. Удалить вашу локальную ветку:
2. Получить последнюю удаленную ветку:
3. Восстановите локальную ветвь на основе удаленной:

Заменить все на удаленную ветку; но , только из того же коммита, в котором находится ваша локальная ветвь:

ИЛИ , получите последний из удаленной ветви и замените все:

Помимо этого, при необходимости вы можете уничтожить неотслеживаемые файлы & каталоги, которые вы еще не добавили:

Самый безопасный и наиболее полный способ заменить текущую локальную ветку удаленной:

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

Или как функция bash:

который переименовывает текущую ветвь в нечто вроде replace_master_98d258f.

Вы можете сделать, как сказал @Hugo из @Laurent, или использовать , чтобы удалить коммиты, от которых вы хотите избавиться Если вы знаете, какие из них. Я склонен использовать (где N — число, позволяющее вам манипулировать последними N коммитами) для операций такого типа.

выбранный ответ является абсолютно правильным , однако он не оставил меня с последним коммитом /нажатием …

Так что для меня:

Поскольку я знаю, что хочу временно установить свою ветвь upstream на несколько недель на определенную ветку (такую ​​же, как та, на которую я переключился /выписал ранее и сделал полный сброс)

Итак, ПОСЛЕ сброса

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

Как указано в выбранном объяснении, сброс git — это хорошо.
Но в настоящее время мы часто используем подмодули: репозитории внутри репозиториев. Например, если вы используете ZF3 и jQuery в своем проекте, вы, скорее всего, захотите, чтобы они были клонированы из своих исходных репозиториев.
В таком случае git reset недостаточно.
Нам нужно обновить подмодули до той точной версии, которая определена в нашем репозитории:

это то же самое, что вы (cd) рекурсивно попадете в рабочий каталог каждого подмодуля и запустите:

И это очень отличается от

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

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

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

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

Важно понимать, что GIT не позволит вам работать над чужой веткой. Принцип такой – вы создаете локальную копию чужой ветки, и над ней уже работаете

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

git fetch

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

git branch -v -a

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

git checkout -b dev1 origin/dev1

Вообще-то можно было написать проще:

git checkout dev1

Но:

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

git checkout -b mydev1 origin/dev1

How it works

will combine multiple sequences of commits into one unified history. In the most frequent use cases, is used to combine two branches. The following examples in this document will focus on this branch merging pattern. In these scenarios, takes two commit pointers, usually the branch tips, and will find a common base commit between them. Once Git finds a common base commit it will create a new «merge commit» that combines the changes of each queued merge commit sequence.

Say we have a new branch feature that is based off the branch. We now want to merge this feature branch into .

Invoking this command will merge the specified branch feature into the current branch, we’ll assume . Git will determine the merge algorithm automatically (discussed below).

Merge commits are unique against other commits in the fact that they have two parent commits. When creating a merge commit Git will attempt to auto magically merge the separate histories for you. If Git encounters a piece of data that is changed in both histories it will be unable to automatically combine them. This scenario is a version control conflict and Git will need user intervention to continue. 

Где и как использовать Git Branch

Не забудьте получить доступ к вашему серверу по SSH перед запуском. Вот руководство по PuTTY, которое вам поможет!

Работать с Git branches довольно просто, это видно из самих команд. Но, как и в большинстве других случаев, чем больше у вас веток, тем сложнее управлять ими.

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

git branch

Если вы не создали ни одной Git branch, в терминале не будет выходных данных. Создать ветку действительно просто:

git branch 

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

git checkout 

Результат сообщит нам, что мы перешли в новую ветку. Мы назвали её тестовой, так что мы увидим следующее сообщение:

Switched to branch ‘test’

Теперь в этой новой ветви разработки мы можем создать столько модификаций кода, сколько захотим, без необходимости что-либо менять в основной Git branch. Как мы видим, это поддерживает готовность программы к добавлению новых частей кода.

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

git branch

Есть кое-что, о чём мы должны помнить, создавая новую ветку разработки. Во-первых, мы должны сделать commit в основную ветку, чтобы Git понял, что это master branch. Если мы этого не сделаем, мы получим ошибку. Итак, сначала сделайте commit, а затем создавайте ветки разработки.

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

git branch -d 

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

git checkout master

git branch -d test

Наконец, наступил момент, когда мы внесли много изменений в ветку разработки и она превратилась в стабильную, поэтому мы хотим связать её с другой веткой разработки. Для этого и существует команда слияния (merge).

Сначала найдите ветку разработки, к которой должна быть присоединена другая ветка. Например, мы хоти прикрепить тестовую ветвь к основной ветке – master branch. Для этого мы должны перейти в master branch и осуществить merge с помощью команды:

git merge 

Как видите, основные функции ветки Git довольно просты. Вам просто нужно знать основы и стараться поддерживать порядок в своём проекте.

Представление конфликтов

Когда Git обнаруживает конфликт в ходе слияния, к затронутым файлам добавляются визуальные индикаторы по обе стороны проблемного содержимого: <<<<<<<, ======= и >>>>>>>. Чтобы обнаружить конфликты, попробуйте поискать в проекте эти индикаторы.

>>>>>>> feature branch;

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

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

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

Как Клонировать Удалённый Репозиторий?

Чтобы клонировать репозиторий, мы будем использовать команду Git clone. Кроме того, вам также необходимо указать URL-адрес репозитория:

1. Вы можете клонировать главную ветку (master branch) из удалённого репозитория с помощью HTTPS или SSH. Для HTTPS:

   git clone https://github.com/imia-polzovatelia/imia-vashego-repozitorija.git

   Для SSH:

   git clone ssh://github.com/imia-polzovatelia/imia-vashego-repozitorija.git

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

   cd vashi_prilozhenija

1. Проверить состояние ветки можно с помощью простой команды Git:

   git status

git pull –rebase

Рассмотрим команду pull с параметром rebase:

git pull --rebase

На результат слияния параметр –rebase не влияет, единственное, что он делает – меняет вид истории коммитов.

До команды pull

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

До pull

Наши локальные коммиты с момента разветвления – это нижние E, F, G, а в удаленном репозитории с тех пор появились коммиты A, B, C. Нам надо их накатить сверху на наши коммиты E, F, G, что собственно и делает команда pull.

Обычный pull

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

git pull

pull –rebase

Если же мы выполним:

git pull --rebase

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

git pull –rebase

При просмотре истории коммитов мы просто увидим ряд коммитов из основной ветки A, B, C, идущих за нашими локальными E, F, G. Кому-то такой вид выглядит чище, хотя разницы в итоговом содержимом файлов нет.

Checkout von Branches

Über den Befehl kannst du zwischen Branches wechseln, die du mit erstellt hast. Wenn du einen Branch auscheckst, werden die Dateien im Arbeitsverzeichnis mit den in dem betreffenden Branch gespeicherten Versionen aktualisiert und Git speichert alle neuen Commits in dem ausgecheckten Branch. Du wählst also im Grunde genommen aus, an welcher Entwicklungslinie du arbeiten möchtest.

Im Vergleich zu einem herkömmlichen SVN-Workflow ist es etwas ganz anderes, für jedes neue Feature einen eigenen Branch zu nutzen. Neue Experimente sind das reinste Kinderspiel und du musst dabei nicht befürchten, eine bestehende Funktionalität zu zerstören. Außerdem kannst du so an vielen nicht zusammengehörigen Features gleichzeitig arbeiten. Außerdem vereinfachen Branches viele Workflows zur Zusammenarbeit.

Der Befehl wird möglicherweise gelegentlich mit verwechselt. Der Unterschied zwischen beiden Befehlen besteht darin, dass beim Klonen Code von einem Remote-Repository abgerufen wird und dass im Gegensatz dazu beim Auschecken zwischen Code-Versionen gewechselt wird, die sich bereits auf dem lokalen System befinden.

Summary

This document is an overview of the command. Merging is an essential process when working with Git. We discussed the internal mechanics behind a merge and the differences between a fast forward merge and a three way, true merge. Some key take-aways are:
 

1. Git merging combines sequences of commits into one unified history of commits.
2. There are two main ways Git will merge: Fast Forward and Three way
3. Git can automatically merge commits unless there are changes that conflict in both commit sequences.

This document integrated and referenced other Git commands like: , , and . Visit their corresponding stand-alone pages for more information. 

04 Сброс коммитов к предшествующим коммиту Oops

Глядя на историю лога (см. выше), мы видим, что коммит с тегом «v1» является коммитом, предшествующим ошибочному коммиту. Давайте сбросим ветку до этой точки. Поскольку ветка имеет тег, мы можем использовать имя тега в команде сброса (если она не имеет тега, мы можем использовать хэш-значение).

Результат:

$ git reset --hard v1
HEAD is now at fa3c141 Added HTML header
$ git hist
* fa3c141 2011-03-09 | Added HTML header (HEAD, v1, master) 
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) 
* 43628f7 2011-03-09 | Added h1 tag 
* 911e8c9 2011-03-09 | First Commit 

Наша ветка master теперь указывает на коммит v1, а коммитов Oops и Revert Oops в ветке уже нет. Параметр указывает, что рабочий каталог должен быть обновлен в соответствии с новым head ветки.

Why do we merge branch in Git?

We create Branches to work separately on a feature without disturbing the main stable branch, also known as the master branch. But, the fate of branches is to get merged. We create them so that they can merge after finishing work on them. Merging a branch into the master branch symbolizes that the feature you were developing into that branch is complete and tested and is now ready to be a part of the software.

A small example will make this clear. Let say you are currently working as usual on your software, and suddenly, a new requirement comes up. It is very urgent and should execute as soon as possible. The straightforward steps for this would be to create a new branch from production or master or any other branch. Work on the feature in this branch. Test this branch. Finally, merge it with the master.

A single repository generally contains multiple branches in Git. A simple merge of two branches is represented pictorially as below:

As seen in the above image, the top branch merges into the master branch after three commits.

Syntax to merge a branch in Git

A merge operation can be executed by typing the command

git merge <branch_name>

So what does Git do behind the scenes when you type this command? When the command executes, git replays all the commits from the time this branch got diverted, i.e., from time marked as “1” in the image to the time the branch is merged into the master, i.e., the time marked as “2”. These commits that happened since the branch diverged from the master branch will then log to a single branch, i.e., the top branch in our case.

Что Такое Git Branch

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

Использование Git Branches имеет несколько преимуществ. Тем не менее, мы хотим подчеркнуть следующие два:

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

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

Recursive Git Merge Strategy Options

The ‘recursive’ strategy introduced above, has its own subset of additional operation options.

Not to be confused with the Ours merge strategy. This option conflicts to be auto-resolved cleanly by favoring the ‘our’ version. Changes from the ‘theirs’ side are automatically incorporated if they do not conflict.

The opposite of the ‘ours’ strategy. the «theirs» option favors the foreign merging tree in conflict resolution.

This option spends extra time to avoid mis-merges on unimportant matching lines. This options is best used when branches to be merged have extremely diverged.

This option allows specification of an explicit diff-algorithim. The diff-algorithims are shared with the  command.

A set of options that target whitespace characters. Any line that matches the subset of the passed option will be ignored.

This option runs a check-out and check-in on all of the tree git trees while resolving a three-way merge. This option is intended to be used with merging branches with differing / states.

Disables the renormalize option. This overrides the configuration variable.

This option will ignore renamed files during the merge.

This is the default behavior. The recursive merge will honor file renames. The parameter can be used to pass a threshold for rename similarity. The default value is

This option borrows from the `subtree` strategy. Where the strategy operates on two trees and modifies how to make them match on a shared ancestor, this option instead operates on the path metadata of the tree to make them match.

Открепленные указатели HEAD

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

Сама команда просто обновляет указатель , чтобы он ссылался на указанную ветку или коммит. Когда HEAD указывает на ветку, Git молчит, но при попытке переключиться на коммит он переходит в состояние (открепленный указатель HEAD).

Это сообщение предупреждает о том, что вся текущая работа «откреплена» от остальной части вашего проекта. Если вы начнете разрабатывать функцию, находясь в состоянии открепленного указателя , у вас не будет ветки, которая позволила бы вам вернуться к этой функции. Когда вы неизбежно переключитесь на другую ветку (например, чтобы слить код своей функции), вы уже никак не сможете сослаться на свою функцию:

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

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонируем репозиторий с той же машины в директорию :

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

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

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

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

git merge username-project/master

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

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

git pull

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

git pull username-project --tags

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

git push — вносим изменения в удаленный репозиторий

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

Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test