2016-04-28 12 views
6

Qualcuno può spiegare perché un commit nel GitHub visualizzerebbe le seguenti informazioni: 'Contributor-A' committed with 'Contributor-B' on 15 Feb.github commettere informazioni: A impegna con B

Significa che "Contributor-A" è l'autore (chi non ha l'accesso push al master) e "Contributor-B" è il committer/manutentore?

Allora perché non v'è un PR creato per unire questo commesso? O significa che c'era un PR chiuso su questo commit, ma il manutentore non lo fondeva tramite l'interfaccia web ma eseguiva rebase o cherry-picking per includerlo?

Grazie mille!

+0

Puoi includere un esempio di ciò che si sta vedendo e come pensate che qualcosa non va? – osowskit

+0

Mi spiace di non averlo detto chiaramente. Non ho trovato nulla di sbagliato. Non capisco appieno le informazioni sulla pagina di commit GitHub. E non riesco a trovare la risposta tramite Google. Ho aggiunto una figura per illustrare la mia domanda. –

+0

È difficile rispondere completamente alla domanda senza vedere un collegamento GitHub al repository o al repository Git stesso. – osowskit

risposta

2

... il maintainer non lo ha unito tramite l'interfaccia web ma ha eseguito rebase o cherry-picking per includerlo?

Sono stato in grado di ottenere questo selezionando un commit da un altro ramo e spingendo direttamente al ramo corrente - an example on GitHub.

Un Pull Request non è necessario per spingere codice tra i rami. Una richiesta pull è un metodo che consente agli sviluppatori di collaborare alle modifiche prima di unire le filiali.

+0

Molte grazie per il tuo esempio. Avrei dovuto provarlo da solo ... Sono consapevole che PR non è obbligatorio per spingere il codice. Ho solo pensato che il flusso di lavoro fosse una regola relativamente rigida che gli sviluppatori dovrebbero seguire. Ma ora so che questa regola è flessibile. Grazie mille. –

+0

Sidenote: quando si usano le caselle di controllo nell'interfaccia di commit integrata in Xcode (7.3.2) si ottiene anche l'effetto di "A" commesso con "A" su Github. Quindi è essenzialmente la raccolta delle ciliegie sotto il cofano. –

1

Di sicuro, succede quando la richiesta di pull è stata fusa per la strategia "rebase e Merge" tramite l'interfaccia web, ma non sono sicuro se questo è il caso unico.

Contributor-A commesso con Contributor-B il 15 febbraio

Contributor-A ha presentato la richiesta di pull e collaboratore-B efficace fuse.

Potrebbe accadere in altri scenari come descritto qui: how to apply a git patch as if the author committed to my repo?

Problemi correlati