Ik gebruik GitHub al geruime tijd en ik pushte meestal mijn feature-branches en startte dan een Pull Request die ik zelf samenvoegde. Ik ontdekte dat het me hielp bij te houden waar ik branches samenvoegde.
Maar onlangs heb ik steeds meer gelezen over hoe Git werkt en ik realiseerde me dat ik de merge-commits kan gebruiken om naar te verwijzen als ik samenging branches.
Dus, wat moet ik doen als ik een feature-branch in master samenvoeg:
Voer een merge-commit uit op master en push deze stroomopwaarts OF Push de lokale branch en start een Pull Request?
Ik heb Introductie van Pull Requests voor een team van 2 personen gelezen – mijn eigen verzoeken samenvoegen? en Wat is de werkstroom met 2 mensen aan een project en Moet ik pull-aanvragen openen vanuit een filiaal op de officiële opslagplaats of mijn vork? maar geen van hen lijkt te beantwoorden wat ik zoek.
Reacties
- Wat ontbreekt er volgens jou precies aan die antwoorden?
- De eerste praat erover vanuit de zin dat pull-verzoeken bedoeld zijn om door vakgenoten beoordeeld te worden. De tweede biedt een workflow. De derde is niet ' zelfs niet gerelateerd.
- Ik bekijk dit vanuit een Best Practices of Hoe te onderhouden een goede git geschiedenis standpunt.
- Wanneer ik een PR samenvoeg, doe ik dat door de branch lokaal samen te voegen. Hierdoor kan ik ervoor zorgen dat de samenvoeging netjes van toepassing is en kan ik tests opnieuw uitvoeren voordat ik het resultaat publiceer. GitHub ' s Pull Requests zijn slechts een formalisering van deze workflow, Git zelf heeft geen concept van PRs.
- Wanneer een PR wordt samengevoegd, produceert het een samenvoeging commit op master, dus ik denk niet dat ' dit enig verschil maakt voor de git-geschiedenis. Daarom denk ik niet dat er ' geen reden is om de een of de ander te gebruiken, afgezien van je persoonlijke voorkeur tussen de opdrachtregel en de Github-gebruikersinterface.
Antwoord
git-merge-mechanisme:
Door git merge feature te gebruiken terwijl op master de tak feature wordt samengevoegd tot master en produceert een merge-commit (als de branch niet snel kan worden doorgespoeld) in de git-geschiedenis. Om het maken van een merge-commit te forceren, gebruik je de --no-ff optie met merge.
Merge Pull Request-mechanisme:
Wanneer we een Pull Request starten op GitHub, wordt er een GitHub Issue waar mensen kunnen praten en discussiëren over de commits in de PR voordat ze worden samengevoegd. Wanneer een PR wordt samengevoegd op GitHub, doet het exact hetzelfde als git merge feature.
Wat moet ik doen ?
Wat de geschiedenis betreft, is er dus geen verschil tussen de twee.
En wat de bijdrage betreft, zullen uw bijdragers niet hebben om iets anders te doen voor de twee situaties. Ze zijn hetzelfde (minus de leuke kleine chat).
Praktische tips:
En ik kon geen best practices vinden, maar de logica zegt dat PRs niet erg nuttig zijn als er maar één bijdrager aan een repository is.
@lxrec en @amon hielpen me tot deze conclusie te komen.
Reacties
- Tip:
git mergeneemt misschien geen merge commit op als het een “fast forward” kan doen. Om een merge-commit te forceren, kun je de--no-ffoptie toevoegen. - Ik doe liever git-merge op lokaal dan op githuib.com, als ik zou zoiets moeten doen op github.com Ik zou het liever niet direct op master branch doen, ik zou liever niet-master branch nemen die eerst in de staging-modus kan worden gezet voordat het beschikbaar wordt gemaakt voor productie.
Antwoord
Zoals Ashhar zei, is er technisch en historisch geen verschil. Voor projecten met een klein team Ik geef er de voorkeur aan rechtstreeks samen te voegen in plaats van de extra stap van het maken van een PR. Als een functie echter moet worden herzien / feedback moet worden gegeven of wanneer het een OHW is en er meer dan één persoon aan zal werken, heb ik de neiging om een PR te openen en een lijst met taken aan de PR-beschrijving.
Merk op dat git merge snel vooruitspoelen zou kunnen gebruiken als er geen wijzigingen in de master zijn, dus u zou kunnen willen gebruiken git merge --no-ff. Meestal niet.
Dus samengevat: gebruik alleen PR s wanneer u discussie nodig heeft. Anders gewoon rechtstreeks samenvoegen.
Opmerkingen
- Het ' is ook het vermelden waard dat de discussie en feedback over een pull-verzoek komen zowel uit geautomatiseerde bronnen als uit teamleden. Als je een CI-server hebt ingesteld, kan deze build- en testresultaten opleveren, zodat je nooit iets samenvoegt dat de build op master verbreekt.