| Autor | Zpráva | ||
|---|---|---|---|
| andynewcastleth Profil |
#1 · Zasláno: 7. 6. 2020, 10:59:37
Prozatím tomu rozumím následovně.
Někdo v týmu na Githubu založí projekt. Já si naklonuji do svého počítače master z tohoto projektu. Na svém počítači si vytvořím branch. Svoji práci odvedu v této branch. Zpět na Github nahraji pouze tuto branch. Následně požádám, aby tato branch byla spojena s masterem. Funguje to na tomto principu? --- Co v případě, kdy původní master na serveru již byl změněn? Nahraji svoji branch jako by se nic nedělo (a správce projektu vyřeší konflikty). Nebo tuto změnu masteru musím nějak reflektovat v mé branch před nahrátím? |
||
| mckay Profil |
#2 · Zasláno: 7. 6. 2020, 11:04:35
andynewcastleth:
„Funguje to na tomto principu?“ Ano, často ano. „Nebo tuto změnu masteru musím nějak reflektovat v mé branch před nahrátím?“ Většinou je očekávané, že konflikty vyřešite vy, ne správce projektu. V principu to uděláte tak, že si před nahráváním své branch na github stáhnete nejnovější master a lokálně zamergujete master k sobě. Až potom pak vytváříte pull/merge request. |
||
| juriad Profil |
Existuje několik modelů, zjednoduším to na dva:
Centralizovaný - jste jeden tým, všichni si věříte, máte na Githubu jeden repozitář, ke kterému mají právo na zápis všichni. V tomto případě si skutečně naklonuješ přímo to repozitory. Distribuovaný - každý vyvíjíte na své triko. Často se neznáte, jen spolupracujete na jednom projektu, protože každý máte trochu jiné potřeby, nebo množství práce převyšuje možnosti jednoho autora. Každý autor má svůj vlastní repozitář; odvozený (forknutý) od jednoho "oficiálního". Každý repozitář žije samostatné a jednotlivý autoři je udržují synchronizované (Github tomu napomáhá). V obou případech pushuješ svou větev, která může být nekompatibilní s nejnovějšími změnami v té oficiální master větvi. Je většinou tvá zodpovědnost vyřešit konflikty. Jedna možnost je merge (jak zmínil mckay), ale možná je lepší rebase. Obojí má své výhody a nevýhody. Často do master větve nemá právo na zápis vůbec nikdo, všechny změnu musí být začleněny skrz Pull Request. Občas se může stát, že ty nastřelíš nějakou změnu ve své větvi, ale nejsi schopný ji dokončit. Pak nějdo jiný může svou větev vytvořit z tvé a pokračovat v práci. Představ si, že najdeš chybu v knihovně pro XYZ. Tu knihovnu si forkneš a ve své větvi opravíš (třeba jen pro sebe) a změněnou ji používáš. Vytvoříš PR do hlavního repozitáře, je obecně přijmuto, že je to chyba a že tvé řešení ji opravuje, ale tvoje změna nespolňuje všechny kritéria pro začlenění. Můzou chybět testy, dokumentace, špatné formátování, mohl jsi vyřešit jen část většího problému, tvoje změna může rozbít něco jiného... Někdo jiný (možná i oficiální správce knihovny) tvoji opravu může dokončit a pak za sebe vytvořít nový PR, který bude přijatý. Git škáluje dobře od práce jednotlivce až po největší projekty na planetě. Viz též git-scm.com/book/cs/v2/Distribuovan%C3%BD-Git-Distribuovan%C3%A9-pracovn%C3%AD-postupy |
||
| andynewcastleth Profil |
#4 · Zasláno: 7. 6. 2020, 17:03:44
Fork tedy momentálně nechci, nyní preferuji nahrání branch a pull request. Děkuji za teoretické vysvětlení.
Vše jsem zatím chápal dokud jsem si lokálně dělal commity, branche a přecházel mezi nimi a nahrával je na Github. To bylo OK. Nyní ale s clonování.... ------------------ Pokud si naklonuji repository git clone https://... a následně udělám git branch, tak vidím pouze master. Aby jsem viděl i branche, tak musím udělat git clone -a (což zobrazí skryté branche). Pokud chci pokračovat v práci na některé z branches, tak udělám git checkout MojeBranch nebo git checkout remotes/origin/MojeBranch? Je to vůbec v pořádku? Mohu takto vstoupit do branche, i když je skrytá?
Následně by jsem odvedl nějakou práci v branche. Moje práce je skončena. Zadám git fetch, který mi sdělí, že mezitím byl změněn master. Tedy vstoupím do mastera git checkout master synchronizuji jej git pull origin master. Čím se udělá merge remote mastera s mým masterem a i merge remote branches s mými branches. Zde budu muset vyřešit konflikty. A jakmile konflikty vyřeším, tak na Github nahraji moji práci v mé branch git push -u origin MojeBranch.
Mýlím se moc? :) |
||
| juriad Profil |
#5 · Zasláno: 7. 6. 2020, 22:07:21
Nic jako skrytá větev neexistuje. Jsou jen lokální a vzálené (remote) větve.
Když provedeš git clone, tak se ti stáhne celý repozitář včetně všech vzdálených větví, ale vytvoří se ti jen jediná lokální větev (master).
Kdykoli provedeš git checkout CizíVětev, tak se ti vytvoří lokální větev stejného jména. Obvykle tedy git clone -a není potřeba, protože si vytváříš větve, až když je potřebuješ.
git branch -a ti ukáže lokální i vzdálené větve.
git checkout remove/origin/CizíVětev nefunguje (je tam to remote/ navíc), ale git checkout origin/CizíVětev funguje. Přesto není vhodné to používat, protože výsledkem je, že nejsi na žádné lokální větvi, budeš na commitu, na který vzdálená větev ukazuje:
You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. git pull origin master aktualizuje master, a pokud jsi ty do masteru nic necommitoval, tak to bude bezproblémové. Toto však nikterak nezasáhne tvoji branch. Každou branch musíš "aktualizovat" zvlášť. Obvykle nemá smysl větve aktualizovat, dokud je nechceš checkoutnout.
Ve svojí branchi můžeš buď: 1) zamergovat master; git merge origin/master; snažší varianta, ale prasáčtější; historie pak obsahuje zbytečné merge. Při mergi řešíš konflikt jednou.
2) rebasnout se nad master: git rebase origin/master; magičtější a občas repetetivní, je jednoduché se ztratit. Pří rebasu řešíš konflikty každého svého commitu.
Všimni si, že tady doporučuji uvádět celý název origin/master, protože takto nemusíš napřed aktualizovat svůj master. Můžeš to provést hned po git fetch.
Ono se ti může stát, že svůj lokální master vůbec nepoužiješ, protože vždy budeš na nějaké své vývojové větvi.
Pří pushi musíš uvádět -u origin MojeBranch jen poprvé.
|
||
| andynewcastleth Profil |
Existuje projekt, chci jej přeložit do angličtiny:
git clone https://... git branch mujpreklad git checkout mujpreklad //prelozim projekt git add . git commit -m "prelozil jsem projekt" git fetch //vrati se prazdny, tedy muj master je aktualni git push -u origin mujpreklad Na githubu založím pull request, aby má změna byla začleněna do mastera. Ovšem mi někdo řekne, že jsem zapomněl přeložit jeden soubor. git clone https://... git checkout mujpreklad //prelozim zbyvajici soubor git add . git commit -m "prelozil jsem chybejici soubor" git fetch // nevrati se prazdny, nekdo mezitim zmenil master git checkout master git pull origin master git checkout mujpreklad git merge origin/master git push -u origin mujpreklad Toto jsem zkoušel a zdá se to fungovat OK. Musím dělat git pull origin master, to mi připadá zbytečné, když následně dělám git merge origin/master?
|
||
| Radek9 Profil |
#7 · Zasláno: 8. 6. 2020, 09:12:04
andynewcastleth:
„Ovšem mi někdo řekne, že jsem zapomněl přeložit jeden soubor.“ Tady ale už přece nemusíš znova klonovat repozitář a vybírat branch. Pokud ti ji pod rukama nikdo nezměnil, tak normálně můžeš pokračovat v původně tom naklonovaném repozitáři z prvního kroku. „Musím dělat git pull origin master, to mi připadá zbytečné, když následně dělám git merge origin/master?“
Pull ti updatne lokální branch. Pokud merguješ s remote branchí, tak to potřeba není. |
||
| juriad Profil |
#8 · Zasláno: 8. 6. 2020, 09:56:11
Doplnění souboru k překladu tedy může být provedeno jednodušeji:
git checkout mujpreklad //prelozim zbyvajici soubor git add . git commit -m "prelozil jsem chybejici soubor" // dokonce můžeš tento a předchozí krok spojit: git commit -m "prelozil jsem chybejici soubor" . git fetch // nevrati se prazdny, nekdo mezitim zmenil master git merge origin/master git push Je užitečné nastavit si pár proměnných; já používám tyto: [commit]
verbose = true
[pull]
ff = only
[rebase]
autostash = true
[branch]
autosetuprebase = alwaysMimochodem, při prvním pushi je občas lepší psát: git push -u origin HEAD, nemusíš se tak vypisovat s názvem branche, pokud je delší jako třeba náš aktuální výherce MDD-1902-be-refactor-persistence-interfaces-and-implement-changes-of-interfaces-for-object-storage. Pokud máš dobrý autocomplete, tak to ale zas takový rozdíl není...
|
||
| andynewcastleth Profil |
#9 · Zasláno: 8. 6. 2020, 10:39:20
Prozatím jste mi zodpověděli vše.
Jen ten git commit -m "prelozil jsem chybejici soubor" . mi nefunguje. Napíše mi to, že mám untracket files a že je mám přidat pomocí git add. Tedy mi tento příkaz neudělal git add . jak jsi říkal.
|
||
| mckay Profil |
andynewcastleth:
Zkus git status - to ti vypíše, které soubory jsou změněné a "untracked". Potom je jmenovitě přidej přes git add path/to/file.txt a až potom použij ten git commit -m "message".
|
||
|
Časová prodleva: 4 roky
|
|||
0