Skrivet av guermantes:
https://dl.dropboxusercontent.com/u/55892413/git-conflict_x.png
Så jag fick mina första konflikter när jag gjorde git merge. Det var bara tre filer och jag kunde lösa de konflikterna och spara de tre filerna.
Git säger (enligt bilden) att jag nu ska göra en commit. Men har alla andra filer mergats? Jag blir lite konfys eftersom header.php finns med på skärmen och den klarade sig utan konflikter, det var en massa andra ändrade filer också som fanns i den branch som mergades in, men de omnämns inte trots att header.php gör det.
Jag är lite osäker på vad som har hänt.
Gick mergen som den skulle förutom konflikterna i de tre filerna?
Om ja, varför finns bara header.php med i outputen och inte alla andra filer som gick bra?
Eller avbröts hela merge-processen efter tre konflikter?
Som @Milky Way skriver ovan: merge-processen "avbröts" inte — du är mitt i den!
De filer som står som Auto-merging
utan att de följs av en CONFLICT
-rad hade separata ändringar i både den gren du stod på och den gren du mergade från, men Git lyckades själv sammanfoga dessa filer utan problem. De läggs automatiskt till i ditt nuvarande index (a.k.a. "staging area", dvs förberedelsen till din nästa commit). Du behöver alltså inte köra git add
på dem, då de redan är tillagda och färdiga.
De som följs av CONFLICT (content)
är också filer som ändrats i både den gren du står på och den gren du mergade ifrån, men där fanns det konflikter som Git inte själv kunde lösa, som du alltså måste fixa manuellt. Dessa läggs inte till ditt index automatiskt, utan du får göra detta själv med exempelvis git add
när du är nöjd.
Du nämnde att det var fler filer som ändrats som inte syntes i utskriften: ifall de endast ändrats i en av grenarna så behövs ingen konfliktlösning, och Git nämner inte dessa filer under merge-operationen. Kontrollerar du med git status
så ser du dock att de filer som kommer adderas jämfört med den gren du står på redan är tillagda i ditt index, och alltså förberedda för att bli en del av din nya commit.
Under en merge-operation så minns Git vilka filer som inte lyckades sammanfogas ordentligt ("unmerged paths") och vägrar göra en commit förrän du klarmarkerat dessa genom att du adderar dem till ditt index. Git kommer inte automatiskt förstå att du fixat konflikten bara för att du själv är nöjd efter att ha ändrat filen i ditt filträd: du måste registrera ändringarna i ditt index, innan du kan committa dem till ditt repo (se till att skilnaden mellan dessa tre områden är glasklar — jag skrev om detta på forumet för inte så länge sedan).
Notera också att ifall du säger "jajamen, jag har fixat konflikerna, git commit
!" efter att ha kört git add
på konfliktande filer trots att du inte faktiskt löst konflikten, dvs det finns kvarvarande konfliktmarkörer (>>>>>>>
, =======
, <<<<<<<
) i filerna, så kommer Git gladeligen lita på ditt omdöme och trycka in dessa filer i din commit. Det är helt och hållet ditt ansvar att lösa konflikten och meddela när du är klar.
Återigen: ha koll på skillnaden mellan filträd, index och repo så blir allt så mycket enklare att förstå.