git

git은 사실상 표준이 되었고, 요즘 git 없이 개발을 하는 건 사실상 불가능합니다. 그런데 git에서 왜 ssh나 https가 나오는지 모르는 사람이 많더라고요. 그래서 이번 글에서는 git과 ssh, https의 관계에 대해서 알아보겠습니다. git은 소스 코드 관리 도구입니다. 형상은 여기서 중요하지 않기 때문에 제외했습니다. 소스 코드를 한 컴퓨터에서 관리한다면 ssh나 https가 필요 없었을 겁니다. 그런데 소스 코드를 깃허브 같은 데에다가 올리잖아요? 서버에 접속하는 과정에서 안전하게 데이터를 전송할 방법이 필요합니다. 그 과정에서 ssh나 https가 사용됩니다.

제가 자주 갔던 카페가 있습니다. 집에서 가깝진 않은데 그 주변에서 일이 많아서 기다릴 떄마다 그 카페에서 코딩을 했죠. 그런데 어느 날, 인터넷은 되는데 깃허브에 푸시를 할 수가 없더라고요. 그래서 몇가지 테스트를 해보니까, SSH 기본 포트인 22번 포트가 막혀있었습니다. 해결법은 간단했습니다만, 검색하기가 좀 어려운 문서 같아서 검색 인덱스 겸, 한국어 해석본 겸으로 쓰는 글입니다. 해결법은 공식 깃허브 문서에 적혀있었습니다. 쉽게 얘기하면 22번 포트가 막혀있으니, 443번 포트를 쓰라는 소리입니다. 443번 포트는 HTTPS 포트인지라, 방화벽이 막을 확률이 매우 낮습니다.

참고: git 훅에 대한 공식 문서가 존재합니다. 소스코드 관리 도구인 git은 여러가지 훅을 지원합니다. 훅을 설정하면 커밋, 푸시 등의 이벤트가 발생했을 때 특정 스크립트를 실행할 수 있습니다. 클라이언트 훅도 존재하고 서버 훅도 존재하지만, GitHub 같은 호스팅 서비스들이 대부분 서버 사이드 훅을 지원하지 않기 때문에 클라이언트 사이드 훅이 주로 쓰입니다. 주의해야할 점은 보안을 위해 레포지토리를 클론해도 git 훅이 자동으로 설정되지 않는다는 점입니다. 그래서 훅을 설치하는 스크립트를 만들어서 그걸 실행해거나, husky 같은 git 훅 관리 도구를 사용해 훅을 설정해야 합니다.

문제 상황 협업을 하다보면 포매팅이나 린팅 관련해서 문제가 생기는 경우가 많습니다. 누구는 에디터의 자동 수정 기능을 켜고 누구는 켜지 않는 경우도 있고, 사용하는 에디터가 달라서 자동 포매팅을 해도 스타일이 맞춰지지 않는 경우도 있습니다. 이러한 문제를 해결하는 좋은 방법이 있습니다. 커밋할 때 CLI 툴을 이용해 포매터와 린터를 적용하는 게 그것이죠. 이렇게 하면 여러가지 장점이 있는데요, 2가지만 꼽고 넘어가겠습니다. 커밋할 떄 일어나므로 자동 수정이 개발을 방해하지 않습니다. CLI 툴을 사용하므로 에디터 룰 떄문에 포매팅이 달라지는 문제가 발생하지 않습니다.