Perché non commettere modifiche non risolte?

Il problema più grande che riesco a vedere è che crea una finestra di commit in cui le cose sono parzialmente unite e (probabilmente) non funzionano correttamente. Quando premi il set finale di commit locali, tutti questi commit intermedi appariranno anche per tutti gli altri. Nel mondo ideale, dovrei essere in grado di eseguire qualsiasi commit e il codice dovrebbe funzionare. Se inizi a commettere nel mezzo di unioni, lo stato del codice non è ben definito.

Una cosa che potresti fare è rendere i commit locali alla tua fusione, e poi raggrupparli in un grosso commit quando premi (anche se non sono sicuro di come (se?) qualsiasi vcs supporti questo). Anche se questo potrebbe produrre alcuni dei vantaggi che hai menzionato, non sono sicuro che valga la pena di una complessità extra (stiamo già affrontando un'area abbastanza confusa e complessa).

Sono più familiare con Git, quindi risponderò per quella prospettiva.

Non vedo un motivo per cui o qualsiasi VCS valido vorrebbe consentire il commit di un file non diviso, in particolare se si tratta di codice. È necessario mantenere il repository in uno stato coerente e ciò che si suggerisce violerebbe l'atomicità del commit. Molti VCS cambiano fisicamente il file per mostrare dove sono i conflitti: Git, SVN e CVS usano > > > > < < < < marcatori di tipo. In un VCS con livello di repository atomico si commette e si fonde, avresti creato un nodo che non ha senso per nessuno tranne te. Nello sviluppo del software, il tuo progetto non può essere realizzato. Nel documento di un gruppo, nessuno sa quali modifiche siano corrette.

Ora Git fornisce alcuni strumenti che potrebbero facilitare questo, se fosse il tipo di commit che suggerisci consentito. Ad esempio, potresti schiacciare tutti i fusioni prima di spingerti. Che finisce per essere lo stesso di un tipico commit di unione.

Preoccupazioni specifiche sul tuo elenco di vantaggi:

1. Le modifiche di unione effettive sono nella cronologia. Perché hai bisogno di ulteriori informazioni? I DVCS sono molto utili per limitare i conflitti in aree confinate. Una volta scelto quale changeset conservare, confrontare la copia del nodo di commit di fusione con la copia precedente ti darà esattamente questo.
2. Se l'unione era molto grande, potresti eseguire commit periodici. Questa è una preoccupazione valida, ma non dovresti mai arrivare qui in primo luogo. Le diramazioni dovrebbero costantemente trainare i cambiamenti a monte proprio così non succederà mai. Strumenti come rebase o cherry-pickking un commit alla volta possono anche aiutarti in alcune situazioni.
3. Se hai commesso un errore, sarebbe molto più facile eseguire il rollback (senza dover ripetere l'intera unione). Vedi sopra - i tuoi conflitti non dovrebbero diventare così ingestibili.

L'unico modo in cui questo suggerimento potrebbe funzionare è se il ramo fosse se l'intera unione fosse atomica - potevi vedere una serie di commit, ma sarebbero semplicemente passi in un commit di fusione più grande che doveva essere trattato come un nodo in l'albero di commit. Non credo che nessun VCS attuale abbia supporto per questo tipo di flusso di lavoro, e non penso sia necessario.

La mia esperienza principale riguarda Mercurial, anche se uso sporadicamente git.

Mercurial non ti impedisce di eseguire il commit di file non risolti, ma ti scoraggia . Lo stesso accordo con la spinta prima di tirare le modifiche che non hai.

Tutto ciò che devi fare in Mercurial è, una volta che hai i file nel modo in cui vuoi impegnarli:

hg resolve --mark --all
hg commit -m "I'm such a rebel"

- contrassegna ... contrassegna i file come risolti senza richiedere lo strumento di fusione. --tutto si occuperà di selezionare tutti i file contrassegnati con conflitti.

Se vuoi spingere senza tirare (e di conseguenza devi unire le altre modifiche) fai come un Jedi :

hg push --force

Il prossimo tizio che tira otterrà +1 testa (nessun gioco di parole)

Sono sicuro che c'è un modo per fare le stesse cose con Git (anche se probabilmente è più contorto).

Quando mi unisco in git, commetto immediatamente tutte le modifiche (inclusi i conflitti di unione). Quindi, nel mio prossimo commit (s), risolvo i conflitti di fusione tramite un editor di testo. Dopo che i conflitti sono stati risolti, posso quindi premere se lo desideri.

Onestamente non capisco perché gli altri non lo fanno in questo modo, o git non lo impone.

• Il "merge commit" ora è una cronologia pulita di esattamente ciò che è necessario unire.
• I seguenti commit mostrano esattamente ciò che hai fatto per risolvere i conflitti di fusione.
• Quando fai Push, i conflitti vengono risolti e la build ininterrotta sulla punta del ramo.
• In qualsiasi momento, se rovini la risoluzione del conflitto, puoi semplicemente tornare a uno dei commit "post fusione" e riprovare.

Un enorme svantaggio del flusso di lavoro standard di risoluzione dei conflitti prima di commit è che le modifiche dalla tua copia locale possono introdursi. Le aggiunte sono nascoste dalla revisione del codice da parte del massiccio diff, quindi non lo fai t noti che hai impegnato accidentalmente una chiave API o ecc.

Il mio flusso di lavoro sopra descritto evita questo problema di copia locale e consente anche ai revisori del codice di esaminare (solo) i dettagli della risoluzione di fusione in una differenza di commit che assomiglia esattamente a una differenza di commit standard.

Penso che sia meglio spingere piccole modifiche e spingere spesso, quando è possibile (e ovviamente non lo è sempre), e non codice di commit che non genera, o è mezzo completo (tutti commettiamo errori, ma non lo facciamo apposta). Vengo anche da Git, e una delle cose migliori che penso è il fatto che si può avere una copia funzionale del repository sul desktop ... che è possibile modificare sul contenuto del tuo cuore. Quando i tuoi grandi cambiamenti sono fatti, mandalo via.

Fare un sacco di open source con git la più grande frustrazione per me è stato far passare il codice mezzo fatto nel repository e provare a fare una build, ma non potevo, perché il ragazzo ha fatto metà del lavoro e ha detto "I" m occupato ora, lo finirò in una settimana ". Quindi finirò per doverla scartare (cosa che infastidirebbe il ragazzo), o prendere il tempo per finire e integrarlo completamente.

Credo che dal mio punto di vista, mantieni localmente le cose a mezzo culo, manda la roba buona sul filo.

Non essere schiavo dei tuoi strumenti.

L'obiettivo di un VCS è di consentirti di svolgere il tuo lavoro. Il tuo lavoro è non per mantenere un repository locale incontaminato, il tuo compito è scrivere codice. Se ti impegni presto e spesso localmente ti consente di lavorare meglio, fallo.

Non dovresti, tuttavia, spingere codice rotto a monte.

Perché fondamentalmente è una cattiva idea - ti condurrà a un repository che è in uno stato di parolacce (e la sua eruzione a presumere che tu spingerai mai ovunque, anche se qualcuno sosterrebbe che dovresti sempre avere almeno una copia ).

Riesco a vedere che nel caso di un'unione complessa / complessa potresti voler salvare il tuo lavoro in corso e stabilire un punto di riferimento, ma avresti comunque lasciato il sistema in uno stato incasinato che deve essere risolto .

E ci sono alternative - hai la possibilità di unirle da prima della testa - che potrebbe darti la possibilità di adattarti alle modifiche senza unioni epiche (o almeno con fusioni più grandi che sono più facili da comprendere).

Questo è il caso in cui trovo che git's rebase è particolarmente utile (soggetto ai soliti avvertimenti sulla ridefinizione) perché stai riproducendo le tue modifiche in cima allo stato corrente in cui risolvi i conflitti in parti più piccole.