Git: come testare il codice locale prima del commit

Naviga le tue risposte
1

Diciamo che ho due file su cui sto lavorando - "a.txt" e "b.txt". Devo confermare la mia modifica a "b.txt" ma voglio continuare a lavorare su "a.txt" per un po 'di tempo. Faccio un "git add b.txt". Ora, prima che io commetta effettivamente questa modifica, c'è un modo per verificare che il commit non interrompa il ramo principale? Se eseguo un test localmente, il database testato nella mia area locale sarebbe diverso da quello sul ramo master poiché anch'io ho modifiche non programmate in "a.txt".

Qual è la procedura standard per il test in tali situazioni (è necessario utilizzare 'git stash'?). Oppure se questa situazione [la necessità di testare il commit nella tua area locale quando hai anche modifiche non programmate] non è molto comune, in che modo gli sviluppatori evitano lo stesso?

    
posta user3647150 11.05.2016 - 11:32
fonte

3 risposte

3

In generale non importa ciò che fai prima di spingere. Non importa a nessuno il tuo flusso di lavoro personale, a patto che tu spinga secondo gli standard della tua squadra.

Nel caso che hai descritto userò git stash. In dettaglio:

  1. commit b.txt
  2. archivia altre modifiche
  3. test
  4. spinta
  5. pop stash
risposta data 11.05.2016 - 11:57
fonte
3

Una buona pratica è quella di lavorare sempre sui rami (vedi Git Flow per uno modo molto comune per farlo), ed eseguire una build solo contro quel ramo, o spingere il ramo su un remoto (es. Bitbucket / GitHub) e farlo eseguire una build di ramo sul tuo server CI. (Si spera che un server di build faccia parte del tuo ambiente di sviluppo.)

L'obiettivo è di sapere che la build principale sarà verde dopo aver unito il ramo eseguendo gli stessi passi di build e test sul ramo prima di unire.

    
risposta data 11.05.2016 - 11:58
fonte
0

Spingi sempre e comunque qualcosa che funzioni davvero. Potresti avere file o modifiche su cui stavi lavorando che non vuoi spingere. devi assicurarti che il tuo ramo che non ha questi file o modifiche funzionerà. Il tuo ramo potrebbe avere ulteriori modifiche apportate da qualcun altro che potrebbe aver infranto il tuo nuovo codice (che la persona che ha spinto quelle modifiche non ha potuto verificare perché non hanno il tuo nuovo codice). Quindi:

  1. Rimuovi le modifiche che non vuoi spingere. Il modo più semplice è utilizzare prima "stash", quindi rimuovere le modifiche.

  2. Estrai lo stato più recente del ramo. Tutti i conflitti sono meglio gestiti in questo momento. Assicurati che il tuo codice funzioni con queste modifiche.

  3. Spingi il tuo codice completo . Spingi sempre ciò che hai testato. Ovviamente il tuo codice completo non contiene i bit che non hai funzionato.

Quindi puoi usare di nuovo lo stash per ripristinare le modifiche su cui stavi lavorando.

    
risposta data 11.05.2016 - 13:20
fonte

Leggi altre domande sui tag

Best practice / pattern per generare report PDF Qual è il ruolo di "genera eccezioni" nella definizione del metodo in Java?