23 komentářů k článku Jasně, umím Git…:

  1. tux.martin

    Nefunguje "git config --global color.* yes"
    Co delam blbe?

    martin@martin:~$ git --version
    git version 1.8.3.2
    martin@martin:~$ 
    martin@martin:~$ git config --global color.* yes
    error: invalid key: color.*
    martin@martin:~$
    
  2. Svaťa

    Větvení všeho
    Větvení nic nestojí, lokálně klidně pro každý commit :-)

    Horší je spravovat 100 větví v centrálním repositáři.

    1. John

      Re: Větvení všeho
      No a proto je lepsi pouzivat github flow. Po mergnuti vetve do masteru ji smazat. Tak budete mit jen master vetev (kter by mela byt deploynutelna kdykoliv – tj. prochazi vsechny unit testy a proslo code review) a vetve ve kterych probiha vyvoj. Kazda vetev by nemela zit dele nez par dni (idealne max. 1 den).

      Gitflow se spis hodi na projekty, kde mate releasy (trochu zavani waterfallem). Github flow je idealni kdyz releasujete skoro kazdy den (doporucuju).

      1. Bystroushaak

        Re: Větvení všeho

        No a proto je lepsi pouzivat github flow. Po mergnuti vetve do masteru ji smazat. Tak budete mit jen master vetev (kter by mela byt deploynutelna kdykoliv – tj. prochazi vsechny unit testy a proslo code review) a vetve ve kterych probiha vyvoj.

        +1

        Pokud hostujete projekt na githubu, tak to má navíc tu výhodu, že první větev, která se návštěvníkům zobrazí bude vždy release. To je dobré i z hlediska třeba šéfa, který už není s githubem tak dobře obeznámen a jen se občas potřebuje mrknou, že něco děláte.

      2. arron

        Re: Větvení všeho
        Což ovšem vyžaduje i poměrně sofistikovanu architekturu aplikace. Ne každý si může dovolit mít v release větvi (v tomto případě master) feature, která se ještě nemá nikde zobrazit, protože napřiklad ještě nenastal ten správný čas, nebo nejsou k dispozici „ostrá“ data apod. Zároveň jsou features, které se prostě vyvíjejí i několik měsíců, je potřeba je testovat u klienta (čili musí se releasovat na nějakou testovací verzi), ale za žádnou cenu se nesmí objevit na produkci (ať už z toho důvodu, že to „všechno rozbije“ nebo i z marketingových důvodů). Pak Tebou popisovaný systém přestává velmi rychle fungovat :-)

          1. arron

            Re: Větvení všeho
            A já ve svém příspěvku netvrdím opak. Jenom to, že aby to takhle mohlo fungovat, tak to musí mít podporu v aplikaci, což není IMHO uplně obvyklé.

  3. ZdenekHenek

    git centralni repozitar
    Zajimave shrnuti. Git pouzivam jiz dlouho, ale vetsinou jsem pouzival jen zakladni prikazy, tig a centralni repozitar s web rozhranim http://www.gitblit.com/ kde si muzu treba nadefinovat, ze kdyz nikdo nemuze odstranit zadny commit, pouze administrator.

  4. Bystroushaak

    Stash

    Tohle tedy patří mezi věci, které použijete asi jednou za uherský rok. :-)

    Zvláštní, zrovna stashe používám poměrně často, i když v repozitáři dělám většinou sám.

    1. Bystroushaak

      Re: Ungit
      Tak jsem zkusil, ale musím říct, že větší krám jsem snad neviděl. Nejen že to má asi milion závislostí, ale navíc je to nenažrané co do paměti i CPU a ještě ke všemu to skoro nic neumí.

  5. Míra

    Co znamená "umím git"
    Zdravím,
    podle mých zkušeností hodně záleží na tom co si dotyčný představuje pod pojmem v titulku. Jestli to má být schopnost odříkat desítky parametrů zpaměti nebo pochopit systém práce s gitem.
    Používáme git na několika projektech v cca 100 lidech. Jde o více repositářů každý obvykle s několika aktivními větvemi. Příkazovou řádku používám minimálně, prakticky vše dělám přes gui (včetně např. branchování a mergování). Pokud dotyčný nechápe co dělá, tak mu ani příkazová řádka nepomůže.

  6. dword

    Představte si to jako kdybyste udělali další nový commit, ale sloučil
    se s tím předchozím. Tedy cokoliv přidáte do stashe, se přidá k
    předchozímu commitu. Tedy pro změnu pouze commit message musíte mít
    stash čistý, samozřejmě.

    Zde se autorovi plete pojem stash (odkladaci prostor) s pojmem stage (obsahuje veci, ktere se zahrnou do commitu).

    Ale pozor! Tímto vlastně starý commit smažete a přestane existovat. Za
    žádnou cenu nesmíte takovou změnu provést, pokud jste již poslední
    commit pushnuli. Tím byste kolegům repositář rozbili!

    To neni pravda, dostanete se jen do konfliktniho stavu, kde to autorita muze vyresit prikazem git push –force, jakmile je vse konzistentni.

  7. JackHat

    git tree a další nastavení
    Náhrada za většinu grafických udělátek je pro mě alias git tree:

    git log --oneline --decorate --all --graph
    

    Taky doporučuju mergtool a difftool – mergetool zavolá nástroj na řešení konfliktů, když se do nich člověk dostane při rebase nebo merge, difftool používám na zjišťování rozdílů mezi větvemi/tagy/commity. U obojího mám nastaveny gvimdiff, a je to paráda.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=13562