Vogliamo una nuova assunzione per lavorare su alcune funzionalità del nostro attuale progetto, tuttavia, dal momento che è una nuova assunzione, vorremmo fare una revisione del codice prima che possa impegnarsi in un ramo principale. Inoltre, non vogliamo che le sue modifiche vengano rifiutate dalla nostra revisione del codice e inserite nella cronologia.
Quale sarebbe il flusso di lavoro git ideale per questo? (Penso che sia abbastanza comune?)
Questo è quello che faccio per garantire una cronologia Git pulita. Potrebbe esserci un modo più veloce per ottenere la stessa cosa con meno comandi. In breve:
Diverse persone sosterranno che lo schiacciamento commette è cattivo; questo funziona per me. Fai tutto ciò che funziona per te.
Inizia un nuovo ramo per la funzione:
git checkout -b some_user/some_feature
Scrivi un codice.
Aggiungi modifiche al ramo:
git add .
git commit -m "I did some stuff."
Scrivi un codice.
Aggiungi modifiche al ramo:
git add .
git commit -m "I did some more stuff."
Verifica le modifiche.
Aggiorna master:
git checkout master
git pull origin master
Torna al ramo della funzione:
git checkout some_user/some_feature
Schiaccia i commit della funzione in un singolo commit:
git rebase -i HEAD~2
Rebase il commit sul master per assicurarti che l'unione sia rapida:
git rebase master
Gestisci eventuali conflitti di fusione.
Unisci la funzione in master:
git checkout master
git merge some_user/some_feature
Invia al server:
git push origin master
Elimina il ramo della funzione:
git branch -d some_user/some_feature
We want a new hire to work on some features of our current project, however, since he is a new hire, we would like to do code review before he can commit into master branch.
Crea un ramo di funzione separato (o diversi, se questa persona lavorerà su più funzioni non correlate) con git branch comando. Periodicamente unisci da master al / i ramo / i della feature (ovvero, esegui git merge master stando in piedi su il ramo delle caratteristiche). Una volta esaminato il codice, unisci i branch (o le feature) in master (esegui git merge feature stando su master ).
Alcune persone ti diranno di usare rebases invece di fondersi in alcuni o in tutti i casi. Un rebase trasforma la tua cronologia in una linea retta, in modo che questo:
A ----> B
\
\
---> C
... diventa questo (C è ribasato su B, creando C '):
A ----> B ----> C'
... piuttosto che questo (C è unito a B, creando D):
A ----> B -----> D
\ /
\ /
---> C ---
La cronologia rebased è più facile da leggere e (marginalmente) più semplice da bisect , ma può fornire un'immagine meno accurata di come è stato sviluppato il tuo codice, il che potrebbe rendere più difficile ragionare su ciò che è realmente accaduto. Il rebasing è anche più complicato se il commit che si sta ridefinendo (C nel nostro esempio) è già stato spinto o estratto in un altro repository, mentre la fusione non presenta questo problema. In definitiva, dovrai decidere autonomamente quale sia la linea di condotta più appropriata per il tuo caso d'uso.
Also, we don't want his changes which is rejected by our code review and get into the history.
Elimina il ramo (con git branch -D feature ) senza unirlo in master , e attendi Git a garbage collector l'orfano si impegna automaticamente. Nota che i cambiamenti sono andati per il meglio, quindi assicurati di non volerli più conservare prima di eseguire questo comando.
Se elimini accidentalmente il ramo sbagliato e noti immediatamente il problema (o subito dopo), puoi recuperarlo dal reflog .