Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020
Wanneer u een pull-aanvraagvoltooit, voegt u de onderwerpbranch samen in uw standaardbranch, meestal main. Met deze merge worden de commits van de onderwerpbranch toegevoegd aan uw hoofdbranch en wordt een merge commit gemaakt om conflicten tussen de defaultbranch en de onderwerpbranch op te lossen. De opmerkingen en discussie in de pull-aanvraag geven meer context voor de wijzigingen die in de onderwerpbranch zijn aangebracht.
De geschiedenis van uw main branch (of een andere standaard branch) volgt geen rechte lijn vanwege de geschiedenis van de gerelateerde onderwerpbranch. Naarmate een project groter wordt, neemt het aantal onderwerptakken gelijktijdig toe, waardoor de standaardtakgeschiedenis steeds moeilijker te volgen wordt.
De standaardbranch is een nauwkeurige weergave van de geschiedenis van elke onderwerpbranch, maar het is moeilijk om bredere vragen over de ontwikkeling van uw project te beantwoorden.
Benodigdheden
| Categorie | Vereisten |
|---|---|
| Toegang tot het project | Lid van een project. |
| toestemmingen | - Code weergeven in privéprojecten: minimaal Basis toegang. - Klonen of bijdragen aan code in privéprojecten: Lid van de Inzenders beveiligingsgroep of bijbehorende machtigingen in het project. - Machtigingen voor tak of opslagplaats instellen: Machtigingen beheren machtigingen voor de tak of opslagplaats. - Standaardtak wijzigen: beleid bewerken machtigingen voor de opslagplaats. - Een opslagplaats importeren: Lid van de Projectbeheerders beveiligingsgroep of Git-projectniveau Opslagplaats maken machtiging ingesteld op Toestaan. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie. |
| Diensten | Repositories ingeschakeld. |
| Gereedschappen | Facultatief. Gebruik az repos opdrachten: Azure DevOps CLI. |
Notitie
In openbare projecten hebben gebruikers met Stakeholder volledige toegang tot Azure Repos, waaronder het weergeven, klonen en bijdragen aan code.
| Categorie | Vereisten |
|---|---|
| Toegang tot het project | Lid van een project. |
| toestemmingen | - Code weergeven: ten minste Basis toegang. - Klonen of bijdragen aan code: Lid van de beveiligingsgroep Contributors of bijbehorende machtigingen in het project. |
| Diensten | Repositories ingeschakeld. |
Squash samenvoegen
Squash samenvoegen is een samenvoegoptie waarmee u de Git-geschiedenis van onderwerpbranches kunt verkorten wanneer u een pull-aanvraag voltooit. In plaats van elke doorvoering op de onderwerpbranch toe te voegen aan de geschiedenis van de standaardbranch, voegt een squash-samenvoeging alle bestandswijzigingen samen tot één nieuwe doorvoering op de standaardbranch. Squash merge commit heeft geen verwijzing naar de onderwerpbranch. Het produceert een nieuwe doorvoer die alle wijzigingen uit de onderwerpbranch bevat. U wordt aangeraden de topic-branch te verwijderen om verwarring te voorkomen.
Een eenvoudige manier om hierover na te denken is dat squash samenvoegen u alleen de bestandswijzigingen geeft en een normale samenvoeging u de bestandswijzigingen en de doorvoergeschiedenis geeft.
Hoe is het nuttig om een squash-merge te gebruiken?
Squash samenvoegen zorgt ervoor dat uw standaard-branchgeschiedenis schoon en eenvoudig te volgen is zonder dat er aanpassingen in de werkwijze van uw team nodig zijn. Bijdragers aan de featurebranch werken zoals ze willen in de featurebranch en de standaard vertakkingen houden een lineaire geschiedenis bij met behulp van squash-merges. De commitgeschiedenis van een main-branch die is bijgewerkt met squash merges bevat één commit voor elke samengevoegde branch. U kunt deze geschiedenis doorlopen om precies te achterhalen wanneer het werk is voltooid.
Overwegingen bij squash-samenvoeging
Squash-merging verkort de geschiedenis van wijzigingen in uw standaardbranch. Het is daarom belangrijk om met uw team te bespreken wanneer u kiest voor squash-mergen versus het behouden van de volledige commitgeschiedenis van een onderwerpbranch. Bij het samenvoegen van squash is het een goed idee om de bronbranch te verwijderen. Als u de bronvertakking verwijdert, voorkomt u verwarring omdat de onderwerpvertakking zelf geen doorvoer heeft die deze samenvoegt in de standaardvertakking.
Pull-aanvragen voltooien met squash samenvoegen
U kunt ervoor kiezen om een squash merge te doen bij het voltooien van een pull-aanvraag in Azure Repos.
Kies Squash commit onder Samenvoegtype in het dialoogvenster Pull-aanvraag voltooien om de onderwerpvertakking samen te voegen.
Meerdere samenvoegingsbasissen
Het tabblad Bestanden in een pull request detecteert verschillen door middel van een driedimensionale vergelijking. Het algoritme houdt rekening met de laatste doorvoering in de doelbranch, de laatste doorvoering in de bronbranch en de bijbehorende algemene samenvoegbasis, bijvoorbeeld de beste gemeenschappelijke voorouder. Het algoritme is een snelle, kostenefficiënte en betrouwbare methode voor het detecteren van wijzigingen. Helaas is er in sommige gevallen meer dan één echte basis. In de meeste opslagplaatsen is deze situatie zeldzaam, maar in grote opslagplaatsen met veel actieve gebruikers kan dit gebruikelijk zijn. U kunt handmatig controleren of er meerdere samenvoegpunten tussen de takken bestaan. Voer hiervoor git merge-base --all feature master opdracht uit. Azure DevOps detecteert het bestaan van meerdere merge-bases voor elke pull request. Wanneer deze worden gedetecteerd, toont Azure DevOps de melding 'Er zijn meerdere samenvoegbasissen gedetecteerd'. De weergegeven lijst met commits kan onvolledig zijn voor de pull request. Azure DevOps voert de detectie van meerdere samenvoegdatabases uit, maar controleert niet of de mogelijke samenvoegingsbasis al is samengevoegd of niet. Een dergelijke controle wordt uitgevoerd door git merge-base. Daarom kan azure DevOps het bericht zelfs weergeven wanneer git merge-base slechts één samenvoegbasis rapporteert.
Notitie
Als u tijdens een PR-beoordeling wijzigingen bent kwijtgeraakt, moet u ervoor zorgen dat meerdere merge-bases niet de hoofdoorzaak zijn.
De volgende voorbeeldscenario's worden gedetecteerd door Azure DevOps als meerdere bases, waarbij de samenvoegdatabases worden aangegeven door getallen één en twee:
- Kruisgewijze samenvoegingen (ook wel criss-cross genoemd) tussen verschillende branches (gerapporteerd door Azure DevOps en
git merge-base)
---1---o---A
\ /
X
/ \
---2---o---o---B
- Samenvoegen van één tak met twee andere (gerapporteerd door Azure DevOps, maar niet door
git merge-base, waardoor mergebasis 2 wordt geëlimineerd)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- Omgaan met de gevolgen van terugdraaien van de hoofdtak, bijvoorbeeld de samenvoegcommit wijzigen
* 42bb2d2 (HEAD, A) Amended merge commit
|\
| | * 67c9bb8 (other) Merge branch 'A' into B
| | |\
| |/ /
|/| /
| |/
| * fa78e32 add second commit
* | 15845c9 add first commit
|/
* 6a52130 add init
- Actief hergebruik van functiebranches
- Andere niet-intuïtieve en complexe manipulaties zoals terugdraaien, cherrypicking en samenvoegingen
Detectie van meerdere samenvoegingsbases maakt deel uit van het bewustzijn van beveiliging. Als er meerdere samenvoegbasisopties zijn, kan het bestandsverschilalgoritme voor de gebruikersinterface mogelijk geen bestandswijzigingen correct detecteren, afhankelijk van welke samenvoegbasis het kiest. Als de bestanden in de pull-aanvraag verschillende versies hebben tussen de samenvoegbases, treedt er een waarschuwing voor meerdere samenvoegingsbasissen op.
Raadpleeg de officiële Git-documentatie voor meer informatie.
Mogelijke beveiligingsrisico's voor het samenvoegen van meerdere bases
- Een kwaadwillende gebruiker kan het UI-algoritme misbruiken om schadelijke wijzigingen door te voeren die niet aanwezig zijn in de PR.
- Als de voorgestelde wijzigingen in de pull request zich al in de doelbranch bevinden, worden ze weergegeven op het tabblad Bestanden, maar kunnen ze mogelijk geen vertakkingsbeleid activeren dat gekoppeld is aan mapwijzigingen.
- Twee sets wijzigingen aan dezelfde bestanden vanaf meerdere samenvoegingsbasissen zijn mogelijk niet aanwezig in de pull request. In dat geval kunnen er verraderlijke logische hiaten ontstaan.
"Oplossen van het probleem met meerdere merge-basissen"
Het hebben van meerdere merge-bases is niet per se slecht, maar je moet dubbelchecken of alles goed is. Als u meerdere samenvoegingsbasissen wilt verwijderen, koppelt u de vertakkingen aan één gemeenschappelijke voorouder door de vertakking opnieuw te baseren op het doel of door het doel samen te voegen in uw vertakking. Deze acties worden verwijderd van het waarschuwingsbericht en helpen u te controleren of de werkelijke wijzigingen goed zijn.
Eén benadering is om een soft reset uit te voeren en je voortgang op te slaan voordat je gaat rebasen of samenvoegen. Vervolgens kunt u een nieuwe vertakking maken of een lege vertakking opnieuw maken en uw wijzigingen vanaf een duidelijk punt toepassen. Dit proces vereist mogelijk een geforceerde push naar de externe repository als uw wijzigingen daar al aanwezig zijn.
Hoe voorkom je het probleem met meerdere samenvoegbasissen?
Hier volgen algemene tips voor het voorkomen van het probleem van meerdere samensmeltingsbasissen:
- Wanneer u een pull request voorbereidt, maakt u feature branches van de nieuwste versies van de hoofd- of releasebranch.
- Vermijd het maken van vertakkingen die niet rechtstreeks afkomstig zijn van stabiele vertakkingen van uw opslagplaats, tenzij vereist.
Wat te doen als het probleem met meerdere samengevoegde basissen terugkomt
In grote opslagplaatsen met veel actieve inzenders kan dit probleem vooral onhandig zijn. Zelfs als u meerdere bases via samenvoegen kwijt raakt, kan de situatie opnieuw verschijnen. Als iemand een langdurige pull request sluit, kan dat de situatie opnieuw creëren. Hoewel er buildbeleid en -tests worden uitgevoerd, hebt u geen mogelijkheid om de pull request te voltooien. Het resetten en starten van een nieuwe branch kan helpen. Als er niets wordt gewijzigd, zijn uw wijzigingen waarschijnlijk duidelijk, zelfs als de situatie zich herhaalt.