Git: Правильный способ изменить Active Branch в голом хранилище?

195

У меня есть пустой репозиторий, который используется в качестве центрального хранилища для моего проекта. Все разработчики делают, git clone <repo>чтобы поделиться с ним. Когда они делают клон, они получают извлечение главной ветви (если они не делают git clone -n), потому что repo.git/HEADсодержит ref: refs/heads/master, делая это Активная ветвь .

Вопрос в том, как правильно изменить Active Branch ? Я мог бы просто взломать repo.git/HEADфайл напрямую, но это кажется неприятным и, ну, в общем, хакерским.

Я попытался сделать это git checkout <otherbranch>в .gitкаталоге репо , но это не удалось, потому что я не был в рабочем дереве.

Я пытался, git update-ref HEAD refs/heads/otherbranchно это только что обновило refs /heads / master так, чтобы оно совпадало с refs /heads / otherbranch (хорошо, я сделал это в фиктивном репозитории, а не в моем производственном!)

Я пытался, git update-ref --no-deref HEAD refs/heads/otherbranchи это почти сработало. Он обновил HEADфайл, но установил его в SHA1 коммита, на который указывает refs/heads/otherbranch.

Я тестирую с git-версией 1.7.0.2.msysgit.0.

Я предполагаю, что нет никакого способа сделать это через git push, так как позволить всем и каждому изменить ветку по умолчанию кажется немного небезопасным (!), Но, безусловно, есть лучший способ сделать это в .gitкаталоге репо, чем прямой взлом HEADфайла.

git

— kbro
источник

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

— Николас Найт

12

Как это в корне пытается сделать что-то не то здесь? Пустой репозиторий поддерживает несколько веток. Я использую пустой репозиторий в качестве резервной копии моего локального репозитория и как таковой отражаю ветви. У меня есть мастер по обоим и ветка разработки по обоим. Если я хочу увидеть журнал ветки разработки в пустом репозитории, я должен взломать файлы - похоже, что git здесь в корне неверен в отношении поддержки голого репозитория.

— Ктхуту

15

@NicholasKnight ИМХО ты здесь в корне не прав. Нет ничего особенного в "master" как имени ветки, это просто значение по умолчанию. В поддерживаемых репозиториях у нас нет главного филиала, так как «мастер» не имеет значения для компании. Всякий раз, когда мы делаем релиз, мы создаем новую ветвь обслуживания с новым номером релиза и назначаем его в качестве активной ветки.

— Spacemoose,

@NicholasKnight Хотя я понимаю, откуда ты, это первая SO Q / A, в которой рассказывается, как перейти к мастеру! У меня было первоначальное репо в функциональной ветке, когда я сделал свой голый клон, и последующие клоны из этого голого репо по умолчанию перешли на эту ветку вместо master.

— Варбо

1

Ничего себе - этот вопрос просто работает и работает - это мой рекордсмен по репутации номер 1! Главное в «master» заключается в том, что это просто имя, и если оно не имеет смысла для вашей организации, команды, проекта, этапа и т. Д., То выберите что-то подходящее, чтобы, когда вы соавторы клонировали репозиторий, они сразу переключались. в ветку, в которой вы, как Configuration Manager, хотите, чтобы они были включены. Раньше я работал с ClearCase (bletch!), Поэтому вы выбирали «main», «main» или «main». ЮК.

— Кбро

280

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

git symbolic-ref HEAD refs/heads/mybranch

Который обновит файл HEAD в вашем хранилище, чтобы он содержал:

ref: refs/heads/mybranch

как указано в git-symbolic-ref

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

Помните, что такая команда git remote set-head:

не меняет ветку по умолчанию удаленного репо.
Это только изменяет удаленную ветку отслеживания, сохраненную в вашем локальном репо, какrefs/remotes/<name>/HEAD
не меняет HEADсебя (опять же, только refs/remotes/<name>/HEAD), следовательно, необходимость git symbolic-ref.

Так что git remote set-head это не ответ здесь.
git symbolic-ref HEADесть, если у вас есть прямой доступ к удаленному репо.

— VonC
источник

3

Спасибо! У меня есть прямой доступ к удаленному репо, так что git-symbolic-ref сделает эту работу. Мне нравится трюк без общих предков, упомянутый в другой ветке - определенно один для нижнего ящика. Я потратил целую вечность на поиск в Google, но не смог найти ваш предыдущий ответ, но «git remote head master» считает его вторым по рейтингу хитом, чуть ниже git-remote (1). Bizarre. Просто показывает, как трудно найти что-то, когда вы не знаете точно, что ищете.

— КБРО

git symbolic-ref HEAD refs/heads/mybranchработал просто отлично для меня! СПАСИБО! ;)

— vinzenzweber

1

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

— Джонни Бест

Это не работает для меня. Как ни странно, хотя удаленный HEAD в голом репо теперь показывает правильную ветвь, git STILL по умолчанию переводит меня в другую ветвь, когда я клонирую из нее!

— Магнус

@Magnus, это был бы хороший вопрос на новой странице.

— VonC

3

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

Сначала перечислите все ссылки в голом хранилище, выполнив

$find ref

Затем найдите ссылку на вашу ветку, формат будет следующим refs/heads/<my_branch>. Следующим шагом является проверка текущей ссылки, просто введите:

$git symbolic-ref HEAD

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

$git sumbolic-ref HEAD ref/heads/<my_branch>

Это все. Наслаждаться.

— Сол Росалес
источник

2

Как правильно изменить Active Branch?

status: git checkout в репозитории .git возвращает фатально: эта операция должна выполняться в рабочем дереве
советы: просто добавьте аргумент --work-tree

подробный пример: предположения: голые мерзавцы на удаленном сервере:

~ / bare_git_repository.git отдельное рабочее дерево: / var / www / myappremote

на локальном сервере: создайте ветку version.1.7 (наш другой филиал)

git branch версия 1..7

git push origin version.7.7

на удаленном сервере с git bare repo:

$ cd ~ / bare_git_repository.git

$ git branch

мастер
версия.1.7

Как указано, следующая команда

git checkout version.1.7

возвращение

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

Используя следующую команду

git --work-tree = / var / www / myappremote checkout version.1.7

успешно изменить Active Branch

$ git branch

мастер

version.1.7

проверьте результаты со следующим

ll / var / www / myappremote

надеюсь это поможет

— с-инструменты
источник

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

— Жоэль Эспонде

-1

Кроме того, если у вас нет доступа к пустому хранилищу, сделайте, git remote set-headи вы сделали

Смотрите этот предыдущий ответ

— dvdvck
источник

-3

У меня также есть репо на нашем сервере, и я смог успешно получить файлы, используя

git clone //server/repo/directory -b branch_name

в новый локальный репозиторий, хотя на man-странице сказано, что это только для не голых репозиториев.

— mcjh
источник

1

Хотя то, что вы говорите, верно, тот факт, что вы используете -b для выбора конкретной ветви, нарушает ваш ответ в контексте моего вопроса, а именно как вы устанавливаете ветку DEFAULT.

— kbro

-4

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

git symbolic-ref HEAD refs/heads/mybranch

и похоже, что был изменен только файл repo.git / HEAD, так что, вероятно, достаточно просто «взломать» файл.

— Борын
источник

2

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

— Ален О'Ди

2

В чем преимущество этого @boryn?

— Алекс Чемберлен

2

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

— qwerty9967

Я использовал команду. Но этот ответ был полезен для понимания того, как он работает, и, в частности, для понимания того, что ссылки / заголовки являются чем-то внутренним, и я не должен менять это, только последнюю часть «пути». Итак, я проголосовал, потому что, по-моему, это была ценная информация.

— Майк Кескинов