Databáze projektů: Git. Commit. Pull. Push a další

10 března, 2020 7 Čas na přečtení

V předchozím příspěvku na blogu jsme vám představili Git (systém pro správu verzí) a Github (cloudová hostingová služba) a způsoby, jak můžete sdílet svůj kód 4D s ostatními vývojáři. V tomto blogovém příspěvku půjdeme o něco dál a prozkoumáme některé scénáře, se kterými se vývojář může setkat, například klonování vzdáleného úložiště, ignorování již odevzdaných souborů a řešení konfliktů při slučování.

Předpoklady

Než budeme pokračovat dále, předpokládáme, že víte, jak vytvořit databázi projektu nebo převést binární databázi na projekt. Nainstalovaný systém Git na vašem počítači a účet na Githubu jsou povinné. Pokud je ještě nemáte, přečtěte si tento příspěvek na blogu, kde se dozvíte, jak postupovat.

Klonování vzdáleného úložiště

Je čas pokračovat v práci na naší aplikaci. Z nějakého důvodu však nemáte na svém počítači projekt, na kterém jsme pracovali minule. Co dělat?

Protože jsme vytvořili repozitář na GitHubu(předchozí příspěvek na blogu), existuje jako vzdálený repozitář. Nyní musíme vytvořit místní kopii na našem počítači a synchronizovat obě umístění. Jak postupovat?

Připojte se ke svému účtu Github,
Přejděte na hlavní stránku úložiště,
Klikněte na tlačítko„Klonovat nebo stáhnout“ a poté klikněte na ikonu schránky (jak je znázorněno na obrázku níže):
Otevřete terminál a označte umístění, kam chcete adresář naklonovat.
Zadejte příkaz git clone a vložte adresu URL, kterou jste zkopírovali v kroku 3.

Gratulujeme! Vytvořili jste místní kopii ve svém počítači.

gitignore

Nechci, aby git sledoval konkrétní soubor nebo složku.

Někdy máme v projektu soubory nebo adresáře, které nechceme sledovat. V takovém případě se hodí soubor .gitignore. Jak název napovídá, dává systému Git pokyn, které soubory, adresáře nebo vzory má v úložišti ignorovat.

V našem případě chceme, aby systém Git ignoroval složku Data (která obsahuje deník, předvolby, .4dd a složku DerivedData ).

Vytvoření souboru .gitignore

Konfigurace ignorovaných souborů/složek

Soubor.gitignore používá k porovnávání názvů souborů globbingové vzory. Vzory můžete sestavit pomocí různých symbolů. Chceme-li například ignorovat složku, připojíme na konec jejího názvu lomítko. Další informace o vzorech .gitignore najdete v tomto článku.

Ignorování souborů, které již byly odevzdány do úložiště

Mějte na paměti, že při vytváření nového úložiště byste měli vytvořit také soubor .gitignore pro všechny vzory souborů, které chcete ignorovat. Někdy se však stane, že proklouznou soubory, které chcete později ignorovat.

Nepropadejte panice! Stačí několik jednoduchých kroků a můžete úložiště vyčistit a zajistit, aby byly tyto položky ignorovány:

Soubory, které chcete odstranit, ale ponechte je na místě: git rm -r –cached
Zkontrolujte celý pracovní adresář a vyhledejte všechny nové, odstraněné nebo změněné soubory a přidejte je do indexu: git add
Odeslání souborů z oblasti staging do místního úložiště: git commit -m „Clean up ignored files“.
Odeslání změn do vzdáleného úložiště: git push

Voilà! Ve vzdáleném úložišti si můžete ověřit, že tam soubory nejsou!

Důležité upozornění: Ignorované soubory zůstávají v historii úložiště. Proto byste při vytváření nových úložišť měli vytvořit také soubory .gitignore, ve kterých uvedete všechny soubory, složky nebo vzory, které chcete ignorovat. V opačném případě, pokud nechcete, aby určité soubory zůstaly v historii, budete muset repozitář z Githubu odstranit a odeslat jej znovu.

Jak řešit konflikty při slučování

Především ZŮSTAŇTE V KLIDU!

Když v rámci jednoho systému správy verzí pracuje více vývojářů, stává se zvládání případných konfliktů každodenním úkolem. K dispozici je několik možností. Konflikt lze snadno vyřešit pomocí editoru 4D, ale protože všechny soubory jsou nyní textové, můžete k ručnímu řešení konfliktů použít také textový editor. Kromě toho je k dispozici mnoho nástrojů pro slučování, které lze integrovat do systému GIT. V níže uvedeném příkladu používáme k řešení konfliktů editor 4D.

Podívejme se na konflikt pomocí metody 4D. K tomu je nutné simulovat sekundárního uživatele / místní repozitář git duplikováním složky databáze a ujistit se, že obsahuje alespoň jednu metodu projektu. Nyní jsou k dispozici dvě databázové složky: my4DApplication a my4DApplication2. Dále otevřete obě aplikace.

1. Otevřete metodu projektu v první aplikaci a přidejte nějaký obsah (například komentář).
2. Pokud spustíte příkaz git status, zjistí se změny v metodě. Odevzdejte a odešlete nové změny.
3. Scénář: Někdo jiný upravuje stejnou metodu, ve stejnou dobu . Simulujme to tak, že otevřeme stejnou metodu v druhé aplikaci a upravíme ji jiným komentářem.
4. Odevzdejte a odešlete nové změny. Jak vidíte, push je odmítnut a místo toho je navrženo pull:
5. Spuštění navrženého git pull nepomáhá:

Co teď?

Otevřete metodu s konfliktem. Řádek s hlavičkou označuje místní změny a červený řádek číslo revize provedené druhým uživatelem.

Vyřešení konfliktu je snadné, stačí vybrat správné části kódu a změny odeslat. V tomto případě ponechávám obě zprávy ALERT s různými komentáři:

Jakmile je toto provedeno, může druhý uživatel spustit příkaz git pull a získat nové změny. Oba uživatelé nyní mají v metodě stejný obsah.

Abychom se vyhnuli konfliktům na prvním místě

Neexistuje žádný zaručený způsob, jak se konfliktům vždy vyhnout, ale spuštění příkazu git fetch vám může ušetřit spoustu starostí se slučováním. Zkontroluje, zda jsou ve vzdáleném úložišti nějaké nové revize. Pokud tak před pokusem o odeslání neučiníte, způsobí to chybu [Rejected].

Závěr

V tomto příspěvku jsme probrali různé scénáře, se kterými se vývojář při práci se systémem Git může setkat. V příštím příspěvku se odpoutáme od příkazového řádku a ukážeme si, jak při práci se systémem Git používat klienta s grafickým uživatelským rozhraním.