Source code management/pl

Wprowadzenie
Głównym narzędziem do zarządzania kodem źródłowym projektu FreeCAD jest Git, który może być łatwo zainstalowany w większości systemów operacyjnych z menedżera pakietów lub bezpośrednio z strony internetowej Git. Zaleca się zapoznanie się ze środowiskiem Git przed bezpośrednią pracą z kodem źródłowym FreeCAD. Odwiedź stronę dokumentacja Git, aby zapoznać się z podręcznikiem źródłowym, a także Pro Git book, aby nauczyć się korzystać z systemu w sposób ogólny. Niniejszy dokument koncentruje się na wykorzystaniu Git do rozwoju FreeCAD. Kompilacja programu FreeCAD jest opisana na stronie Kompilacja.

Chociaż Git jest przede wszystkim aplikacją terminalową, istnieje wiele klientów graficznych, które ułatwiają pracę z gałęziami, nanoszenie poprawek i wysyłanie żądań ściągnięcia do gałęzi głównej. Przykłady obejmują gitk (pierwszy opracowany interfejs graficzny), gitg (Gnome), qgit (Qt), tig (Ncurses), git-cola i GitKraken (własnościowy). Krótkie wprowadzenie do tego narzędzia można znaleźć w Rozwój FreeCAD z GitKraken.

Uwaga: jeśli to wszystko zaczyna przyprawiać cię o zawrót głowy, istnieje bardzo dobra nietechniczna seria o tym, jak używać Gita i Githuba, zatytułowana "Git i Github dla poetów".

Dostęp do kodu źródłowego
Każdy może uzyskać dostęp i kopię kodu źródłowego FreeCAD, ale tylko menedżerowie projektu FreeCAD mają do niego dostęp do zapisu. Możesz uzyskać kopię kodu, studiować go i modyfikować, ale jeśli chcesz, aby Twoje zmiany zostały włączone do oficjalnego kodu źródłowego, musisz wykonać "pull request" w stosunku do głównego repozytorium, aby Twoje modyfikacje mogły zostać sprawdzone przez menedżerów. Ten styl rozwoju jest znany jako Dyktator i porucznicy, ponieważ główni programiści (dyktatorzy) i zaufani programiści (porucznicy) filtrują kod nadsyłany przez niezależnych programistów i użytkowników.

Jeśli zmiany w kodzie źródłowym są znaczące, zaleca się wyjaśnienie ich w sekcji pull request na forum FreeCAD.



Oficjalne repozytorium GitHub
Kod źródłowy programu FreeCAD jest dostępny w serwisie Github, https://github.com/FreeCAD/FreeCAD

Aby móc wnieść swój kod, należy posiadać konto GitHub account.

W przeszłości kod źródłowy był przechowywany w repozytorium SVN, https://free-cad.svn.sourceforge.net/svnroot/free-cad. Przeniesiono je na GitHub, 10 października 2011 r. za pomocą commit 120ca87015.


 * W związku z tym istnieje wiele zmian, które zostały wprowadzone przed tym czasem, a które nie są zapisane we współczesnej historii commitów Git. Więcej na ten temat można przeczytać na stronie Historia.

Ustawianie nazwy użytkownika Git
Programiści powinni wysyłać kod do swojego osobistego repozytorium używając swojej nazwy użytkownika GitHub. Jeśli nie jest ona jeszcze ustawiona globalnie, można ją ustawić lokalnie dla bieżącego repozytorium Git w następujący sposób:

Gdzie reprezentuje twoje pełne imię i nazwisko lub pseudonim, używane do identyfikacji autora danego commitu, a  oznacza nazwę twojego konta na GitHubie.

Repozytoria zdalne
Proszę przeczytać Jaka jest różnica między origin a upstream na GitHubie? (Stackoverflow), aby pomóc w zrozumieniu różnicy między a  w kontekście Git. Ta sekcja wyjaśnia, jak ustawić właściwe repozytoria dla rozwoju. Zasadniczo:
 * to Twój osobisty fork oficjalnego repozytorium FreeCAD, czyli https://github.com/GITHUB_USERNAME/FreeCAD
 * to oficjalne repozytorium FreeCAD, czyli https://github.com/FreeCAD/FreeCAD.

To rozróżnienie jest ważne, ponieważ najpierw należy napisać kod we własnej kopii repozytorium, a dopiero potem przesłać zmiany do oficjalnego repozytorium.

W oparciu o powyższe informacje można skonfigurować środowisko programistyczne Git na dwa sposoby:
 * Pierwsza metoda: rozwidlenie na GitHubie i sklonowanie go lokalnie.
 * Druga metoda: sklonuj FreeCAD bezpośrednio na lokalnym komputerze i dostosuj zdalne serwery.

Zalecamy pierwszą metodę, ponieważ jest ona o jeden krok krótsza.

Metoda pierwsza: Rozwidlenie na GitHub i sklonowanie swojego widelca lokalnie
Najpierw rozwidlisz repozytorium FreeCAD na GitHubie, następnie sklonujesz to osobiste rozwidlenie na swój komputer, a na koniec ustawisz repozytorium.
 * Zaloguj się na swoje konto GitHub.
 * Przejdź do oficjalnego repozytorium FreeCAD: https://github.com/FreeCAD/FreeCAD
 * W prawym górnym rogu strony naciśnij przycisk "Fork". Spowoduje to utworzenie osobistej kopii repozytorium FreeCAD pod Twoją nazwą użytkownika GitHub:
 * Na swoim komputerze sklonuj nowo utworzony fork programu FreeCAD. Zostanie on utworzony wewnątrz katalogu.


 * Po zakończeniu pobierania wprowadź nowy katalog źródłowy i ustaw repozytorium.


 * Potwierdź swoje zdalne repozytoria za pomocą ; rezultat powinien być podobny do tego


 * Teraz można rozpocząć prace rozwojowe.

Metoda druga: Sklonuj FreeCAD bezpośrednio na swój komputer lokalny
Najpierw rozwidlisz repozytorium FreeCAD w serwisie GitHub, jednak oryginalne repozytorium FreeCAD sklonujesz na swój komputer lokalny, a następnie zmienisz swoje zdalne adresy za pomocą terminala.
 * Zaloguj się na swoje konto GitHub.
 * Przejdź do oficjalnego repozytorium FreeCAD: https://github.com/FreeCAD/FreeCAD
 * W prawym górnym rogu strony naciśnij przycisk "Fork". Spowoduje to utworzenie osobistej kopii repozytorium FreeCAD pod Twoją nazwą użytkownika GitHub:
 * Sklonuj oryginalne repozytorium FreeCAD. Zostanie ono utworzone wewnątrz katalogu.


 * Po zakończeniu pobierania należy wejść do nowego katalogu źródłowego i ustawić repozytorium.


 * Następnie należy skonfigurować repozytorium.


 * Potwierdź swoje zdalne repozytoria za pomocą ; rezultat powinien być podobny do tego


 * Teraz można rozpocząć prace rozwojowe.

Jeśli z jakiegoś powodu zdalne repozytoria istnieją, ale wskazują na niewłaściwy adres, możesz naprawić sytuację, zmieniając nazwę zdalnego repozytorium. Na przykład powinno wskazywać na Twój osobisty fork. Jeśli wskazuje na oryginalne repozytorium FreeCAD, zmień nazwę tego zdalnego na i ręcznie dodaj repozytorium.

Można również wyświetlić więcej informacji za pomocą słowa kluczowego.

Odgałęzienia
Zamiast pracować na głównej wersji kodu, najlepsze praktyki Git zalecają tworzenie nowej gałęzi za każdym razem, gdy chcesz pracować nad nową funkcjonalnością. Gałęzie są niedrogie, nie kopiują całego drzewa źródłowego, a jedynie tworzą punkt w czasie, na którym będziesz pisał kod. W ten sposób gałęzie pomagają oddzielić prace w toku od głównego kodu.

Korzystanie z nowej gałęzi odbywa się w dwóch etapach: najpierw należy utworzyć gałąź, a następnie przejść do niej:

Alternatywnie można wykonać obie czynności za pomocą jednej instrukcji:

Teraz możesz zmieniać gałęzie za pomocą, kiedy tylko chcesz nad nimi pracować. Aby zobaczyć gałęzie w projekcie i bieżącą gałąź, użyj samej operacji lub dodaj  lub, aby uzyskać więcej informacji:

Po wprowadzeniu zmian i ich zatwierdzeniu użyj operacji z następującymi opcjami, aby wyświetlić gałęzie

Committing
Gdy już znajdziesz się w nowej gałęzi, edytuj wybrane pliki źródłowe za pomocą edytora tekstu. Aby sprawdzić, które pliki zostały zmodyfikowane, użyj operacji i. Kiedy będziesz zadowolony z wprowadzonych zmian, zapisz je za pomocą operacji :

W przeciwieństwie do SVN, musisz wskazać, które pliki mają być commitowane. Użyj opcji, aby zapisać zmiany we wszystkich plikach, które zostały zmienione. Otworzy się edytor tekstu, na przykład lub, aby umożliwić napisanie wiadomości do zgłoszenia commit.

Ewentualnie dodaj wiadomość w samym zgłoszeniu commit:

Jeśli tworzysz nowe pliki lub katalogi, musisz najpierw użyć operacji, aby dodać je do lokalnego repozytorium przed zatwierdzeniem zmian.

Gdzie może być dowolnym katalogiem lub plikiem.

Pisanie dobrych komunikatów zgłoszeń commit
Powinieneś starać się pracować małymi krokami, czyli często zatwierdzać zmiany po wprowadzeniu niewielkiego dodatku do swojego kodu. Jeśli nie potrafisz streścić swoich zmian w jednym zdaniu, to prawdopodobnie minęło zbyt dużo czasu od wykonania zgłoszenia commit.

W przypadku dużych zmian ważne jest, abyś miał pomocne i przydatne opisy swojej pracy. FreeCAD przyjął format wspomniany w książce Pro Git, który składa się z krótkiej wiadomości, a następnie większego akapitu opisowego.

Jeśli wykonujesz wiele powiązanych prac w gałęzi, powinieneś wykonać wiele małych commitów (zobacz post na forum ). Gdy chcesz scalić te zmiany w gałęzi głównej, powinieneś wydać polecenie:

aby zobaczyć poszczególne komunikaty zgłoszeń commit. Dzięki temu można napisać wysokiej jakości komunikat podczas wykonywania scalania.

Kiedy łączysz się z wersją master, użyj opcji i wykonaj commit z wysokiej jakości komunikatem commit. To pozwoli ci być bardzo liberalnym w swoich zgłoszeniach commit i pomoże zapewnić dobry poziom szczegółowości w komunikatach commit bez tak wielu odrębnych opisów.

Squashing commits
Squashing odnosi się do procesu łączenia różnych kolejnych commitów w jeden. Może to być pożądane, jeśli wykonałeś wiele małych commitów, które chcesz przedstawić jako jeden commit, na przykład przy zmianie pojedynczej zmiennej, poprawianiu błędów ortograficznych i poprawianiu odstępów w kodzie. Powinieneś zgnieść tylko małe commit'y do pojedynczego pliku. Duże zmiany w kodzie w wielu plikach powinny zawierać pełną historię commit'ów.

Dzięki możesz zobaczyć wiele commitów po kolei, z najnowszym na górze. W tym przykładzie, zaczynając od "cechy A", powstało wiele commitów implementujących "cechę B"; chcielibyśmy zebrać wszystkie commity należące do "cechy B" w jeden.

Użyj operacji z opcją  lub, aby wybrać różne commity i je usunąć. Użyj hash commitu znajdującego się tuż przed pierwszym, który chcesz usunąć, w tym przypadku tego odpowiadającego "cechom A".

(WSKAZÓWKA: Jeśli wiesz, ile commitów chcesz edytować, możesz użyć, aby pracować na ostatnich commitach).

Edytor wiersza poleceń, taki jak lub, otworzy się, aby ponownie wyświetlić listę commitów, teraz ze starszym commitem na górze. Przed każdym commitem pojawi się słowo. Usuń słowo i wpisz w jego miejsce słowo  lub po prostu literę, z wyjątkiem pierwszego wpisu; ten commit jest najstarszy, więc wszystkie następne zostaną w nim zebrane.

Zapisz plik i zamknij edytor.

Edytor zostanie ponownie otwarty. Teraz możesz dodać dłuższy komunikat opisujący wszystkie zmiany, tak jakby były pojedynczym commitem. Zapisz plik i ponownie zamknij edytor. W ten sposób zakończysz łączenie tych commitów w jeden, z nowym komunikatem commit, który napisałeś.

Możesz użyć ponownie, aby zaobserwować historię nowych zgłoszeń commit. W tym przypadku pojawi się tylko pojedynczy commit dla "cechy B", na wierzchu niezmodyfikowanego commitu dla "cechy A".

Podczas kodowania dla FreeCAD prosimy, abyś rozpoczynał każdą wiadomość commit od modułu, którego dotyczy. Na przykład wiadomość commit dla zmiany w Szkicowniku może wyglądać następująco: Sketcher: make straight lines curve a bit

Straight lines are sort of ugly, so this commit adds a little bit of curvature to them, so they are more visually pleasing. They also sparkle some, and change colors over time.

Fixes bug #1234.

Twój PR będzie ułatwiał przeglądanie i szybciej zostanie scalony, jeśli będziesz uważał, aby używać rebase do strukturyzacji i opisywania swoich zgłoszeń commit przed wysłaniem.

Przesłanie pracy do repozytorium GitHub
Gałęzie lokalne na Twoim komputerze nie są automatycznie synchronizowane ze zdalnymi serwerami, które określiłeś jako lub  ( patrz Remote repositories). Musisz jawnie wysłać gałęzie na zdalne serwery, do których wymagany jest dostęp z prawem zapisu. Gdy to zrobisz, gałęzie staną się publiczne i dostępne do wglądu dla innych programistów.

W przypadku programu FreeCAD powinieneś przesłać swoją lokalną gałąź do zdalnego repozytorium, czyli do. Musisz podać swoją nazwę użytkownika i hasło za każdym razem, gdy wykonujesz push, chyba że ustawiłeś Buforowanie poświadczeń. Przeczytaj Pushing commit do zdalnego repozytorium, aby uzyskać więcej informacji.

Podczas pracy z pojedynczą gałęzią może zajść potrzeba wielokrotnego, interaktywnego przekształcania, usuwania i poprawiania zgłoszeń commit. W takim przypadku historia oddziału (branch) nie będzie prosta i nie będzie można jej przesłać do zdalnego repozytorium. Może pojawić się komunikat taki jak poniżej, mówiący, że nie jest możliwe wykonanie pchnięcia "fast-forward".

Aby ostatecznie przepchnąć swoją gałąź do zdalnego repozytorium, musisz wykonać "force push". Spowoduje to całkowite nadpisanie zdalnej gałęzi aktualną gałęzią, którą mamy w trybie offline.

Zwykły programista nie ma dostępu do zapisu w repozytorium https://github.com/FreeCAD/FreeCAD, dlatego nigdy nie należy umieszczać kodu na tym zdalnym serwerze.

Rebasing from upstream
Podczas gdy Ty pracujesz nad swoją własną gałęzią, oficjalny kod programu FreeCAD "idzie do przodu" dzięki zgłoszeniom commit innych deweloperów i w ten sposób zaczyna odbiegać od kodu, który masz w swoim osobistym forku.

.-A origin/myNewBranch / -o---Z FreeCAD upstream/master

Dlatego, gdy jesteś gotowy do połączenia swojego oddziału z głównym repozytorium FreeCAD, musisz "przebudować" swoją kopię repozytorium, tak aby była jak najbardziej zbliżona do oficjalnego repozytorium. Zapoznaj się z treścią Git Branching - Rebasing, aby uzyskać więcej informacji.

Spowoduje to pobranie kodu z gałęzi repozytorium  (oficjalne źródło programu FreeCAD) i scalenie go z Twoją bieżącą gałęzią, tak aby Twoje zmiany znalazły się na wierzchu najnowszego oficjalnego kodu. Jeśli nikt nie zmodyfikował tych samych plików, co Ty, to scalenie przebiegnie bez problemów. Jeśli niektóre pliki zostały zmienione w tym samym czasie przez różne osoby, może istnieć konflikt, który należy rozwiązać.

.-A' origin/myNewBranch / -o---Z FreeCAD upstream/master

Podsumowując, trzeba być w odpowiedniej gałęzi, przebudować kod do wykonania upstreamu, a następnie wykonać push.

Operacja jest równoważna operacji, po której następuje. Gdy użyta jest opcja, zamiast prostego wykonywana jest operacja.

Scalanie gałęzi (pull request)
Po lokalnym wprowadzeniu zmian, przebudowaniu swojej gałęzi z repozytorium upstream i umieszczeniu swojej gałęzi online, możesz zainicjować "pull request". Prośba pull request mówi administratorom oficjalnego repozytorium FreeCADa, że chcesz połączyć nowy kod w swojej gałęzi z oficjalnym kodem.

Podsumowując, proces rozwoju wygląda następująco:
 * 1) Utwórz fork programu FreeCAD i uzyskaj lokalną kopię tego forka.
 * 2) Utwórz gałąź na swoim rozwidleniu i zmień na tę gałąź.
 * 3) Koduj! Udostępniaj tyle lub tak mało, jak chcesz, pisząc dobre komunikaty commit, aby śledzić, co robisz.
 * 4) Gdy będziesz zadowolony ze swojej pracy, użyj  (gdzie n jest całkowitą liczbą zgłoszeń commit, które wykonałeś), aby zebrać swoje commity w logiczny zestaw z dobrymi komunikatami do zgłoszeń commit (każdy komunikat powinien zaczynać się od nazwy modułu, którego dotyczy, np. "Sketcher: make straight lines curve bit").
 * 5) Użyj GitHuba, aby przesłać swój kod jako "Pull Request (PR)", jak opisano poniżej.

Gdy tylko umieścisz kod w swoim repozytorium, GitHub da Ci możliwość porównania i utworzenia pull requestu do repozytorium. Po naciśnięciu przycisku otworzysz interfejs, który pozwoli Ci wybrać, które repozytorium jest "bazą", czyli celem scalania, a które "głową", czyli Twoim dodatkowym kodem. System szybko sprawdzi, czy nie ma konfliktów z plikami, które zmodyfikowałeś. Jeśli pracowałeś nad plikami, których nikt nie dotykał, twoja gałąź będzie mogła zostać scalona bez problemów.

GitHub wyświetli edytor tekstu, w którym można napisać wiadomość dokumentującą zmiany: edytor ten będzie wstępnie wypełniony wiadomością powitalną (którą można usunąć), listą kontrolną (którą należy przejrzeć) oraz przypomnieniem o konieczności udokumentowania zmiany na wiki, gdy zostanie zaakceptowana. Aby skorzystać z listy kontrolnej, przejdź przez każdy element po kolei i zmień na, aby zaznaczyć, że wykonałeś dany krok. GitHub wyświetli także liczbę commitów w Twojej gałęzi, liczbę plików, które zostały zmodyfikowane, oraz widok pokazujący różnice między "bazą" a "głową", aby każdy mógł natychmiast zobaczyć, jakie są Twoje zamierzone modyfikacje. Sprawdź dwukrotnie, czy nie ma tam takich rzeczy, jak zabłąkane puste linie, których nie chciałeś dodać, lub ogromne zmiany formatowania, które IDE postanowiło wprowadzić za Twoimi plecami.

Kliknij, aby kontynuować. Pojawi się komunikat informujący, że kod musi zostać sprawdzony. Jest to system, który automatycznie kompiluje program FreeCAD i uruchamia testy jednostkowe. Jeśli testy przejdą pomyślnie, pull request będzie miał większe szanse na połączenie z głównym kodem, w przeciwnym razie zostanie sporządzony raport wskazujący napotkane błędy. Zobacz FreeCAD pull requests.

Some checks haven’t completed yet


 * continuous-integration/travis-ci/pr Pending — The Travis CI build is in progress |Required|

Jeśli testy zakończą się powodzeniem, pojawi się komunikat taki jak poniżej:

All checks have passed


 * continuous-integration/travis-ci/pr — The Travis CI build passed |Required|

Ta gałąź nie ma konfliktów z gałęzią podstawową Tylko osoby z prawem zapisu do tego repozytorium mogą łączyć zgłoszenia pull request.

Teraz musisz poczekać, aż administratorzy połączą Twoją gałąź. Zostaniesz o tym poinformowany.

Jeśli chcesz, możesz usunąć gałąź, która została właśnie scalona, a nawet cały swój fork programu FreeCAD, ponieważ Twój własny kod jest już dołączony na końcu gałęzi głównej.

możesz kontynuować pracę na tej samej gałęzi, czekając na zatwierdzenie scalenia. Jeśli ponownie wykonasz, drugi commit scalenia zostanie umieszczony w kolejce w tym samym żądaniu ściągnięcia, a kolejny automatyczny test zostanie wykonany. Oznacza to, że podczas gdy twoje scalenia nie są jeszcze zatwierdzone przez administratorów, możesz nadal wysyłać zmiany do swojego repozytorium, a to spowoduje umieszczenie tych zgłoszeń commit w kolejce tego samego żądania wyciągnięcia do repozytorium. Używanie pojedynczego żądania pull do kolejkowania wielu pojedynczych zgłoszeń commit jest często pożądane w przypadku małych zmian. W przypadku dużych zmian w kodzie źródłowym, należy utworzyć inną gałąź, rozwijać w niej swoje funkcje, a następnie wysłać osobne żądanie pull request dla tej gałęzi.

Przetłumaczono z www.DeepL.com/Translator (wersja darmowa)

Interfejs pull request może być używany za każdym razem, gdy chcesz przesłać kod z własnego repozytorium do innego repozytorium w GitHubie. Można go również używać do scalania kodu w odwrotnym kierunku, z gałęzi innych osób do własnej, a nawet pomiędzy własnymi gałęziami. W tym ostatnim przypadku, ponieważ jesteś właścicielem gałęzi, możesz od razu zatwierdzić scalanie.

Utrzymywanie aktualnego repozytorium GitHub
Po rozwidleniu FreeCAD, Twoje osobiste repozytorium istnieje niezależnie od oryginalnego. Kiedy oryginalne repozytorium będzie miało nowe zgłoszenia commit, GitHub poinformuje Cię, że Twoje osobiste repozytorium jest opóźnione pod względem liczby zgłoszeń commit:

W podobny sposób, jeśli utworzyłeś gałąź rozwojową z nowym kodem, GitHub poinformuje Cię, że ta gałąź wyprzedza Cię w liczbie zgłoszeń commit. To znaczy, że ta gałąź zawiera zmiany, które nie zostały jeszcze scalone z oficjalnym repozytorium FreeCAD:

Podczas rozwijania możliwe są oba przypadki, ponieważ Twoja własna gałąź może nie zawierać zgłoszeń commit innych deweloperów, ale zawierać nowe, napisane przez Ciebie:

Podczas tworzenia kodu zaleca się, abyś zmienił bazę gałęzi, w której aktualnie pracujesz, ponieważ dzięki temu Twoja gałąź będzie zawsze wyprzedzać kod główny FreeCAD.

Jeśli chodzi o twoją oryginalną gałąź, to nigdy nie będzie ona automatycznie aktualizowana przez GitHub. Musisz o to zadbać samodzielnie. Przełącz się na gałąź, a następnie z  (co spowoduje pobranie  i ), a następnie przepchnij zaktualizowaną gałąź  do swojego zdalnego repozytorium.

Po wykonaniu tych czynności GitHub poinformuje Cię, że jesteś zsynchronizowany z repozytorium.

Teraz, gdy twój jest aktualny, możesz zdecydować się na przejście do niego i usunąć inną gałąź, której używałeś wcześniej do rozwijania funkcji.

Aby usunąć gałąź w zdalnym repozytorium, można użyć operacji. Zwykle pcha się lokalną gałąź. Spowoduje to utworzenie zdalnej gałęzi o tej samej nazwie co lokalna.

Jeśli jednak użyjesz zapisu, lokalna gałąź zostanie utworzona w zdalnym repozytorium pod inną nazwą:

Dlatego można usunąć zdalną gałąź, przesuwając pustą gałąź lokalną:

Teraz, gdy masz już tylko aktualny, możesz utworzyć nową gałąź i powtórzyć kroki zmiany plików, zgłoszenia commit, push, wysłania pull request, scalenia i aktualizacji.

Jeśli nie chcesz usuwać swojej już niestandardowej gałęzi, możesz wymusić jej aktualizację tak, aby była równa zaktualizowanej gałęzi ; następnie możesz zrobić z nią, co tylko chcesz, włączając w to dodawanie kolejnych zgłoszeń commit i wypychanie jej do zdalnego repozytorium.

Takie twarde resetowanie gałęzi zwykle nie jest potrzebne. W większości przypadków należy wykonać następujące czynności: utworzenie nowej gałęzi, wprowadzenie zmian, przepchnięcie tych zmian, scalenie gałęzi, a następnie usunięcie gałęzi.

Wyszukiwanie
Oto kilka przydatnych narzędzi, które pomogą Ci znaleźć to, czego szukasz:

Wyszukiwanie plików według nazw
Użyj, aby przeszukać repozytorium w poszukiwaniu plików, które zawierają w nazwie określony ciąg znaków. Poniższy przykład zwróci wszystkie przypadki plików, które zawierają w nazwie ciąg 'dxf'.

Wyszukiwanie ciągu znaków
Użyj, aby przeszukać repozytorium w poszukiwaniu plików, które zawierają określony ciąg znaków w samych plikach. Poniższy przykład zwróci wszystkie wystąpienia plików, które zawierają "dxf" w każdym z nich.

Rozwiązywanie konfliktów scalania
Łączenie gałęzi za pomocą, lub zmiana lokalizacji gałęzi za pomocą , może czasami powodować konflikty, ponieważ pliki mogły być modyfikowane przez innego autora w tym samym czasie. Jeśli tak się stanie, powinieneś zobaczyć zmiany obu stron, autora i swoje własne, a następnie podjąć decyzję, jak uwzględnić oba zestawy zmian w najlepszy możliwy sposób. Jest to zwykle proces ręczny, którego nie da się zautomatyzować; programista musi zrozumieć kod i zdecydować, jaki kod przenieść, przerobić lub usunąć, aby rozwiązać konflikt.

Po wystąpieniu konfliktu może zostać wyświetlony komunikat podobny do tego.

Jeśli dla projektu Git jest zainstalowane i skonfigurowane specjalistyczne narzędzie diff, na przykład program Meld firmy Gnome, konflikt można zbadać i rozwiązać za pomocą operacji.

Narzędzie Scalanie zwykle wyświetla trzy kolumny; dwie kolumny po bokach wyświetlają dwa sprzeczne pliki, natomiast kolumna pośrodku wyświetla nowy kod, który zostanie zapisany i ostatecznie zatwierdzony. Dlatego też środkowa kolumna powinna być edytowana w taki sposób, aby scalała kod z obu kolumn bocznych. Po rozwiązaniu konfliktu i zapisaniu nowego kodu źródłowego (kolumna środkowa) można zamknąć narzędzie Meld. Następnie można kontynuować operację lub.

Więcej informacji o scalaniu i rozwiązywaniu konfliktów można znaleźć na stronach:
 * Jak są przedstawiane konflikty scalania z.
 * Podstawowe konflikty scalania i Narzędzia Git - Zaawansowane scalanie.
 * Rozwiązywanie konfliktu scalania za pomocą wiersza poleceń.
 * Zewnętrzne narzędzia do scalania i dyfuzji, których można użyć po napotkaniu konfliktu w programie Git.

Sprawdzanie zmian
Sprawdź historię pojedynczego pliku dla różnych zgłoszeń commit za pomocą operacji :

Gdzie może być dowolnym katalogiem lub plikiem. Zamiast można również użyć skrótów  lub.

Sprawdzanie zmian między dwoma gałęziami
Sprawdź zmiany między dwiema gałęziami za pomocą operacji i  z podaniem nazw gałęzi:

Operacja pokazuje zgłoszenia commit, natomiast  pokazuje rzeczywiste zmiany w plikach.

Resetowanie plików i katalogów
Jeśli przypadkowo wprowadzono modyfikacje w pliku lub katalogu, może być konieczne całkowite odwrócenie tych zmian, aby uzyskać poprzedni stan kodu źródłowego.

Można to szybko wykonać za pomocą operacji :

Spowoduje to przywrócenie (plików lub katalogów) do stanu z początku gałęzi, odrzucając zmiany, które nie zostały zatwierdzone. Jeśli jest pojedynczą kropką, to przywróci wszystkie pliki w bieżącym katalogu.

Jeśli przez przypadek dodano pliki i katalogi, można użyć operacji :

Spowoduje to wymuszone usunięcie wszystkich plików i katalogów, które nie są śledzone przez repozytorium, czyli takich, które nie zostały wcześniej dołączone za pomocą operacji.

Aby całkowicie zresetować repozytorium, tracąc wszystkie niezaangażowane modyfikacje, należy użyć operacji :

Gdzie jest wierzchołkiem repozytorium. Można też użyć innego zgłoszenia commit.

Operacja również odwraca zmiany. Jednak to polecenie robi to przez dodanie kolejnego zgłoszenia commit do historii. W wielu przypadkach nie jest to pożądane.

Obcinanie starych gałęzi
Jeśli wysłałeś wiele gałęzi do repozytorium, możesz chcieć usunąć te gałęzie ze swojego lokalnego systemu, ponieważ zostały już scalone. Gałąź w repozytorium online może zostać usunięta natychmiast po scaleniu. Następnie można usunąć lokalne odwołania do tej gałęzi, używając opcji lub  w operacjach  i.

Na koniec można usunąć gałęzie lokalnie:

Dobrą praktyką jest również odśmiecanie repozytorium po pewnym czasie za pomocą operacji. Spowoduje to wyczyszczenie niepotrzebnych plików i skompresowanie lokalnych rewizji plików, aby zoptymalizować wykorzystanie lokalnego dysku w repozytorium.

Praca z łatkami
Chociaż Git pozwala na łączenie różnych gałęzi kodu za pomocą (na swoim komputerze) lub pull request (w zdalnym repozytorium), to jednak zdarzają się sytuacje, w których pożądane może być utworzenie tradycyjnej "łatki" (patch), którą można wysłać jako załącznik przez e-mail. Poniższy przepływ pracy wyjaśnia, jak to zrobić.

Tworzenie łatek

 * Nowy kod powinien być rozwijany w gałęzi dodatkowej repozytorium, a nie w gałęzi głównej. Dlatego pierwszym krokiem jest upewnienie się, że znajdujesz się we właściwej gałęzi.


 * Teraz użyj względem gałęzi master i użyj opcji, aby przekierować wynik na standardowe wyjście. Następnie przekieruj standardowe wyjście do pliku, który dla wygody jest tworzony powyżej katalogu z kodem źródłowym.


 * Inną metodą jest

Liczba znaków nawigacyjnych lub liczba  wskazują liczbę zgłoszeń commit, które należy wziąć pod uwagę, czyli  lub  utworzą trzy poprawki dla trzech zgłoszeń commit.

Spowoduje to utworzenie łaty lub serii łat zgodnie z następującą konwencją nazewniczą

gdzie jest liczbą od  do, a komunikat commit stanowi większą część nazwy pliku, np,

Stosowanie łatek
Git może scalać poprawki lub różnice. Aby dowiedzieć się więcej o tym procesie, przeczytaj stronę Stosowanie poprawek za pomocą Git.

Jeśli plik z poprawką znajduje się już w systemie, wystarczy go zastosować.

Można użyć, aby pobrać łatę z witryny internetowej, a następnie zastosować ją za pomocą.

Dodaj lub  na końcu adresu URL zgłoszenia commit, pull requestu lub widoku porównania na GitHubie, aby na stronie był wyświetlany zwykły widok tekstowy.
 * Zwykła strona zgłoszenia commit: https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621
 * Strona porównania: https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.diff
 * Strona poprawki: https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch

Możesz wskazać na konkretne zgłoszenie commit poprawki w repozytorium i przesłać go bezpośrednio do, aby zastosować poprawkę.

curl https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch | git apply -

Cofanie poprawki
Podczas stosowania poprawki modyfikuje się niektóre pliki. Modyfikacje te nie są jednak trwałe, dopóki nie zatwierdzisz zmian. Dlatego jeśli chcesz cofnąć poprawkę, skorzystaj z poniższych instrukcji.

Spowoduje to cofnięcie wprowadzonych zmian, jeśli nadal masz dostęp do oryginalnego pliku poprawki.

Alternatywnie, spowoduje to usunięcie niezaakceptowanych zmian w gałęzi.

Przechowywanie zgłoszeń commit git
Powiedzmy, że pracujesz nad gałęzią i okazuje się, że dokonujesz pewnych modyfikacji w źródle, które wykraczają poza zakres bieżącej gałęzi. Innymi słowy, te zmiany byłyby lepsze w innej gałęzi, a nie w bieżącej. Polecenie może być użyte do tymczasowego przechowywania tych niezaangażowanych zmian lokalnych.

Jeśli w przyszłości będziesz chciał użyć tych zgłoszeń commit, możesz je "wyciągnąć" ze schowka i umieścić w swojej gałęzi roboczej.

Jeśli zdecydujesz, że nie lubisz już tych zapisanych zgłoszeń commit, możesz całkowicie usunąć je ze schowka.

Można wyświetlić listę wielu schowków dla zgłoszeń commit za pomocą:

Aby dowiedzieć się więcej, przeczytaj Przydatne sztuczki, których możesz nie wiedzieć o schowkach Git.

Sprawdź lokalnie żądania z GitHub
Checkout GitHub pull requests locally

Obciążanie winą
Dodaj zawartość z witryny https://forum.freecadweb.org/viewtopic.php?f=23&t=55943&p=481483#p481287

Bisect
Jest to metoda umożliwiająca znalezienie konkretnego zgłoszenia commit, które wprowadziło błąd.

Musisz znaleźć dwa zgłoszenia commit:
 * Prawidłowy commit (na przykład ) przed uszkodzeniem systemu.
 * Nieprawidłowy commit (na przykład ) po uszkodzeniu systemu.

Potem w terminalu wprowadź następujące dane:

Wynik: Polecenie sprawdzi spójność między dwoma zgłoszeniami commit.

Następnym krokiem jest zbudowanie i przetestowanie kodu. Jeśli system działa, kontynuuj proces, wpisując:

Powtórz poprzedni etap budowania kodu i jego testowania.

Jeśli system jest uszkodzony, wpisz:

Powtórz poprzednie kroki, stosując lub  w zależności od wyników testów.

W końcu powie ci, że  jest pierwszym błędnym commitem.

Na koniec, aby zakończyć proces bisect, wpisz:

Uwaga: zajmuje dużo czasu, jeśli obszary poprawne i błędne są odległe od siebie.

Numer rewizji FreeCAD
W przeciwieństwie do subversion, które używa kolejnych numerów dla swoich rewizji, Git tworzy SHA-1 hash values z każdym zgłoszeniem commit. Wartość skrótu to długi alfanumeryczny ciąg znaków, który wygląda następująco

Numer ostatniej wersji
Aby znaleźć numer ostatniej rewizji w konkretnym oddziale, należy użyć operacji z opcją. Podaj nazwę gałęzi, zdalnego repozytorium, znacznika lub specjalny wskaźnik, taki jak, aby wskazać ostatni commit w tym konkretnym obiekcie.

Można też przejrzeć repozytorium na GitHubie i zapoznać się z liczbą zgłoszeń commit zgłoszonych w danej gałęzi.

Numer wersji określonego hasha zatwierdzenia commit
Ponieważ hash jest łańcuchem alfanumerycznym, nie jest zbyt użyteczne określanie, czy dany commit jest starszy czy nowszy od innego hasha. Aby znaleźć numer rewizji określonego hasha, ponownie użyj operacji ; dane wejściowe mogą być pełnym hashem lub częściowym hashem, który jest unikalny, zwykle wystarczy pierwsze 7 cyfr.

Hash wersji określonego numeru zatwierdzenia commit
Jeśli mamy numer commit, powiedzmy 15000, i chcemy znaleźć odpowiadający mu hash, musimy obliczyć liczbę zgłoszdeń commit od tego momentu do ostatniego commitu. Najpierw należy uzyskać numer ostatniego zgłoszenia commit.

Następnie należy odjąć numer zgłoszenia commit

Następnie użyj operacji, aby wyświetlić wszystkie zatwierdzenia i hashes. Opcja przeskakuje różnicę w zatwierdzeniach, które obliczyliśmy, dzięki czemu przechodzimy bezpośrednio do hasza, którego szukamy.

Since the log may show you two close commits, confirm it's the right commit number. If it's off by one, just pick the next commit in the sequence (before or after) and check again.


 * Show the commits immediately before a particular commit in GitHub: in the address bar of the browser, change the word to  to show a list.
 * Finding the revision number of the commit
 * Finding the revision number of the commit
 * Finding the corresponding hash value to a particular commit number

Revision number in FreeCAD's interface
The version number that appears with the Std About tool is defined in, which is created at compile time when the tool is run. Read Extract version number from git source for more information.

Adding other repositories (remotes)
Several collaborators of the FreeCAD project have their own Git repositories where they build up their work or where they experiment new ideas before they are ready to be included in the official source code. You may want to get their sources in order to test their code yourself when they make a pull request.

Use the command to add these other repositories so that you can  and  their code.

For example, lets add Bernd's remote repository:

The command downloads the references from that remote repository.

List all branches in your own repository, and those from your added remotes. Bernd's branches will display as.

Now, lets view a summarized list of the last 10 commits of bernd's branch.

Now we can checkout the desired branch to inspect.

Then we can create a local branch that is based on the remote branch. This local branch we can modify, and add our own code to it.

You may wish to the newly obtained branch onto the  branch to make sure it is using the latest code. If there are conflicts, they will have to be solved at this point.

The new branch is ready to be modified and compiled as described in Compiling.

Head to the development section of the FreeCAD forum to discuss more about development.