Stronę tą wyświetlono już: 383 razy
Poprzednio utworzony został branch o nazwie 001_index_html przełączę się czym prędzej na branch-a develop:
git checkout develop
a następnie z develop-a utworzę kolejnego branch-a:
git checkout -b 002_some_content
na którym również utworzę plik index.html ale nieco inny:
Czas dodać plik i commit-a zrobić:
git add * git commit -m "some content" [002_some_content c303cdb] some content 1 file changed, 17 insertions(+) create mode 100644 index.html
a następnie przełączyć się z powrotem na develop:
git checkout develop
Teraz możesz przejść do folderu projektu, otworzyć plik index.html i z przerażeniem stwierdzić, że twoje zmiany w tajemniczy sposób zniknęły! Ale spokojnie zaraz powrócą! Czas na merg-owanko, najpierw 001_index_html:
git merge 001_index_html
Updating 8f2e6e8..1bd50b6
Fast-forward
index.html | 12 ++++++++++++
1 file changed, 12 insertions(+)
create mode 100644 index.html
Mały diagram merg-owania stan przed:
A---B---C topic / D---E---F---G master
i po
A---B---C topic / \ D---E---F---G-----------H master
A teraz trzeba by było spróbować merg-ować drugiego brancha:
git merge 002_some_content CONFLICT (add/add): Merge conflict in index.html Auto-merging index.html Automatic merge failed; fix conflicts and then commit the result.
I cóż za zaskoczenie! Merge conflict (konflikt). Jeżeli przejdziesz do pliku index.html oczom twym coś takiego się ukarze:
W sekcji pomiędzy <<<<<<< HEAD a ======= znajdują się bieżące zmiany z develop-a, natomiast pomiędzy ======= a >>>>>>> 002_some_content zmiany z 002_some_content, które kolidują z bieżącymi zmianami. Należy porównać te zmiany i zostawić te, które powinny być gdyż system sam nie może podjąć takiej decyzji. Tak więc w tym przypadku wszystkie zmiany z 002_some_content powinny pozostać, a więc plik powinien wyglądać tak:
Po zapisaniu zmian należy dodać je:
git add index.html
a następnie utworzyć commit-a:
git commit -m "Merge 002_some_content into develop"
Warto nadmienić, że w rozwiązywaniu konfliktów pomaga użycie odpowiedniego edytora np. Visual Studio Code, gdzie można porównywać zmiany, zastosować obie lub jedną z nich jednym kliknięciem (jeżeli jest to tylko możliwe).
Zaistniałą w tym przypadku sytuację opisuje następujący diagram zmian przed:
A---B---C topic / D---E---F---G master
i po merge-owaniu
A---B---C topic / \ D---E---F---G---H master