Wprowadzenie do kontroli wersji i Git

Znasz Dokumenty Google? Cóż, jeśli tak, można bezpiecznie założyć, że jesteś świadomy dzięki małej karcie „Historia wersji”, która pozwala autorom i zaangażowanym osobom sprawdzać i śledzić wszystkie zmiany wprowadzone w dokumencie. w dowolnym momencie. Poręczne narzędzie, prawda?

Teraz wyobraź sobie, że zamiast arkusza pełnego akapitów są pliki pełne setek linijek kodów. I w przeciwieństwie do jednego dokumentu, istnieje mnóstwo różnych plików, stale aktualizowanych.

W takim scenariuszu, w którym w grę wchodzą tysiące linijek kodów, a efekt końcowy, tj. aplikacja mobilna jest tym, od czego zależy przyszłość firmy, jeszcze ważniejsze staje się posiadanie oprogramowania, które będzie mieć zakładkę ze wszystkimi zmianami wykonane w plikach kodu.

W tym miejscu pojawia się oprogramowanie do kontroli wersji.

Dlaczego kontrola wersji jest ważna w tworzeniu oprogramowania?

Jak sama nazwa wskazuje, oprogramowanie do kontroli wersji umożliwia twórcom aplikacji mobilnych śledzenie różnych wersji cyklu rozwoju oprogramowania i wprowadzanie w nich zmian. Ta możliwość śledzenia wszystkich zmian zachodzących w kodzie, a następnie możliwość cofnięcia zmian, sprawia, że ​​kontrola wersji jest ważną częścią procesu firmy zajmującej się tworzeniem aplikacji mobilnych, w który zaangażowanych jest wielu programistów.

Obecnie, jeśli chodzi o kontrolę wersji, na rynku dostępnych jest wiele programów. Przyjrzyjmy się niektórym z nich –

Dostępne oprogramowanie do kontroli wersji

Chociaż w ankiecie GitLab, lider oprogramowania rozproszonego stwierdził, że 98% użytkowników korzysta z narzędzi open source Git, a ponad 92% programistów używa Git jako języka kontroli wersji w procesie tworzenia aplikacji, istnieje wiele powodów, dla których programiści mogą spojrzeć na alternatywę Git. Niektóre z tych powodów mogą się różnić – struktura cen GitHub i fakt, że Github jest uruchamiany zarówno na iOS, jak i Android, niechęć do Octocat lub prosty poziom wygody z językiem kontroli wersji, który nie jest Git.

Niezależnie od przyczyny, oto alternatywa Git do kontroli wersji —

Teraz, nawet jeśli istnieje wiele alternatyw dostępnych dla kontroli wersji i Appinventiv, mamy doświadczenie z pierwszej ręki w pracy nad wieloma z nich, ponieważ ze względu na różne wymagania klientów, rzeczywiście jesteśmy stronniczy w stosunku do Git. Powiem ci dlaczego.

Dlaczego Appinventiv używa Gita do kontroli wersji

1. Ze względu na szybkość błyskawicy

Spośród wszystkich dostępnych na rynku programów do kontroli wersji szybkość działania elementów Git log i Commit jest nieporównywalna z żadnym innym. A kiedy twój zespół programistów pracuje na platformie, absolutnie konieczne staje się, aby oprogramowanie było szybkie.

2. Umiejętność pracy offline

Kiedy pracujesz nad oprogramowaniem, które opiera się na Internecie, może to być ryzykowne, gdy jesteś w ruchu i tracisz połączenie z centralnym repozytorium. Ale tak nie jest w przypadku Git. Dzięki Git możesz wykonywać prawie wszystkie zadania na swoim lokalnym komputerze – zatwierdzać, przeglądać historię projektu, tworzyć gałęzie lub scalać.

3. O cofnięcie ulgi

Git jest wyposażony w polecenie „cofnij”, które pozwala poprawić i cofnąć całe zatwierdzenie. W rzeczywistości daje nawet opcję przywrócenia „usuniętego” zatwierdzenia za pomocą opcji Reflog.

4. Dla kopii zapasowej

Gdy zespół pracuje nad Git, każdy klon, który zespół ma na swoim komputerze, ma przydatną kopię zapasową. Poza tym prawie każda akcja Git tylko dodaje dane, a nie je usuwa.

5. Za podejmowanie użytecznych zobowiązań

Kiedy zespół naszych programistów wprowadza zestaw niepowiązanych zmian – przejmując niektóre funkcje z A, naprawiając pewne błędy w innym – innym członkom zespołu może być bardzo trudno zrozumieć, co się stało i może być im trudno wycofać się cechy A, jeśli powoduje to problemy.

Git rozwiązuje ten bałagan, tworząc szczegółowe zatwierdzanie. Dzięki koncepcji „obszaru postojowego” można łatwo dowiedzieć się, jakie zmiany zostaną uwzględnione w następnym zatwierdzeniu, nawet jeśli ograniczysz się do spojrzenia na pojedyncze wiersze.

Oto pięć głównych powodów, dla których używamy Gita w Appinventiv. Teraz, gdy przyjrzeliśmy się, dlaczego, nadszedł czas, aby przyjrzeć się, jak. Jak włączamy Git do naszego procesu kontroli wersji.

Przejdźmy teraz do tego.

Proces kontroli wersji podczas korzystania z Git

Tworzenie repozytorium

Celem Gita jest zarządzanie zbiorem plików, znanym również jako Projekt. W tym celu Git zapisuje wszystkie informacje w strukturze danych znanej jako Repozytorium. Repozytorium składa się z kodów źródłowych aplikacji, zasobów i zestawów danych. Zasadniczo ma wszystko, co definiuje projekt aplikacji.

Teraz są dwa sposoby uzyskania repozytorium w Git. Możesz użyć katalogu lokalnego i przekonwertować go na repozytorium Git za pomocą wiersza poleceń lub skopiować już przesłane repozytorium Git do swojego.

Kiedy tworzysz repozytorium, zwykle masz dwie opcje – Publiczną i Prywatną. Repozytorium publiczne to takie, które może przeglądać inni programiści korzystający z Git, a prywatne to takie, które może przeglądać tylko kilka osób.

Rozgałęzienia

Obok tworzenia repozytorium jest rozgałęzianie. W firmie takiej jak Appinventiv, gdzie w danym momencie nad jednym projektem pracuje ponad 15-20 programistów, często zdarza się, że programiści dzielą się tym samym kodem źródłowym i pracują nad nim. Dzieje się tak, ponieważ niektórzy programiści są zajęci rozwiązywaniem problemów, inni mogą wdrażać niektóre funkcje.

W takiej sytuacji potrzebujemy systemu, który ułatwi obsługę różnych wersji kodu w tej samej bazie kodu.

W tym miejscu pojawia się Gitflow. Gitflow to framework służący do systematycznego i wydajnego rozgałęziania.

Zanim przejdziemy do tego, jak działa proces rozgałęziania w Gitflow, wyjaśnię tę koncepcję na przykładzie.

Załóżmy, że w Twoim zespole jest 5 programistów, którzy pracują nad rozwojem aplikacji typu Instagram. Teraz poszczególne funkcje aplikacji, takie jak Załóżmy, że Kanał i Powiadomienia są oznaczone jako Moduł 1, Moduł 2 i tak dalej i tak dalej. Teraz te różne moduły są gałęziami rozwojowymi, które po przepracowaniu są łączone z gałęzią nadrzędną lub Master.

W momencie, gdy deweloper dodaje gałąź, tworzy niezależną linię rozwoju, która izoluje ich pracę od pracy członków zespołu. Różne gałęzie są następnie łączone w gałąź nadrzędną.

Rozgałęzienie to metoda, która pozwala członkom zespołu określić, jakich wszystkich zmian powinni się spodziewać i ułatwia cofanie się.

W naszych projektach zwykle trzymamy te gałęzie –

• Oddział główny
• Oddział Rozwoju
• Oddział funkcji
• Wydanie oddziału
• Gorące poprawki i poprawki błędów

Popełniać

Zmiany wprowadzane przez programistę w pojedynczym pliku są znane jako Commit. Zmiany lub zatwierdzenie są dodawane w lokalnym repozytorium, a nie na serwerze. Następnie nasi programiści mają zwyczaj pisania komunikatu o zatwierdzeniu, w którym zamieszczany jest opis zatwierdzenia (zmian dokonanych w pliku), aby inni programiści również znali szczegóły zmian dokonanych w pliku.

Naciskać

Kiedy zatwierdzasz w lokalnym repozytorium Git, następna jest sytuacja, w której zmiany są następnie wysyłane na serwer, który jest znany jako Push .

Dość łatwo jest przesłać historię zmian na serwer, gdy jesteś jedyną osobą pracującą nad plikiem, ale w przypadku, gdy w proces są zaangażowani również inni programiści, będziesz musiał pobrać zmiany, zanim będziesz mógł przesłać zestaw zobowiąż się do Git.

Następnie przyjrzymy się, co zostało zrobione w kroku Pull Change.

Prośba o pociągnięcie

Kiedy więcej niż jeden programista pracuje nad tym samym plikiem, zdarza się, że niektóre zatwierdzenia mogą zostać wepchnięte na serwer przez drugiego programistę, zanim je wypchniesz. A kiedy tak się dzieje, dochodzi do konfliktu (o tym później).

Aby uniknąć dwukrotnego przesyłania tej samej bazy kodu na serwer, programiści najpierw ściągają zmiany z repozytorium i upewniają się, że kody są różne. Teraz, ogólnie rzecz biorąc, gdy dwóch lub więcej programistów pracuje nad tym samym plikiem i przesyła swoje zatwierdzenie na serwer, pojawia się opcja „Scal”.

Porozmawiajmy teraz o Merge.

Łączyć

Scalanie to etap, w którym programiści łączą wszystkie gałęzie najpierw ze sobą, a następnie z gałęzią główną lub nadrzędną.

Za każdym razem, gdy dostawa wprowadza polecenie Push, otrzymują opcję Merge, która następnie pyta ich o gałąź, z którą chcieliby scalić zatwierdzenie.

Teraz, na etapie łączenia, występowanie konfliktu jest bardzo powszechne. Konflikt zwykle występuje, gdy dwie gałęzie, które zamierzasz scalić, zostały zmienione w tej samej części w tym samym pliku. Dzieje się tak, że Git nie jest w stanie określić, której wersji należy użyć.

Kiedy pojawia się ten problem z konfliktem, Git oferuje dwie rozdzielczości – automatyczną i ręczną.

Jak sama nazwa wskazuje, w jednym Git sam dowiaduje się o problemie, a w drugim programiści muszą to zrobić ręcznie. W Appinventiv koncentrujemy się na ręcznym rozwiązywaniu konfliktów, ponieważ eliminuje nawet najmniejsze szanse wystąpienia błędu.

Chociaż używamy Git do kontroli wersji naszego procesu tworzenia aplikacji, to, co dzieje się jednocześnie, to śledzenie problemów.

Ponieważ jesteśmy wielkim zwolennikiem Agile i ufamy Agile w procesie tworzenia naszych aplikacji mobilnych , rozumiemy znaczenie obsługi wielu procesów programistycznych w tym samym czasie. Funkcja śledzenia problemów znacznie ułatwia testerom śledzenie w czasie rzeczywistym kodu napisanego i przesłanego na serwer Git.

Korzystamy z płyty ZenHub do monitorowania przepływu pracy w każdym repozytorium. Tablica pozwala nam śledzić priorytet sugerowanej zmiany, a także pomaga deweloperom aktualizować ich komentarze na tablicy w czasie rzeczywistym.