Eksempel på, hvordan en fusionskonflikt diff ser ud

5 enkle trin for at undgå sammenlægning af konflikter

Der er mange gode ting ved at bruge kildekontrol (også kaldet versionskontrol). Dette gælder især, når der er flere, der arbejder på det samme projekt. Et af de smertepunkter, der plager folk, der arbejder på det samme projekt, er fusionskonflikter. Det er altid det værste, når du skriver git merge other-branch, og du får nogle output som dette:

Når automatisk fusion ikke fungerer

Så hvordan sker fusionskonflikter?

Flettekonflikter kan ske, når den eller de samme linier i en fil ændres i to forskellige forpligtelser, og du prøver at flette disse forpligtelser sammen. På det tidspunkt ved git ikke, hvilke ændringer der skal holdes i den endelige fusion.

Her er et par måder, der kan hjælpe dig med at undgå fusionskonflikter:

  1. Gør ikke al din udvikling på mastergrenen (forudsat at din standardgren er master). Hvis du arbejder på et projekt med andre mennesker, får du næsten altid sammenflettningskonflikter, når du samtidig forpligter dig til den samme gren.
  2. Lav en ny filial og (en pull-anmodning) for hver funktion / fejl, du arbejder på. I denne gren skal du kun foretage ændringer, der løser den fejl eller implementerer den funktion. Det er så let at smide en typofix eller fjerne nogle gamle glemte printf () udsagn sammen med uanset hvilken ændring du foretager. Men ikke gør det! Hvis du bemærker en printf () eller console.log (), glemte nogen at fjerne, oprette en ny filial og åbne en anmodning om træk for det. Hvis du ser en skrivefejl, mens du løser en fejl, skal du oprette en ny filial og åbne en anmodning om træk for den.
  3. Foretag små ændringer. Der er ikke noget galt i at oprette en ny filial og åbne en pull-anmodning for kun en ændret linje. Faktisk er min antagelse, at det er mere sandsynligt, at det hurtigt vil blive slået sammen, fordi det kun er en linje. Det er lettere at spore introduktionen af ​​fejl, der blev introduceret, hvis ændringerne holdes små og fokuserede. Tænk også på det fra en korrekturlæsers perspektiv. Vil du hellere gennemgå en pull-anmodning med 10.000 linjekoder (LOC) ændret, eller en pull-anmodning med kun en linje ændret?
  4. Har ikke langvarige grene. Jo længere din filial går uden at blive fusioneret, jo større er sandsynligheden for, at en anden vil røre ved den samme kode, som du gjorde. Før du ved det, har du en fusionskonflikt.
  5. Gennemgå straks anmodninger. Jo længere det sidder der uden at blive fusioneret, jo større er sandsynligheden for, at nogen redigerer den eller de samme filer og flettekonflikter vises.

Noget af dette vil virke lidt overdreven, især på enmannsprojekter. Hvis det er tilfældet (du er den eneste person, der arbejder på et projekt), behøver du måske ikke gøre alt dette. Men det betyder ikke, at det ikke er en god ide, især at foretage små trinvise ændringer.

Alt dette bliver sagt, fusionskonflikter er ikke det værste i verden. Det meste af tiden er de ikke for svære at løse. Men de er stadig en smerte, tager ekstra tid og kan næsten fuldstændigt undgås ved kun at gøre et par små ting.

Håber dette indlæg var nyttigt og informativt! Du er velkommen til at fortælle mig dine tanker og meninger i kommentarerne.