GIT도문

About this offer

모든 커밋과 브랜치와 머지의 앞에서 Git을 사용하는 모든 개발자는 기억할지어다. 네가 남긴 모든 변경은 기록될 것이며, 네가 확인하지 않은 모든 변경은 언젠가 너를 찾아올 것이다. Git은 단순히 코드를 올리는 도구가 아니다. 개발자가 지금까지 무엇을 했고, 무엇을 바꿨으며, 어디서부터 문제가 시작되었는지를 기록하는 개발의 역사 그 자체다. 그렇기에 우리는 Git을 존중해야 한다. 항상 커밋하기 전에는 반드시 변경 사항을 확인해야 하며 git status 와 git diff 를 생활화해야 한다. 내가 뭘 바꿨는지도 모르면서 git add . 부터 박아버리는 것은 Git을 사용하는 것이 아니라 Git에게 코드를 바치는 행위다. 커밋 메시지 역시 아무 생각 없이 update , fix , asdf , 진짜마지막 , final , final2 , final_final 따위로 작성해서는 안 된다. 커밋 하나하나에는 내가 무엇을 했는지 미래의 내가 알아볼 수 있는 의미가 있어야 한다. 작업을 시작하기 전에는 원격 저장소의 상태부터 확인해야 한다. 다른 사람이 이미 코드를 올렸을 수도 있는데 아무 생각 없이 작업부터 시작하고 나중에 push 를 박다가 rejected를 맞고서야 pull 을 하는 것은 Git을 존중하지 않는 자의 전형적인 행동이다. pull 을 했는데 충돌이 발생했다고 당황해서 아무 파일이나 지워버리는 것도 안 된다. Conflict가 발생했다면 먼저 양쪽 변경 내용을 읽고 무엇을 남기고 무엇을 버릴지 판단해야 한다. <<<<<<< HEAD 가 보인다고 무작정 위아래를 지우는 순간, 수 시간 동안 작성한 코드가 조용히 사라질 수 있다. 특히 git pull 은 마법의 명령어가 아니다. 원격 변경 사항을 가져오고 현재 브랜치와 합치는 과정에서 무슨 일이 일어나는지 이해해야 한다. Pull을 했다고 안심하고 바로 작업하는 것이 아니라 현재 브랜치가 어디인지, 원격이 어디를 가리키는지, 내가 지금 어떤 상태인지 확인해야 한다. git branch , git remote -v , git status 정도는 눈 감고도 확인할 수 있어야 한다. 브랜치도 마찬가지다. main 에서 작업하다가 실수로 중요한 파일을 망가뜨리고 나서야 "아 브랜치를 따야 했구나"라고 깨닫는 것은 너무 늦었다. 기능 하나를 개발한다면 기능 브랜치를 만들고, 작업을 끝낸 뒤 검증하고, 커밋하고, 필요한 경우 Pull Request를 통해 병합하는 것이 기본이다. 브랜치 이름을 헷갈려서 다른 브랜치에 커밋하거나, 엉뚱한 브랜치에 push 해버리는 일도 충분히 일어날 수 있으니 항상 내가 어느 브랜치에 서 있는지 확인해야 한다. Remote도 절대 만만하게 보면 안 된다. origin 하나만 있는 줄 알고 살다가 sparta 같은 두 번째 remote를 추가해놓고 어느 저장소로 push해야 하는지 헷갈릴 수도 있다. git remote -v 한 번이면 확인할 수 있는 것을 기억하지 않고 엉뚱한 저장소에 코드를 올리는 것은 Git의 문제가 아니라 사용자의 문제다. 그리고 Git은 사용자의 신원까지 기억한다. 커밋하려는데 갑자기 Author identity unknown 이 뜨고 user.name 과 user.email 을 설정하라고 하는 순간이 온다. 이때 아무 이메일이나 집어넣는 것이 아니라 내가 어떤 계정으로 커밋하고 있는지 확인해야 한다. GitHub 계정과 커밋 이메일의 관계까지 이해해야 나중에 contribution이 제대로 연결되는지도 알 수 있다. 무엇보다 가장 중요한 것은 push 다. git add . 했다고 끝난 것이 아니고, commit 했다고 끝난 것도 아니며, push 했다고 성공한 것도 아니다. 실제로 원격 저장소에 반영되었는지 확인해야 한다. Push가 성공했다는 메시지를 보고도 GitHub에서 확인하지 않고 넘어가면 나중에 "분명 올렸는데 왜 없지?"라는 사태가 발생한다. 그리고 절대로 git add . && git commit -m "update" && git push 를 아무 생각 없이 습관처럼 실행해서는 안 된다. 물론 편리한 명령어를 만들어 사용하는 것은 좋다. 하지만 자동화는 내가 Git의 상태를 이해하고 있다는 전제에서 편리한 것이지, 상태 확인을 대신해주는 것이 아니다. 무슨 파일이 추가되었는지 모르는 상태에서 자동화된 fuck git 을 갈기는 순간, 이름만 웃길 뿐 사고 방식은 전혀 웃기지 않게 된다. git reset , git restore , git revert , git rebase , git commit --amend , git push --force 같은 명령어도 마찬가지다. 각각 무엇을 되돌리고 무엇을 변경하는지 모른 채 인터넷에서 본 명령어를 복붙해서 실행해서는 안 된다. 특히 push --force 는 원격 저장소의 다른 사람 작업까지 날릴 수 있는 강력한 명령어이므로 "안 되면 force push"라는 생각은 버려야 한다. 그리고 .gitignore 도 존중해야 한다. .env , API Key, 비밀번호, 인증서, 개인 설정 파일, 빌드 결과물 따위를 아무 생각 없이 git add . 로 올려버리는 순간 Git은 개발자의 실수를 영구히 기록하는 증인이 된다. 이미 원격 저장소에 올라간 비밀 정보는 단순히 파일을 삭제하고 다시 커밋한다고 사라지는 것도 아니다. 필요하다면 키를 폐기하고 기록에서 제거하는 별도의 조치까지 해야 한다. Commit은 보험이지만 백업과 동일하지도 않다. "커밋했으니까 괜찮겠지"라고 생각해서는 안 된다. Git은 버전을 관리하는 도구이지 모든 사고를 자동으로 복구해주는 신이 아니다. 결국 Git을 잘 사용한다는 것은 명령어를 많이 안다는 뜻이 아니다. 내가 지금 어느 브랜치에 있는지 알고, 어디에서 코드를 가져왔는지 알고, 무엇을 변경했는지 확인하고, 왜 변경했는지를 커밋에 남기고, 원격 저장소의 상태를 확인하고, 충돌이 났다면 무슨 충돌인지 읽어보고, push한 뒤 실제 반영까지 확인하는 것. 이 모든 기본을 지키는 것이 Git을 존중하는 것이다. 그러므로 나는 말한다. Git은 죄가 없다. pull 도 죄가 없고, push 도 죄가 없으며, merge conflict 도 죄가 없다. 문제는 git status 한 번 확인하지 않고 작업한 개발자에게 있으며, git diff 도 보지 않고 git add . 를 갈긴 개발자에게 있으며, 충돌 내용을 읽지도 않고 전부 지워버린 개발자에게 있으며, 어느 브랜치인지 확인하지 않고 push한 개발자에게 있으며, 무엇을 커밋했는지도 모르면서 "update" 라고 적은 개발자에게 있다. 그러니 개발자들이여. 넌 GIT을 존중해야 한다. 항상 확인하고, 항상 이해하고, 항상 기록하고, 그리고 무엇보다 커밋하기 전에 네가 무슨 짓을 했는지 먼저 확인해라. Git은 네 실수를 기억한다.