Gitflow: git flow init schlägt bei geklontem Repository fehl.

Ich habe genau das gleiche Problem. Ich habe lokal noch keinen Master-Branch erstellt (da mir das auch falsch erscheint), aber ich habe noch keine andere Lösung gefunden. Werde aber nochmal posten wenn ich was finde.

Die einzige Lösung, die ich bisher gefunden habe, besteht darin, den Master-Zweig zu erstellen, auch wenn er nicht verwendet wird. Es ist nicht angenehm, aber es funktioniert. Hoffentlich gibt es bald eine Lösung dafür!

Wäre es nicht am klügsten, den anfänglichen Master-Zweig zu verfolgen, z
git checkout -t origin/master

Klar... Wenn es einen gibt! Wenn ich neue Projekte erstelle, dränge ich kein
leerer master-Zweig, und nach dem Pushen von Develop gibt es keinen Master in
github auch nicht.

Es ist also immer noch ein Problem.

Gesendet von meinem Windows Phone (ja du hast richtig gelesen) Von: shuane
Gesendet: Samstag, 2. Juli 2011 6:33
An: [email protected]
Betreff: Re: [gitflow] git flow init schlägt bei geklontem Repo fehl. (#121)
Wäre es nicht am klügsten, den anfänglichen Master-Zweig zu verfolgen, z
git checkout -t origin/master

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/nvie/gitflow/issues/121#issuecomment -1486906

+1 gleiches Problem...

+1 gleiches Problem

Was ist der philosophische Grund dafür, den leeren anfänglichen Master-Zweig (der standardmäßig erstellt wird) nicht zu verschieben, wenn das Repository zum ersten Mal erstellt wird?

Wenn Sie den Master-Zweig nicht pushen (was die Kommentatoren hier anscheinend absichtlich nicht getan haben), können Sie ihn nicht in einen Klon ziehen. Git-Flow ist richtig, wenn Sie nicht versuchen, einen neuen zu erstellen, falls Sie vergessen haben, einen bereits vorhandenen Master-Zweig auszuchecken und dann einen Konflikt haben, wenn ein neuer Zweig erstellt wird.

Daran ist nichts Philosophisches. Es hat mit Arbeitsabläufen zu tun. Ich kann einen Master-Branch pushen, aber das hält die Leute vielleicht nicht davon ab, nur den Development-Branch zu greifen.

Git-Flow könnte richtig sein, wenn es nicht versucht, ein neues zu erstellen. Aber warum nicht mich fragen, anstatt zu scheitern? "Möchtest du, dass ich einen neuen Zweig erstelle oder soll ich den Remote-Master für dich aufspüren?"

Die Gedanken?

Bei manchen hier gibt es keinen Remote-Master, weil sie meinen, es wäre falsch, einen leeren Zweig zu pushen. Es wäre nützlich für sie, durchzuführen

git push --all origin 

um zunächst sowohl den Entwicklungs- als auch den Master-Zweig zu pushen, um diesen Teil des Problems zu beheben.

Wenn es einen Remote-Master gäbe, wäre es nützlich, diese Frage an diesem Punkt zu stellen, und sollte für jemanden nicht allzu schwierig sein, ihn zu implementieren. Es ist ein einfacher Fallback und hat keinen Einfluss auf den Arbeitsablauf anderer, wenn sie den Master-Branch selbst erstellen.

So sind wir auf das Problem gestoßen. Die meisten unserer Entwicklungen in unserem Git-Repo befinden sich derzeit in Feature-Zweigen außerhalb von Develop.

Ich hatte "develop" als Standardzweig des Repositorys auf github festgelegt. Ich wollte an einem Feature-Zweig einer neuen Maschine arbeiten. Ich habe das Repo geklont, "git flow init" ausgeführt und es ist fehlgeschlagen.

@lorin Dies zeigt, dass es eine

Ein Teil dieses Problems kann sein, dass git möglicherweise nur einen einzelnen Branch abruft, wenn Sie git clone ausführen, und wenn Sie den GitHub-Standard-Branch auf etwas anderes als master setzen, wie ich es auch tue, dann wird master nicht da sein eine Remote-Referenz, bis Sie git fetch origin ausführen (glaube ich). Wenn dies bei vielen der Fall ist, muss der Commit, der die Änderung für git-flow-init hinzugefügt hat, um die Überprüfung auf Remotes/origin/master [1] zu unterstützen, möglicherweise erweitert werden, um einen "git fetch origin"-Aufruf hinzuzufügen, bevor überprüft wird, ob der Meister existiert.

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

dann ist master nicht als Remote-Referenz da, bis Sie git fetch origin ausführen (glaube ich).

Der git clone-Vorgang klont das Repository buchstäblich, wie im Folgendes tun:

git checkout -b master origin/master

git erstellt Ihnen den lokalen Branch namens master als Kopie von origin/master.

Notiz:

git checkout master

ist ausreichend, als ob der Zweig nicht gefunden wird, aber ein Tracking-Zweig vorhanden ist, der verwendet wird.

@kasterma danke!

$ 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

Um die lokale Filiale zu erhalten:

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

Führen Sie nun git flow init wie gewohnt aus.

$ git flow init

git config gitflow.branch.master master, um Ihren Master-Branch richtig einzustellen, wenn Sie eine Git-Flow-Init nicht "abbrechen" können.

Hier das gleiche, ich habe das gleiche Problem.

+1 gleiches Problem

+1

Bin gerade darauf gestoßen. Garrrgh! +1

Stellen Sie sicher, dass Sie den Master mindestens einmal in Ihrem lokalen Repository auschecken.

Werde ich, danke

Am 18. November 2016, 18:41 Uhr, schrieb "Rob Moore" [email protected] :

Stellen Sie sicher, dass Sie den Master mindestens einmal in Ihrem lokalen Repository auschecken.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/nvie/gitflow/issues/121#issuecomment -261593726 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AVuyNjaPvHr8jyO9Zmy1bzynI0mhm0F_ks5q_eNRgaJpZM4AD0E_
.

+1 ist mir auch passiert.

hat die folgenden Schritte ausgeführt, um das Problem bei geklonten Repositorys zu beheben

 git checkout -b master
 git checkout develop
 git flow init

Mein TeamCity CI-Prozess kann einen Build in ein _git flow release_ über _ant_-Skripte einschließen, aber ich habe dabei gelernt, dass es notwendig war, sowohl master als auch develop auszuchecken und dann die Standardinitialisierung auszuführen vor dem Bau:

git flow init -d

Wäre es nicht am klügsten, den anfänglichen Master-Zweig zu verfolgen, z
git checkout -t origin/master

funktioniert bei mir! Danke schön

Die Lösung ist:
-git ckeckout master
-git checkout entwickeln
-git flow init

@andres310597 Das könnte die Antwort für Sie sein. Bei meinem Repo hat es nicht geholfen.

➜  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]

Und meine .gitconfig Datei enthält keinen Verweis auf eine Flow-Einstellung. Ich weiß also nicht, wo die Werte gespeichert werden.

Die Tatsache, dass dieses Problem seit 9 Jahren offen geblieben ist, sagt viel über unsere Chancen aus, dass es bald gelöst wird. Ich habe jedoch die Standardeinstellungen akzeptiert und diese Nachricht erhalten:
To force reinitialization, use: git flow init -f
Es ist also nicht kaputt. Ich denke, es ist nicht gut dokumentiert. Jemand sollte dieses Problem wahrscheinlich schließen.