GIT
21.02.2021
Visual studio - Udělej Git jako aktivní repository system
Na CZPRGS031 je nainstalován GitHub aplikace, protože Git z VisualStudia se nedostane na github.com (err 443). Na mém DESKTOP-H0GEDQS vše funguje OK (Fetch, pull i push)
21.08.2021
zive dotaz na github - zde najdes i odkaz na knihu
15.01.2022
SCM --- Source Code Management – verzování historie uchovávaných informací nebo dat, nejčastěji pro sledování změn ve zdrojových kódech softwaru během jeho vývoje.
instalace dle příručky https://git-scm.com/book/cs/v2/%C3%9Avod-Instalace-syst%C3%A9mu-Git. https://desktop.github.com/
instalace git z https://git-scm.com/download/win (protoze to chce vs code a zaroven pak funguje git command)
git clone https://github.com/ZdenekPetrik/Photogallery -naklonuje fotogalerii do aktuální adresáře (tim ze smazes adresar bez push je to vlastne jen chytra kopie s git vlastnostmi. - Chytrost je v tom ze si pamatuje odkud byl naklonovan)
1.11.2022 Po CSOB
Vytvoření GIT projektu z ničeho. Chci zkusit Valáškovu aplikaci na Mysql a dát ji do Gitu. Vytvořil jsem si tedy nový projekt na GitHub.com a nazval jsem ho AltairMysql. Zároveň jsem na svém PC vytvořil adresář d:\Aplikace\Git\AltairMysql, kde jsem umístil soubor readme.md.
Nyní chci oba adresáře propojit.
git init -- K tomu nejprve potřebuji vytvořit Git adresář na PC. Jukni na .git
git add README.md -- Přidá soubor do adresáře a i do gitu (asi by stačilo pouhé vytvoření)
git remote add origin https://github.com/ZdenekPetrik/AltairMysql.git -- oznámím gitu kde je github - (viz config)
git branch -M main -- vytvořím branch
git commit -m "first commit" -- comitnu změny tj nový soubor Readme
git push -u origin main -- dám změny na github
Nyní mám první commit u sebe na githubu. Pro jistoytu si to ještě zkontroluji v aplikaci GitHub Desktop.
Konflikt
na serveru změním text v readme.md. Na PC změním text v readme.md. Udělám Commit (v GitHub Desktop). Pak chci udělat Push na GitHub, ale nejde to. Udělám tedy Fetch a Pull a dostaví se konflikt, Ten vyřeším přes nebídnutý editor z VS Code a je to.
git blame -- Zobrazí řádky souboru s prefixem kdo kdy udělal poslední změnu.
5.11.2022
Informace o GIT psáno poměrmně srozumitelně
1.6 Úvodní nastavení GIT
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession" nastavim editor např. pro řešení konfliktů, jinak použije systémový
git config --list seznam všech nastavení
1.7 Help
git help [příkaz]
git [příkaz] --help Ale když napíšeš git init help tak vytvoří help adresář jako git
man git-[příkaz]
Základy práce se systémem GIT
2.1. Získání repozitáře Git
Varianta 1 - inicializace, neboli z ničeho.
git init
git add *.c přidá sledování souborů *.c
git add LICENSE přidá konkrétní soubor. Chybí zástupné znaky *?[] - tak se jedná o jeden soubor. Koncové lomítko adresář
git commit -m "initial project version" Provede první commit
Máme vytvořený gitový adresář se sledovanými soubory v úvodní revizi. (Komit tvoří revizi)
Když teď uděláme další commit, tak jen dostaneme hlášku typu všechno čistý (nothing to commit, working tree clean). Když ale do adrsáře dáme nějaký soubor (a.a), který nesledujeme (untracking), dostaneme hlášku Untracked files a jméno souboru.
Varianta 2 - klonováním již existujícího adresáře.
git clone https://github.com/libgit2/libgit2 Vytvoří adresář libgit2 (v něm .git), stáhnou se všechna data pro repositář, a vytvoří kopii pracovní verze. Nejnovější. Protokol přenosu je zde https, ale může být i jiný (git,SSH). Důležité je vědět, že se kopíruje vše včetně starých verzí (změn). git clone není checkout.
2.2 Nahrávání změn do repozitáře
Figure 8. Cyklus stavů vašich souborů.
Každý soubor v pracovním adrsáři je ve stavu:
- untracked - nesledován. Buď není soubor nebo adresář add, nebo naopak pomocí .gitignore vyřazen. Historicky - všechny soubory, které nejsou obsaženy ve vašem předchozím snímku. Zde je trochu problém problém s podadresáři, protože to platí v root, ale když je monitorován celý podadresář, tak se automaticky dostává do stavu modified.
- tracked - Unmodified. - sledován, žádná změna
- tracked - Modified. - sledován změněn
- tracked - Staged. - sledován připraven k zapsání (je na scéně)
- Commit - (vytvoří historický snímek, zapíše revizi) přesune soubory ve staged opět do Unmodified. A někam uloží změny.
Kontrola stavu souborů
git status - Your branch is up to date with origin/master1 -> pracovní adresář je čistý. A nejsou tam žádné nové nesledované soubory. Ani na serveru žádná změna.
Pokud do pracovního adresáře přidáme nový soubor bude ho status v nesledovaných. Pokud ho přidáme přes git add ve výpisu se projeví jako Changes to by commited
Pokud v pracovním adresáři změním již sledovaný soubor projeví se mi jako Changes not staged for commit. Opět pomůže git add aby ho dal do stage. git add je víceúčelový. Přidávání nových, stageování sledovaných, řešení konfliktů. (Jinak tímto postupem se lze před git add ze stage vrátit k původní verzi). git add vlastně udává soubor na scénu ke komitu. Pokud provedem změnu souboru po git add opět se dostane do stavu že se změny do komitu nezapíšou. Čili jeden soubor lze do komitu zapsat i nezapsat. Zapíše se jen to co je ve staged.
git status --short První dvě písmena ve výpisu u každého souboru značí co se bude dít. První sloupec říká stage area, druhý sloupec pracovní adresář
- ?? Nesledován
- A Přidán
- M Modifikován
- D Odstraněn
- MM Modifikován, dán do stage a opět modifikován
- D Smazán v pracovní adresáři
.gitignore obsahuje masky souborů, které nechceme aby byly sledovány, nebo aby se vůbec vyskytovalu jako nesledované.
- *.[oa] soubory, které končí na o nebo a
- !lib.a ale sledul lib.a i když končí na a
- /TODO soubor TODO ignoruj jen v tomto adresáři, ale neignoruj podadresář TODO
- build/ ignoruj soubory v adresáři build
- doc/*.txtVčechny soubory *.txt v podadresáři doc. Ale né jinde ani v podadrsářích
- doc/**/*.txt dtto ale i v podadresářích
Problém je, pokud do gitignore zapíšeš masku k souboru, který je sledován. A třeba ho smažeš. Pak se smazání provede až po git add.
git status informuje jen o změnách globálně. Pokud chceš detailně po řádcích použij git diff.
git commit -a Všechno sledované do commit. Neboli nahrazuje zdlouhavé git add pro každý (sledovaný) soubor.
git rm file Odstraní soubor a to i ze sledování. Někdy je potřeba vynutit přes -f force. Pokud ještě nebyl zaznamenám do stage. Je smazání natrdo, na měko ho zapiš do .gitignore.
git rm log/\*.log. odstraní vše s příponou log v adresáři log.
git rm --cached file.log. Odstraní soubor co jste právě přidali do .gitignore
Přesouvání souborů se neeviduje. git nv oldname newname. Ale výsledek je stejný jako rm/add
git log. Zobrazí historii revizí.
git log -p -2 Jen poslední dvě revize. Zobraz rozdíly mezi nimi.
git log --pretty=format:"%h - %an, %ar : %s" co, kdy kdo commit text (subject)
git log --since=2.week. Omezení výstupu. Revize dle data. Dá se zadat datum, hledat dle autora, dle změny určitého stringu (např, jména funkce)
git commit --amend Připojí všechny změny k předchozí revizi. Lze tak do poslední revize přidáva/měnit/smazat soubory nebo měnit zprávu k revizi. "Vytvoř reviz znovu"
git reset HEAD <file> unstage - odstraní file ze stage (oblasti připravených změn).
git checkout <file> zahodí změny od poslední revize. Stashing - odloží změny na pozdější uložení.
Abyste mohli na gitových projektech spolupracovat, je třeba vědět, jak manipulovat se vzdálenými repozitáři (remote repositories). Vzdálené repozitáře jsou verze vašeho projektu umístěné na Internetu nebo kdekoli v síti. Vzdálených repozitářů můžete mít několik, každý pro vás bude přístupný buď pouze pro čtení (read-only) nebo pro čtení i zápis (read/write). Spolupráce s ostatními uživateli zahrnuje správu těchto vzdálených repozitářů a odesílání (push) a stahování dat (pull) v okamžicích kdy chcete práci sdílet. Při správě vzdálených repozitářů musíte vědět, jak lze přidat vzdálený repozitář, jak odstranit vzdálený repozitář, který už není platný, jak spravovat různé vzdálené větve, jak je určit jako sledované či nesledované a další věci. V této podkapitole se budeme zabývat některými z těchto dovedností.
git origin -v Zobrazí adresu github a zkrácený název (origin).
git remote add origin2 https://github.com/fullname/project takto jsi vytvořil nový vzdálený repositář se jménem origin2. Vzdálených repo můžeš mít více. Lze na ně mít práva read a read/write. origin2 je vlastně zkrácený název adresy https
git fetch <vzdálený repo> Zjistí změny na vzdáleném repo
git pull <vzdálený repo> Natáhne změny na klienta. provede automatický merge a pokud to nejde musíš sám provést merge
git push <vzdálený repo> <branch> Opak - všechny commits co máš na lokále dá na server.
git remote show origin zobrazí info o serveru a sledovaných větvích
2.6 Používání značek
git tag zobrazí značky (tags).
2.7 Aliasy v Gitu
2.8 Shrnutí
Git ukládá data jako s´érii snímků. (ne sérii změn nebo rozdílů - ale co to znamená nevím asi že se ukládá celá historie a né jen poslední soubory. Tím pádem je na každém klientu plná historie).
Součástí každého comitu je i nformace kdo a kdy ho vytvořil a zároveň odkaz na předka.
- git branch testing vytvoří novou větev
- git log log s ukazatelema na větve (větve máme dvě master je aktuální)
- git checkout testing přepne se do větve testing
- V souboru popis.txt provedu nějaké změny. Ty jsem ale provedl jen ve větvi testing. Na větev master se teď nedostanu.
- git commit -a -m "zmena ve vetvi testing" - změny komitnu (už se dostanu na větev master)
- git checkout master - změny nevidím
- git checkout testing - změny vidím
- git log --pretty=oneline --decorate hezky jednoradkovy vypis historie
g
