터미널에서 커맨드로 깃을 사용하면 좋은 점

vim 에디터 쓰는 개발자가 멋이 있잖아요.

터미널에서 커맨드를 통해 깃을 사용하는 것의 좋은 점은 다음과 같다.

1. 멋있다.
2. 편하다.
3. 동작을 이해하기 쉽다.

1 - 멋있다

깃허브 페이지에서 레포 생성하고, 클론하고, 파일 드래그 앤 드랍 했던 때를 생각하면 작금의 내 모습은 거의 임베디드 개발자의 모습이다.

42서울에서 상당 시간 리눅스 명령어를 사용하며 터미널의 단축키와 UI(?)에 익숙해진 결과 지금까지 터미널을 통해 깃 관련 작업을 해오고 있다.

오히려 GUI를 쓰는 것을 못 해서 효과적인, 혹은 시각적인 협업 툴을 못 쓰는 … 불상사가 있던 적은 없지만 아무튼?

불친절한 Xcode와 함께 살아오기를 n개월… vim 에디터를 켜서 머지 컨플릭트 해결하는 데에 도가 터버린 것이다.

단순히 컨플릭 해결하는 삽질의 과정에서도 개발자다움을 놓치지 않을 수 있는 것..!

2 - 편하다

사실 1번은 우스개소리였고, 2번이 핵심이다.

편하다고? 그럴리가.

없다. 맞다. 처음엔 편하지 않다.

하지만 처음엔 GUI도 안 편하다. 깃허브 웹사이트도 처음엔 어려웠을 것이 분명해..!

지속적으로 변화하는 GUI와 달리 커맨드라인 인터페이스는 변치 않는다. 명령어도 변하지 않고, 단축키도 내가 바꾸지 않는 이상 변할 일이 없다.

사용성의 편의도 있지만 그보다 더 큰 장점은, 커맨드라인 인터페이스에서 오류가 나거나 오탈자가 나면 관련해서 해결방법을 제시해주고, 현재 내 파일들이 어떤 상태고 얼마나 진행이 됐는지 등 모든 상태에 직접 접근해 그 내용을 확인할 수 있다.

직관성을 위해 GUI로 만들어진 버튼들은 결국 직접 명령어를 치는 것보다 그 내용이나 진행상황을 알기 어렵다. (물론 아닐 수 있음..)

3 - 동작을 이해하기 쉽다

2번과 이어지는 이야기인데, CLI를 사용하면 절차를 밟아나가고 그 절차에 대한 결과를 실시간으로 확인할 수 있다. 이 과정에서 내가 작성하고 있는 이 명령어들의 역할과 내가 다음으로 해야 할 일에 대해 숙지하게 된다.

버튼 온클릭에 감춰진 git add ., git commit, git rebase 등의 절차들과 이를 실패했을 때 발생하는 에러 메시지, 직접 스테이징하고 푸시하고, 땡겨오고, 컨플릭을 수정하는 과정을 모두 한 땀 한 땀 겪으면 이 명령어의 이름이 왜 이렇고, 이 다음 동작이 왜 이렇게 되어야 하는지 알게 된다.

동작을 이해하면 보다 빠르게 작업을 수행할 수 있고, 남는 시간에 내가 아는 것 이상의 것들을 시도해볼 수 있다.

결론

주니어, 그리고 솔직히 CLI 뭐 그렇게 하드하게 쓰는 사람도 아닌 입장에서 이 글의 깊이가 얼마나 있겠냐만 어쨌든 내가 경험한 것에 따라, 내 생각에 따라 CLI로 깃 작업을 하는 것이 좋은 점을 이야기해봤다.

근데 그건 분명한 듯… 브랜치는 CLI로 보는 거 아닌 것 같ㅇㅏ요 ,… ㅠㅠ

그리고 이건 실습!