GitHub 용 GUI 앱이있을 때 왜 git을 배우나요?

GitHub가 Mac 과 Windows 모두에 GUI 앱을 제공한다고 가정 하면 명령 행에서 git을 사용하는 방법을 배우면 어떤 이점이 있습니까?

현재 Mac 응용 프로그램을 사용하여 리포지토리를 업데이트하고 있으며 지금까지 내 요구를 충족시키는 것으로 보입니다. 무엇을 놓칠 수 있습니까?

이 질문은 "GUI 대안이 존재하는 CLI를 왜 알아야합니까?"의 특별한 경우라고 생각합니다. 나는 후자의 질문이 GUI만큼 오래되었다고 생각하며, 몇 년 동안 많은 시도가 있었다고 가정합니다. 나는이 질문에 대한 내 자신의 대답을 통해 내 방식 범블을 시도 할 수 있지만, 닐 스티븐슨은 내가 그의 놀라운 에세이 10 년 이상의 전 '궁극적 인 대답'등의 동의 관절 ... 명령 줄이 되었습니까 처음에 .

에세이는 컴퓨팅의 여러 측면에 대해 다루고 있으며 심지어 Stephenson 자신도 이제는 더 이상 쓸모가 없다고 생각 하지만 CLI는 어떤 방식으로 CLI가 더 나은 GUI로 어떤 방식으로 문자 그대로 내 인생을 바꿨는지 설명합니다. 오래 읽었지만 (최대 40 페이지) 여기에 질문 한 사람에게는 충분히 추천 할 수 없습니다.

마지막으로, 비슷한 맥락에서 어떤 CLI 대 GUI 종류의 질문에 대답 하겠지만, 내가 선택한 모든 컴퓨터 때문에 내 대답이 특정 질문에 특히 해당한다고 생각합니다 git. git아마도 Stephenson의 에세이에 설명 된 것처럼 홀-홀그 은유에 진정으로 가치가있는 컴퓨터 도구 목록의 최신 도구 일 것입니다. git다른 유닉스 계열과 마찬가지로 CLI 자체를 모두 알아야하는 이유입니다. 때로는 불규칙한 '도자기' 에도 불구하고 ; 때때로 그것 때문에.

따라서 OSX 또는 웹 사이트에서 github의 GUI를 사용하여 생산성을 높일 수 있습니다. 예, 실제로 매우 매끄 럽습니다. 사이트의 기능을 자주 사용합니다. 그러나 아닙니다. 당신의 오른쪽 핑키가 git filter-branch이온 한두 명을위한 미친 명령 위에 매달려있을 때 그처럼 경건한 느낌을 갖지 못할 것입니다 . 컴퓨팅에 대한 내 경험에서 한 가지만-정신적 도전, 2AM의 다문화 센터, 친밀한 상승의 사다리, 사용자의 삶에 감동을주고 귀중한 데이터의 PB를 지배하는 친밀한 관계 직업과 편안한 삶- 한 가지만 지키십시오 – 그것은 하나님의 느낌 일 것입니다.

모든 요구 사항이 훌륭하고 훌륭하며 git에 대해 더 깊이 파고들 필요가 없다면 실제로 필요한 것을 배우는 데 시간이 더 많이 소요됩니다.

git은 도구 일뿐입니다 .GUI 앱으로는 할 수없는 일을해야 할 때 알 수 있습니다. github! = git임을 명심하십시오.

CLI 전용 기능의 대부분은 실수로 저장소를 이상한 상태로 가져 와서 고치려고 할 때만 작동합니다. 반면에 레포를 이상한 상태로 만드는 가장 일반적인 방법은 이해하지 못하는 고급 기능을 사용하는 것입니다. GUI가 제공하는 것을 고수하면 99 %의 요구를 충족시킬 수 있습니다.

CLI를 배우고 싶은 다른 이유는 그것이 git의 lingua franca이기 때문입니다. 이는 많은 사람들이 다른 플랫폼에서 다른 GUI를 사용하는 동안 StackOverflow 또는 다른 곳에서 도움을 요청하면 대부분 CLI 명령의 형태로 답을 얻을 수 있음을 의미합니다. CLI를 모르면 도움을 얻을 수있는 옵션이 훨씬 제한적입니다.

GUI 응용 프로그램은 수동 상호 작용을 사용하여 복잡한 동작을 수행합니다. 이것은 프로젝트를 설정하고 새로운 것을 개발하는 데 좋습니다.

CLI (명령 줄 인터페이스)의 이점은 자동화 할 수있는 미리 결정된 스크립트를 만들 수 있다는 것입니다. GitHub의 모든 GUI는 git CLI를 호출하는 멋진 그래픽과 멋진 버튼입니다.

GUI 응용 프로그램 이 당신을 위해 하지 않는 것은 매일 오전 1시 30 분에 서버에서 저장소의 트렁크를 자동으로 업데이트하는 것이지만 git CLI를 호출하는 크론 작업은 실제로 설정하는 쉬운 방법입니다.

또한 팀의 프로젝트에서 작업 할 때 팀원이 지루한 반복 작업 대신 문제 해결에 집중할 수 있도록 설치 스크립트 설정, 스크립트 작성, 스크립트 배포 등이 편리합니다.

CLI가 선호되는 또 다른 이유는 워크 플로 문제입니다. 많은 프레임 워크가 명령 행을 통해 관리됩니다. CLI를 통해 git을 사용하면 프로젝트와 해당 프로젝트 디렉토리에 계속 집중할 수 있습니다. 예를 들어 테스트를 실행 한 다음 새로운 인터페이스를 모두 같은 인터페이스와 위치에서 커밋하기로 결정할 수 있습니다.

나는 최근 SVN에서 Git 로의 마이그레이션을 돕기 위해 Git을 파헤쳐 야한다. 그리고 내가 배운 것은 Git 명령 행 도구는 배우기 어려운 부분 이 아니라는 것입니다.

Git의 개념과 아이디어는 복잡한 부분입니다. (디자인이 잘못 되었기 때문이 아니라 다른 중앙 집중식 VCS에서 온 대부분의 사람들에게 외국 적이기 때문입니다.)

개념을 파악한 후에는 실제 명령 줄 설명이 비교적 쉬워졌습니다. 즉, UI가 실제로 Git을 이해하는 데 도움이되지 않습니다 (가장 간단한 작업 제외).

CLI를 아는 것은 GUI 앱을 얻을 수없는 환경에있을 때 유용합니다.

하나의 잠재적 인 시나리오 : 새로운 도구를 시스템에 도입하기가 귀찮고 긴 폐쇄 된 장소에서 며칠 동안 프로젝트를 도와 달라는 요청을 받았습니다. CLI 만 사용합니다. 모든 것을 다시 배워야하기 때문에 생산성이 크게 떨어졌습니다.

명령 행 git을 배우는 한 가지 이유는 대부분의 문서가 해당 환경에 맞게 작성 되었기 때문입니다. 또한 "git으로 X를 어떻게합니까?"라는 질문을하면 대답에 명령 줄 명령이 포함될 가능성이 있습니다.

GUI와 명령 줄을 사용할 때의 주요 문제 중 하나는 대부분의 경우 프로세스를 동일하게 제어 할 수 없다는 것입니다. 예를 들어, GitHub 애플리케이션은 많은 git 워크 플로우에서 유용성면에서 우수하지만 고급 git 프로세스에서는 여전히 번거로울 수 있습니다.

예를 들어, GitHub 응용 프로그램을 사용하는 방법을 알지 못했던 몇 가지 사항이 있습니다 (각 GUI마다 학습 곡선이 있다는 점에 유의하십시오).

• 리베이스 커밋
• 개별적으로 푸시 / 풀 / 페치 (GitHub에서는 단일 "sync"명령으로 그룹화되어 문제가 발생할 수 있음)
• 커밋 수정

마지막으로 CLI를 사용하면 스크립팅 할 때 이러한 도구를 사용할 수 있습니다.

Mac 용 GitHub에 대해서는 잘 모르지만 Windows 앱은 가장 일반적인 작업 (추가, 커밋, 푸시, 풀 등) 만 수행합니다. 더 복잡한 작업 git merge --no-ff은 명령 줄에서 수행해야합니다.

또한 GUI를 사용할 수없는 경우 (예 : 원격 서버에 SSH로 연결할 때) git이있는 경우가 있습니다.

그러나 그렇지 않으면 GUI가 필요한 모든 것을 제공하면 명령 줄을 배우는 것이 시간 낭비 일 수 있습니다. 내 작업은 Windows 전용 환경에서 TortoiseSVN을 사용하므로 SVN 명령 줄을 한 번만 터치하지 않아도됩니다.

CLI보다 GUI보다 나은 경우를 배웠습니다. 이것을 설명하기 위해, 나는 모든 사람들을위한 책 git-version control에서 예를 들었다.

인트라넷을 통해 공유하려는 경우 다음을 사용할 수 있습니다.

1. Gitolite 서버
2. 베어 리포지토리가있는 공통 공유 디렉토리

Bare Repo 작성 단계를보십시오.

CLI 모드에서 Bare 저장소 작성

베어 리포지토리를 만드는 명령은 --bare 매개 변수를 제외하고 리포지토리를 복제하는 데 사용한 명령과 동일하므로 모든 차이가 있습니다. git clone --bare C:\Users\raviepic3\Desktop\Workbench C:\generic_share\ Bare_Workbench 콘솔에서 앞의 코드를 실행하면 generic_share라는 공통 공유 폴더에 워크 벤치 저장소의 복제본이 작성됩니다.

GUI 모드에서 Bare 저장소 작성

GUI를 사용하여 이미 존재하는 리포지토리에서 베어 클론을 생성하는 것은 쉬운 과정입니다. 당신이해야 할 일은 :

1. 기존 저장소에서 .git 디렉토리를 복사하여 저장소 외부에 different_name.git (새 베어 저장소에 지정할 이름)로 붙여 넣으십시오. 우리의 경우 C : \ Users \ raviepic3 \ Desktop \에 Workbench라는 맨손이 아닌 저장소가 있으며 그 안에 content.docx가 있습니다. 그리고 지금 GUI를 사용하여 새로운 저장소를 만들고 싶습니다. C : \ Users \ raviepic3 \ Desktop \ Workbench.git을 복사하여 C : \ generic_share \ Bare_Workbench.git로 붙여 넣습니다.

2. config file텍스트 편집기로 내부 Bare_Workbench.git을 열고 bare = false문자열 false를 true로 바꾸는 행을 찾으십시오 .

3. 저장 및 종료.

GUI에서는 많은 클릭을해야하고 편집 할 파일을 기억해야합니다. CLI에서 하나의 간단한 명령으로 모든 것을 수행 할 수 있습니다.