Flusso di lavoro di sviluppo n.

Hai già la tua copia fork del repository Matplotlib , seguendo Making your own copy (fork) of Matplotlib . Hai impostato la forchetta . Hai configurato git seguendo Configure git . Ora sei pronto per un vero lavoro.

Riepilogo del flusso di lavoro n.

In quanto segue faremo riferimento al mainramo Matplotlib a monte, come "trunk".

  • Non usare il tuo mainramo per niente. Valuta di eliminarlo.

  • Quando inizi una nuova serie di modifiche, recupera tutte le modifiche dal tronco e avvia un nuovo ramo di funzionalità da quello.

  • Crea un nuovo ramo per ogni serie separabile di modifiche: "un'attività, un ramo" ( ipython git workflow ).

  • Assegna un nome alla tua filiale ai fini delle modifiche, ad esempio bugfix-for-issue-14o refactor-database-code.

  • Se puoi evitarlo, evita di unire il tronco o altri rami nel tuo ramo delle caratteristiche mentre lavori.

  • Se ti ritrovi a unirti dal tronco, considera la possibilità di ribasare sul tronco

  • Chiedi sulla mailing list di Matplotlib se rimani bloccato.

  • Richiedi la revisione del codice!

Questo modo di lavorare aiuta a mantenere il lavoro ben organizzato, con una cronologia leggibile. Questo a sua volta rende più facile per i manutentori del progetto (che potresti essere tu) vedere cosa hai fatto e perché lo hai fatto.

Vedi il flusso di lavoro di linux git e il flusso di lavoro di ipython git per alcune spiegazioni.

Prendi in considerazione l'eliminazione del tuo ramo principale #

Può sembrare strano, ma eliminare il tuo mainramo può aiutare a ridurre la confusione su quale ramo ti trovi. Vedi l'eliminazione di main su github per i dettagli.

Aggiorna lo specchio del bagagliaio #

Per prima cosa assicurati di aver fatto Linking your repository to the upstream repo .

Di tanto in tanto dovresti recuperare le modifiche a monte (trunk) da github:

git fetch upstream

Questo eliminerà tutti i commit che non hai e imposterà i rami remoti in modo che puntino al commit giusto. Ad esempio, "trunk" è il ramo a cui fa riferimento (remote/branchname) upstream/main- e se ci sono stati commit dall'ultima volta che hai controllato, upstream/maincambierà dopo aver eseguito il recupero.

Crea un nuovo ramo di funzionalità #

Quando sei pronto per apportare alcune modifiche al codice, dovresti iniziare un nuovo ramo. I rami che sono per una raccolta di modifiche correlate sono spesso chiamati "rami di funzionalità".

La creazione di un nuovo ramo per ogni serie di modifiche correlate renderà più facile per qualcuno che rivede il tuo ramo vedere cosa stai facendo.

Scegli un nome informativo per il ramo per ricordare a te stesso e al resto di noi a cosa servono i cambiamenti nel ramo. Ad esempio add-ability-to-fly, o bugfix-for-issue-42.

# Update the mirror of trunk
git fetch upstream
# Make new feature branch starting at current trunk
git branch my-new-feature upstream/main
git checkout my-new-feature

In generale, vorrai mantenere i tuoi rami di funzionalità sul tuo fork github pubblico di Matplotlib . Per fare ciò, devi spingere questo nuovo ramo fino al tuo repository github. Generalmente (se hai seguito le istruzioni in queste pagine e per impostazione predefinita), git avrà un collegamento al tuo repository github, chiamato origin. Esegui il push fino al tuo repository su github con:

git push origin my-new-feature

In git >= 1.7 puoi assicurarti che il collegamento sia impostato correttamente utilizzando l' --set-upstreamopzione:

git push --set-upstream origin my-new-feature

D'ora in poi git saprà che my-new-featureè correlato al my-new-featureramo nel repository github.

Il flusso di lavoro di modifica #

Panoramica n.

# hack hack
git add my_new_file
git commit -am 'NF - some message'
git push

Più in dettaglio #

  1. Apporta alcune modifiche

  2. Guarda quali file sono stati modificati con (vedi git status ). Vedrai un elenco come questo:git status

    # On branch ny-new-feature
    # Changed but not updated:
    #   (use "git add <file>..." to update what will be committed)
    #   (use "git checkout -- <file>..." to discard changes in working directory)
    #
    #  modified:   README
    #
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    #
    #  INSTALL
    no changes added to commit (use "git add" and/or "git commit -a")
    
  3. Controlla quali sono le modifiche effettive con ( git diff ).git diff

  4. Aggiungi eventuali nuovi file al controllo della versione (vedi git add ).git add new_file_name

  5. Per eseguire il commit di tutti i file modificati nella copia locale del tuo repository, esegui . Nota le opzioni per . Il flag segnala solo che stai per digitare un messaggio sulla riga di comando. La bandiera - puoi semplicemente crederci - o vedere perché la bandiera -a? - e l'utile descrizione del caso d'uso nel problema della copia di lavoro aggrovigliata . Anche la pagina di manuale git commit potrebbe essere utile.git commit -am 'A commit message'-amcommitma

  6. Per inviare le modifiche al tuo repository fork su github, esegui un (vedi git push ).git push

Richiedi la revisione o l'unione delle modifiche #

Quando sei pronto a chiedere a qualcuno di rivedere il tuo codice e prendere in considerazione un'unione:

  1. Vai all'URL del tuo repository biforcuto, ad esempio https://github.com/your-user-name/matplotlib.

  2. Utilizza il menu a discesa "Cambia ramo" nella parte superiore sinistra della pagina per selezionare il ramo con le modifiche:

    ../../_images/branch_dropdown.png
  3. Fare clic sul pulsante "Richiesta pull":

    ../../_images/pull_button.png

    Inserisci un titolo per la serie di modifiche e una spiegazione di ciò che hai fatto. Dì se c'è qualcosa per cui vorresti un'attenzione particolare, come una modifica complicata o un codice di cui non sei soddisfatto.

    Se non ritieni che la tua richiesta sia pronta per essere unita, dillo semplicemente nel messaggio di richiesta pull. Questo è ancora un buon modo per ottenere una revisione preliminare del codice.

Alcune altre cose che potresti voler fare #

Elimina un ramo su github #

git checkout main
# delete branch locally
git branch -D my-unwanted-branch
# delete branch on github
git push origin :my-unwanted-branch

Nota i due punti :prima di my-unwanted-branch. Vedi anche: https://help.github.com/articles/pushing-to-a-remote/#deleting-a-remote-branch-or-tag

Diverse persone condividono un unico repository #

Se vuoi lavorare su alcune cose con altre persone, dove ti impegni tutti nello stesso repository, o anche nello stesso ramo, condividilo semplicemente tramite github.

Primo fork Matplotlib nel tuo account, come da Making your own copy (fork) of Matplotlib .

Quindi, vai alla pagina github del tuo repository biforcuto, ad esempio https://github.com/your-user-name/matplotlib

Fai clic sul pulsante "Amministratore" e aggiungi chiunque altro al repository come collaboratore:

../../_images/pull_button.png

Ora tutte quelle persone possono fare:

git clone https://github.com/your-user-name/matplotlib.git

Ricorda che i collegamenti che iniziano con httpso git@sono di lettura-scrittura e che git@utilizzano il protocollo ssh.

I tuoi collaboratori possono quindi impegnarsi direttamente in quel repository con il solito:

git commit -am 'ENH - much better code'
git push origin main # pushes directly into your repo

Esplora il tuo archivio #

Per visualizzare una rappresentazione grafica dei rami e dei commit del repository:

gitk --all

Per visualizzare un elenco lineare di commit per questo ramo:

git log

Puoi anche guardare il visualizzatore grafico di rete per il tuo repository github.

Infine l' alias di output del registro di fantasia lg ti fornirà un ragionevole grafico basato su testo del repository.

Ribasamento su tronco #

Diciamo che hai pensato a un lavoro che ti piacerebbe fare. Aggiorna il mirror del trunk e crea un nuovo feature branch chiamato cool-feature. A questo punto il tronco è in qualche commit, chiamiamolo E. Ora fai dei nuovi commit sul tuo cool-featureramo, chiamiamoli A, B, C. Forse le tue modifiche richiedono un po' di tempo, o ci ritorni dopo un po'. Nel frattempo, il tronco è passato dal commit E al commit (diciamo) G:

      A---B---C cool-feature
     /
D---E---F---G trunk

A questo punto prendi in considerazione l'unione di trunk nel tuo feature branch e ricordi che questa pagina qui ti consiglia severamente di non farlo, perché la cronologia diventerà disordinata. La maggior parte delle volte puoi semplicemente chiedere una revisione e non preoccuparti che il bagagliaio sia andato un po' avanti. Ma a volte, i cambiamenti nel tronco potrebbero influenzare le tue modifiche e devi armonizzarle. In questa situazione potresti preferire eseguire un rebase.

rebase prende le modifiche (A, B, C) e le riproduce come se fossero state apportate allo stato corrente di trunk. In altre parole, in questo caso, prende le modifiche rappresentate da A, B, C e le riproduce sopra G. Dopo il rebase, la cronologia sarà simile a questa:

              A'--B'--C' cool-feature
             /
D---E---F---G trunk

Vedi rebase senza strappi per maggiori dettagli.

Per fare un rebase sul tronco:

# Update the mirror of trunk
git fetch upstream
# go to the feature branch
git checkout cool-feature
# make a backup in case you mess up
git branch tmp cool-feature
# rebase cool-feature onto trunk
git rebase --onto upstream/main upstream/main cool-feature

In questa situazione, in cui sei già su branch cool-feature, l'ultimo comando può essere scritto in modo più succinto come:

git rebase upstream/main

Quando tutto sembra a posto, puoi eliminare il tuo ramo di backup:

git branch -D tmp

Se non ha un bell'aspetto, potrebbe essere necessario dare un'occhiata a Ripristino dai pasticci .

Se hai apportato modifiche ai file che sono cambiati anche nel trunk, questo potrebbe generare conflitti di unione che devi risolvere - vedi la pagina man di git rebase per alcune istruzioni alla fine della sezione "Descrizione". C'è qualche aiuto correlato sull'unione nel manuale dell'utente di git - vedi risoluzione di un'unione .

Recuperare dai pasticci #

A volte, sbagli unioni o rebase. Fortunatamente, in git è relativamente semplice recuperare da tali errori.

Se sbagli durante un rebase:

git rebase --abort

Se noti di aver sbagliato dopo il rebase:

# reset branch back to the saved point
git reset --hard tmp

Se hai dimenticato di creare un ramo di backup:

# look at the reflog of the branch
git reflog show cool-feature

8630830 [email protected]{0}: commit: BUG: io: close file handles immediately
278dd2a [email protected]{1}: rebase finished: refs/heads/my-feature-branch onto 11ee694744f2552d
26aa21a [email protected]{2}: commit: BUG: lib: make seek_gzip_factory not leak gzip obj
...

# reset the branch to where it was before the botched rebase
git reset --hard [email protected]{2}

Riscrittura cronologia commit #

Nota

Fallo solo per i tuoi rami di funzionalità.

C'è un errore di battitura imbarazzante in un impegno che hai fatto? O forse hai fatto diverse false partenze che vorresti che i posteri non vedessero.

Questo può essere fatto tramite il rebasing interattivo .

Supponiamo che la cronologia dei commit assomigli a questa:

git log --oneline
eadc391 Fix some remaining bugs
a815645 Modify it so that it works
2dec1ac Fix a few bugs + disable
13d7934 First implementation
6ad92e5 * masked is now an instance of a new object, MaskedConstant
29001ed Add pre-nep for a copule of structured_array_extensions.
...

ed 6ad92e5è l'ultimo commit nel cool-featureramo. Supponiamo di voler apportare le seguenti modifiche:

  • Riscrivi il messaggio di commit per 13d7934qualcosa di più sensato.

  • Combina i commit 2dec1ac, a815645, eadc391in uno solo.

Facciamo come segue:

# make a backup of the current state
git branch tmp HEAD
# interactive rebase
git rebase -i 6ad92e5

Questo aprirà un editor con il seguente testo al suo interno:

pick 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
pick a815645 Modify it so that it works
pick eadc391 Fix some remaining bugs

# Rebase 6ad92e5..eadc391 onto 6ad92e5
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Per ottenere ciò che vogliamo, apporteremo le seguenti modifiche:

r 13d7934 First implementation
pick 2dec1ac Fix a few bugs + disable
f a815645 Modify it so that it works
f eadc391 Fix some remaining bugs

Ciò significa che (i) vogliamo modificare il messaggio di commit per 13d7934e (ii) comprimere gli ultimi tre commit in uno solo. Ora salviamo e chiudiamo l'editor.

Git aprirà quindi immediatamente un editor per modificare il messaggio di commit. Dopo averlo revisionato, otteniamo l'output:

[detached HEAD 721fc64] FOO: First implementation
 2 files changed, 199 insertions(+), 66 deletions(-)
[detached HEAD 0f22701] Fix a few bugs + disable
 1 files changed, 79 insertions(+), 61 deletions(-)
Successfully rebased and updated refs/heads/my-feature-branch.

e la storia ora appare così:

0f22701 Fix a few bugs + disable
721fc64 ENH: Sophisticated feature
6ad92e5 * masked is now an instance of a new object, MaskedConstant

Se è andato storto, il recupero è nuovamente possibile come spiegato sopra .