Ist es gut, Dateien oft zu übertragen, wenn man Mercurial oder Git verwendet?

Question

Es scheint, dass es vorgeschlagen wird, dass wir oft committen können, um zwischenzeitliche Änderungen des Codes, den wir geschrieben haben, zu verfolgen wie auf hginit.com, wenn wir Mercurial oder Git verwenden.

Aber nehmen wir an, wir arbeiten an einem Projekt und übertragen häufig Dateien. Aus dem einen oder anderen Grund möchte der Manager, dass ein Teil des Features veröffentlicht wird, also müssen wir einen Push machen, aber ich habe gehört, dass es bei Mercurial oder Git keine Möglichkeit gibt, einzelne Dateien oder einen Ordner zu pushen entweder wird alles gepusht oder nichts. Also müssen wir entweder alle Dateien, die wir nicht pushen wollen, rückgängig machen, oder wir sollten nie einen Commit machen, bevor wir pushen - direkt nach dem Commit machen wir einen Push?

Answer 1

Der beste Weg, dies zu handhaben (unabhängig davon, ob Sie Mercurial, Git oder ein anderes Revisionskontrollsystem verwenden) ist es, sicherzustellen, dass Ihre Arbeit in Zweigen durchgeführt wird, die diesen "Teilen von Funktionen" entsprechen. Wenn es auch nur eine kleine Chance gibt, dass ein Teil der Arbeit unabhängig von anderen Arbeiten freigegeben werden muss, sollte er sollte er von Anfang an einen eigenen Zweig haben.

Dies gibt Ihnen die Flexibilität, nur den "Teil des Feature" zu schieben, und ist viel besser geeignet, wenn der "Teil Teil des Merkmals" und ein anderer "Teil des Merkmals" beide Änderungen an der gleichen Datei enthalten.

Das Schöne an der Verwendung von Mercurial oder Git ist, dass die Verwaltung von Verwaltung dieser Zweige trivial ist, so dass die Kosten für die Erstellung und Verwendung (selbst wenn sie sich als nicht notwendig erweisen) minimal sind.

Nun kann man nicht immer alles vorhersehen. Wenn Sie in der von Ihnen beschriebenen in der von Ihnen beschriebenen Situation stecken, kann man sich aber leicht entkommen. Angenommen, Sie haben lokal 100 Änderungssätze (noch nicht auf dem Server) und wollen nur den aktuellen Inhalt von 1 Datei pushen. Erstellen Sie einen Klon des Projektarchivs, an dem Sie arbeiten, zurück zur Serverrevision, kopieren die Datei rüber, Commit, Push und Integration zurück. In Mercurial würde dies etwa wie folgt aussehen:

$ cd ~/project
$ hg clone http://server/project/trunk trunk-oops
$ cp trunk/shouldve-branched trunk-oops/shouldve-branched
$ cd trunk-oops; hg addrem; hg ci -m "We need to organize better!"; hg push
$ cd ../trunk; hg fetch ../trunk-oops

Answer 2

Entwicklung auf Zweigen.

Sie haben einen Versionszweig und Funktionszweige. Führen Sie jede Funktion ein, sobald sie verfügbar ist.

Answer 3

Es ist eine gute Praxis, sich oft zu verpflichten. In Ihrem Fall scheint es so, als müssten Sie öfter mit dem Taggen und/oder Verzweigen beginnen.

Answer 4

Um das, was andere gesagt haben, zu erweitern und zu verdeutlichen: Häufiges Engagement und flexibles Drängen schließen sich nicht gegenseitig aus.

Sie sollten vorausschauend planen und Ihre Zusagen so gestalten, dass Sie in der Lage sind, sich anzupassen. Das bedeutet zweierlei: Sie müssen sicherstellen, dass Sie wirklich oft committen, und Sie müssen häufig verzweigen (wie in Git). Wenn Ihre Commits klein sind, ist es einfacher, sie später zu reorganisieren, wenn Sie Teile Ihrer Arbeit selektiv zusammenfassen müssen. Und wenn Ihre Zweige gut organisiert sind, haben Sie vielleicht schon einen Zweig, der genau dem entspricht, was Sie veröffentlichen wollen.

Vergleichen Sie diese beiden:

One branch, few commits:

- A1 - B1 - C1 - B2 - A2 - B3 - C3 (master)

Many branches, many commits:

  M1 - M2 (master)
 /
o - A1 - A2 - A3 - A4 - A5 - A6 (topicA)
|\
| B1 - B2 - B3 - B4 - B5 - B6 - B7 (topicB)
\ 
 C1 - C2 - C3 - C4 - C5 (topicC)

Wenn Sie nun eines dieser drei Themen so wie es ist veröffentlichen wollen, müssen Sie es nur noch mit Master zusammenführen und veröffentlichen! Wenn Sie die Hälfte von ThemaA freigeben wollen, und diese Hälfte ist in den Commits A1, A3, A4 und A6 enthalten, müssen Sie nur ThemaA umbasen, um diese vier Commits an die erste Stelle zu setzen, den letzten von ihnen in Master einbinden und pushen. Der Rest von topicA (A2 und A5) kann für die weitere Arbeit herumliegen.

  M1 - M2 ------------- X (master)
 /                     /
o - A1 - A3' - A4' - A6' - A2' - A5' (topicA)

(Commits, die mit A1', ... bezeichnet werden, weil bei Git zwei Commits mit demselben Inhalt, aber verschiedenen Elternteilen, eigentlich verschiedene Commits sind).