Git-conflicten oplossen met behoud van beide bedoelingen.
Conflictoplossing moet bedoelde wijzigingen van beide kanten behouden als ze compatibel zijn. Vraag naar bedrijfsgedrag wanneer syntaxis alleen geen beslissing toelaat.
Stem de werkwijze af op je taak.
Lees de conflicterende versies en omliggende code en bepaal de bedoeling van elke wijziging. Combineer compatibel gedrag en vraag om een keuze waar eisen botsen; test daarna de resulterende interactie.
- Wat je aanlevert
- Conflictmarkeringen en bedoelde wijzigingen.
- Wat je krijgt
- Conflictuitleg en voorgesteld samengevoegd concept.
Bekijk de invoer en het resultaat.
Illustratieve invoer en uitvoer · een leervoorbeeld, geen live uitvoering van WebAct
Voorbeeld invoerveld
Resolve this simplified HTML conflict: base button was <button type="button">Save</button>. Branch A changes its label to Save draft. Branch B adds disabled because submission is unavailable.
Uitgewerkt voorbeeld
<button type="button" disabled>Save draft</button> Both changes are retained: the new label and the unavailable state. Confirm when the application should remove disabled; the merged markup alone does not implement that state transition.
Laad deze invoer in de prompt en kopieer deze naar WebAct om de taak te proberen. Je resultaat kan afwijken van het voorbeeld.
Keuzes en probleemoplossing.
Is ours of theirs kiezen altijd een volledige conflictoplossing?
Het kan een geldige wijziging van de andere kant weggooien. Vergelijk bedoelingen voordat je inhoud kiest of combineert.
Waarom breekt een syntactisch schone merge toch de functie?
Het gecombineerde gedrag kan botsen zonder markeringen. Controleer toestand, gebeurtenisafhandeling en de eisen waaraan beide branches moesten voldoen.
Probeer het met je eigen bron.
Vervang het voorbeeld door je eigen materiaal in de taakprompt. Behoud de eisen die je nodig hebt en kopieer de taak naar WebAct.
De taak aanpassen en kopiëren ↑