Sto lavorando attivamente a un progetto a due persone con pochissime filiali di funzionalità di lunga data (il ramo più lungo esistente è di 3 settimane).
Ho passato il pomeriggio a cercare di capire merge vs rebase e quali sono i vantaggi e gli svantaggi. Ho fatto alcuni progressi e ho in programma di incorporare rebase per ripulire i miei commit locali prima di passare a github per una revisione del codice. Mi piace commettere spesso e ho eseguito test automatici, quindi sembra che l'argomento principale contro rebase che potrebbe introdurre bug per i commit rebased non è rilevante. Mentre ho visto alcuni argomenti contro questo tipo di ribellione sembra meno controverso. La mia confusione riguarda la ridefinizione e l'unione di un ramo di funzione in master dopo che la revisione del codice è stata completata. So che nessun altro si basa su di esso e il processo di revisione del codice ha generato molti piccoli commit di sintassi senza senso. Entrambi sembrano suggerire una ridefinizione.
La mia comprensione è che per il mio progetto rebase ha il vantaggio di mantenere pulita la cronologia, il che mi consente di vedere riassunti migliori in merito al motivo per cui è stata introdotta una modifica. Aiuta anche a mantenere lineare la cronologia, che rende più facile l'uso di git bisect (si tratta di una cronologia lineare o del fatto che ogni commit è completo e non intenzionale). Permette anche correzioni al mio esempio corrente in cui ho dimenticato di rinominare e modificare un file in commit separati prima di inviare una richiesta di pull, portando a una grande diff non necessaria. Per questo progetto nessuno di questi sembra essere uno svantaggio nell'uso del workflow git-merge (il codebase potrebbe non essere abbastanza grande per sperimentare i veri svantaggi) ma sarebbe bello avere se non ci fossero grossi svantaggi.
Gli svantaggi che vedo sono che non sono un esperto di git e sembra molto più facile spezzare le cose con rebase che con l'unione. In secondo luogo, facciamo un sacco di commenti attivi sulle richieste di pull in github e sono titubante a rompere o perdere quei commenti ribasando e cambiando lo SHA (a pensarci bene non credo che perderò i commenti ma lo faranno non fare più riferimento ai commit corretti, quindi dovrei dare la caccia ai commit riferiti con altri mezzi). Terzo, dà l'illusione che ogni commit sia un commit logico completo e funzionante quando in realtà probabilmente avrò ancora dei commit parzialmente interrotti.
In questo articolo su unire contro rebase danno il seguendo i consigli su questa situazione:
Review is done and ready to be integrated into the target branch. Congratulations! You‘re about to delete your feature branch. Given that other developers won’t be fetch-merging in these changes from this point on, this is your chance to sanitize history. At this point you can rewrite history and fold the original commits and those pesky ‘pr rework’ and ‘merge’ commits into a small set of focussed commits. Creating an explicit merge for these commits is optional, but has value. It records when the feature graduated to master.
Sono molto interessato a sapere se la mia analisi precedente è sulla strada giusta. In questo momento mi sto orientando con cautela a usare rebase come descritto nel precedente consiglio. Ma sono persino confuso su come effettivamente fare ciò che suggeriscono. Come posso creare un'unione esplicita? Creo un ramo locale che è una copia di feature e quindi rebase -i su quel ramo per far apparire la cronologia come voglio e quindi unire con il master? Oppure rebasso feature direttamente sul master e poi uso rebase -i per schiacciare i commit in modo appropriato. Se questo approccio è ciò che stanno suggerendo, come faccio a creare un'unione esplicita alla fine?