Изменить ветку по умолчанию, чтобы оформить заказ от мастера до разработки - PullRequest
0 голосов
/ 08 января 2019

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

Ответы [ 2 ]

0 голосов
/ 08 января 2019

Проверка ветки git по умолчанию определяется удаленным репозиторием HEAD, который почти всегда указывает на master. Я не знаю о локальной настройке, которая могла бы изменить значение по умолчанию clone. (Вы можете аппроксимировать это поведение предостережениями; см. Ниже.) Поскольку git обычно не может предполагать, что ветвь любого заданного имени (включая master) будет существовать в произвольном удаленном устройстве, я не ожидаю, что у него будет такая возможность ; он полагается на пульт, чтобы сообщить ему, что такое ветка по умолчанию (опять же, через HEAD) пульта.

Проверка master по умолчанию не самая удобная вещь для разработчиков во многих моделях ветвления, но это довольно глубоко укоренившееся соглашение; поэтому я рекомендую адаптировать ваши привычки рабочего процесса к этому, вместо того, чтобы пытаться сделать обратное.

Но какие есть варианты?

Для данной команды clone вы можете использовать опцию --branch, чтобы выбрать то, что изначально извлечено

git clone --branch develop http://some.server/repo.git

Опираясь на это, вы можете определить псевдоним для клонирования с помощью опции --branch. (Но псевдоним потерпит неудачу, если используется в репо, в котором нет ветки с выбранным вами именем.)

Для репозиториев, которыми вы управляете, вы можете изменить HEAD так, чтобы он указывал на ветку по вашему выбору, но я действительно не рекомендую этого делать по нескольким причинам. Во-первых, это может привести к путанице, если репо является общим. (Точно так же это может усложнить настройку инструментов сборки, хотя с этим действительно не сложно разобраться.) Но главная причина, по которой я бы не стал этого делать, - это то, что вы создаете привычки, когда используете свои собственные репозитории, и эти привычки не будут перевести на использование репо других.

0 голосов
/ 08 января 2019

Да, есть способ сделать это.

Когда вы запускаете git clone <url>, ваш Git вызывает другой Git. Этот другой Git имеет хранилище; ваш Git создает новую копию своего хранилища.

Если вы предоставите -b <em>branch</em> аргумент для вашего git clone, вашего Git завершит процесс клонирования с помощью git checkout <em>branch</em>. Так что это самый простой способ сделать это, но, конечно, если вы забыли запустить git checkout, вы можете забыть и аргумент -b.

Если вы не поставляете -b <em>branch</em>, ваш Git получает рекомендованную лучшую ветку от другого Git. Затем ваш Git использует это для своего последнего шага git checkout. Так что если у вас есть доступ к другому Git-репозиторию, вам просто нужно пойти туда и изменить, какую ветку он предложит.

Ветвь, которую предложит другой Git, определяется тем, какая ветка извлечена / текущая в этом хранилище. Так как большинство серверных репозиториев "голые" (не имеют рабочего дерева), вы не можете проверить ветку там, но они все еще имеют ветку current . Вы можете обновить его с помощью git symbolic-ref:

server$ cd repo
server$ git symbolic-ref HEAD refs/heads/develop

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

...