Jaki jest sens korzystania z konsoli GIT?

0

Cześć.
Od 3 miesięcy pracuję jako programista. Wcześniej GIT'a znałem z teorii. W pierwszej pracy zetknąłem się z praktyką i jako że nie za wiele umiałem to zostałem przeszkolony przez pracodawcę co i jak ogarnąć na start żeby sobie radzić z projektami.
Ostatnio jednak zacząłem sam się interesować i dużo czytać ponieważ push, pull, commit i merge to jednak niewiele. Wszystkie tutoriale/opisy jakie znajduje w internecie opierają się na konsoli. Ja w pracy korzystam z EGITa lub ewentualnie SourceTree.
Próbowałem trochę pobawić się konsolą ale dla mnie osobiście wydawało się to kompletnie niepraktyczne. Nie dość że muszę znać komendy (okej, można nadać aliasy ale nadal trzeba je pamiętać) to jeszcze wszystko trzeba klepać z klawiatury.
EGIT, SourceTree itp pozwalają wszystko szybko i łatwo wyklikać. Nawet IntelliJ CE bez problemu posiada taką funkcjonalność.

Więc jaki sens jest korzystania z konsoli? Ma ona jakieś "super moce" w Gicie w stosunku do nakładek graficznych? Na co dzień w pracy wszystko klepiecie ręcznie czy jednak żeby było szybko i sprawnie korzystacie z jakichś dodatkowych narzędzi?

Pozdrawiam.

1

Gitextensions na co dzień.

6

Konsola w przeciwieństwie do pluginów jest mniej więcej wszędzie taka sama, tzn. niezależnie od tego czy ktoś pracuje na linuxie czy windowsie, lub czy pracuje w Eclipsie, Visual Studio czy Notatniku to zawsze może tak samo użyć GITa "konsolowego" przez co uczy się uniwersalnej wiedzy i komend, a nie uzależnia się od konkretnego dodatku do konkretnego IDE dlatego wszystkie tutoriale pokazują GITa od tej strony. Poza tym o ile graficzne dodatki są przyjemniejsze w codziennym użyciu to jednak zdarzają się problemy, które da się rozwiązać dużo szybciej w konsoli, albo wręcz są nie do rozwiązania w graficznych narzędziach, które często nie mają 100% funkcjonalności udostępnianej przez GITa. Dodatkowo ucząc się komend GITa poznajesz jak to wszystko dokładniej działa i co się może kryć np. pod przyciskiem "Commit" w graficznym pluginie, a nie korzystasz z tego na ślepo ;)

0

Jeżeli pracujesz na linuxie to jest to w miarę wygodne. Masz auto-uzupełnianie za pomocą tab, gwiazdkę i nie musisz za każdym razem sięgać do myszki, co w połączeniu z praktyką bardzo przyspiesza pracę. Windowsa też zapewne da się w ten sposób skonfigurować. Poza tym, 90% pracy to i tak te podstawowe komendy: commit, push, pull, checkout i ew. branch/merge.

0
eL napisał(a):

Więc jaki sens jest korzystania z konsoli? Ma ona jakieś "super moce" w Gicie w stosunku do nakładek graficznych? Na co dzień w pracy wszystko klepiecie ręcznie czy jednak żeby było szybko i sprawnie korzystacie z jakichś dodatkowych narzędzi?

korzystam z konsoli zeby bylo szybko i sprawnie :) pomijajac githuba, GUI jest przydatne praktycznie wylacznie do bardziej skomplikowanych machlojek na drzewie commitow (i wtedy uzywam tortoise).

najprawdopodobniej nie rozumiesz jak dziala git bo jestes przyzwyczajony do svn update/commit i dlatego masz problem z obsluga przy uzyciu konsoli.

jesli pracujesz na jednej galezi i zwykle nad jednym, dobrze zdefiniowanym zadaniem, niezbyt duze repo, pare osob w lokalnym teamie i rzadkie merge to git moze byc malo praktyczny, przez to ze tylko czasem uzywasz komend to nie masz okazji zeby weszly ci w krew.

najczesciej mam otwarte przynajmniej pare okienek terminali gita, w kazdym repo po kilka galezi moich lub kolegow wiec jak sobie podliczyc ilosc push, pull, merge, rebase, add, commit, branch, checkout, log dziennie to nie wyobrazam sobie tego wyklikiwac.

wbrew pozorom nie jest tego duzo, po paru tygodniach intensywnego uzywania nie bedziesz chcial wracac do GUI

1

Palce mają lepszą pamięć niż dłoń na myszce + wzrok. Szybciej napiszesz polecenia po paru dniach pracy w konsoli niż po paru miesiącach klikania. Git ma wszędzie takie samo API, ale GUI mogą się różnić więc przy zmianie appki lub nawet wersji nawyki stają się nieprzydatne. Konsolę możesz połączyć w innymi narzędziami w konsoli (choćby ls) bez narzutów związanych ze zmianą kontekstu.

Edit: Temat jest źle nazwany. Git to narzędzie konsolowe więc nie ma czegoś takiego jak git + konsola. Jest git + graficzny interfejs.

0

Wg mnie obsługa gita w konsoli jest znacznie szybsza, bez względu na system operacyjny (oczywiście, jeśli umiesz posługiwać się konsolą).
Obsługa najczęściej używanych poleceń sprowadza się na dobrą sprawę do użycia strzałki w górę i tabulacji - masz historię wpisywanych komend i możliwość dopełnienia ścieżek.
Wydaje mi się, że jedynie rozwiązywanie konfliktów może być łatwiejsze w trybie graficznym.

Jeśli chodzi o aliasy, możemy je rozpatrywać w dwóch zakresach: aliasy bashu, gdzie możesz sobie zdefiniować, np. gc jako git commit i aliasy w samym gicie, gdzie np. możesz sobie zdefiniować alias typu git mtom, który będzie robił merge to master (przykład).
Bez przesady, że ciężko zapamiętać aliasy- przecież chodzi o to, żeby nazwa była intuicyjna i krótka, poza tym możesz pod jeden alias zapisać skrypt (np 3 polecenia).

Do najczęściej używanych komend dorzuciłabym jeszcze stash, stash pop, stash clear, bardzo przydatne jeśli nie chcemy robić commita, ale musimy zrobić pull.

1

" SourceTree itp pozwalają wszystko szybko i łatwo wyklikać", zrób pusha z forcem - powodzenia...

tylko i wyłącznie git bash

0

Tylko nakładki graficzne, konsola mnie zawsze denerwuje we wszystkim, nienawidzę konsol dlatego ograniczam to do minimum.

1

Poza zaletami linii poleceń podanych wyżej, jest jeszcze: community support.
O wiele łatwiej opisać/rozwiązać problem podając listę komend linii poleceń, niż opisać gdzie ktoś ma kliknąć.

Poza tym git pod Linusem dobrze integruje się z shellem, tab podpowiada wszystko nazwy komend, nazwy branch'y, nazwy zmienionych plików (strasznie mi tego brakuje na innych platformach).

Poza tym nie wyobrażam sobie robić rebase za pomocą nakładki (Source Tree) szczególnie jeśli w grę wchodzą trzy branche (miałem prę takich przypadków). Przy zaawansowanych rzeczach, piszczac w konsoli wiem co się stanie, w SourceTree efekt bywa nieprzewidywalny.

5

A jaki jest sens korzystania z nakładek graficznych? :D

0

Imho każdy system kontroli wersji lepiej używać z poziomu cui z jednym wyjątkiem - Perforce (ma zdumiewająca dobrego klienta z kapitalnym difftoolem).
Z klientami graficznymi mam takie problemy, jak:

  • nie wiem gdzie są trzymane klucze publiczne (często jest to inna lokacja niż ~/.ssh)
  • jeśli nie chcę zrobić czegoś trywialnego (nowy commit/push/pull/merge) tylko np. commit --amend to tracę sporo czasu na odszukanie takiej opcji (o ile w ogóle to jest możliwe z poziomu gui)
  • co gdy pracuję na rebase flow zamiast merge? (3 dni szukania opcji o ile istnieją) Widział ktoś kiedyś rebase interactive w kliencie gui?
  • cherry pick?
  • jak chcę zrobić alias na push do refs/for/master z jakimiś przełącznikami i pod jakimiś warunkami to jak to wyklikać z poziomu gui i jak to zarejestrować jako macro?
  • w gui da radę konfigurować git log? (patrz pkt z aliasami)
  • git to nie tylko kontrola wersji, więc jak to wygląda z integracją z pozostałymi toolami?
  • najgorzej to jest w ogóle gdy ktoś coś skopie w lokalnym drzewku (zdarza mi się do bardzo często ; p). Nie widzę wtedy innej opcji wyprowadzenia tego na prostą jak zaklepanie kilku komend z cui.
3
niezdecydowany napisał(a):

" SourceTree itp pozwalają wszystko szybko i łatwo wyklikać", zrób pusha z forcem - powodzenia...

Did you mean?
13c0476524.png

Poza tym git pod Linusem dobrze integruje się z shellem, tab podpowiada wszystko nazwy komend, nazwy branch'y, nazwy zmienionych plików (strasznie mi tego brakuje na innych platformach).

Dla Windows - posh-git: http://dahlbyk.github.io/posh-git/

  • jeśli nie chcę zrobić czegoś trywialnego (nowy commit/push/pull/merge) tylko np. commit --amend to tracę sporo czasu na odszukanie takiej opcji (o ile w ogóle to jest możliwe z poziomu gui)

Oh rly?
57abd8b637.png

  • jeśli nie chcę zrobić czegoś trywialnego (nowy commit/push/pull/merge) tylko np. commit --amend to tracę sporo czasu na odszukanie takiej opcji (o ile w ogóle to jest możliwe z poziomu gui)

Muszę tak nawiasem przyznać, że git log --graph jest dla mnie na przykład o wiele mniej czytelny niż obejrzenie tego w formie graficznej w jakimś GUI. W ogóle historię commitów o wiele lepiej mi się ogląda poza konsolą.

I druga rzecz - o wiele wygodniej mi się wybiera pliki do dodania/commitu klikając myszką (jeżeli nie commituję wszystkiego, a po kawałku, bo niestety tak mam).

0

@Ktos wybrałeś najbardziej banalny przykład. Pokaż jak wyklikać np. rebase interactie mając 5 lokalnych commitów będąc w konflikcie z remote branchem i chcąc squoshować np commity 1 3 5 dodatkowo je przegrupowując do postaci 3 1 5 a resztę np. zestashować.

Poza tym...

Ktos napisał(a):

Muszę tak nawiasem przyznać, że git log --graph jest dla mnie na przykład o wiele mniej czytelny niż obejrzenie tego w formie graficznej w jakimś GUI. W ogóle historię commitów o wiele lepiej mi się ogląda poza konsolą.

To argument z cyklu wolę motor od samochodu. Fakt faktem, że cały ten wątek taki jest (moja opinia także ; p).

Ktos napisał(a):

I druga rzecz - o wiele wygodniej mi się wybiera pliki do dodania/commitu klikając myszką (jeżeli nie commituję wszystkiego, a po kawałku, bo niestety tak mam).

Jak wyżej.

2

Jak ktoś mi znajdzie GUI Gita wspierające Git LFS lub git-imerge na dzień dzisiejszy to przyznam, że nadążają. Ale tak jak powiedzieli przedmówcy - Git w poziomu linii poleceń jest IMHO znacznie szybszy i wygodniejszy (zwłaszcza jak się używa dobrego shella, w moim przypadku - fish).

Wystarczy ustawić parę aliasów, mieć dobre tab-completion oraz zainstalować parę dodatków (hub, git-up, git-imerge) i bangla znacznie lepiej niż jakiekolwiek GUI dało by radę. Nawet do wyświetlania drzewa można użyć tig jak ktoś nie lubi git log --graph --oneline (poniżej wersja trochę bardziej dokoksana).

Tak BTW moje aliasy, może ktoś znajdzie coś ciekawego dla siebie (polecam git todo i git fixme):

alias.aliases config --get-regexp ^alias
alias.b branch
alias.ca commit --amend
alias.ci commit
alias.cl clone
alias.co checkout
alias.conflicts !git ls-files -u | cut -f 2 | sort -u
alias.cp cherry-pick
alias.d difftool
alias.f fetch
alias.fix grep --heading -n --break -I --ignore-case -e '\bFIX(ME)?\b'
alias.git !git
alias.issue !ghi
alias.latest for-each-ref --sort=-committerdate --format='%(committerdate:short) %(refname:short)'
alias.lg log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
alias.lga log --color --graph --abbrev-commit --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --all
alias.rci commit --amend --reuse-message=HEAD
alias.rmdf !git rm $(git ls-files --deleted)
alias.rollback reset --hard HEAD^
alias.root rev-parse --show-toplevel
alias.skip update-index --assume-unchanged
alias.skipped !git ls-files -v | grep -P '^[a-z]'
alias.st status -sb
alias.todo grep --heading -n --break -I --ignore-case -e '\bTODO\b'
alias.ui !gitg
alias.unskip update-index --no-assume-unchanged
alias.today log --since=midnight --author='Łukasz Niemier' --oneline
alias.fall fetch --all --prune
alias.restream rebase @{u}
alias.squash rebase -i @{u}

PS @Ktos jakkolwiek jest amend, to jakoś --fixup nie widzę.

1

rebase interactive też jest do zrobienia w TortoiseGit, więc squash, pick czy zmiana kolejności tam są do zrobienia. Ale nie widzę opcji do stash :-)

c0589ff992.png

Tak BTW moje aliasy, może ktoś znajdzie coś ciekawego dla siebie

Ja od siebie dorzucę:

alias.mm=merge --no-ff
alias.st=status
2
eL napisał(a):

Więc jaki sens jest korzystania z konsoli? Ma ona jakieś "super moce" w Gicie w stosunku do nakładek graficznych? Na co dzień w pracy wszystko klepiecie ręcznie czy jednak żeby było szybko i sprawnie korzystacie z jakichś dodatkowych narzędzi?

Niektóre bardziej zaawansowane operacje lepiej robić za pomocą konsoli. Niektóre trzeba robić przez konsolę, jeśli GUI jest upośledzone i się nie da. Ale jeśli wygodnie pracuje Ci się na co dzień z GUI, to nie widzę sensu w zmianie przyzwyczajeń na siłę, tylko po to, żeby móc się polansować znajomością konsoli.

mar-ek1 napisał(a):

Konsola w przeciwieństwie do pluginów jest mniej więcej wszędzie taka sama, tzn. niezależnie od tego czy ktoś pracuje na linuxie czy windowsie, lub czy pracuje w Eclipsie, Visual Studio czy Notatniku to zawsze może tak samo użyć GITa "konsolowego" przez co uczy się uniwersalnej wiedzy i komend, a nie uzależnia się od konkretnego dodatku do konkretnego IDE

Ale nie trzeba używać dodatków do IDE, można używać normalnego graficznego klienta, który jest taki sam na wszystkich platformach i tak samo się go obsługuje.

Co Wy macie z tymi myszkami? Korzystanie z GUI nie oznacza konieczności używania myszki i klikania. Istnieje coś takiego jak skróty klawiaturowe. Za to GUI bardzo dobrze wizualizuje historię commitów i zmiany między nimi, zawartość katalogu roboczego i indeksu, konflikty. Moim zdaniem dużo lepiej niż konsola, która nie wizualizuje niczego, no ale to pewno kwestia przyzwyczajeń i wzroku.

MarekR22 napisał(a):

Poza tym git pod Linusem dobrze integruje się z shellem, tab podpowiada wszystko nazwy komend, nazwy branch'y, nazwy zmienionych plików (strasznie mi tego brakuje na innych platformach).

Doskonałe rozwiązanie problemów nieznanych podczas korzystania z GUI. :)

Poza tym nie wyobrażam sobie robić rebase za pomocą nakładki (Source Tree) szczególnie jeśli w grę wchodzą trzy branche (miałem prę takich przypadków). Przy zaawansowanych rzeczach, piszczac w konsoli wiem co się stanie, w SourceTree efekt bywa nieprzewidywalny.

Bo SourceTree jest c****. Wystarczy spojrzeć na to cukierkowe GUI, żeby stwierdzić, że to się do niczego nie nadaje.

satirev napisał(a):
  • jeśli nie chcę zrobić czegoś trywialnego (nowy commit/push/pull/merge) tylko np. commit --amend to tracę sporo czasu na odszukanie takiej opcji (o ile w ogóle to jest możliwe z poziomu gui)

Banał.

  • co gdy pracuję na rebase flow zamiast merge? (3 dni szukania opcji o ile istnieją) Widział ktoś kiedyś rebase interactive w kliencie gui?

Ja.

  • cherry pick?

Żaden problem.

  • jak chcę zrobić alias na push do refs/for/master z jakimiś przełącznikami i pod jakimiś warunkami to jak to wyklikać z poziomu gui i jak to zarejestrować jako macro?

Aliasy to typowo konsolowe wspomagacze, więc jaki byłby sens robienia tego przez GUI?

  • w gui da radę konfigurować git log? (patrz pkt z aliasami)

Po co?

  • git to nie tylko kontrola wersji, więc jak to wygląda z integracją z pozostałymi toolami?

Konkretnie którymi? Bo zdaje sie, że twórcy gita uważają go właśnie za system kontroli wersji.

  • najgorzej to jest w ogóle gdy ktoś coś skopie w lokalnym drzewku (zdarza mi się do bardzo często ; p).

No i to jest właśnie dowód na "wyższość" konsoli...

Nie mam zamiaru nikogo do niczego przekonywać, niech każdy używa, co mu wygodnie, ale niech ludzie, którzy porządnego klienta GUI nie widzieli na oczy, nie piszą, że nic się w nich nie da zrobić, bo to trochę śmieszne.

P.S. Ja wciskam ctrl + spacja, otwiera mi się okno ze wszystkimi zmianami w katalogu roboczym, przechodzę po plikach widząc natychmiast to, co się w nich zmieniło, alt + s dodaje mi plik do indeksu, potem 2 x tab, wpisuję komentarz i wciskam ctrl + enter, żeby zrobić commit. Ile poleceń muszę wydać w konsoli, żeby osiągnąć ten sam efekt?

0

Zaczniemy od wierszyka

Żadna Laska
Żadna Lala
Nie zastąpi
Terminala

Konsola git to podstawa. Klienty Gui może i są fajne, ale zazwyczaj maja w sobie jakieś magiczne przełączniki pokonfigurowane, które nie zawsze robią to co chcemy. Ponad to na poziomie konsoli masz mniej więcej to samo wszędzie. Windows czy linux nie ma różnicy, a klienty GUI? Każdy inny. I najważniejsza rzecz moim zdaniem. Jeżeli opanujesz konsolę to będziesz pracować szybciej. Inny komputer? Nie problem. Brak GUI. Nie problem.

// edit jak skonfigurujesz git przy bardziej skomplikowanych jobach Jenkinsa/TeamCity?

0
Koziołek napisał(a):

Klienty Gui może i są fajne, ale zazwyczaj maja w sobie jakieś magiczne przełączniki pokonfigurowane, które nie zawsze robią to co chcemy.

To jest kwestia znajomości narzędzia. Przecież jeśli ktoś w konsoli będzie klepał polecenia bez zrozumienia, to też prawdopodobnie nie osiągnie tego, czego chce.

Ponad to na poziomie konsoli masz mniej więcej to samo wszędzie. Windows czy linux nie ma różnicy, a klienty GUI? Każdy inny.

Ale nie trzeba używać innego klienta na każdym środowisku, można tego samego na każdym.

I najważniejsza rzecz moim zdaniem. Jeżeli opanujesz konsolę to będziesz pracować szybciej. Inny komputer? Nie problem. Brak GUI. Nie problem.

No i to jest faktyczny argument - konsola jest znacznie szybsza w użyciu wtedy, gdy niczym poza konsolą nie dysponujemy. :P

A tak na serio - znajomość działania gita (a więc i jego poleceń) to trochę co innego niż efektywna praca na co dzień. O ile proste operacje typu fetch, push czy nawet commit wszystkich zmian bez zastanowienia względnie łatwo zrobić z konsoli, o tyle w przypadku jakichkolwiek operacji wymagających interakcji czy czytania kodu rzekoma wyższość konsoli staje się dyskusyjna.

0
somekind napisał(a)

o tyle w przypadku jakichkolwiek operacji wymagających interakcji czy czytania kodu rzekoma wyższość konsoli staje się dyskusyjna.

też nie zawsze, narzędzia GUI (poza zintegrowanymi z IDE) nie mają podpowiadania składni, sprawdzania i kompilacji w locie, zatem finalnie wiele rzeczy i tak musisz robić ręcznie, bo czy jest różnica pomiędzy git-gui, a vimdiff-em w edycji kodu? Co innego z poziomu Idei na ten przykład. Tam rzeczywiście czasami pewne rzeczy robi się łatwiej, bo edytor krzyczy, że psujesz kod.

2

Jaki jest sens korzystania z konsoli GIT?

Taki, że Git jest tak skomplikowany, że twórcy GUI jeszcze go do końca nie ogarnęli.

0
somekind napisał(a):

A tak na serio - znajomość działania gita (a więc i jego poleceń) to trochę co innego niż efektywna praca na co dzień. O ile proste operacje typu fetch, push czy nawet commit wszystkich zmian bez zastanowienia względnie łatwo zrobić z konsoli, o tyle w przypadku jakichkolwiek operacji wymagających interakcji czy czytania kodu rzekoma wyższość konsoli staje się dyskusyjna.

Niektórych bardziej zaawansowanych opcji nie użyjesz nawet w GUI. O ile pewnie takie nieudane rebase to jakoś rozwiązali by odwrócić to jakoś (terminal to git reflog i git reset), ale np. takiego git imerge z poziomu żadnego GUI raczej nie zrobisz. Tak samo jak niektórzy używają (nie wiem po co) git flow to GUI w większości musisz się samemu męczyć zamiast używać jasnych poleceń. Dodatkową zaletą terminala jest to, że istnieje wiele narzędzi, które pozwalają Ci uprościć sobie pracę, jak np. hub, który znacznie upraszcza pracę na GitHubie (forkować, pull-requesty robisz z poziomu linii poleceń, można sprawdzić status CI, etc.). Niby GitHub for Windows/Mac to wszystko ma, ale to się kłóci z tym by używać wszędzie tego samego narzędzia.

A tak jak wcześniej powiedziałem - odpowiednie aliasy i parę dodatkowych narzędzi (np. git-up czy git-imerge) powoduje, że GUI staje się bardziej przeszkodą w normalnej pracy niż pomocą.

0
somekind napisał(a):
MarekR22 napisał(a):

Poza tym git pod Linusem dobrze integruje się z shellem, tab podpowiada wszystko nazwy komend, nazwy branch'y, nazwy zmienionych plików (strasznie mi tego brakuje na innych platformach).

Doskonałe rozwiązanie problemów nieznanych podczas korzystania z GUI. :)

Mam teraz repo, na którym pracuje dużo ludzi i jest dużo branch'y. Wierz mi to, że w SourceTree wiedzę te wszystkie branche i mogę je klikać, to wcale nie jest tak pomocne, bo najpierw muszę wypatrzeć ten którego szukam. Z linii poleceń w tym wypadku jest szybciej i wygodniej (jeśli jest integracja i uzupełnianie tabem), piszę parę liter i uzupełniam tabulatorem i zajmuje mi to 3 razy mniej czasu niż wyszukiwanie wzrokiem w SourceTree.

By była jasność też używam SourceTree i na pewno będę używał w przyszłości gita z GUI, ale wyklinanie linii poleceń uważam za bezsens.

2
Koziołek napisał(a):

też nie zawsze, narzędzia GUI (poza zintegrowanymi z IDE) nie mają podpowiadania składni, sprawdzania i kompilacji w locie, zatem finalnie wiele rzeczy i tak musisz robić ręcznie bo czy jest różnica pomiędzy git-gui, a vimdiff-em w edycji kodu?

Jakoś nigdy chyba nie potrzebowałem zaawansowanej edycji kodu podczas robienia commitowania. Za to sprawdzenie, co wbijam przydaje się często.
Zobacz jak to tu wygląda:
user image
Lewy górny róg to widok na working directory, lewy dolny to indeks, strzałeczkami wygodnie przerzucam pliki między nimi, a prawy górny róg to podgląd zmian w wybranym pliku.
Konsola będzie szybsza tylko jeśli dodam na raz wszystkie pliki do indeksu i nie będę ich przeglądał przed zacommitowaniem. Jeśli ktoś tak pracuje i mu wygodnie, to ok, ja jednak wolę mieć pełną kontrolę i dobrą widoczność na to, co robię.

winerfresh napisał(a):

takiego git imerge z poziomu żadnego GUI raczej nie zrobisz.

Nie zrobię też z konsoli, bo to nie jest polecenie gita tylko zewnętrzne narzędzie.

Dodatkową zaletą terminala jest to, że istnieje wiele narzędzi

Tylko wątek jest o gicie, nie o terminalu.

Zresztą, do githuba, flowa i paru innych narzędzi istnieją pluginy wbudowane w GitExtensions: http://git-extensions-documentation.readthedocs.org/en/latest/plugins.html

A tak jak wcześniej powiedziałem - odpowiednie aliasy i parę dodatkowych narzędzi (np. git-up czy git-imerge) powoduje, że GUI staje się bardziej przeszkodą w normalnej pracy niż pomocą.

Każde narzędzie będzie przeszkodą, jeśli nie będzie się go umiało używać albo będzie używało niepoprawnie.

MarekR22 napisał(a):

Mam teraz repo, na którym pracuje dużo ludzi i jest dużo branch'y. Wierz mi to, że w SourceTree wiedzę te wszystkie branche i mogę je klikać, to wcale nie jest tak pomocne, bo najpierw muszę wypatrzeć ten którego szukam. Z linii poleceń w tym wypadku jest szybciej i wygodniej (jeśli jest integracja i uzupełnianie tabem), piszę parę liter i uzupełniam tabulatorem i zajmuje mi to 3 razy mniej czasu niż wyszukiwanie wzrokiem w SourceTree.

Checkout innego brancha: wciskam ctrl + ., wpisuję klika liter, nazwa brancha mi się podpowiada i wciskam enter.
Merge z innym branchem - tak samo, tylko ctrl + m.
Nie muszę niczego szukać wzrokiem, nie muszę niczego klikać. Może to jednak problem z SourceTree?

wyklinanie linii poleceń uważam za bezsens.

Ja również. Problem w tym, że tutaj wyklinane są wyłącznie klienty GUI, a nie linia poleceń. Jak na razie, to główne argumenty za konsolowym gitem:

  1. mogę naprawić to, co sam zepsułem w repo korzystając z konsoli (bez komentarza);
  2. istnieją inne niż git programy konsolowe (no tak, bo włączenie GUI sprawia, że narzędzia konsolowe znikają z dysku);
  3. muszę używać myszki (no tak, bo skróty klawiaturowe nie istnieją).
    I serio, nawet ja mam problem z określeniem, który z nich jest bardziej bez sensu.
0
somekind napisał(a):
winerfresh napisał(a):

takiego git imerge z poziomu żadnego GUI raczej nie zrobisz.

Nie zrobię też z konsoli, bo to nie jest polecenie gita tylko zewnętrzne narzędzie.

Nie by coś, ale Git składa się z "zewnętrznych narzędzi". Tak naprawdę to mało poleceń jest w core, reszta to skrypty/nakładki. Więc dodatkowe polecenia są normalne i dość często używane.

/usr/lib/git-core/git-http-push
/usr/lib/git-core/git-difftool--helper
/usr/lib/git-core/git-am
/usr/lib/git-core/git-rebase
/usr/lib/git-core/git-mergetool--lib
/usr/lib/git-core/git-sh-i18n
/usr/lib/git-core/git-submodule
/usr/lib/git-core/git-instaweb
/usr/lib/git-core/git-shell
/usr/lib/git-core/git-merge-octopus
/usr/lib/git-core/git-filter-branch
/usr/lib/git-core/git-credential-store
/usr/lib/git-core/git-credential-cache--daemon
/usr/lib/git-core/git-rebase--interactive
/usr/lib/git-core/git-subtree
/usr/lib/git-core/git-daemon
/usr/lib/git-core/git-mergetool
/usr/lib/git-core/git-show-index
/usr/lib/git-core/git-stash
/usr/lib/git-core/git-rebase--am
/usr/lib/git-core/git-credential-cache
/usr/lib/git-core/git-merge-resolve
/usr/lib/git-core/git-difftool
/usr/lib/git-core/git-pull
/usr/lib/git-core/git-request-pull
/usr/lib/git-core/git-upload-pack
/usr/lib/git-core/git-sh-setup
/usr/lib/git-core/git-bisect
/usr/lib/git-core/git-quiltimport
/usr/lib/git-core/git-add--interactive
/usr/lib/git-core/git-sh-i18n--envsubst
/usr/lib/git-core/git-sh-prompt
/usr/lib/git-core/git-web--browse
/usr/lib/git-core/git-remote-http
/usr/lib/git-core/git-rebase--merge
/usr/lib/git-core/git-http-backend
/usr/lib/git-core/git-imap-send
/usr/lib/git-core/git
/usr/lib/git-core/git-merge-one-file
/usr/lib/git-core/git-fast-import
/usr/lib/git-core/git-relink
/usr/lib/git-core/git-parse-remote
/usr/lib/git-core/git-remote-testsvn
/usr/lib/git-core/git-http-fetch
/usr/lib/git-core/git-check-ignore
/usr/lib/git-core/git-for-each-ref
/usr/lib/git-core/git-ls-remote
/usr/lib/git-core/git-diff-files
/usr/lib/git-core/git-fsck-objects
/usr/lib/git-core/git-checkout-index
/usr/lib/git-core/git-push
/usr/lib/git-core/git-replace
/usr/lib/git-core/git-pack-refs
/usr/lib/git-core/git-check-mailmap
/usr/lib/git-core/git-read-tree
/usr/lib/git-core/git-hash-object
/usr/lib/git-core/git-pack-redundant
/usr/lib/git-core/git-column
/usr/lib/git-core/git-symbolic-ref
/usr/lib/git-core/git-fast-export
/usr/lib/git-core/git-mv
/usr/lib/git-core/git-cat-file
/usr/lib/git-core/git-mailinfo
/usr/lib/git-core/git-format-patch
/usr/lib/git-core/git-init-db
/usr/lib/git-core/git-remote-fd
/usr/lib/git-core/git-index-pack
/usr/lib/git-core/git-remote-ftp
/usr/lib/git-core/git-rev-parse
/usr/lib/git-core/git-add
/usr/lib/git-core/git-status
/usr/lib/git-core/git-var
/usr/lib/git-core/git-prune
/usr/lib/git-core/git-patch-id
/usr/lib/git-core/git-pack-objects
/usr/lib/git-core/git-tag
/usr/lib/git-core/git-credential
/usr/lib/git-core/git-rerere
/usr/lib/git-core/git-remote-ftps
/usr/lib/git-core/git-unpack-objects
/usr/lib/git-core/git-verify-commit
/usr/lib/git-core/git-fsck
/usr/lib/git-core/git-merge-ours
/usr/lib/git-core/git-show
/usr/lib/git-core/git-annotate
/usr/lib/git-core/git-update-server-info
/usr/lib/git-core/git-merge-index
/usr/lib/git-core/git-diff-index
/usr/lib/git-core/git-remote-https
/usr/lib/git-core/git-cherry-pick
/usr/lib/git-core/git-merge-tree
/usr/lib/git-core/git-commit-tree
/usr/lib/git-core/git-update-index
/usr/lib/git-core/git-config
/usr/lib/git-core/git-reflog
/usr/lib/git-core/git-prune-packed
/usr/lib/git-core/git-receive-pack
/usr/lib/git-core/git-apply
/usr/lib/git-core/git-grep
/usr/lib/git-core/git-stage
/usr/lib/git-core/git-ls-tree
/usr/lib/git-core/git-describe
/usr/lib/git-core/git-init
/usr/lib/git-core/git-mailsplit
/usr/lib/git-core/git-fetch
/usr/lib/git-core/git-revert
/usr/lib/git-core/git-notes
/usr/lib/git-core/git-mktag
/usr/lib/git-core/git-show-branch
/usr/lib/git-core/git-mktree
/usr/lib/git-core/git-cherry
/usr/lib/git-core/git-repack
/usr/lib/git-core/git-fmt-merge-msg
/usr/lib/git-core/git-merge-subtree
/usr/lib/git-core/git-verify-tag
/usr/lib/git-core/git-remote
/usr/lib/git-core/git-write-tree
/usr/lib/git-core/git-rev-list
/usr/lib/git-core/git-get-tar-commit-id
/usr/lib/git-core/git-commit
/usr/lib/git-core/git-verify-pack
/usr/lib/git-core/git-name-rev
/usr/lib/git-core/git-branch
/usr/lib/git-core/git-help
/usr/lib/git-core/git-merge-recursive
/usr/lib/git-core/git-gc
/usr/lib/git-core/git-bisect--helper
/usr/lib/git-core/git-interpret-trailers
/usr/lib/git-core/git-check-attr
/usr/lib/git-core/git-checkout
/usr/lib/git-core/git-archive
/usr/lib/git-core/git-check-ref-format
/usr/lib/git-core/git-whatchanged
/usr/lib/git-core/git-clone
/usr/lib/git-core/git-show-ref
/usr/lib/git-core/git-blame
/usr/lib/git-core/git-bundle
/usr/lib/git-core/git-diff-tree
/usr/lib/git-core/git-send-pack
/usr/lib/git-core/git-clean
/usr/lib/git-core/git-ls-files
/usr/lib/git-core/git-shortlog
/usr/lib/git-core/git-fetch-pack
/usr/lib/git-core/git-diff
/usr/lib/git-core/git-rm
/usr/lib/git-core/git-unpack-file
/usr/lib/git-core/git-merge
/usr/lib/git-core/git-reset
/usr/lib/git-core/git-merge-file
/usr/lib/git-core/git-count-objects
/usr/lib/git-core/git-upload-archive
/usr/lib/git-core/git-stripspace
/usr/lib/git-core/git-merge-base
/usr/lib/git-core/git-remote-ext
/usr/lib/git-core/git-log
/usr/lib/git-core/git-update-ref
0

@winerfresh, nie żeby coś, ale jak zainstaluję gita, to mam wszystko z wyjątkiem tego Twojego imerge. Jeśli chce się go używać, trzeba go niestety doinstalować, bo to zewnętrzne narzędzia. To co Ty wylistowałeś, to standardowe narzędzia gita.

Tak czy siak, w czym to narzędzie jest lepsze od utworzenia brancha na czas mergowania? Bo tak sobie radziłem do tej pory, i uznaję to za całkiem wygodne rozwiązanie.

0

Tworzenie brancha na czas merge to nie to samo. Różnica jest taka, że imerge stara się zredukować ilość konfliktów poprzez nakładanie małych zmian i naprawianie konfliktów "po drodze", dzięki czemu łatwiej jest je rozwiązać i często będzie ich znacznie mniej.

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