Quando devo effettuare il primo commit per il controllo del codice sorgente?


118

Non sono mai sicuro quando un progetto sia abbastanza lontano da impegnarsi per il controllo del codice sorgente. Tendo a rimandare l'impegno fino a quando il progetto non sarà "completo dal punto di vista del quadro" e da quel momento in poi impegnerò principalmente le funzionalità. (Non ho fatto alcun progetto personale abbastanza grande da avere un framework di base troppo grande per questo.) Ho la sensazione che questa non sia la migliore pratica, anche se non sono sicuro di cosa potrebbe andare storto.

Diciamo, ad esempio, che ho un progetto che consiste in un singolo file di codice. Ci vorranno circa 10 righe di codice boilerplate e 100 righe per far funzionare il progetto con funzionalità estremamente basilari (1 o 2 funzionalità). Devo prima fare il check-in:

  1. Il file vuoto?
  2. Il codice del boilerplate?
  3. Le prime caratteristiche?
  4. Ad un altro punto?

Inoltre, quali sono i motivi per effettuare il check-in in un punto specifico?


10
prima di tornare a casa, ti impegni nella tua filiale di lavoro.
Reactgular,

59
Il primo commit dovrebbe sempre essere fatto dopo aver creato un progetto Sourceforge, aver creato un sito Web, configurato la mailing list e fatto blog sul progetto per diversi anni. :)
Kaz,

15
Qual è il lato negativo di impegnarsi troppo presto o spesso?
Isaac Rabinovitch il

13
mkdir myproj; cd myproj; git init; iniziare a lavorare.
Eddie B,

10
Ho imparato a gestire il salvataggio dei progressi dal pulsante di salvataggio rapido nei videogiochi. La regola è qualcosa di simile: Will I mind having to redo that part ? Save : SaveAnyway;adotto lo stesso approccio al controllo del codice sorgente, non aspetto che qualcosa funzioni o sia quasi completo, aspetto solo che non abbia capito qualcosa o fatto abbastanza cambiamenti che non voglio per provare a capirlo di nuovo o apportare di nuovo tali modifiche, quindi faccio il check-in. Ecco perché le persone suggeriscono di salvare dopo la creazione del progetto; La creazione di progetti è fastidiosa, fai il check-in in modo che non dovrai assolutamente rifarlo.
Jimmy Hoffa,

Risposte:


103

Dovresti impegnarti non appena avrai completato una "unità" ragionevole.

Cos'è un'unità? Dipende da cosa stai facendo; se stai creando un progetto Visual Studio, ad esempio, esegui il commit della soluzione subito dopo la sua creazione, anche se non contiene nulla.

Da quel momento, continua a impegnarti il ​​più spesso possibile, ma impegna ancora solo "unità" completate (ad es. Classi, configurazioni, ecc.); farlo ti renderà la vita più semplice se qualcosa va storto (puoi annullare una piccola serie di modifiche) e ridurrà la probabilità di conflitti.


27
Mi impegno costantemente vicino a un ramo del lavoro e unisco quel ramo alla linea principale in unità. Dà il meglio di entrambi i mondi in quanto la linea principale è composta da unità con piccoli gruppi di modifiche da ripristinare, ma il ramo dell'argomento può farmi tornare indietro solo un po 'alla volta.
Jeff Ferland,

16
Un commit non è mai troppo piccolo! Non trattenersi dal commettere le modifiche!
Leonardo Herrera,

1
Direi +1 a molti piccoli e frequenti commit, a seconda del flusso di lavoro e di quante persone sono interessate al tuo repository per svolgere il proprio lavoro. La capacità di Git di riscrivere un po 'la storia in modo che quei 15 impegni FooSerializerpossano diventare una cosa prima di spingere aiuta in questo.
Tim Post

1
@loldop: dipende dal software di controllo della versione che stai utilizzando. Supponiamo che tu stia usando Git: puoi riporre ciò che hai fatto, fare la correzione, impegnarlo, riapplicare le modifiche ripiene e ricominciare a lavorarci. In Subversion, puoi fare un altro checkout del repository in un'altra cartella, correggere il bug e impegnarti nel repository lì senza influire sul refactoring. Oppure crea un file patch, ripristina la modifica, correggi il bug, esegui il commit e riapplica la patch. Ci sono molti modi per farlo.
Albireo,

1
Forse è una buona risposta al 2 °, 3 ° commit ecc. Ma il primo dovrebbe essere solo vuoto.
Felipe,

143

Per quanto mi riguarda, il tuo repository di controllo del codice sorgente fa parte della configurazione di base del progetto, quindi mi impegno subito dopo aver generato il mio progetto vuoto.


29
Impegnarsi presto, impegnarsi spesso.
Leonardo Herrera,

11
Sono d'accordo con questo più della risposta accettata. Vedo anche il controllo del codice sorgente (intendo DVCS) come un grande pulsante di annullamento se rovino le cose in modo reale. Consiglio vivamente anche di usare semver (tramite tag) e di iniziare con la versione 0
Antony Scott,

2
Grazie @AntonyScott Sono d'accordo al 100% con la risposta accettata, ma quando ho scritto questo, ho avuto questa visione di confondere le acque con un saggio di 1500 parole su come gestisco il controllo del codice sorgente e perché. Così ho deciso di mantenerlo semplice e puntuale.
John MacIntyre,

2
Sì, +1. Se ti senti male per un commit vuoto, inizia con .gitignore (o equivalente) come Xion ha scritto in un'altra risposta [ programmers.stackexchange.com/a/176845/5405] . È un primo impegno molto naturale.
Hanno Fietz,

Ho notato la bandiera "risposte lunghe" sulla domanda e non posso fare a meno di pensare che si riferisca a questa risposta. AFAIC Ho risposto al "perché?" domanda con il "repository di controllo del codice sorgente fa parte della configurazione di base del progetto" parte della risposta. Come ho detto, potrei scrivere un saggio sulla mia filosofia completa su come uso il controllo del codice sorgente, ma toglierebbe solo questa risposta. Se qualcuno ha una domanda specifica sulla mia risposta, sarò felice di rispondervi, ma per il resto non voglio soffocare questa risposta per motivi di verbalità. Se vuoi eliminarlo, vai avanti.
John MacIntyre,

77

Ieri

... in alternativa, se non sei in grado di viaggiare nel tempo ...
(forse la tua auto non può arrivare a 88 miglia all'ora, o il tuo condensatore di flusso si è appena spezzato)

Adesso

Nuovi progetti dovrebbero essere impegnati sul posto insanguinato, è pazzesco non farlo, e i sistemi DVCS contemporanei hanno appena rimosso ogni possibile scusa per evitare impegni : git init . ; git add * ; git commit -m initial-commitora, prima che sia troppo tardi, come potrebbe già essere.

Un'altra domanda sensata, discutibile, potrebbe essere stata: "Quando dovrei unire i miei commit a un controllo sorgente condiviso su un repository gestito dal team su un progetto stabilito ?" (nota gli aggettivi, gli aggettivi sono importanti) E ho la sensazione che la maggior parte delle altre risposte stiano effettivamente cercando di rispondere.

Il tuo ramo personale dovrebbe essere impegnato come pazzo , almeno una volta al giorno , prima di coricarsi. Potresti svegliarti la mattina dopo e scoprire di non avere idea di cosa diavolo stavi facendo, la notte precedente. Il VCS dovrebbe coprirti da questo, e avere l'opportunità di tornare a una versione molto recente di una sub-versione che si compila bene, funziona senza intoppi e / o supera i test potrebbe essere la tua migliore opzione.


3
Non mi dispiace commettere cambiamenti che non vengono compilati, soprattutto alla fine della giornata. Il giorno dopo hai qualcosa che non viene compilato ma hai ancora la cronologia dei commit - se non vuoi che la tua cronologia sia "sporca" ci sono opzioni per il rollback in ogni buon DVCS (penso che tutti concordino che i DVCS sono l' unico modo per vai.)
Leonardo Herrera il

@LeonardoHerrera Capisco il tuo POV, anche se in progetti linguistici interpretati con più punti di ingresso, finisci per commettere qualche ramo non compilante con motivi legittimi (come condividere correzioni di bug su un punto di ingresso diverso) sicuramente può essere fatto in modo migliore e molto più bello , ma poi diventa una questione di gusti ... e de gustibus non est disputandum .
ZJR,

20

Direi commettere il prima possibile. Lo scopo principale del controllo del codice sorgente è consentire di tornare indietro nel caso in cui qualcosa vada storto, e questo è in sintonia con la pratica "commettere presto e spesso".

Personalmente, il mio primo commit in genere contiene solo il file .gitignore (o equivalente) con pochi filtri che so saranno necessari, come * .py [co] per il codice Python. L'installazione di base del progetto e / o il primo prototipo più semplice è ciò che di solito segue.


Faccio qualcosa di simile. Da quando uso GitHub, ho sempre anche un file README di base, anche se contiene solo il nome del progetto. Trovo che avere il file lì fin dall'inizio sia molto più probabile che lo aggiornerò in futuro :).
Tikhon Jelvis,

16

Il primo commit può essere un file README con un solo riepilogo di una riga del progetto o informazioni sufficienti sulla prima pietra miliare del progetto. Gli argomenti generali possono anche includere:

  • introduzione
  • Descrizione del progetto
  • Struttura del progetto
  • Convenzioni di codifica
  • Istruzioni su come:
    • costruire
    • test
    • schierare
  • Problemi noti e soluzioni alternative
  • lista di cose da fare
  • Condizioni d'uso

La pratica di aggiornare il file README prima di apportare modifiche a un progetto è anche definita Readme Driven Development e ti consente di riflettere sulle modifiche prima di investire tempo per apportarle.

Chiunque voglia contribuire o utilizzare questo software inizierà quindi con README.


12

Se hai svolto un lavoro che non vorresti perdere, dovrebbe essere nel tuo sistema di controllo del codice sorgente.

Questo si applica certamente a sistemi distribuiti come Git. Se stai utilizzando un sistema centralizzato e l'unico modo per archiviare qualcosa è renderlo visibile a tutti , potresti voler tenere a bada o potresti prendere in considerazione la possibilità di configurare il tuo repository git locale e inviarlo al centralizzato sistema quando sei pronto.


3
La mia regola è questa, con l'aggiunta che voglio anche che sia un "punto nel tempo in cui il codice viene compilato". Commetti ciò che non si compila e bisecando diventa molto più fastidioso, se mai dovessi trovare quando hai rotto qualcosa.
Warren P,

Una filiale temporanea non lo avrebbe indirizzato, almeno per Git? Non ho usato git bisectmolto.
Keith Thompson,

Uso mercurial senza rebase, quindi considero tutti i commit come permanenti
Warren P

7

La mia regola empirica è quella di effettuare il check-in una volta che il mio file di soluzione (o altro pezzo di script di build) è stato eseguito, anche se contiene alcuni file vuoti. È buona pratica quando più di una persona sta lavorando al progetto. Quel file tende ad avere i problemi di fusione peggiori inizialmente poiché le persone stanno aggiungendo cose al progetto, quindi è necessario impegnarsi presto e spesso.

Anche se sei l'unico che lavora al progetto e ha solo un file, trovo più facile seguire lo stesso flusso di lavoro e salvare il pensiero per il problema in questione.


6

Non sono sicuro se è stato menzionato.

Ma assicurati che ciò che commetti venga eseguito / compilato! Quindi nessun errore di sintassi, ecc.

Niente di più frustrante del checkout del codice non funzionante.


anzi, ha senso!
Aquarius_Girl

Non sono d'accordo. Se il mio codice non viene compilato quando voglio eseguire il commit, scrivo WIP da qualche parte nel messaggio di commit. Quindi posso semplicemente ignorare quei commit quando ho bisogno dell'ultima versione che viene compilata.
Minthos,

5

Un altro punto di vista più legato ai test del software (approccio TDD) sarebbe impegnarsi non appena avrai nuovi casi di test in verde. Ciò significherebbe che hai una nuova "unità" di codice completata.


Per coprire un metodo potrebbe essere necessario (principalmente) diversi test unitari. Non è proprio vero dire se si effettua un superamento del test, quindi significa che si finisce un'unità di lavoro. Non è nemmeno vero dire che finire quel metodo sia un'unità di lavoro.
Behnam Rasooli,

5

Poco prima di fare qualcosa di stupido.

Per quelli di noi senza poteri magici, ciò significa poco e spesso.

Se lavori da solo, fallo ogni volta che prendi un drink o qualsiasi altra cosa.

Se lavori in una squadra, probabilmente devi assicurarti che la cosa si compili, in modo che se qualcun altro arriva all'ultimo, non riceveranno un sacco di errori. Ma a parte questo, il più possibile.


4

Circa 2 ~ 3 ore nel progetto.

Solo scherzando. Non esiste una buona risposta adatta a tutte le situazioni. Prima di tutto, se hai un sistema di controllo della versione distribuito (come git o Mercurial), il commit nel tuo repository locale non preserverà i tuoi dati in caso di errore catastrofico. Ma un repository remoto privato può costarti denaro, ad esempio su Github. Conserverai la cronologia dei commit, ma nella mia esperienza non ne avrai bisogno fino a quando il tuo progetto non sarà un po 'avanzato.

Inoltre, probabilmente non vuoi troppo sfornare all'inizio, specialmente se stai spostando i file. Commettere cambiamenti sarà un peso se non di poco conto. Puoi anche decidere di buttare via la cosa. Ma se perdi modifiche che non sono banali da replicare, ti perderai dopo aver fatto una copia di backup e i sistemi di controllo della versione creano sistemi di backup estremamente preziosi.

Al giorno d'oggi alcune persone usano DropBox o simili per memorizzare il loro codice. Potrebbe essere un buon compromesso all'inizio di un progetto poiché non è necessario alcuno sforzo per istituire. È comunque un'abitudine barbarica nello sviluppo di software serio, specialmente se diverse persone toccano il codice contemporaneamente.

Quindi, tendo a impostare il controllo della versione ogni volta che ho qualcosa di prezioso, cioè non banale da replicare. Il valore è soggettivo (e dipende dalle proprie capacità), quindi dovrai esprimere il tuo giudizio. A quel punto conservo un secondo repository su un disco esterno o su github se si tratta di un progetto pubblico o il mio conto a pagamento lo manterrà.


3

Molte persone hanno già risposto "Immediatamente" e sono d'accordo al 100%. Mi piace anche il suggerimento di Xion di iniziare con gli schemi di ignorare del VCS (cioè .gitignoreo equivalenti).

Immagino sia abbastanza concordato sul fatto che non ci sono aspetti negativi nei primi impegni. Vorrei aggiungere degli aspetti positivi:

  • È meno probabile che commetti cose che hai scelto di scartare ma che continuano a persistere. Quando inizio un nuovo sviluppo, codificherò e discraderò rapidamente le cose, e quando commetterò più tardi, quando ci sono già un sacco di file, ho commesso accidentalmente cose solo per cancellarle nel prossimo commit. Questo, al contrario di piccoli, o addirittura vuoti, è un vero rumore nella storia.
  • Se sei un tipo sistematico e hai i primi passi tipici nei tuoi progetti, avere quelli come punti di commit può essere istruttivo per te o per altri, e potrebbe anche fornire l'opportunità di ramificarsi ad un certo punto e creare uno stub riutilizzabile del progetto. Ho lavorato su progetti basati su Maven in cui questo è stato utile (perché nella creazione di un progetto Maven, alcuni piccoli primi passi possono già definire una base abbastanza sostanziale e, sebbene quei passaggi non siano molto da fare , possono richiedere abbastanza pensiero per giustificare riusabilità).

2

Può dipendere dal VCS in uso.

Con Git, eseguo il commit di una directory vuota (o con un file README quasi vuoto). Il punto è che posso tornare indietro e ripristinare il mio ramo a quello stato vuoto se voglio ricominciare completamente mentre sono ancora all'inizio del processo di sviluppo (prima di spingere a monte). Vorrei quindi eseguire il commit dei miei file "generati" (ad esempio la soluzione di Visual Studio). Quindi, quando sto effettivamente programmando, comincerò a impegnare ogni unità come faresti normalmente.

Con SVN, stai spingendo a monte con ogni commit in modo da non avere il lusso di ricominciare da capo come fai con Git. In questo caso, potrebbe non essere utile impegnarsi in anticipo se si pensa che si effettuerà un importante rinnovamento all'inizio del processo. Questo dipenderà dalla codifica della persona però.


2

Quando inizio un nuovo progetto di solito comincio a commetterlo prima che sia stato aggiunto qualsiasi codice. Una regola generale che ho sempre seguito è: se il tuo PC si è bloccato e cancellato tutti i tuoi dati quale codice preferiresti non dover scrivere dalla memoria. Dieci anni fa, prima del TDD e delle migliori pratiche di programmazione, ero piuttosto ottimista su ciò che ricordavo. Ora tendo ad essere più cauto. Come molti altri manifesti hanno detto commettere presto e commettere spesso. Non stai perdendo nulla facendolo.

Sto lavorando da solo per la maggior parte del tempo, quindi devo confessare che mi sto rilassando, ma generalmente mi impegno prima di tornare a casa. In questo modo, se non arrivo domani, i miei colleghi potranno riprendere da dove avevo interrotto.

Attualmente sto usando Tortoise / SVN al lavoro.


2

Impegna subito il progetto vuoto. Continua a impegnarti più volte all'ora che passi a lavorare sul progetto. Esegui il commit anche se il codice non viene compilato. Contrassegno tali impegni con "WIP" nel massaggio di commit per tenerne traccia.

Ho anche uno script che esegue automaticamente il commit di tutti i miei progetti ogni 10 minuti in un repository di backup, nel caso in cui dimentichi di impegnarmi manualmente. Chiamiamolo il mio buffer di annullamento supportato dal cloud.

Effettua il check-in (ovvero push ) del progetto in un repository team quando hai bisogno del tuo team per vedere il tuo codice. Che è probabilmente prima che il tuo codice sia pronto per essere visto dal tuo team, se sei qualcosa come me.

Se vuoi essere gentile con la tua squadra, elimina i tuoi impegni prima di spingerli al repository della squadra.


1

Ho esaminato tutti gli articoli e penso che abbiamo già avuto molte buone soluzioni, ma vorrei condividere la mia metodologia con te.

Mentre si lavora sulla creazione del framework (da zero), verranno apportate molte modifiche per ciascun modulo fino a quando il modulo non viene completato o finalizzato. Quindi ho sempre 2 posizioni, una è chiamata DINAMICA e l'altra è STATICA. Quando le modifiche sono in corso e il framework non è ancora finalizzato, è stato eseguito il commit nella posizione DYANMIC e una volta completato e finalizzato, lo sposto nella posizione STATIC. Quindi ho un controllo completo del codice sorgente.

Grazie


0

Con qualsiasi applicazione, trascorrerai un po 'di tempo a progettare i componenti. Dovresti conoscere, approssimativamente o in dettaglio, spazi dei nomi, progetti, riferimenti esterni, librerie di terze parti ecc.

Se fai parte di una squadra, suggerirei la tua guida, o chiunque sia scelto, per creare il progetto di base, ottenere le dipendenze e controllare quello scheletro (fondamento su cui sarà costruito il tuo progetto).

Inoltre, devi assicurarti di avere i rami di attività, rilascio, trunk, ecc. Specificati prima di effettuare il check-in in modo che il processo sia solido.

Se stai lavorando a una nuova "attività" per un progetto che è già in corso e sei nel tuo ramo di attività, fai i check-in notturni in modo da preservare il tuo lavoro.


0

Di solito faccio il check-in ogni volta che aggiungo qualcosa di nuovo, ma provo a separare le cose in commit discreti.

Ciò significa che, se aggiungo una nuova dipendenza, apporto le modifiche fino a quando non vengono compilate o sono sufficientemente grandi da perdere tempo a rifarle da zero. Se ho un compito più grande, provo a impegnarmi più volte, quando ha senso (una volta per funzione, ogni volta che lo compilo e lo eseguo correttamente, ecc.).

Mi impegno anche quando desidero un punto di backup (ovvero "se ciò che provo ora non funziona o diventa troppo complicato, voglio tornare al codice così com'è ora", o quando qualcuno mi chiede di eliminare ciò che sono fare e risolvere alcuni problemi urgenti).

Se si utilizza un sistema centralizzato di controllo del codice sorgente, non è possibile eseguire il commit arbitrario per i punti di backup, poiché un commit che non viene compilato / funzionante influisce su tutti i membri del team.

Di solito quando inizio ad aggiungere il codice boilerplate (ad es. Aggiungo una nuova webapp in un sito Web django), commetto ogni operazione che faccio.

Se seguo un'esercitazione per generare / scrivere codice, utilizzo i nomi delle fasi nell'esercitazione per i messaggi di commit. In questo modo, posso differire le revisioni e vedere cosa ha fatto un passaggio del tutorial, in qualsiasi momento successivo.

Diciamo, ad esempio, che ho un progetto che consiste in un singolo file di codice. Ci vorranno circa 10 righe di codice boilerplate e 100 righe per far funzionare il progetto con funzionalità estremamente basilari (1 o 2 funzionalità).

Dipenderebbe da quanto sia difficile aggiungere le cose:

  • se fosse banale aggiungere il codice della piastra della caldaia, lo aggiungerei e lo impegnerei subito prima di iniziare con l'altro codice (in questo modo, se commetto un errore o introduco uno strano bug in seguito, posso semplicemente tornare al codice della piastra della caldaia e iniziare ancora).

  • Se il codice fosse non banale, mi impegnerei ogni volta che aggiungessi qualcosa di nuovo (ovunque tra le due righe di codice cambiate, a circa cento).

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.