Git - Nur einen Branch (z.B. Master) in ein Repository pushen

[White_Fox]

Moin

Angenommen, ich hätte ein Git-Repository auf z.B. Sourceforge, klone es damit ich eine lokale Kopie habe, ändere darin irgendwas und will per Push nun meine Änderungen wieder auf das Repository auf SF hochladen: Schmeißt Git dann alles, also auch Branches die ich neu angelegt und schon mit dem Masterbranch zusammengeführt habe, in das SF-Repository, oder nur den Masterbranch?

Wenn ja: Kann ich Git dazu bringen, nur z.B. den Masterbranch auf das Git-Repository zu pushen?

 

[KonradN]

Es sollte nur der Branch gepusht werden, in dem du bist. Die anderen lokalen Branche werden da nicht mit gepusht.

 

[mrBrown]

Gesetzt wird es btw über diesen Config-Parameter: https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushdefault

 

[khmarbaise]

Ein einfaches:

git push origin master

macht genau das.

 

[DefconDev]

Lad dir SourceTree oder ähnliches und dann siehst du sehr schnell welchen Branch du ausgescheckt hast bzw. auf welchem du gerade arbeitest. Mach dich vertraut mit dem Unterschied von Commit und Push und dir wird schnell klar, dass nur das auf dem Server landet was du am Ende des Tages gepushed hast.

Beim Initial-Push deines lokalen Branch musst du bei den meisten Programmen wie SourceTree nur darauf achten, zu welchen Remotebranch, also der Branch auf dem Git- Server gepushed wird. In der Regel wirst du kurz vor dem pushen gefragt, da ein bisschen aufpassen.

 

[khmarbaise]

@DefconDev Wozu braucht man da SourceTree?
Ein:

git branch

liefert Dir, auf welchem Branch Du dich befindest...(Wird durch "*" markiert.).
Oder:

git status

liefert Dir die Info ebenfalls.

 

[DefconDev]

Vielleicht möchte der TE auch andere Sachen machen? Also eine Git History grafisch darzustellen, kann auch ganz nett sein.

 

[White_Fox]

Vielleicht möchte der TE auch andere Sachen machen?

Nö...ich habe mit git nur noch nie gearbeitet und überlege, es mal einzusetzen.

 

[KonradN]

Nö...ich habe mit git nur noch nie gearbeitet und überlege, es mal einzusetzen.

Da kann ich nur empfehlen, einfach mal in eines der freien Git Bücher zu schauen:

Git - Book

git-scm.com

Das deutsche Git-Buch

gitbu.ch

Das ist zum einen gut, um einen besseren Überblick zu gewinnen (a.la. "Was ist die Staging Area?") und ist existenziell, sobald es um das Branchen und Mergen geht (Ansonsten gibt es nur noch mehr Threads a.la. "Git ist fehlerhaft - das hat Änderungen verworfen!" da man bei einem Merge einfach eine vorhandene Änderung gnadenlos überschrieben hat ...)

Aber Git ist unter dem Strich sehr einfach und auf Grund der hohen Verbreitung ist es vom Tooling her extrem gut unterstützt.

 

[White_Fox]

Danke für die Links. Vielleicht schaue ich da mal rein, ansonsten habe ich vor einiger Zeit mal ein sehr gutes Buch über git gelesen und zumindest die ungefähre Arbeitsweise ist sogar bei mir hängengeblieben.
Allerdings eher aus Neugier, weil zwar einige Kollegen meinten git wäre klasse, warum genau konnte mir aber niemand sagen. Naja...jedenfalls habe ich damals den Umstieg auf git verworfen weil es mir damals keine oder nur sehr geringe Vorteile gebracht hätte. Aber das wird jetzt vielleicht anders.

 

[LimDul]

Für einen alleine ist es relativ egal, was man nimmt. In größeren Teams bietet git einige Vorteile:

• Funktionierendes Branching Model (in CVS ist das quasi gar nicht vorhanden, in SVN rudimentär)
• Möglichkeit lokal zu commiten und konsolidiert Änderungen zu pushen
• Mittels Pull-Requests saubere Mechanismen für Reviews & Co
• Unglaublich mächtiges Tooling (aber auch in Teilen leider komplexes Tooling) um eigentlich alles, was man machen will, lösen zu können und im Fehlerfall korrigieren zu können.

 

[khmarbaise]

Für einen alleine ist es relativ egal, was man nimmt. In größeren Teams bietet git einige Vorteile:

Die Team Größe hat hier keinen einfluss. Ob ich nun mit Git oder SVN arbeitet. Das ist egal. Das Problem was SVN in der Zwischenzeit hat ist, dass in einigen Bereichen die Toolunterstützung nicht mehr auf dem aktuellesten Stand ist (z.B. IDE's/CI/CD usw.) Das ist viel mehr ein Argument.

Funktionierendes Branching Model (in CVS ist das quasi gar nicht vorhanden, in SVN rudimentär)

Die Aussagen sind nicht wirklich korrekt. In CVS konnte (kann) man branchen und aber nur in eine Richtung mergen. (keine "rebase" / "sync" merge Möglichkeit).

In SVN ist Branching / Merging vorhanden und funktioniert. (Es ist deutlich anders als in Git, dass liegt aber am konzeptionellen Unterschied).

Möglichkeit lokal zu commiten und konsolidiert Änderungen zu pushen

Wenn wie typischerweise mithilfe eine Feature Branches arbeitet (Feature Branches sind u.U. Problematisch!) ist lokales Committen nicht wirklich Notwendig. Bei git kann ich halt meine Commits vor dem "push" noch Bearbeiten und "schön" machen. Technisch ist das aber nicht unbedingt nötig.

Mittels Pull-Requests saubere Mechanismen für Reviews & Co

Pull-Requests als Mechanismen für Reviews sind eigentlich das Gegenteil, weil das CI/CD verhindert. In der Zwischenzeit wird sehr viel mit sog. main-based Entwicklungsmodellen gearbeitet (Reviews sollten in Form von Pair Programming durchgeführt werden).

 

[LimDul]

Die Team Größe hat hier keinen einfluss. Ob ich nun mit Git oder SVN arbeitet. Das ist egal. Das Problem was SVN in der Zwischenzeit hat ist, dass in einigen Bereichen die Toolunterstützung nicht mehr auf dem aktuellesten Stand ist (z.B. IDE's/CI/CD usw.) Das ist viel mehr ein Argument.

Worauf ich hinauswollte - alleine profitiert von einen Version Control System (nach der Historieriserung) relativ wenig. Da ist es ziemlich egal was nimmt. Die Stärken spielen alle erst bei der Zusammenarbeit aus.

Die Aussagen sind nicht wirklich korrekt. In CVS konnte (kann) man branchen und aber nur in eine Richtung mergen. (keine "rebase" / "sync" merge Möglichkeit).

Was "quasi keine Unterstützung" ist aus meiner Sicht.

In SVN ist Branching / Merging vorhanden und funktioniert. (Es ist deutlich anders als in Git, dass liegt aber am konzeptionellen Unterschied).

Jepp, ich find es allerdings relativ bescheiden (auch wenn es früher noch grausamer war). SVN hat erst mit Hilfe der Metadaten überhaupt nachgerüstet, dass man nachvollziehen kann, welche Revisionen wohin gemergt wurde.

Wenn wie typischerweise mithilfe eine Feature Branches arbeitet (Feature Branches sind u.U. Problematisch!) ist lokales Committen nicht wirklich Notwendig. Bei git kann ich halt meine Commits vor dem "push" noch Bearbeiten und "schön" machen. Technisch ist das aber nicht unbedingt nötig.

Klar, aber es ist nett.

Pull-Requests als Mechanismen für Reviews sind eigentlich das Gegenteil, weil das CI/CD verhindert. In der Zwischenzeit wird sehr viel mit sog. main-based Entwicklungsmodellen gearbeitet (Reviews sollten in Form von Pair Programming durchgeführt werden).

Ok, da hast du recht. Kommt auf das Entwicklungsmodell an. Wenn man eins hat, was mit Pull-Requests und Feature Branches arbeitet, spielt GIT seine Stärken aus.