Gitflow: git flow init не работает на клонированном репо.

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

Пока что я нашел единственное решение - создать главную ветку, даже если она не используется. Это неприятно, но работает. Надеюсь, это скоро исправят!

Разве не было бы разумным отслеживать начальную главную ветвь, например
git checkout -t происхождение / мастер

Конечно ... Если он есть! Создавая новые проекты, я не нажимаю
пустая мастер-ветка, и после нажатия разработки нет мастера в
github тоже.

Так что это все еще проблема.

Отправлено с моего Windows Phone (да, вы правильно прочитали) От: shuane
Отправлено: суббота, 2 июля 2011 г., 6:33
Кому: [email protected]
Тема: Re: [gitflow] git flow init не работает на клонированном репо. (# 121)
Разве не было бы разумным отслеживать начальную главную ветвь, например
git checkout -t происхождение / мастер

Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/nvie/gitflow/issues/121#issuecomment -1486906

+1 такая же проблема ...

+1 такая же проблема

Какова философская причина нежелания отправлять пустую начальную главную ветвь (которая создается по умолчанию) при первом создании репозитория?

Если вы не отправите основную ветку (как кажется, комментаторы намеренно этого не сделали), вы не сможете превратить ее в клон. Git-flow правильно не пытается создать новую ветку, если вы забыли проверить уже существующую основную ветку, и тогда возникнет конфликт, если она создаст новую ветку.

В этом нет ничего философского. Это связано с рабочим процессом. Я могу протолкнуть основную ветку, но это может не помешать людям хвататься только за ветку разработки.

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

Мысли?

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

git push --all origin 

сначала подтолкнуть обе ветки разработки и master, чтобы исправить эту часть проблемы.

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

Вот как мы столкнулись с проблемой. Большая часть нашей разработки прямо сейчас в нашем репозитории git связана с функциональными ветками разработки.

Я установил "develop" в качестве ветки по умолчанию для репозитория на github. Я хотел поработать над функциональной веткой новой машины. Я клонировал репо, сделал "git flow init", и это не удалось.

@lorin Это показывает, что есть множество способов, которыми мы можем укусить. Для меня имеет смысл иметь git-flow для обработки этого случая, даже если для этого требуется раздражающая подсказка, это все же лучше, чем вообще не работать и полагаться на людей, которые выяснят это сами.

Частично эта проблема может заключаться в том, что git может извлекать только одну ветку при запуске git clone, и если вы установите ветвь по умолчанию GitHub как что-то иное, чем master, как я тоже, тогда master не будет там как удаленная ссылка, пока вы не запустите git fetch origin (я думаю). Если это так для многих людей, коммит, добавивший изменение для git-flow-init для поддержки проверки удаленных / origin / master [1], возможно, необходимо расширить, чтобы добавить вызов «git fetch origin» перед проверкой того, действительно ли мастер существует.

[1] https://github.com/nvie/gitflow/commit/baf163e07d579bec3dd0e21d00297832e8848b8b

тогда master не будет там в качестве удаленной ссылки, пока вы не запустите git fetch origin (я думаю).

Операция git clone буквально клонирует репозиторий, как указано в загрузке progit , вы можете отключить сетевой провод и сделать:

git checkout -b master origin/master

git создаст вам локальную ветку с именем master как копию origin / master.

Примечание:

git checkout master

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

@kasterma спасибо!

$ git flow init

Which branch should be used for bringing forth production releases?
   - develop
Branch name for production releases: [] 
Local branch '' does not exist.

$ git branch -a
* develop
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/master

Чтобы получить местный филиал:

$ git checkout master
$ git checkout develop
$ git branch -a
* develop
  master
  remotes/origin/HEAD -> origin/develop
  remotes/origin/develop
  remotes/origin/master

Теперь запустите git flow init как обычно.

$ git flow init

git config gitflow.branch.master master, чтобы правильно настроить главную ветку, когда вы не можете «отменить» инициализацию потока git.

То же самое, у меня такая же проблема.

+1 такая же проблема

+1

Просто столкнулся с этим. Гаррр! +1

Обязательно проверьте мастер хотя бы один раз в вашем локальном репо.

Сделаю. Спасибо

18 ноября 2016 г. в 18:41 «Роб Мур» [email protected] написал:

Обязательно проверьте мастер хотя бы один раз в вашем локальном репо.

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/nvie/gitflow/issues/121#issuecomment -261593726 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AVuyNjaPvHr8jyO9Zmy1bzynI0mhm0F_ks5q_eNRgaJpZM4AD0E_
.

+1 Со мной тоже было.

сделал следующие шаги, чтобы исправить проблему с клонированным репо

 git checkout -b master
 git checkout develop
 git flow init

Мой процесс TeamCity CI может заключить сборку в _git flow release_ с помощью _ant_ скриптов, но по ходу дела я узнал, что необходимо было проверить как master и develop , а затем запустить инициализацию по умолчанию до сборки:

git flow init -d

Разве не было бы разумным отслеживать начальную главную ветвь, например
git checkout -t происхождение / мастер

работает для меня! Спасибо

Решение:
-git ckeckout мастер
-git checkout разработать
-git flow init

@ andres310597 Это может быть для вас ответом. Это не помогло моему репо.

➜  mobile_provider git:(develop) git checkout master   
Updating files: 100% (17199/17199), done.
Switched to branch 'master'
Your branch is up to date with 'origin/master'. 
➜  mobile_provider git:(master) ✗ git checkout develop
Updating files: 100% (17199/17199), done.
Switched to branch 'develop'
Your branch is up to date with 'origin/develop'.                                                            /3.1s
➜  mobile_provider git:(develop) git flow init       

Which branch should be used for integration of the "next release"?
   - bug/mstelly/prov/2449-leave-job-crash
   - master
   - poc/realmdb
Branch name for "next release" development: [develop]

И мой файл .gitconfig не содержит ссылки на какие-либо настройки потока. Поэтому я не знаю, где хранятся значения.

Тот факт, что эта проблема оставалась открытой в течение 9 лет, многое говорит о наших шансах на ее решение в ближайшее время. Однако я принял значения по умолчанию и получил следующее сообщение:
To force reinitialization, use: git flow init -f
Значит, не сломано. Я думаю, это плохо документировано. Кому-то, наверное, стоит закрыть этот вопрос.