spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Der andere Fall, in dem du das per Hand machen musst, nennt sich dann Konflikt.

Beispiel:

Originalzeile:
int x = 42;

Entwickler A ändert die Zeile wie folgt:
int x = 1337;

Entwickler B ändert unabhängig davon die Zeile wie folgt:
int x = 4711;

Das gibt nun einen Konflikt, und jemand muss per Hand entscheiden, was beibehalten werden soll.
Bei Nicht-Text-Dateien (z.B. Bild- oder Audiodateien) gibt es quasi immer Konflikte. Automatisches Merging funktioniert soweit ich weiß nur bei Textdateien und nur zeilenbasiert.

Nochmal etwas detaillierter:
- Ändern A, B und C in verschiedenen Dateien, ist der Stand am Ende der von allen dreien zusammen. Hierbei müssen sie vorher kein Update vor dem Commit ziehen.
- Ändern A, B und C (zusätzlich) in gleichen Dateien, aber in unterschiedlichen Zeilen, ist der Stand am Ende ebenfalls der von allen dreien zusammen. Hierbei müssen sie ein Update vor dem Commit ziehen.
- Ändern A, B und C in gleichen Dateien und gleichen Zeilen, gibt es Konflikte. Sie müssen hierbei vor dem Commit ein Update ziehen und die auftretenden Konflikte manuell bereinigen (Zeilen korrigieren und als Solved markieren - Tortoise ist dabei sehr hilfreich). Hier gilt zudem der Grundsatz, dass der erste immer gewinnt und die danach dann Mergen und Konflikte beheben müssen. Sollte man möglichst vermeiden, dass Entwickler an denselben Dateien *und* Methoden herum fummeln müssen und die Aufgaben besser trennen. Dann tritt das erst gar nicht auf.

Um das mal mit trunk/Tag/Branch zu erklären.
Also Trunk ist die aktuelle Version. Sagen wir mal v1.2. An der arbeiten alle Entwickler. Dann gibt es den Branch.
Meistens wird der vor einem Livegang einer Version erstellt. Eigentlich ist ja irgendwann mal "Code Freeze".
Dann wird der aktuelle Trunk zum Branch v1.2 und der Trunk zu v1.3 beispielsweise.
Alle arbeiten weiter an neuen Features und im Branch werden noch Bugs für den Livegang gefixed.
In vielen Firmen ist es dann noch üblich, dass z.B. einmal automatisch Nachts alles gebaut wird.
Der Stand im SVN bekommt dann einen "Tag" wie "2013_12_24" oder was auch immer. Dann können
Leute wie die QA beispielsweise tagsüber mit einem definierten Stand testen (falls der überhaupt geht)
und müssen nicht immer auf den Trunk gehen. Denn der Trunk kann ja auch mal kaputt sein.

@buggypixels:
Das ist eine Möglichkeit, wie man Branches verwenden kann

Grundsätzlich sind Branches Abzweigungen der Entwicklung, was wiederum die unterschiedlichsten Gründe haben kann.
Einer wäre, dass man einen Stand erreicht hat, dem keine neuen Features ergänzt werden sollen, in dem sich aber durchaus noch die einen oder anderen Fehler befinden können bzw. an dem später noch Änderungen durchgeführt werden können (was buggypixels beschrieben hat).
Eine andere Möglichkeit wäre aber, dass ein Feature implementiert werden soll, welches die Entwicklung der anderen Features aber nicht beeinträchtigen soll, was ich wiederum bei uns auf Arbeit eher mal beobachten kann.