Po co uczyć się git, gdy istnieją aplikacje GUI dla GitHub?

Biorąc pod uwagę, że GitHub zapewnia aplikacje GUI zarówno dla komputerów Mac, jak i Windows , jakie są zalety nauki korzystania z git z wiersza poleceń?

Obecnie używam ich aplikacji Mac do aktualizacji moich repozytoriów i jak dotąd wydaje się, że pokrywają moje potrzeby. Czego mi brakuje?

Myślę, że to pytanie jest tylko szczególnym przypadkiem „Dlaczego powinienem nauczyć się dowolnego CLI, dla którego istnieje alternatywa dla GUI?”. Podejrzewam, że to ostatnie pytanie jest tak stare jak GUI, i zakładam, że przez wiele lat próbowano na nie odpowiedzieć. Mógłbym spróbować przebić się przez własną odpowiedź na to pytanie, ale Neal Stephenson sformułował to, z czym się zgadzam, jako „ostateczną odpowiedź” ponad dziesięć lat temu w jego niezwykłym eseju Na początku ... Była linia poleceń .

Podczas gdy esej dotyczy wielu aspektów informatyki, a nawet sam Stephenson uważa, że wiele z nich jest obecnie nieaktualnych, esej wyjaśnia, w jaki sposób CLI są lepszymi GUI w niezwykle przekonujący sposób, który dosłownie zmienił moje życie. To długa lektura (~ 40 stron), ale nie mogę jej wystarczająco polecić każdemu, kto zadaje pytania takie jak zadane tutaj.

Na koniec, choć odpowiedziałbym na jakiekolwiek pytanie CLI kontra GUI w podobnym tonie, myślę, że moja odpowiedź jest szczególnie zgodna z twoim konkretnym pytaniem, ponieważ na wszystkie pytania dotyczące komputera, o które zdecydowałeś się zapytać git. gitjest prawdopodobnie najnowszym narzędziem z niezbyt długiej listy narzędzi komputerowych, które naprawdę są warte metafory „dziurawej dziury”, jak opisano w eseju Stephensona. git, podobnie jak kilka innych uniksowych rzeczy, jest powodem, aby znać CLI same w sobie. Czasami pomimo nieregularnej „porcelany” ; czasami z tego powodu.

Tak, z pewnością możesz być produktywny dzięki graficznemu interfejsowi użytkownika github, zarówno dla OSX, jak i tylko na ich stronie internetowej. Tak, w rzeczywistości jest dość elegancki, często korzystam z funkcji strony. Ale nie, nigdy nie będziesz odczuwał tego pobożnego uczucia, gdy prawy mały wisi nad szalonym git filter-branchrozkazem na eon lub dwa. Gdybym musiał powstrzymać się przed jednym doświadczeniem z komputerami - mentalnymi wyzwaniami, bliskimi przyjaźniami nawiązanymi w centrum danych o 2 nad ranem, nieskończoną drabiną kompetencji do wspinania się, dotykania życia użytkowników i panowaniem nad PB cennych danych, cushy praca i wygodne życie - zachowaj tylko jedną rzecz - byłoby to boskie uczucie.

Jeśli wszystkie twoje potrzeby są zaspokojone, niesamowite, nie musisz zagłębiać się w git, lepiej poświęć swój czas na naukę czegoś, czego naprawdę potrzebujesz.

git to tylko narzędzie, gdy będziesz musiał zrobić coś, czego nie możesz zrobić z aplikacją GUI, będziesz o tym wiedział. Pamiętaj tylko, że github! = Git.

Większość funkcji dostępnych tylko w interfejsie CLI wchodzi w grę tylko wtedy, gdy przypadkowo wprowadzisz repozytorium w dziwny stan i chcesz go naprawić. Z drugiej strony najczęstszym sposobem na wprowadzenie repozytorium w dziwny stan jest użycie zaawansowanych funkcji, których nie rozumiesz. Jeśli będziesz trzymać się tego, co zapewnia GUI, to pokryje twoje potrzeby w 99% przypadków.

Innym powodem, dla którego możesz chcieć nauczyć się CLI, jest to, że jest to lingua franca git. Oznacza to, że chociaż wiele osób używa różnych GUI na różnych platformach, jeśli poprosisz o pomoc w StackOverflow lub gdzie indziej, odpowiedź najprawdopodobniej przyjdzie w postaci poleceń CLI. Jeśli nie znasz interfejsu CLI, opcje uzyskania pomocy będą znacznie bardziej ograniczone.

Aplikacje GUI polegają na ręcznych interakcjach w celu wykonywania złożonych zachowań. Jest to świetne do tworzenia projektów i opracowywania nowych rzeczy.

Zalety interfejsu wiersza poleceń (CLI) wynikają z możliwości tworzenia z góry określonych skryptów, które można zautomatyzować. Wszystkie GUI GitHub to ładne grafiki i fantazyjne przyciski, które wywołują CLI git.

To, czego aplikacja GUI nie zrobi dla ciebie, to automatyczna aktualizacja pnia repo na serwerze codziennie o 1:30, ale zadanie cron, które wywołuje CLI git, jest naprawdę łatwym sposobem na skonfigurowanie tego.

Ponadto podczas pracy nad projektem w zespole wygodnie jest konfigurować skrypty instalacyjne, budować skrypty, wdrażać skrypty itp., Aby członkowie drużyny mogli skupić się na rozwiązywaniu problemów zamiast żmudnych, powtarzalnych zadań.

Innym powodem, dla którego preferowany może być interfejs CLI, jest przepływ pracy. Wiele platform jest zarządzanych za pomocą wiersza polecenia. Używanie git przez CLI pozwala mi pozostać skupionym na moim projekcie i katalogu tego projektu. Na przykład mogę uruchomić test, a następnie zdecydować o zatwierdzeniu wszystkich zmian z tego samego interfejsu i lokalizacji.

Niedawno muszę naprawdę zagłębić się w Git, aby móc pomóc w migracji SVN do Git. I nauczyłem się, że narzędzia wiersza poleceń Git nie są skomplikowaną częścią do nauki.

Koncepcje i pomysły stojące za Git stanowią część złożoną (i to nie dlatego, że są źle zaprojektowane, ale po prostu dlatego, że są obce większości ludzi pochodzących z innych, scentralizowanych VCS).

Po zrozumieniu pojęć rzeczywiste instrukcje wiersza poleceń stały się stosunkowo łatwe. Oznacza to, że interfejs użytkownika tak naprawdę nie pomaga zrozumieć Git (z wyjątkiem najprostszych operacji).

Znajomość interfejsu CLI jest przydatna, gdy (a nie jeśli) jesteś w środowisku, w którym nie można uzyskać aplikacji GUI.

Jeden potencjalny scenariusz: poproszono Cię o pomoc przez kilka dni w projekcie w zamkniętym miejscu, w którym denerwująco trudno jest wprowadzić nowe narzędzia do systemu. Używają tylko CLI. Twoja produktywność właśnie uderzyła, ponieważ musisz nauczyć się wszystkiego od nowa.

Jednym z powodów, dla których warto nauczyć się git z wiersza poleceń, jest to, że większość dokumentacji jest napisana dla tego środowiska. Ponadto, jeśli zadasz pytanie: „jak zrobić X za pomocą git?”, Są szanse, że odpowiedź będzie zawierać polecenia wiersza polecenia.

Jednym z głównych problemów z użyciem GUI w porównaniu z wierszem poleceń jest to, że w większości przypadków nie można mieć takiej samej kontroli nad procesem. Na przykład aplikacja GitHub jest świetna pod względem użyteczności dla wielu przepływów pracy git, ale nadal może być uciążliwa dla zaawansowanych procesów git.

Jako przykład, oto kilka rzeczy, których nie wymyśliłem, jak korzystać z aplikacji GitHub (należy również zauważyć, że każdy GUI ma również krzywą uczenia się).

• Rebasing zatwierdza
• Wciśnij / pociągnij / pobierz indywidualnie (w GitHub są one zgrupowane w jednym poleceniu „synchronizacji”, co może czasami powodować problemy)
• Zmienia zobowiązania

Wreszcie interfejsy CLI pozwalają użytkownikom korzystać z tych narzędzi podczas tworzenia skryptów.

Nie wiem o GitHub dla komputerów Mac, ale aplikacja Windows wykonuje tylko najbardziej typowe zadania - dodawanie, zatwierdzanie, wypychanie, wyciąganie itp. Bardziej złożone zadania, takie jak git merge --no-ffmuszą być wykonywane z wiersza poleceń.

Są też przypadki z git, gdy GUI nie jest dostępne, np. Gdy SSHing do zdalnych serwerów.

Ale w przeciwnym razie, jeśli GUI daje ci wszystko, czego potrzebujesz, to nauka wiersza poleceń może być stratą czasu. Moja praca wykorzystuje TortoiseSVN w środowisku tylko Windows i nie musiałem dotykać wiersza poleceń SVN ani razu.

Właśnie nauczyłem się jednego przypadku, w którym CLI może być lepszy niż GUI. Aby to zilustrować, wziąłem przykład z książki git - kontrola wersji dla wszystkich.

Jeśli chcesz udostępnić przez intranet, możesz użyć:

1. Serwer Gitolite
2. Wspólny katalog udostępniania z nagimi repozytoriami

Spójrz na kroki, aby utworzyć nagie repo.

Tworzenie pustego repozytorium w trybie CLI

Polecenie utworzenia pustego repozytorium byłoby takie samo, jak użyte do klonowania repozytorium, z wyjątkiem parametru --bare, co robi różnicę. git clone --bare C:\Users\raviepic3\Desktop\Workbench C:\generic_share\ Bare_Workbench Wykonanie powyższego kodu w konsoli powinno utworzyć czysty klon naszego repozytorium Workbench we wspólnym folderze współdzielonym o nazwie udział_ogólny.

Tworzenie nagiego repozytorium w trybie GUI

Tworzenie gołego klonu z już istniejącego repozytorium za pomocą GUI jest łatwym procesem. Wszystko, co musisz zrobić, to:

1. Skopiuj katalog .git z istniejącego repozytorium i wklej go z inną nazwą ..git (jakakolwiek nazwa chcesz nadać nowemu nagiemu repozytorium) poza repozytorium. W naszym przypadku mamy niezabezpieczone repozytorium o nazwie Workbench w C: \ Users \ raviepic3 \ Desktop \, w którym mamy content.docx. A teraz chcę utworzyć nowe nagie repozytorium z tego interfejsu graficznego. Skopiuję C: \ Users \ raviepic3 \ Desktop \ Workbench.git i wkleję go jako C: \ generic_share \ Bare_Workbench.git.

2. Otwórz config filewewnętrzny plik Bare_Workbench.git za pomocą edytora tekstu i znajdź wiersz, który mówi, bare = falsei zamień ciąg false na true.

3. Zapisz i wyjdź.

W GUI musisz wykonać tak wiele kliknięć i pamiętać, który plik ma być edytowany. W CLI jedno proste polecenie robi to wszystko za Ciebie.