Wątek przeniesiony 2015-04-19 15:37 z Off-Topic przez somekind.

Git jako źródło wszelkiego zła...

2

Uzywam Eclipse + tortoise Git.

Na moje oko, z svnem pracowalo sie duzo wygodniej.

Dlaczego Git, jesli ma ten sam plik edytowany przez dwie osoby w roznych miejscach widzi to jako konflikt, nie potrafi sam zmegrowac, svn radzi sobie z tym bez problemu.

Ponadto praca, np. z branchem zdalnym per task i pull requestami jest bardzo uciazliwia i stanowi duzy narzut, a mergowanie idiotycznych rzeczy typu importy, czy zmiany w roznych metodach, czy doddanie nowej metody - meczace.

Czy GIT jest tak swietny i ja nie widze plusow (po za lepszy performance od svn'a) czy moze wszyscy zakladaja ze git jest fajny, bo na topie, a to troche taki bubel... ?

3

The answer is: you're doing it all wrong.
Jeśli będziesz próbował używać gita według zasad panujących przy svnie... nie wyjdzie to ani ładnie, ani dobrze, ani przyjemnie.

0

moj typ pracy:

na kazdy task zdalny branch, kommituje do niego, po skonczonej pracy pull request + review. Czy to zle podejcscie pod gitem ?

11

By poznać potęgę Gita trzeba go wpierw poznać. Jak dobrze się potrafi przeprowadzić merge lub rebase to nie ma za wielu konfliktów. Jeśli chodzi o branch per feature to to jest to idealne rozwiązanie. Dzięki temu masz pewność, że to co zrobiłeś działa i nie psuje istniejących funkcjonalności. Jednak trzeba znać umiar, to nie ma być tak, że każda zmiana to nowa gałąź, ale cały feature to jedna gałąź. Następnie robisz squash i próbujesz zrobić merge.

Nie ma sensu by każdy task to był zdalny branch. Masz go lokalnie, potem robisz squash i dopiero gotowego wysyłasz jako pull-request.

3

Transfer pomiędzy svn a git jest uciążliwy i trwa zwykle około 2-4 tygodnie, gdyż musisz zmienić sposób myślenia o kontroli wersji.
Jednak po miesiącu lub dwóch będziesz patrzył na svn z pogardą, a potem z lękiem.

0

Podepnę się pod temat: czy w komercyjnych projektach używacie płatnej wersji githuba, czy raczej macie własne repo? Jakich narzędzi używacie do code review?

0

@Adam Boduch w takim intellij idea można zapuścić code analysis przed commitem a na końcu diff i opowiadanko co i jak.

1

@Adam Boduch jako student mam plan bronze za darmo tak długo jak jestem studentem, więc nie mam zbytnio tego problemu. Co do code review to GH jest dostatecznie dobry do tego - w każdym pull requescie można komentować po linijce, a jak się podepnie np. takiego Hounda to z automatu wytknie błędy stylistyczne. IMHO TravisCI + GitHub to połączenie, które zapewnia rozwiązanie w 99% zastosowań bez dodatków, choć ja jeszcze często podpinam Waffle.io by mieć KanBan na issues i Gitter by mieć czat developerski, ale ostatnio Slack się robi popularniejszy (chyba jest trochę bardziej dopracowany niż Gitter, ale za to Gitter lepiej się synchronizuje z GitHubem).

1

Podepnę się pod temat: czy w komercyjnych projektach używacie płatnej wersji githuba, czy raczej macie własne repo?

Ja używam gitlaba i polecam. Mam wszystko na swoim prywatnym serwerze, na każdym projekcie prywatność ustawiona jak sobie życzę. Nie muszę zawierzać zewnętrznej firmie. Do tego dla klienta można dodać konkretnego użytkownika, z dostępem tylko do tego, do czego ma być.

1

Prywatne repozytoria:

Code review:

Miałem okazję mergować jakieś zmiany wygenerowane przez pull-requesty - robi się to automatycznie (po akceptacji).
Być może w niektórych (w większości?) przypadkach to nie działa automatycznie - nie zdziwiło by mnie to.
W końcu korzenie gita zobowiązują (Linux).

W każdym razie nie zaszkodzi przeczytać na ten temat jakiś poradnik lub książkę - komendy są całkiem odmienne od tych w SVN.

2
Maly Grzmot napisał(a):

Uzywam Eclipse + tortoise Git.

Na moje oko, z svnem pracowalo sie duzo wygodniej.

Dlaczego Git, jesli ma ten sam plik edytowany przez dwie osoby w roznych miejscach widzi to jako konflikt, nie potrafi sam zmegrowac, svn radzi sobie z tym bez problemu.

Ponadto praca, np. z branchem zdalnym per task i pull requestami jest bardzo uciazliwia i stanowi duzy narzut, a mergowanie idiotycznych rzeczy typu importy, czy zmiany w roznych metodach, czy doddanie nowej metody - meczace.

Bo używasz gównianej nakładki na Gita. Jeśli chcesz korzystać z trybu graficznego, to używaj Git Extensions, a nie jakichś cudactw. Ja rozumiem, że fajnie jest korzystać ze znanego sobie interfejsu, ale Tortoise Git przypomina montowanie okrągłej kierownicy, trzech pedałów i dźwigni zmiany biegów na motocyklu.

0
karolinaa napisał(a):

@Adam Boduch w takim intellij idea można zapuścić code analysis przed commitem a na końcu diff i opowiadanko co i jak.

Tylko, że Ty mówisz o analizie kodu dokonywanej automatycznie przez IDE (typu nigdzie nieużywane zmienne itp). Ja natomiast o code review robionym przez ludzi.
Jeżeli chodzi o komercyjne rozwiązania to znam coś takiego: https://www.atlassian.com/software/crucible/overview/feature-overview

1
Maly Grzmot napisał(a):

Uzywam Eclipse + tortoise Git.
[...]

Tortoise Git ssie tak samo, jak Eclipse. Przesiądź się na IntelliJ IDEA + konsola + jakiś zewnętrzny tool do merge/pull requestów i code review (np. GitHub lub Gitlab)
Nie chce mi się tłumaczyć tutaj, dlaczego Git jest lepszy od takich VCS-ów, jak SVN lub TFS, bo w Internecie jest mnóstwo informacji na ten temat.
IMO, jeśli masz problem z Gitem, to oznacza to, że po prostu wystarczająco dobrze tego narzędzia nie znasz lub go nie rozumiesz. Nie ma w tym nic złego, bo wszystkiego można się nauczyć i nie wszystko przychodzi od razu. Mogę Ci wymienić kilka zalet Gita, które mi się nasuwają:

  • podczas tworzenia brancha nie jest kopiowane całe repo do osobnego katalogu (TFS tak robi)
  • dzięki ww. zalecie ściąganie repa nie trwa np. 3 godziny, tylko zazwyczaj góra kilka minut (oczywiście wszystko zależy od projektu, ale na pewno jest to krótszy okres czasu, niż w przypadku innych systemów) i tworzenie nowego brancha też trwa krócej
  • przy odpowiednim flow, żadna zmiana nie wejdzie do brancha master lub development przed przejściem przez code review
  • repo jest zdecentralizowane - jeśli padnie serwer, to każdy developer ma kopię u siebie z całą historią zmian i może ją "od strzału" wysłać na serwer - FYI: w SVN-ie się tak nie da
  • każdy programista pracuje na osobnym branchu, więc jak coś się spieprzy, to tylko na branchu
  • w każdej chwili można dostarczyć klientowi ostatnią działającą wersję aplikacji (branch master) lub wersję developerską (branch development)
  • łatwo integruje się z Jenkinsem (można np. tworzyć joby budujące projekt z różnych branchy)
  • w przypadku konieczności szybkiego przepięcia się na inny branch, można stashować zmiany bez konieczności ich commitowania, a potem wrócić do uprzednio rozpoczętej pracy i zacommitować ją po zakończeniu zadania

Można tak dalej wymieniać. Oczywiście nie znam jeszcze Gita aż tak dobrze, jakbym chciał, więc pewnie więksi eksperci jeszcze więcej Ci powiedzą w tym temacie.

2

Imho, git to przykład projektu, który jest używany bo jest popularny, można mówić, że używasz go żle itp, ale Panowie, svn JEST PROSTSZY w obsłudze, ilośc kombinacji znacznie mniejsza, i mówie to z perspektywy osoby, która używa gita. Największa zaleta i wada to dla mnie lokalne repo i podejście do branchowania, z jednej strony wygodne, z drugiej strony w organizacji circa 150 robi się burdel bo każdy branchuje jak chce i nie wiadomo co gdzie jest i (najlepsze) wszyscy twierdzą, że ich praktyki to te dobre (!). Kolejna kwestia, ja szanuje swój czas i git jest dla mnie narzędziem, które niewiele wniosło natomiast wymagało sporo czasu aby być w stanie w nim pracowac - klepanie dziesiątek komend aby być tru hipsterskim programistom mnie nie bawi, wyrosłem z tego, $ sie musi zgadzać, a ten jest związany z czasem jaki spędzam nad projektem.

5

SVN rzeczywiście jest prostszy, ale bez przesady. To tak jakby porównywać rower z samochodem - w teorii oba służą do tego samego, ale jak się opanuje samochód, to się nim porusza znacznie szybciej i wygodniej.

Jak ktoś mi mówi, że wadą DVCS jest lokalne repo i to, że baranche są lekkie to automatycznie wiem, że taka osoba nie rozumie idei, która za tym stoi. Co więcej, im większy projekt tym większy jest sens zastosowania DVCS. Wyobraźmy sobie, że gdzieś pojawia się nam w repo błąd (całkiem prawdopodobne) i jest on niezauważony przez powiedzmy 2 lata. Wypływa on na wierzch i nagle panika, bo nie wiadomo, które wersje są narażone. W Gicie znajduje się bardzo przydatna komenda git bisect, która tak na prawdę może całą robotę odwalić za nas automatycznie. W SVNie? Mamy do tego skrypt Perla (yay, wszyscy kochamy Perla), ale przeskakiwanie między kolejnymi rewizjami zajmie wieki (zwłaszcza jeśli team jest cały mobilny i nie ma dostępu do serwera gdzie składuje się kod).

Mówisz, że szanujesz swój czas, a nie chcesz się nauczyć narzędzia, które pozwoli Ci go w znacznym stopniu zaoszczędzić. No cóż, niektórzy ludzie nie potrafią planować długoterminowo.

Jak masz organizację ~150-osobową pracującą nad 1 repo w stylu gwiaździstym to ja się nie dziwię, że jest burdel (przy SVNie był by pewnie jeszcze większy, bo praca niektórych by polegała na czekaniu, aż będzie mógł zrobić commita). Parę rzeczy - wprowadźcie strukturę drzewiastą pracy (15 osobowe zespoły z wyznaczonym leadem), podzielcie repo na mniejsze projekty oraz stwórzcie style guide (ktoś projekt musi prowadzić, więc niech ta osoba powie, że robimy tak i tak i koniec, pull-requesty nie będą przyjmowane od osób, które się nie stosują). Znacznie łatwiej będzie.

Powiem tak, gdyby przy takiej organizacji zastosować SVNa, to serwer eksplodował by w ciągu jednego dnia lub powstał taki chaos, że przez następne 3 lata byście się z niego wygrzebywali. Jedna z ideii używania Gita jest taka (http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows):

  • wszyscy mają to samo w masterze, do którego mogą commitować tylko project leadzi (albo nawet oni nie mogą commitować bezpośrednio, a tylko narzędzie do code review)
  • każdy nowy feature powstaje w nowej (lokalnej) gałęzi wymergowanej z mastera - dzięki temu (o ile są dobre testy) wiadomo, że cokolwiek chciałem dodać/poprawić/zrefaktoryzować nie spieprzyło tego co już działa
  • commity wykonuje się gęsto i często (po parę linijek) bo można i dzięki temu mamy coś w stylu "persistent undo" (jak ktoś używa Vima to za pewne ma to i bez tego)
  • kiedy uznamy, że feature jest ukończony robimy git rebase -i --autosquash by z wuchty małych, jednolinijkowych, commitów zrobić bardziej sensowne grupy, które są ładnie opisane (no i pozbyć się wszystkich fixup! i squash! , polecam sprawdzić git help rebase i git help commit)
  • CI robi testy by mieć pewność, że nic nie spapraliśmy
  • ktoś robi review
  • team lead robi signed merge do repo teamu
  • pod koniec sprintu/ukończeniu głównego taska jest robiony pull-request do głównego repo (to się może dziać automatycznie)
  • znów CI
  • znów review
  • signed merge do mastera

Przy takim toku pracy masz pewność, że nikt niczego nie spieprzy i kod w masterze powinien działać.

Więc IMHO dalej uważam, że skoro twierdzisz, że Git nic nie wnosi, poza zwiększoną złożonością narzędzia, to po prostu go nie znasz. By wypowiadać się nt. użyteczności narzędzi warto je wpierw poznać :)

1

No właśnie przerabiałem wszystko o czym piszesz, sam stosuje gita i w robocie i w prywatnych projektach, nadal jednak stoi obok svn, który robi za worek na stare dane i ani myślę go przenosić bo jest wystarczający.

Mamy wiele projektów, mamy submoduły, mamy code review (gerrit) mamy jenkinsa, a nawet kilka jenkinsów, mamy automatyzacje od budowania paczek po sam deployment. Problem z narzędziami nie jest w nich samych, problem jest jak masz zespoły techniczne i każdy z zespołów twierdzi, że ma racje. Programiści mają tendencje do znania się na wszystkim w IT, a wybujałe ego niektórych nie dopuszcza myśli, że można zrobić coś prościej, szybciej czyli taniej. Taka imho jest sytuacja z gitem, skoro wszyscy ewangelizują że git jest naj naj naj to my też musimy się na niego przenosic, niestety bez ewaluacji kosztów bo zmiana z svn na git to koszt, do tego nie mały i nie zawsze uzasadniony.

Wdrożenie lub zmiana USŁUGI wersjonowania kodu, to nie tylko użycie svn / git, ale także przeszkolenie wszystkich z obsługi narzędzia, zmiana procesów i zmiana narzędzi w okół tej usługi, mówi o tym ITIL, dlatego jeżeli Ty lub twoja organizacja używa svn i jest na nim produktywna, a zmiana na gita nie ma uzasadnienia ekonomicznego to nie brnąłbym w tym kierunku tylko dlatego, że wszyscy(?) dookoła używają czegoś innego.

1

@somekind

Bo używasz gównianej nakładki na Gita. Jeśli chcesz korzystać z trybu graficznego, to używaj Git Extensions, a nie jakichś cudactw. Ja rozumiem, że fajnie jest korzystać ze znanego sobie interfejsu, ale Tortoise Git przypomina montowanie okrągłej kierownicy, trzech pedałów i dźwigni zmiany biegów na motocyklu

A co jest nie tak z Tortoise Git? Używam go w zasadzie od ponad roku - projekcie rozwijanym przez kilku programistów i jakoś nie mam za bardzo powodów do narzekań. Nie używałem jednak Git Extensions - mógłby ktoś podzielić się wrażeniami jeśli zdarzyło mu się korzystać z obu nakładek?

3
ikol napisał(a):

A co jest nie tak z Tortoise Git? Używam go w zasadzie od ponad roku - projekcie rozwijanym przez kilku programistów i jakoś nie mam za bardzo powodów do narzekań. Nie używałem jednak Git Extensions - mógłby ktoś podzielić się wrażeniami jeśli zdarzyło mu się korzystać z obu nakładek?

Skoro łysy Git i inne nakładki nie mają problemów z tym, o czym pisze autor, a on korzystając z Tortoise Git ma, to najwyraźniej z tym narzędziem jest coś nie tak.

Ja to widziałem tylko w akcji u kolegów, powiem tyle:

  1. Wygląda jak narzędzie do SVN, przez co wspiera w ludziach błędne przekonanie, że "Git, to taki inny, nowszy SVN", co utrudnia im zrozumienie Gita i korzystanie z niego prawidłowo.
  2. Upoobnienie jest na siłę - np. posiada funkcję "Cleanup", która w Gicie nazywa się inaczej i robi "trochę" co innego niż w SVN.
  3. Jest Tortoisem, obsługuje się je przez PPM i milion okienek, więc prosta operacja typu sprawdzenie różnicy między dwoma wbitkami wymaga tysiąca kliknięć.
  4. Ma wygląd kojarzący się z pracą w XVI wiecznej kopalni siarki z użyciem SVN.

Git Extensions w przeciwieństwie do np. Source Tree umożliwia wykonanie wszystkich operacji dostępnych w Gicie. Jest brzydki i surowy, ale efektywny, bo:

  1. Główne okno pokazuje historię, i umożliwia przeglądanie (w zakładkach na dole) szczegółów rewizji, drzewa plików i różnicy między nim, a poprzednim commitem).
  2. Jeśli chcę obejrzeć różnicę między dwoma dowolnymi commitami, to zaznaczam je w głównym oknie, a w dolnej sekcji pokazują mi się różnice.
  3. Okno commitowania też jest jedno i zawiera: listę zmienionych plików, listę plików w indeksie, różnice między zaznaczonym plikiem, a poprzednią wersją oraz pole wpisania komentarza.

I to jest główna różnica, między Git Extensions a Tortoise Gitem - potrzebne do codziennej pracy okna są dwa, a nie dwieście, dzięki czemu pracuje się z nim bardzo szybko, bo wszystkie istotne w danym momencie informacje są podane jak na tacy.

0

Jak ktoś chce, to jest jeszcze GitHub for Windows. Jak nazwa wskazuje, współpracuje głównie z GH, ale można pracować też z innymi serwisami. W miarę ładny i z tego co wiem użyteczny.

0
somekind napisał(a):

I to jest główna różnica, między Git Extensions a Tortoise Gitem - potrzebne do codziennej pracy okna są dwa, a nie dwieście, dzięki czemu pracuje się z nim bardzo szybko, bo wszystkie istotne w danym momencie informacje są podane jak na tacy.
Sęk w tym, że commit/update (czy ich odpowiedniki gitowe) zajmują promil czasu dziennie, więc tu tortoise ma przewagę, że nie plącze się zbędnie między oknami gdy z niego nie korzystamy. I nie trzeba za każdym razem uruchamiać programu, wyszukiwać odpowiedniego katalogu by dokonać akcji. Ot, edytowaliśmy plik, jesteśmy już w jego katalogu, prawym, commit, gotowe. Myślę, że to sprawia, że Tortoise jest tak popularne. Jest po prostu zawsze na miejscu tam, gdzie go potrzebujemy. Gita nie znam za bardzo, ale może wystarczyłoby TortoiseGita nieco zmodyfikować z porzuceniem powiązań do Subversion by stał się sensowny dla wszystkich? Takie akademickie dywagacje.

1

Pamiętam moje początki korzystania z gita. Oczywiście zainstalowała od razu Tortoise'a, bo byłam zadowolona z wersji do svn. Po pierwszym pushu druga osoba z zespołu przyszła mi oznajmić, że kompletnie rozpiździłam repo. Szczerze, to do dziś nie mam pojęcia co takiego zrobiłam (nie klikalam nie wiadomo czego, zwyczajnie prawym - commit - prawym - push), ale od tamtej pory trzymaj się z dala od Tortoise Git ;) Z konsoli czy z Git Extensions nigdy nie miałam żadnych problemów...

1
Marooned napisał(a):

Sęk w tym, że commit/update (czy ich odpowiedniki gitowe) zajmują promil czasu dziennie, więc tu tortoise ma przewagę, że nie plącze się zbędnie między oknami gdy z niego nie korzystamy. I nie trzeba za każdym razem uruchamiać programu, wyszukiwać odpowiedniego katalogu by dokonać akcji. Ot, edytowaliśmy plik, jesteśmy już w jego katalogu, prawym, commit, gotowe.

  1. Uruchomienie GitExtensions trwa szybciej niż otwarcie dowolnego okienka z Tortoisa.
  2. GitExtensions nie wymaga znajdowania katalogu z każdym razem, po prostu otwiera się repozytorium z listy ostatnio otwartych.
  3. Większość ludzi nie edytuje kodu przez eksplorator/TC lecz przez IDE, a tam już można okienko np. GitExtensions wywołać przez opcję menu albo nawet skrót klawiaturowy.
  4. I co najważniejsze - GitExtensions też może się dodać do menu kontekstowego, więc i z TC się zintegruje.
0

@somekind

Wygląda jak narzędzie do SVN, przez co wspiera w ludziach błędne przekonanie, że "Git, to taki inny, nowszy SVN", co utrudnia im zrozumienie Gita i korzystanie z niego prawidłowo. Upoobnienie jest na siłę - np. posiada funkcję "Cleanup", która w Gicie nazywa się inaczej i robi "trochę" co innego niż w SVN.

Przesiadłem się z Tortoise SVN na Tortoise GIT i potwierdzam to co piszesz - podobne okna i nazwy funkcji są tylko pozornym ułatwieniem.

Jest Tortoisem, obsługuje się je przez PPM i milion okienek, więc prosta operacja typu sprawdzenie różnicy między dwoma wbitkami wymaga tysiąca kliknięć.

Aż tak źle nie jest - najczęściej używane okna to ShowLog, Swicht/Checkout, a do zarządzania commitami mamy GitSync - gdzie wszystkie potrzebne opcje są pod ręka.

Ma wygląd kojarzący się z pracą w XVI wiecznej kopalni siarki z użyciem SVN.

No niestety, spartański interfejs to chyba największa wada Tortoisów... I nie mówię tu o jakiś wodotryskach - studenckie projekty mają czasem bardziej ergonomiczne rozwiązania.

Główne okno pokazuje historię, i umożliwia przeglądanie (w zakładkach na dole) szczegółów rewizji, drzewa plików i różnicy między nim, a poprzednim commitem).

Brzmi jak ShowLog w Tortoise GIT (jedno kliknięcie na pliku i drugie na tej opcji).

Jeśli chcę obejrzeć różnicę między dwoma dowolnymi commitami, to zaznaczam je w głównym oknie, a w dolnej sekcji pokazują mi się różnice.

Przy konfliktach może być przydatne - ale w Tortoise edytor daje radę dla prostych konflitków - dla większych otwieram IDE i robię ShowLog.

Okno commitowania też jest jedno i zawiera: listę zmienionych plików, listę plików w indeksie, różnice między zaznaczonym plikiem, a poprzednią wersją oraz pole wpisania komentarza.

Czyli to samo co w Tortoise GIT? Fakt - zmiany trzeba wyświetlić już w osobnym oknie - ale jak się pracuje na dwa monitory to czasami nawet zaleta.

Uruchomienie GitExtensions trwa szybciej niż otwarcie dowolnego okienka z Tortoisa.

Od jakiegoś czasu zauważyłem mocne przeyśpieszenie Tortoisa - wcześniej faktycznie był nazwa była adekwatna ;)
Ale z ciekawości sprawdzę, jak Extensions się sprawuje.

1

Gdzieś w okolicznych wątkach o gicie było wspominane, że słabo sobie radzi z dużymi plikami. Tu jakieś próby łatania tego:
https://github.com/blog/1986-announcing-git-large-file-storage-lfs

1

Odnośnie gita to w sumie nie rozumiem skąd wzięła jego tak wielka popularność. W zestawieniu z takim mercurialem to praktycznie na każdym szczeblu hg wydaje się mieć sensowniejsze rozwiązania + ma już ogarnięty extension dla binarek.

1

Proste. Bo GitHub.

Git i Mercurial powstały w podobnym czasie i rozwiązywały podobne problemy w podobny sposób. Ale GitHub jako świetny serwis znacząco wpłynął na popularność Gita. Być może gdyby powstał jakiś HgHub odpowiednio wcześnie to sprawa by się potoczyła inaczej, ale to (niestety?) Git uzyskał popularność.
Do tego złożyła się popularność niejakiego Linusa Torvaldsa oraz fakt, że Git został również wybrany początkowo przez parę innych projektów, np. X Window System. No i może to, że Git był początkowo znacznie szybszy od Hg.

Ja sam przeszedłem z Hg na Gita właśnie z powodu popularności tego drugiego. I czasami mi niektórych rzeczy brakuje.

1

Mnie natomiast drażni to parcie na gita. W mojej firmie postanowiono używać gita bo jest modny i ns topie dziś. Problem w tym, że nikt nie wie jak go używać i każdy używa tak jakby był to nowszy modniejszy svn. I tak wszyscy pushują od razu do mastera, praca sprowadza się do commitów, pull i push przez tortoisa, wszystkie działania od razu na masterze. Czy w takim wypadku uzasadnione było przejście na gita? Wg mnie nie.

A tak na marginesie. Ciagle słyszę że tylko lamerzy upierają się na graficzne nakładki na gita. Powiedzcie mi zatem, jak byście w trybie tekstowym na linuksie osiagnęli dokładnie taki sam sposób rozwiązania konfliktu jaki przedstawiono tu:
Nie ma żadnego graficznego diffa ani nic z tych rzeczy. Więc jak to się robi?

4

@Wybitny Orzeł ale niby czemu nie? Bo ja nie bardzo widzę co jest złego w takim modelu. Ja rozumiem że są fanatycy którzy zaraz wpadną i będą krzyczeć o rebase i o branchowaniu wszystkiego, ale przecież nie o to chodzi. W rzeczywistości nic nie stoi na przeszkodzie żeby w ten sposób korzystać z gita i nadal masz przewagę nad svnem bo masz chociażby lokalne commity.

0

A wbudowany Git/wtyczka w IDE nie starczy? ;)

2
Shalom napisał(a):

@Wybitny Orzeł ale niby czemu nie? Bo ja nie bardzo widzę co jest złego w takim modelu. Ja rozumiem że są fanatycy którzy zaraz wpadną i będą krzyczeć o rebase i o branchowaniu wszystkiego, ale przecież nie o to chodzi. W rzeczywistości nic nie stoi na przeszkodzie żeby w ten sposób korzystać z gita i nadal masz przewagę nad svnem bo masz chociażby lokalne commity.

A co ci takiego dają te lokalne commity? A TortoiseSVN i tak lepiej wg mnie rozwiązywał konflikty. Łatwiej to było ogarnąć, a trudniej było rozwalić repozytorium

1 użytkowników online, w tym zalogowanych: 0, gości: 1