Praktyczny kurs GIT dla zielonych cz. 3 – Konflikty, .gitignore i Pull Requesty

W tym artykule postaram się wytłumaczyć czym są i jak rozwiązywać konflikty powstające, podczas mergowania branchy. Wyjaśnię też, dlaczego nie powinno się wykonywać mergów pobocznych w głównych branchach i dlaczego zamiast tego, lepiej użyć Pull Requesty.

Spis treści

  1. Konflikty
    • Czym są konflikty?
    • Jak się pojawiają?
    • Jak je rozwiązywać?
  2. Gitignore
    • Czym jest .gitignore?
    • Jak tworzyć .gitignore?
  3. Pull Requesty
    • Czym są Pull Requesty?
    • Jak je wykonywać?
    • Dlaczego i kiedy należy ich używać?
  4. Podsumwoanie

Konflikty

Konflikty to elementy kodu których nie da się połączyć automatycznie podczas mergowania. Pojawiają się w przypadku, gdy w obu branchach zmiany w kodzie występują w tym samym obszarze, tego samego pliku (np. w dwoch branchach edytowaliśmy tę samą linijkę, tego samego pliku i potem próbujemy te gałęzie ze sobą połączyć). Innym częstym zjawiskiem są środowiska programowania (np. NetBeans, Android Studio), które przy każdym włączeniu generują dodatkowe pliki, wymagane do działania (np. ustawienia projektu, środowiska, jakieś cache itp.). Aby ich uniknąć warto dodać dynamicznie generowane pliki do gitignore (więcej w dalszej części artykułu).

Jak wygląda konflikt?

Aby przygotować przykładowy konflikt utworzyłem plik conflicts-are-bad.txt z przykładowym kodem, a następnie wydzieliłem z mastera osobny branch o nazwie lets-make-a-conflict. Potem w obu branchach edytowałem treść tego samego pliku. Efekt ten można uzyskać następującą grupą komend:

Zmergowanie brancha lets-make-a-conflict do mastera komendą:

wywoła konflikt. Całość prezentuje się w następujący sposób:

Jak rozwiązać konflikt?

Do rozwiązywania konfliktów istnieją gotowe narzędzia. Jedne są multi-platformowe, inne tylko dla jednego systemu np. Windows. Ja osobiście preferuję zrobić to ręcznie, w dowolnym edytorze tekstowym, aby mieć pewność co do każdej zmiany, którą wprowadzam. Przed zmianami plik wyglądał tak:

Jak widzimy na powyższym obrazku Git zaznaczył nam ładnie, co zawiera który branch. Istnieje możliwość automatycznego rozwiązywania problemu, za pomocą określenia tylko nasz kod lub tylko ich (mine, theirs). Nasz kod to kod brancha, w którym się aktualnie znajdujemy. Theirs odpowiada za branch który mergujemy. Jeśli zajdzie kiedyś potrzeba użycia tego,szczegóły można sobie wygooglać. Po mojej edycji manualnej plik wygląda następująco:

Jedyne co nam pozostało, po naprawieniu wszystkich konfliktów, to dodać zmodyfikowane pliki i wrzucić do repozytorium zmiany, jako osobny commit naprawiający problemy. W moim przypadku będzie to:

Naszą operacje przedstawia ładnie graf na githubie.