Обсуждение:Краткое руководство по сборке с gear

Материал из ALT Linux Wiki

(Различия между версиями)
Перейти к: навигация, поиск
(Новая страница: «Насколько я знаю, при клонировании клонируется только одна ветка, поэтому git checkout <BRANCH> воо...»)
(использование remotes)
 
(1 промежуточная версия не показана)
Строка 1: Строка 1:
Насколько я знаю, при клонировании клонируется только одна ветка, поэтому
Насколько я знаю, при клонировании клонируется только одна ветка, поэтому
git checkout <BRANCH> вообще не сработает.
git checkout <BRANCH> вообще не сработает.
 +
 +
----
 +
Клонируется ВСЁ, что есть в репозитории. Только основная ветка создаётся явно, остальные хранятся как remotes, на их основе можно уже создавать такую структуру, какая нужна. Поясню. На git.alt есть некий репозиторий, пусть это будет my.git, колнируем:
 +
git clone git.alt:packages/my.git
 +
Если у нас там было 2 бранча - master и upstream, после клонирования получится вот такой набор бранчей:
 +
* master
 +
* origin/HEAD
 +
* origin/master
 +
* origin/upstream
 +
 +
Чтобы получить бранч upstream, с которым уже можно работать локально, достаточно выполнить:
 +
git checkout -b upstream origin/upstream
 +
 +
Примерно, вот так.
 +
:[[Участник:Real|real]] 01:53, 17 июля 2009 (UTC)
 +
 +
----
 +
Кстати, по поводу remotes - очень удобная штука. Без них нередко приходится выполнять ужасные конструкции типа git pull git.alt:/people/логин/packages/пакет.git для втягивания в свой git чужих изменений. А вот с remotes всё намного проще:
 +
 +
git remote add логин git.alt:/people/логин/packages/пакет.git
 +
 +
После этого достаточно периодически делать
 +
  git remote update
 +
и все изменения в чужом репозитории зальются в наш репозиторий, будет набор бранчей, соответствующих имени добавленного remotes.
 +
 +
Для примера:
 +
git remote add led git.alt:/people/led/packages/blcr.git
 +
После выполнения команды git remote update получится примерно такой набор бранчей (если предположить, что в нашем репозитории бранча два - master и upstream):
 +
* master
 +
* upstream
 +
* remotes/led/master
 +
* remotes/led/releases
 +
* remotes/origin/HEAD -> origin/master
 +
* remotes/origin/master
 +
* remotes/origin/upstream
 +
Детали могут отличаться, но смысл будет тот же.
 +
 +
Периодически выполняя git remote update, все изменения (как в своём репозитории, так и в репозитории led@) будут залиты на машину, и втянуть обновления себе очень просто (например, обновим upstream):
 +
git checkout upstream
 +
git merge led/releases
 +
 +
:[[Участник:Real|real]] 23:28, 18 июля 2009 (UTC)

Текущая версия на 23:28, 18 июля 2009

Насколько я знаю, при клонировании клонируется только одна ветка, поэтому git checkout <BRANCH> вообще не сработает.

Клонируется ВСЁ, что есть в репозитории. Только основная ветка создаётся явно, остальные хранятся как remotes, на их основе можно уже создавать такую структуру, какая нужна. Поясню. На git.alt есть некий репозиторий, пусть это будет my.git, колнируем: 

git clone git.alt:packages/my.git

Если у нас там было 2 бранча - master и upstream, после клонирования получится вот такой набор бранчей: 

* master
* origin/HEAD
* origin/master
* origin/upstream

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

git checkout -b upstream origin/upstream

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

real 01:53, 17 июля 2009 (UTC)

Кстати, по поводу remotes - очень удобная штука. Без них нередко приходится выполнять ужасные конструкции типа git pull git.alt:/people/логин/packages/пакет.git для втягивания в свой git чужих изменений. А вот с remotes всё намного проще: 

git remote add логин git.alt:/people/логин/packages/пакет.git

После этого достаточно периодически делать 

 git remote update

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

Для примера: 

git remote add led git.alt:/people/led/packages/blcr.git

После выполнения команды git remote update получится примерно такой набор бранчей (если предположить, что в нашем репозитории бранча два - master и upstream): 

* master
* upstream
* remotes/led/master
* remotes/led/releases
* remotes/origin/HEAD -> origin/master
* remotes/origin/master
* remotes/origin/upstream

Детали могут отличаться, но смысл будет тот же.

Периодически выполняя git remote update, все изменения (как в своём репозитории, так и в репозитории led@) будут залиты на машину, и втянуть обновления себе очень просто (например, обновим upstream): 

git checkout upstream
git merge led/releases
real 23:28, 18 июля 2009 (UTC)
 
Личные инструменты