2012-03-15 1 views
0

У меня есть сценарий оболочки Bourne, который будет строить HEAD указанной удаленной ветви или указанный удаленный тег. Тег branch/tag указан в качестве входного аргумента скрипту.Как сделать Git тянуть только на ветку в сценарии оболочки?

В скрипте я выполняю git fetch, чтобы обновить всю локальную информацию с помощью удаленной информации. Затем я выполняю ветку/тег git checkout.

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

Как я могу лучше всего решить эту условную тягу git? Или более простой: какие команды git мне нужны в сценарии оболочки для создания удаленной ветви или удаленного тега?

  • Ed
+0

Если вы действительно хотите построить на основе удаленной ветви, есть ли какая-то причина не проверять эту фактическую ветку? 'git checkout remotes/origin/GRONKLE' предоставит вам состояние' HEAD' ('.git/HEAD' будет содержать исходный идентификатор фиксации), чтобы ваше дерево работы содержало то, что находится в удаленной ветке. Аналогично, вы можете просто «git checkout tagname» проверить эту ветку. Вам нужно только создать и/или объединить в локальный ветвь, если вы хотите, чтобы локальная ветка и/или локальные изменения. – torek

+0

Я нахожусь в локальной ветке и хочу перейти к указанной ветке/тегу (как входной аргумент) и построить его. Однако, если это касается ветви, мне нужно выполнить какое-то нажатие, чтобы объединить все удаленные изменения. Только проверка ветки не даст мне последних изменений. – edbras

+0

Вам не нужно использовать 'pull'; 'git fetch' получит самые последние обновления с пульта. См. Также ответ @Adam Dymitruks ... но я думаю, что у вас есть какое-то фундаментальное непонимание того, как работают ветки, теги и «пульты», и я не уверен, что это недоразумение. – torek

ответ

0

Вы хотите получать. Затем слить, переустановить или сбросить.

+0

Слияние не будет работать, когда я нахожусь тег, не так ли? – edbras

+0

Вы никогда не можете «быть на ярлыке». Вы можете быть без головы. –

1

Я думаю, что на данном этапе (на основе обсуждения выше), что вы получаете немного перепутали с тем, что значит быть «на ветке», и т.д.

Глубоко внутри мерзавца, когда вы делаете git checkout NAME, git разрешает NAME конкретному конкретному фиксации. Эта фиксация привязана к дереву - дереву каталогов, заполненному файлами, - и проверяет попытки получить то конкретное дерево в ваше дерево (не сбивая никаких несохраненных файлов и т. Д.), Но давайте предположим, что ваше дерево работы во всех случаях является нетронутым, чтобы упростить здесь).

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

$ git checkout remotes/origin/master 
Note: checking out 'remotes/origin/master'. 

You are in 'detached HEAD' state. You can look around, make experimental 
changes and commit them, and you can discard any commits you make in this 
state without impacting any branches by performing another checkout. 

If you want to create a new branch to retain commits you create, you may 
do so (now or later) by using -b with the checkout command again. Example: 

    git checkout -b new_branch_name 

HEAD is now at fb4a1b2... (some commit message) 

Это также является то, что произойдет, если вы заканчивали явный тег:

$ git checkout v1.0 
Previous HEAD position was fb4a1b2... (some commit message) 
HEAD is now at cfb9904... (another commit message) 

Во всех этих случаях, у вас есть отлично подходящее дерево работы, которое представлено этими конкретными идентификаторами фиксации. Вы больше не находитесь «на ветке» вообще (состояние «отдельно стоящего HEAD»). (Вы можете «вернуться на ветку», проверив какую-либо локальную ветку или создав новую локальную ветвь с git checkout -b newname, чей совет тогда является то, что HEAD is now at ...)

Теперь скажите, что у вас есть «удаленная ветка», умышленное отслеживание:

$ git checkout GRONKLE # my local branch, which tracks remotes/origin/GRONKLE 
$ git pull 

«тянуть» здесь состоит из выборки и слияния. В шаге «выборка» используется соответствующий базовый транспорт для переноса любых новых коммитов на удаленную ветку. Это дает вам «то, что они сделали». Шаг «merge» затем пытается применить «то, что они сделали» к «тому, что у вас есть» в вашей локальной сети.

Скажем, например, что «то, что у вас есть» было полностью синхронизировано с «тем, что они сделали» вчера. Затем, сегодня вы изменили dir1/file1 и dir1/file2 (и зафиксировали это). Между тем, «они» изменили dir2/file3 (и зафиксировали это в вашем репозитории remotes/origin).Когда вы делаете «git fetch», это получает их обновления в dir2/file3 и делает remotes/origin/GRONKLE имя «что у них есть». Ваша отрасль: behind ... by 1 commit.

Когда вы продолжать делать «GIT слияния», однако, что касается их изменения dir2/file3, но и сохраняет изменения в dir1/file1 и file2 dir1 /. Это дает вам новый commit, который является «фиксацией слияния». Ваша ветка теперь впереди одной фиксацией.

Если вы хотите создать «то, что у них есть» - это то, что вы сказали в исходном вопросе, - тогда вы не должны ваши изменения в dir1/file1 и dir1/file2, сидящие вокруг. Вы можете просто проверить remotes/origin/GRONKLE (в этом примере), и у вас будет именно то, что они вам дали, не больше и не меньше.

Если вы хотите построить «то, что у них есть, плюс то, что у меня есть», вам необходимо объединить и/или переупаковать, как сказал @Adam Dymitruk. Но это не «то, что у них есть». И - в ответ на ваш ответ на него - вы никогда не «на теге» вообще. Тег - это просто имя конкретной фиксации, и если вы проверите этот тег, вы снова находитесь в том же состоянии «отдельно стоящего HEAD». Если вы хотите внести изменения в «новую ветку, которая начинается с того, где начинается этот тег» (см. Сноску), вам нужно создать новую ветку, начиная с этого тега.

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

$ git checkout <commit> 

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

$ git checkout -b new_local_branch 

Или, если вы достаточно уверены в своей начальной точки:

$ git checkout -b new_local_branch <commit> 

(и примерно полдюжины других способов, используя git branch, но вышеприведенных двух хватает).


Сноска: ветви на самом деле не «начинают» нигде, ведь все сказано и сделано. Точнее, вы получаете исходную точку - проверяете какой-то конкретный идентификатор фиксации - и делаете любую работу, которая вам нравится оттуда, делаете новые коммиты и т. Д., Но как только вы помещаете ярлык филиала, чтобы помнить эту работу, ветвь метка просто следует «подсказке» этой работы. До тех пор, если вы находитесь в состоянии «отдельно стоящего HEAD», первичная ссылка на любые новые фиксации, которые вы делаете, - это ваша отдельная головка. Легко «потерять» эту ссылку, хотя, если вы не делаете новую ветку, хотя, если вы соскучитесь внутри git, вы можете найти все дополнительные места, которые она сохраняет для вас, как правило, до трех месяцы.