Używanie OASIS-SVN i git do kontroli kodu źródłowego Access

UWAGA: Omówię ten temat szczegółowo w nadchodzącym comiesięcznym seminarium internetowym dotyczącym programu Access i SQL Server, które odbędzie się 9 lipca o 18:30 czasu CDT. Zarejestruj się, aby zobaczyć proces na żywo i zadawać pytania!

Ponieważ pracujemy z kilkoma aplikacjami i czasami w zespole, kontrola kodu źródłowego jest bardzo ważna dla zarządzania zmianami. Pokochaliśmy używanie gita w naszych projektach. Początkowo używanie git z Accessem byłoby wyzwaniem, ale dzięki dodatkowi o nazwie OASIS-SVN możemy efektywnie używać git z projektami Access do zarządzania zmianami.

Dlaczego warto korzystać z kontroli kodu źródłowego? Nie możesz go po prostu zapiąć?

Głównym celem kontroli kodu źródłowego jest możliwość łatwego odpowiadania na kryminał.

Jest to szczególnie ważne, gdy masz do czynienia ze zgłoszeniem błędu i przypomina ci się, że widziałeś coś podobnego wcześniej i myślałeś, że może to naprawiłeś, ale klient nadal to zgłasza. Jednak gdy błąd został „naprawiony” sześć miesięcy temu, równie dobrze może to być zupełnie nowy błąd, ponieważ już zapomnieliśmy o naprawie, którą wprowadziliśmy 6 miesięcy temu. Nie wiem jak wy, ale perspektywa przekopywania się przez kilka spakowanych kopii zapasowych nie wydaje się zbyt… wykrywalna.

Umieszczanie zmian w kontroli kodu źródłowego wymaga dyscypliny, ale znacznie ułatwi przeglądanie i zarządzanie zmianami. Możesz łatwo przeszukać historię i zobaczyć, co dokładnie się zmieniło.

Innym scenariuszem jest ustalenie, co dokładnie się zmieniło. Jeśli wprowadziłeś kilka zmian i musisz je przejrzeć, zanim wypchniesz nową wersję, w tym pomoże Ci kontrola kodu źródłowego. Masz możliwość sprawdzenia swojej pracy i upewnienia się, że zrobiłeś wszystko, co zamierzałeś zrobić. Nigdy więcej „Myślę, że już to zrobiłem”. tylko po to, by klient powiedział ci, że zapomniałeś o drobnym szczególe, o który klient pytał cię w zeszłym tygodniu. Ponadto umożliwia to zespołowi przeprowadzanie przeglądów kodu dla innych; możemy przyglądać się pracy innych i udzielać informacji zwrotnych oraz pomagać sobie nawzajem w utrzymaniu wysokiego standardu jakości.

Dlaczego głupku? Access działa z Visual SourceSafe, prawda?

W wersjach wcześniejszych niż Access 2013 program Access natywnie obsługiwał kontrolę kodu źródłowego, ale korzystał z zastrzeżonej specyfikacji Microsoft, MSSCCI. Co gorsza, specyfikacja zakłada model check-out/check-in, który daje programistom wyłączną blokadę nad obiektami, nad którymi pracują. Co więcej, tabele w aplikacji Access były w zasadzie jedną dużą plamą, której nie można było odczytać, nie mówiąc już o przejrzeniu.

W praktyce taki model jest bardzo kłopotliwy w użyciu nawet w przypadku małego zespołu. Jednym z głównych problemów jest to, że żądanie zmiany rzadko jest potwierdzane tylko dla jednego obiektu; programiści mogą potrzebować dotknąć więcej niż garstki obiektów, a zatem kolizje mogą być nieuniknione, szczególnie w przypadku modułów podstawowych/współdzielonych.

Git unika całej brzydoty, którą widzimy w starym modelu wymeldowania/zameldowania, ale wymaga to innej filozofii zarządzania zmianami. Zamiast sprawdzać coś, po prostu pracujemy nad gałęzią, a kiedy z tym skończymy, łączymy ją z powrotem z gałęzią główną. Możemy mieć kilka rozgałęzień równolegle, gdybyśmy chcieli, chociaż w praktyce potrzebujemy tylko 2 lub 3 równoległe rozgałęzienia; jeden reprezentujący wersję produkcyjną; inne dla rozwoju i może trzecia dla krytycznych poprawek błędów. Można to zrobić za pomocą projektu programu Access i powinno tak być. W przeciwnym razie śledzenie tego, co dzieje się w pliku produkcyjnym, może być bardzo trudne, szczególnie w przypadku nietrywialnych aplikacji.

Doskonałe źródło do nauki git można znaleźć tutaj; ma piaskownicę, dzięki czemu możesz grać. Jeśli jesteś podobny do mnie i lubisz jeść mięsiste kawałki i wiesz, jak to działa, to jest dobry zasób.

Na koniec po prostu przestań już korzystać z Visual SourceSafe. Jest wadliwy, podatny na utratę danych i nie jest obsługiwany od _lat_, nawet przez Access od 2013 roku.

Ale jeśli program Access 2013+ nie obsługuje już kontroli kodu źródłowego, jak moglibyśmy nadal go mieć?!?

Ponieważ OASIS-SVN nie jest dostawcą MSSCCI, ale zwykłym dodatkiem Access. Istnieją inne podobne dodatki Access (np. Ivercy), które pozwalają obejść to ograniczenie. We wszystkich przypadkach te dodatki intensywnie wykorzystują dokładnie te same nieudokumentowane metody, których program Access używał wewnętrznie do kontroli kodu źródłowego; Aplikacja.SaveAsText i Aplikacja.LoadFromText . Te metody są nadal obecne w aktualnej wersji programu Access. Z boku jest element UV, który to dokumentuje, aby zapewnić ciągłość. OASIS-SVN nadal działa dobrze nawet z obecną wersją Access.

Dlaczego ciągle mówisz o OASIS-SVN i git? Czy mogę po prostu użyć jednego lub drugiego?

Ważne jest, aby zrozumieć, że oba narzędzia uzupełniają się i potrzebujesz obu. Widzisz, powodem, dla którego potrzebujesz OASIS-SVN, jest ułatwienie Ci ciężkiej pracy i przedstawienie ich jako zbioru plików tekstowych, zamiast umieszczania ich w dużym blobie pliku binarnego, który jest Plik ACCD*. Nie ma sensu kontrolowanie pliku ACCDB w kodzie źródłowym, ponieważ nie miałby odpowiedniej historii zmian i byłby w dużej mierze nieczytelny. W ten sposób OASIS-SVN jest narzędziem do tworzenia plików tekstowych, których można użyć do odbudowania aplikacji Access, a zadaniem git jest faktyczne zakodowanie tych plików. Git nie może i nie powinien działać z plikiem ACCDB.

Jeśli jesteś nowicjuszem w git, masz dodatkowy krok w porównaniu z tym, co zwykle robią inni w swoich projektach Visual Studio, ponieważ pracujesz z plikiem binarnym, a nie z rzeczywistym zestawem folderów z mnóstwem plików tekstowych z zabawnymi rozszerzeniami. Musisz więc wyrobić w sobie nawyk ciągłego eksportowania/importowania zmian między plikiem ACCDB a plikami tekstowymi, które tworzą twoje repozytorium git.

Wymagania wstępne

Aby rozpocząć, potrzebujemy 3 programów:

1. Git dla Windows
2. ŻółwGit
3. OASIS-SVN

Ściśle mówiąc, nie potrzebujesz drugiego i trzeciego oprogramowania. Właściwie możesz zadowolić się tylko pierwszym, ale dużym minusem jest to, że musisz ręcznie eksportować/importować, pisząc własny moduł VBA, aby to zrobić i uwierz mi, to dużo pracy z powodów, które staną się jaśniejsze, ponieważ idziemy dalej. Dlatego zdecydowanie zaleca się OASIS-SVN. Nie musisz też mieć TortoiseGit, ale naprawdę lubię mieć GUI, aby ułatwić pracę. Może to urazić niektórych purystów wiersza poleceń, którzy powiedzą ci, że powinieneś używać git w wierszu poleceń, a nie za pomocą ładnego GUI. Jednak lubię to leniwe i szybkie, a przez większość czasu proces jest prosty, ponieważ szybciej jest mi po prostu wykonać polecenie z menu niż otworzyć powłokę bash i wpisać jakieś polecenie. To powiedziawszy, TortoiseGit jest tak naprawdę tylko cienkim opakowaniem na polecenia git, więc powinieneś zrobić dobrze, aby zwrócić szczególną uwagę na to, jakie polecenie git uruchamia i co to oznacza.

Zainstaluj je wszystkie; Odwołam się do ich odpowiednich stron internetowych, aby uzyskać szczegółowe instrukcje. Gdy to wszystko zostanie skonfigurowane, musisz mieć projekt, nad którym chcesz przejąć kontrolę. Co więcej, potrzebujesz miejsca, które będzie działać jako twoje pierwotne repozytorium. Może masz konto Azure DevOps? Bitbucket? GitHub? Dostępnych jest kilka opcji hostowania kontroli kodu źródłowego. Heck, jeśli masz ochotę, możesz nawet skonfigurować prywatny serwer git. Ale to również wykracza poza zakres tego artykułu. Ponownie odsyłam Cię do dokumentacji odpowiedniego dostawcy, aby skonfigurować puste repozytorium.

Gdy masz już puste repozytorium, powinieneś otrzymać do niego link. Używamy Auzre DevOps i stworzyliśmy nowe repozytorium znajdujące się pod tym adresem URL:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
Teraz, gdy mamy link do pustego repozytorium, możemy rozpocząć konfigurację.

Tworzenie lokalnego repozytorium

Chociaż OASIS-SVN ma kreatora, łatwiej jest mi sklonować istniejące repozytorium i pracować z niego. Możesz użyć kreatora, który zrobi coś podobnego, ale myślę, że przestrzeganie instrukcji pomoże ci zrozumieć, co naprawdę się dzieje i ułatwi pracę z narzędziami. Załóżmy, że mamy aplikację w określonym folderze:

Folder Source jest pusty i będzie miejscem, w którym będziemy przechowywać pliki tekstowe dla naszego lokalnego repozytorium. Możemy kliknąć prawym przyciskiem myszy białe miejsce w folderze, aby otworzyć TortoiseGit menu kontekstowe i wybierz repozytorium klonów.

W wyświetlonym oknie dialogowym wpisz adres URL otrzymany od dostawcy usług hostingowych:

UWAGA

Powinieneś wtedy otrzymać okno dialogowe sukcesu, że repozytorium zostało sklonowane:

W wyniku klonowania będziesz mieć teraz ukryty folder o nazwie .git . W ten sposób git śledzi Twoje zatwierdzenia i zmiany w lokalnym repozytorium.

Mamy teraz działające lokalne repozytorium, którego możemy następnie użyć do przechowywania naszych plików tekstowych z programu Access. Aby z tego skorzystać, będziemy musieli skonfigurować OASIS-SVN.

Konfigurowanie OASIS-SVN

Jak wspomniano wcześniej, OASIS-SVN ma kreatora, którego można użyć do skonfigurowania nas, ale chcemy to zrobić ręcznie, abyś wiedział, jak działa OASIS-SVN, a tym samym może efektywnie korzystać z kreatora. Zaczniemy od przejścia do Ustawienia menu na karcie wstążki OASIS-SVN.

To otworzy okno dialogowe. Na razie musimy zrobić tylko jedną rzecz; skonfigurować ścieżkę źródłową. Ogólnie uważam, że wygodniej jest użyć ścieżki względnej niż ścieżki bezwzględnej, dlatego umieścimy \Source jak pokazano na rysunku:

Po wprowadzeniu należy zaznaczyć pole wyboru zawsze używaj :

To sprawia, że ​​folder repozytorium jest względny, a tym samym umożliwia przeniesienie folderu projektu w dowolne miejsce. Ale uważaj – jeśli skopiujesz lub przeniesiesz plik Access poza ten folder, nie będzie można go trzymać pod kontrolą kodu źródłowego, ponieważ OASIS-SVN nie będzie miał wtedy .oasis plik, którego potrzebuje OASIS-SVN. Kliknij OK, aby zamknąć okno dialogowe i zapisać zmiany w ustawieniach. Jeśli zajrzysz do folderu, zobaczysz teraz .oasis plik dla twojego pliku ACCDB.

.oaza plik jest po prostu plikiem XML, który zawiera wszystkie ustawienia projektu i musi mieć taką samą nazwę jak plik ACCDB, aby OASIS-SVN wiedział, że ten plik ACCDB powinien być pod kontrolą kodu źródłowego. Tak więc, jeśli masz zwyczaj zmieniania nazwy pliku ACCDB, będziesz musiał zerwać z tym nawykiem. Jeśli istniejący przepływ pracy wymaga zmiany nazwy pliku, jednym ze sposobów, które uważam za przydatne, jest użycie stałej nazwy dla kopii programistycznej (np. SampleApplication Dev.accdb , być może), to kiedy muszę zmienić nazwę, robię kopię tego pliku i podaję właściwą nazwę. Należy podkreślić, że przy kontroli kodu źródłowego zmiana nazwy w celu śledzenia wersji ma teraz mniej sensu, ponieważ powinieneś być w stanie odtworzyć ją z historii git, zamiast mieć kilka kopii o różnych nazwach.

Konfigurowanie pozostałych ustawień

W poprzednim kroku skonfigurowaliśmy tylko plik źródłowy, ponieważ nie mieliśmy .oasis plik; gdybyśmy dokonali jakichkolwiek innych zmian, być może nie zostały one zapisane, ale teraz mamy jedną utworzoną w wyniku ustawienia folderu projektu, możemy przejrzeć resztę ustawień. Prawdopodobnie dobrym pomysłem jest rozważenie posiadania szablonu .oasis plik, dzięki czemu można szybko kopiować i ręcznie dostosowywać, aby uzyskać jednolite ustawienia projektu dla różnych projektów programu Access. Wróćmy do Ustawień na wstążce i zacznij od pierwszej zakładki w oknie dialogowym.

Okienko Typy obiektów

Ponieważ nie pracujemy już z ADP i nie używamy przestarzałych stron dostępu do danych, zwykle odznaczamy je, aby zminimalizować bałagan w oknie dialogowym importu/eksportu. Przydatne może być również automatyczne wybieranie automatycznej zmiany, która wymaga śledzenia znacznika czasu obiektu. Należy jednak pamiętać, że znacznik czasu obiektu nie jest w pełni niezawodny w programie Access. Omówimy to więcej w dalszej części. To powiedziawszy, jest to dobry sposób, aby wskazać, czy zapomniałeś popełnić jakiś zabłąkany obiekt.

Okienko Opcje tabeli

Ten panel będzie wymagał starannych przemyśleń i będzie zależeć od rodzaju projektów, z którymi masz do czynienia. Zasada numer jeden mówi, że _nie_ chcesz, aby kod źródłowy kontrolował dane w twoich tabelach. To nie ma sensu, ponieważ dane nie są kodem. Jednak nie zawsze jest to prawdą. Na przykład mamy szereg tabel, których używamy jako danych konfiguracyjnych aplikacji. W pewnym sensie te tabele są więc „kodem”, ponieważ wpływają na sposób działania aplikacji. Ponieważ większość naszych projektów to front-endy Access z backendami SQL Server, tabele, które zwykle są obecne, to głównie tabele konfiguracyjne, a zatem odpowiednie do kontroli kodu źródłowego. Ale gdybyśmy mieli tabele danych, prawdopodobnie nie powinno się ich uwzględniać. To właśnie tam Zaawansowane przydaje się przycisk. Kliknięcie tego otworzy to okno dialogowe:

Odznaczając Eksportuj dane dla wszystkich tabel pole wyboru na dole, możesz następnie wybrać dane tabel, które chcesz zachować pod kontrolą kodu źródłowego, z wyjątkiem tych, które są tylko tabelą danych, a nie częścią kodu źródłowego aplikacji.

Zwykle nie uwzględniamy również tabel połączonych ODBC, ponieważ zwykle mamy procedurę kodu do ponownego łączenia tabel, więc posiadanie jej w kontroli kodu źródłowego nie ma dla nas sensu. Jednak posiadanie tabeli konfiguracji aplikacji, a może nawet samej definicji tabeli lokalnej, jest dobrym pomysłem, ponieważ mielibyśmy zepsutą aplikację, gdybyśmy zbudowali plik z repozytorium git bez definicji tych tabel.

Okienko ustawień

Widzieliśmy to już wcześniej, tworząc .oazę plik. Teraz, gdy mamy plik, skonfigurujemy resztę ustawień. Oto nasza typowa konfiguracja.

Jak wspomniałem na początku, możesz napisać własną procedurę importu/eksportu. Jednak wartość OASIS-SVN polega na tym, że możemy rozwiązać różne problemy związane z przechowywaniem plików tekstowych programu Access w kodzie źródłowym. Na przykład plik tekstowy programu Access może zawierać typowe pola u góry pliku:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
Są one złe dla kontroli kodu źródłowego, ponieważ mogą wprowadzać niepotrzebne zmiany i zanieczyszczać historię zmian, które tak naprawdę nie są zmianami. Suma kontrolna może się zmienić, nawet jeśli nie zmieniłeś niczego w samym formularzu. Dzięki OASIS-SVN możemy usunąć niepotrzebne dane za pomocą opcji Oczyść wyeksportowane pliki :
Version =21
VersionRequired =20
Begin Form
...
End Form
Być może zauważyłeś żółtą ikonę ostrzeżenia dotyczącą raportów. Powodem, dla którego tak jest, jest to, że OASIS-SVN usunie również dane drukarki, co jest bardzo złe dla kontroli kodu źródłowego. Gdy w raportach używana jest drukarka domyślna, zwykle nie stanowi to problemu. Jednak nierzadko tworzy się raporty zależne od konkretnej drukarki. Na przykład, może mamy raport, który tworzy etykietę z kodem kreskowym na specjalistycznej drukarce. W tym raporcie wybraliśmy konkretną drukarkę, a nie drukarkę domyślną. Zaznaczenie tego pola dla raportów oznacza, że ​​dane drukarki zostaną zdmuchnięte. Jeśli Twój projekt nie zależy od żadnej konkretnej konfiguracji drukarki, może być łatwiej sprawdzić raporty. W przeciwnym razie nie ma powodów, aby nie zaznaczać tego w formularzach.

Z podobnych powodów naprawdę uwielbiamy mieć pliki Split Form i pliki Split Reports opcja zaznaczona. Zwykle Aplikacja.SaveAsText wyeksportuje pojedynczy plik tekstowy dla pojedynczego obiektu programu Access. Jeśli jednak przeczytałeś plik tekstowy, zobaczysz, że kod układu może być… żmudny do czytania. Zaznaczenie tej opcji oznacza, że ​​otrzymujemy 2 pliki tekstowe na obiekt Access; jeden zawiera wszystkie dane układu, a drugi rzeczywisty kod źródłowy VBA za formularzem. To znacznie ułatwia przegląd kodu, ponieważ możesz skupić się na zmianach VBA i zrozumieć, co się zmieniło, co ułatwia zrozumienie, o co chodzi w zmianie układu.

Być może pamiętasz to z poprzedniej sekcji o Typach obiektów wybraliśmy zmienionego, co wymaga zapisania daty/czasu obiektu jako data/godzina pliku. Tutaj również jest to zaznaczone. Warto zauważyć, że program Access nie zawsze niezawodnie oznacza znacznik czasu podczas zmiany obiektów. Omówimy to ponownie w dalszej części poświęconej dokonywaniu zatwierdzeń.

Okienko integracji

Zwykle chcemy mieć pewność, że autokorekta jest zawsze wyłączona, ale ważniejsza jest opcja użycia Ctrl + S jako klucza do eksportu. Jest to bardzo pomocne i pozwala uniknąć problemu ze znacznikiem czasu obiektu Access. Wymaga to jednak dyscypliny, aby konsekwentnie używać skrótu klawiaturowego do zapisywania zmian. Za każdym razem, gdy uruchomisz klawiaturę, zobaczysz na krótko następujące okno dialogowe:

Zapewnia to, że drzewo robocze git jest zsynchronizowane z roboczym plikiem ACCDB podczas pracy nad zmianami. Ważne jest, aby podkreślić, że nie musisz się wstydzić częstego zapisywania – nie musi to oznaczać, że musisz zatwierdzać każdy zapis, ale dzięki częstym zapisom Twoje drzewo robocze będzie dokładnie odzwierciedlać zakres Twoich zmian, gdy będziesz są gotowi do popełnienia zobowiązania. Omówimy to szczegółowo w dalszej części.

Automatyczna aktualizacja przed importem i Automatyczne ZATWIERDZENIE po eksporcie może wydawać się wygodną rzeczą, ale w praktyce uznaliśmy, że znacznie lepiej jest robić to ręcznie, zwłaszcza gdy eksportujemy za pomocą skrótu Ctrl+S, ponieważ niekoniecznie chcemy zatwierdzać; zapisuj tylko naszą pracę w toku, abyśmy wiedzieli, co się zmieniło, gdy jesteśmy rzeczywiście gotowi do zaangażowania. Z tego powodu pomijamy je.

.oaza Plik ustawień

Po kliknięciu OK w oknie dialogowym ustawień zmiany wprowadzone w różnych panelach zostaną zapisane w .oasis plik w formie XML. Jak wspomniano, możesz go skopiować i utworzyć szablon, aby szybko skonfigurować inną aplikację Access. Jesteśmy teraz gotowi do rzeczywistej kontroli kodu źródłowego.

Eksportowanie i zatwierdzanie

Jak już wspomniano, ponieważ pracujemy z plikiem binarnym, musimy wyeksportować wszystko do reprezentacji tekstowej, aby można było nimi odpowiednio zarządzać przez kontrolę kodu źródłowego. Aby to zrobić, musimy wyeksportować obiekty. Możesz użyć przycisku eksportu OASIS-SVN, jak wskazano.

Otrzymasz okno dialogowe ze wszystkimi typami obiektów wymienionymi do eksportu. Ponieważ jest to nasz pierwszy eksport, użyjemy Ctrl + A aby wybrać wszystko do eksportu.

Kliknij OK, aby zakończyć eksport. Jeśli wszystko pójdzie dobrze, otrzymasz komunikat informujący o tym.

Jeśli zajrzysz do folderu źródłowego, zobaczysz wszystkie pliki tekstowe reprezentujące różne obiekty, które właśnie wyeksportowałeś. Zwróć uwagę, że konwencja nazewnictwa może się różnić w zależności od tego, co wybrałeś w okienku Ustawienia, jak pokazano w poprzedniej sekcji. Również dlatego, że zdecydowaliśmy się na dzielenie plików, mamy oba .def i .layout plik dla pojedynczego obiektu Access.

Po wyeksportowaniu obiektów jako plików tekstowych musimy teraz zatwierdzić nasze zmiany. OASIS-SVN zapewnia polecenia TortoiseGit bezpośrednio z programu Access, jak pokazano.

Zazwyczaj pokazane są tutaj 4 polecenia, których będziesz chciał użyć – inne polecenia są dobre w użyciu, ale nie musimy się o to martwić, dopóki nie przejdziemy do bardziej złożonych scenariuszy git. Nawiasem mówiąc, te polecenia są w rzeczywistości tymi samymi poleceniami, które są udostępniane przez TortoiseGit za pośrednictwem menu kontekstowego Eksploratora Windows:

Ponadto podzbiór poleceń jest dostępny za pośrednictwem menu prawego przycisku myszy w okienku nawigacji Dostęp:

W związku z tym masz kilka sposobów wykonywania pracy z OASIS-SVN lub z TortoiseGit bezpośrednio z programu Access, lub możesz po prostu użyć TortotiseGit bezpośrednio z eksploratora Windows. Pamiętaj, że masz Zatwierdź na wszystkich zrzutach ekranu; co będzie naszym kolejnym krokiem. Wybranie go otworzy okno dialogowe TortoiseGit:

Zazwyczaj będziesz chciał zaznaczyć wszystkie. Zauważ, że śledzi tylko pliki tekstowe, które umieściliśmy w folderze projektu. Ten punkt jest wart podkreślenia; jeśli nie wyeksportowałeś obiektu z programu Access, git prawdopodobnie nie może o tym wiedzieć. Musisz podać opisową wiadomość o zatwierdzeniu; im szczegółowe, tym lepiej. Wolimy również wykonać kilka małych zmian, ponieważ w ten sposób łatwiej jest zrozumieć historię. Nie chcesz robić zatwierdzenia raz w tygodniu z 1000 zmian; byłoby to niemożliwe do zrozumienia. Potrzebujesz zatwierdzenia po zakończeniu zadania (np. naprawienie konkretnego błędu lub wprowadzenie funkcji), aby Twoja historia była łatwa do zrozumienia.

Ponieważ przyzwyczajasz się do zatwierdzania swojej pracy, możesz chcieć zauważyć, że TortoiseGit daje ci 3 opcje zatwierdzania:

Ponownie zatwierdź jest przydatne, jeśli musisz wykonać wiele zatwierdzeń, ponieważ wykonałeś 2 lub więcej zadań i chcesz oddzielić zatwierdzenie dla każdego zadania. Prawdopodobnie najlepiej nie musieć tego robić i zatwierdzać zaraz po zakończeniu zadania, ale jeśli wpadniesz w podekscytowanie, po prostu zaznaczysz tylko podzbiór plików, które chcesz zatwierdzić, i kliknij ponownie. TortoiseGit zatwierdzi tylko te podzbiory plików, a następnie zresetuje okno dialogowe zatwierdzenia, abyście mogli zatwierdzić inne podzbiory plików za pomocą oddzielnej wiadomości.

Zatwierdź i naciśnij jest często używany do łączenia poleceń commit i push. Ważne jest, aby pamiętać, że commits zapisuje tylko do lokalnego repozytorium git. Ale zaczęliśmy od posiadania zdalnego repozytorium. Nie możesz udostępniać swoich zmian w kodzie współpracownikom ani mieć zdalnej kopii zapasowej swojej pracy, dopóki nie wypchniesz lokalnych zatwierdzeń na serwer, i po to jest push. Omówimy to szczegółowo później.

Kiedy zatwierdzisz, TortoiseGit zapewni ci okno dialogowe postępu i powiadomi cię, jeśli się udało.

Zawijanie

Do tej pory nauczyłeś się, jak skonfigurować repozytorium git, skonfigurować OASIS i wykonać pierwsze zatwierdzenie. Jednak to ledwo drapie powierzchnię. Pełna moc git nie jest jeszcze widoczna, dopóki nie przejdziesz do rozgałęziania, czytania historii i rozwiązywania konfliktów. Są to jednak rzeczy ściśle git i mają mniej wspólnego z Accessem lub OASIS; każdy ogólny przewodnik git, do którego już linkowaliśmy na początku artykułu, będzie bardzo pomocny w zrozumieniu, jak zarządzać repozytorium git. Warto przypomnieć, że TortoiseGit jest tylko cienkim opakowaniem GUI nad poleceniami git, więc nawet jeśli samouczek mówi o używaniu powłoki bash, powinieneś być w stanie zrobić to samo za pomocą menu TortoiseGit o tej samej nazwie. Mieć pytania? Zapytaj w komentarzach!