Arbeiten im Team

[vagtler]

Wenn es nicht mehr als 5 Benutzer sind, bietet sich auch https://bitbucket.org/plans/ an, wo ich ein Git-Hosting mit privaten Repositories kostenfrei erhalte.

[Perlsau]

Da hätt ich doch mal eine Frage, die mich immer wieder mal kurz beschäftigt, obwohl ich selber ja nur lokal als einziger an meinen Projekten arbeite:

Wie wird das mit GIT gehandhabt, wenn zwei oder mehr Entwickler dieselbe Unit bearbeiten? Sperren, wie Captnemo das oben andeutet, ist ja mit GIT nicht möglich, weil man ja offline am lokalen Repository arbeitet. Das kann (oder muß) doch zu Konflikten führen, wenn die Bearbeitung derselben Pas-Datei vorher nicht genau abgesprochen wurde. Sollte man das zeitgleiche Bearbeiten derselben Datei durch verschiedene Programmierer dann nicht eher vermeiden?

[TheMiller]

Der Vorteil gegenüber einer eigenen privaten Lösung ist der, dass die Quelltexte keinem anderen Unternehmen in Amerika und Co. anvertraut werden. Natürlich muss der eigene Server dann relativ sicher sein. Es empfiehlt sich dann auch, keine Domain dafür zu registrieren, sondern es bei der Standard-Hostindomain "[e-mail]" (wie auch immer) zu belassen.

Lokal brauchst du dann übrigens einen GitClient zB SourceTree. Sehr und und kostenlos.

[TheMiller]

Git führt die Dateien per Diff zusammen. Bei Konflikten kann man alles selbst bestimmen, welche Version übernommen wird. In der Regel kommt es aber nicht zu Problemen, da diff beide Dateien zu einer zusammenführt.

[Perlsau]

Zitat von DJ-SPM:

Git führt die Dateien per Diff zusammen. Bei Konflikten kann man alles selbst bestimmen, welche Version übernommen wird. In der Regel kommt es aber nicht zu Problemen, da diff beide Dateien zu einer zusammenführt.

Ich meinte auch nicht Konflikte beim Committen, sondern für das Projekt selbst: Wenn sich z.B. der eine Entwickler auf einen Methode bezieht, deren Parameter der andere Programmierer geändert hat, dann läßt sich das Projekt doch gar nicht mehr kompilieren.

[TheMiller]

Das liegt ja in der Natur der Sache. Da muss man halt entweder feste Bereiche definieren, wer wo programmieren darf, die anderen im Wiki benachrichtigen oder eben neue Methoden via overload deklarieren.

[Perlsau]

Okay, danke für die Bestätigung, so hab ich mir das auch zusammengereimt, wollte es aber mangels eigener Erfahrung mal von jemand anderem hören/lesen

[Neutral General]

Im Normalfall arbeiten aber auch nur selten mehrere Leute an einer Unit.
Ich weiß nicht wie das bei GIT ist aber in SVN kann man auch Dateien blockieren. Diese können dann solange nicht von anderen commited werden solange die Datei blockiert ist.
Ansonsten kann GIT/SVN meistens die Arbeit der beiden Personen mergen, wenn sie nicht wirklich an exakt der gleichen Stelle Sachen hinzugefügt/geändert haben.

Und ein wenig Absprache sollte/muss sowieso vorhanden sein. Wenn jeder nur sein Ding durchzieht ohne Absprache wird das natürlich nichts.

[Lemmy]

Zitat von Neutral General:

Im Normalfall arbeiten aber auch nur selten mehrere Leute an einer Unit.

Arbeiten an einer Unit sind unproblematisch (zumindest mit git und co) - abreiten mehrere an der selben Zeile kann das kein VCS richtig zusammen bringen.

Eine Sperre in git kann es nciht geben, da es keinen zentralen Server gibt, der das regeln könnte - lokale Arbeitsbranches könnten damit eh nicht "erschlagen" werden.

[jobo]

Zitat von Perlsau:

Wenn sich z.B. der eine Entwickler auf einen Methode bezieht, deren Parameter der andere Programmierer geändert hat, dann läßt sich das Projekt doch gar nicht mehr kompilieren.

Der Austausch der geänderten (commited) Dateien erfolgt erstmal nicht automatisch. Wenn irgendein Entwickler irgendeinen (auch speziellen) Stand vom Github oder so (auch dem eigenen Source Server) gezogen hat, kann er jahrelang dagegen arbeiten, weil er selbst gegen eine lokale Kopie arbeitet. Was andere Entwickler machen, interessiert also nicht direkt.
Erst wenn man Aktualisierungen (z.B. die neueste) oder ein bestimmten Stand oder Branch anfordert, wird das lokale Repository geändert.
Man muss sich mit der Arbeitsweise etwas umgewöhnen. Vor Jahren, habe ich immer Zwischenstände in anderen Verzeichnissen gesichert und all sowas (oder die Krise gekriegt mit VSS). Das muss man so nicht mehr machen. Man kann Schritt für Schritt committen, hochladen, runterladen, "vor- und zurückspulen" oder Branches anlegen, wenn man neue Interfaceversionen beginnt.
Im Prinzip arbeitet man immer mit 2 Source "Versionierern", dem (entfernten) Server und dem lokalen Abbild. Beide halten immer alle Versionen, zumindest der Server und man bestimmt, welche Variante im Projektverzeichnis bearbeitet wird oder auf den Server geschrieben wird.