Doporučené grafické rozhraní pro GIT
- Namespace
- Člen | 81
Ahoj,
rád bych se zeptal, zda někdo používá nějakého grafického klienta pro
GIT. Do nedávna jsem požíval Github for Windows, ale má takovou malou
nevýhodu a to tu, že funguje jen s Githubem. Hledám něco, co se jednoduše
nastavuje, jednoduše používá a běží pod Windows. Našel jsem jich asi
milion, tak proto bych rád věděl, jestli někdo nějaký používá, nebo by
nějaký doporučil :-).
Díky!
- Kenji179
- Člen | 4
Z těch pár, které jsem vyzkoušel, mi nejvíc vyhovuje SourceTree. Byl jsem ale při výběru limitován na grafického klienta pro OS X. Pro Windows jich asi bude víc a lepších.
- jasir
- Člen | 746
Console + aliasy, na komitování git gui (umí totiž nejlíp ze všech git commit –amend) a na blbnutí v historii gitextensions https://code.google.com/…textensions/
Editoval jasir (24. 3. 2015 22:37)
- abc
- Člen | 92
Já používám:
http://code.google.com/…textensions/
SourceTree mi přišel strašně pomalej
- Vojtěch Dobeš
- Gold Partner | 1316
GitHub for Mac – pěkné grafické rozhraní s minimem funkcí. Řeší mi právě jednu jedinou věc, a to commitování po řádcích. Svým malým množstvím funkcím mi umožňuje bez zbytečného rozhodování se dělat vše ostatní v konzoli.
Teď si čtu první příspěvek a vidím GitHub for Windows :D – proč by měl tento klient být limitován pouze na GitHub? Každopádně je možné, že rozdíl ve funkcionalitě obou klientů je značný, nevím.
- Vojtěch Dobeš
- Gold Partner | 1316
akadlec napsal(a):
@VojtěchDobeš tipnu si že proto protože je to appka přímo githubu aby se spojovala s repozitářema tam a né nějakýma soukromýma. Co jsem ji ale zkusil tak nic moc teda.
No, po prvním vyzkoušení jistě vyjde najevo, že na GitHub repozitáře limitovaná není :). Každopádně jak jsem psal, používám ji právě jen na commitování samotné, zbytek provádím v konzoli.
- Filip Procházka
- Moderator | 4668
Používám konzolového klienta a integrovaného klienta v PhpStorm. Když si na to nastavíš zkratky, tak se to používá fakt dobře. Neumí jen partial commit. IMHO je daleko efektivnější commitovat z IDE než dalšího programu.
- Zax
- Člen | 370
Filip Procházka napsal(a):
Používám konzolového klienta a integrovaného klienta v PhpStorm. Když si na to nastavíš zkratky, tak se to používá fakt dobře. Neumí jen partial commit. IMHO je daleko efektivnější commitovat z IDE než dalšího programu.
Tohle už mě taky napadlo, ale v mém případě to asi bude chtít trochu změnu ve workflow – k dev serveru přistupuji vzdáleně a používám automatic upload ve stormu. Složku .git na localu nemám. Máš na to nějaký pěkný trik, kterým by se to dalo snadno vyřešit, aniž bych musel ručně neustále pushovat na dev nebo něco takovýho?
- Michal Vyšinský
- Člen | 608
@Zax doporučil bych používat git tak jak se má a nevymýšlet
***
Proč nemáš git repozitář naklonovaný lokálně a proč si
komplikuješ život?
Editoval Michal Vyšinský (25. 3. 2015 23:12)
- Zax
- Člen | 370
@MichalVyšinský No nevím, čím si pomůžu když si naklonuju repo k sobě? Já potřebuju, aby se změny ve zdrojákách rovnou sypaly na vzdálený dev, aniž bych musel neustále dokola spouštět nějaký příkaz…
Možná hloupý dotaz – přiznávám, že si s Gitem ještě moc nerozumím, takže možná vidím problém kde žádný není…
- David Kudera
- Člen | 455
@Zax k tomu poměrně nedávný dotaz na devel . Za mě osobně… Už nikdy více ;-)
- Zax
- Člen | 370
Mně vzdálený vývoj docela vyhovuje, nemusím řešit dvojí databázi, dvojí nastavení serveru, stovky megabajtů obrázků apod. a navíc se mi přenáší skutečně jen změněné zdrojáky, což je pro mě jakožto uživatele velmi pomalého ADSL nesmírná výhoda. Pokud tam není nějaký fakt užitečný life hack, který nevidím (kromě možnosti používat Git z IDE), tak mi z toho vyplývá spousta nevýhod a málo výhod :-(
- Filip Procházka
- Moderator | 4668
@hrach pokud „uklízíš“ commity, tak se partial velice hodí, ale jednak většina programátorů partial nepoužívá (protože třeba ani neví že existuje) a druhak, stále je velice pohodlné mačkat zkratky v IDE a 90% práce udělat přes to a občas skočit do konzole a commitnout si partial, když je to potřeba. Snažím se začít víc používat workflow přes phpstorm a za sebe můžu říct, že to má spoustu výhod. Changelisty v kombinaci s issues jsou hodně silné.
Co třeba teď hodně používám a je hodně super, tak mít zkratku na
fetch --all a pak druhou zkratkou si checkoutnu větev kolegy a
buď dělám review, nebo mu tam něco opravím. Storm má skvěle vyřešenou
navigaci klávesnicí a nemusíš nic opisovat, kopírovat ani na nic klikat. Na
pár stisknutí kláves máš checkoutlou větev i s nastaveným správným
remotem atd.
A rebasování v IDE je taky lahoda. Merge window je úplně mňam :)
@zax Vzdálený vývoj je ta největší hovadina co můžeš udělat. Ale když upustíme od toho, jak je to nelogické a neefektivní a budeme se soustředit jen na tvou otázku… V čem je problém nemít git v té vzdálené složce, ale jenom lokálně a přes ten storm uploadovat na ten „hosting“ rovnou? Nebudeš muset řešit vývojové prostředí ale zároveň budeš používat git „správně“ (=distribuovaně tzn že máš lokální kopii).
- David Kudera
- Člen | 455
Filip Procházka napsal(a):
V čem je problém nemít git v té vzdálené složce, ale jenom lokálně a přes ten storm uploadovat na ten „hosting“ rovnou?
Kdyžtak ještě malý dodatek. Přesně tohle jsme chvíli zkoušeli, protože nás nějak napadlo, že logicky to bude docela dobrá volba.. Jen v bodech proč nebyla:
- Přepínání větví (rychlost gitu v háji a musím čekat na upload), závěr: větve jsou nepoužitelné
- Spouštění db migrací na serveru? To už bylo rychlejší ty změny naklikat v admineru
- Composer, npm, bower? Buď instalovat lokálně a upload (lepší pro ide) nebo ssh na server a install. Závěr: na nic..
- Použití gulpu (nebo gruntu apod.).. Stejné jako composer
- Občas vypadne internet nebo je nedostupný vps (třeba taky výpadek)
Tohle je jen pár základních problémových věcí. Pokud ale nic z tohoto nepoužíváš, tak asi ok, ale má smysl potom vůbec použít git? Nechápej mě špatně, bez gitu bych už nezačal dělat ani dvouřádkovou knihovnu. Ani tě nechci @Zax přesvědčit o tom, že já mám pravdu a ty snad ne. Je to spíš takový podmět k zamyšlení, jestli by to opravdu nešlo řešit trochu líp ;-)
Edit: ještě jsem si vzpomněl, že občas se stalo, že phpstorm ani nenahrál na server vše a pak jsme buď uploadovali vše znovu (pro jistotu) a nebo pomalý synchronize. Občas to bylo kvůli nějakým právům, občas prostě jen tak
Editoval David Kudera (26. 3. 2015 8:28)
- Zax
- Člen | 370
@FilipProcházka Git jenom na localu? To mi osobně přijde trochu jako blbost – jak mám potom řešit když k mému kódu na tom vzdáleném serveru přijde někdo jiný a bude se chtít třeba podívat na historii? Zatím jsem nenarazil na jediný problém spojený se vzdáleným vývojem, nic, co by nabourávalo efektivitu. BTW možná si trošku nerozumíme, ty píšeš jako kdybych vzdáleně vyvíjel přímo na produkci a to je samozřejmě totální ptákovina, nic takového neděláme. Ne, my máme vývojářský server a git na něm potřebujeme, protože mergnutí do větve release + push = nasazení změn na produkci (máme na to script, který to nasazení řeší). Když k tomu přidám ještě git u sebe na localu, tak mám akorát zase o starost víc :-(
@DavidKudera Však já hledám cesty, jak pracovat líp a snažím se přitom myslet na výhody a nevýhody ještě předtím, než začnu ztrácet čas zkoušením. Ovládání gitu přímo ze stormu mi zní jako fajn nápad, ale není snadné to zkloubit s aktuálně zavedeným workflow.
- David Kudera
- Člen | 455
@Zax no nejspíš tady není nejvhodnější místo to řešit, ale když už...... :-)
Dám jen drobnou ukázku u nás. Máme 2 základní větve (production a master, ty máme navíc v gitlabu protected, aby do nich nešlo přímo commitovat). Potom se vytváří feature branche, prostě tak nějak na způsob zjednodušenýho successful branching modelu. Vlastně je to téměř gitlab flow.
No a dál je to easy, na jednom dev serveru, běží ten gitlab s gitlab ci, který po testech na production spustí deploy na veřejný server a nebo spustí deploy na ten stejný dev server pro větev master. Snad to je srozumitelné. Takže… Venku je stabilní verze, na dev serveru master a taky gitlab.
A samozřejmě je git nainstalovaný i na production serveru, kde má přístup pomocí deploy keys ke gitu, aby se mohl aktualizovat. A na to už máme šikovný deploy skript, který migruje databázi, aktualizuje závislosti, builduje css a js apod…
Neříkám, že je to to nejlepší (např. chci zkusit docker), ale funguje to parádně a rozhodně i řeším míň problémů, než předtím ;-)
- Filip Procházka
- Moderator | 4668
@DavidKudera good point. Popravdě, nikdy jsem to nezkoušel, vždy jsem vyvíjel „správně“ (=kompletně lokálně).
@zax tak předpoklad je, že máš na to nějaký repozitář, nejlépe privátní gitlab, pokud děláte hodně projektů.
Vyvíjet na vzdáleném stroji je strašný opruz. V momentě kdy na tom pracuje víc než 1 člověk tak to přestane fungovat úplně. Takže ti to nebudu dál rozmlouvat a nechám tě ať na to přijdeš sám časem :)
- hrach
- Člen | 1838
@Elijen podle me ty to delas spatne ;-) Pokud je v mode squash (souhlasim), tak musis mit co squashovat. Jak udelam vic commitu? Ze prave commitnu jen souvisle veci a delam je oddelene. Jenze tak se efektivne prakticky nikdy nepracuje. Ja vyznavam pristup staleho progressu, tj. kdyz neco opravuji, provedu zaroven i drobne vylepseni, abych nenarustal technicky dluh – poupravim coding style, etc. A to opravdu nedelam zvlast, delam to naraz. Partial commit vyuzivam taky pri vetsim refaktoringu – tehdy nikdy nevis, kam dojdes, mam to vsechno v jednom WIP commitu, ktery postupne ammenduju, a nakonci ho celej rozkomituju do vice commitu. Ano, neplati zde pak treba krasna teorie, ze kazdy commit ma o sobe sam byt funkcnim celkem, na druhou stranu mam pak prehledne commity, ktere zahrnuji logicke celky, byt samostatne ne treba uplne funkci. Rebase+sqaush (respektive fixup)+merge pouzivam opravdu hodne a partial commit je neco, co to hodne usnadnuje :)
