Git·GitHub 처음 쓰는 법: 커밋, 브랜치, 풀 리퀘스트 개념과 기본 명령어

꼭 알아야 할 개념

• 저장소(repository): Git이 이력을 관리하는 프로젝트 폴더입니다. 내 컴퓨터에 있는 것을 로컬 저장소, GitHub에 있는 것을 원격 저장소라고 부릅니다.
• 커밋(commit): 변경 내용을 하나의 기록으로 저장한 것입니다. 게임의 세이브 포인트처럼, 언제든 그 시점으로 돌아가 볼 수 있습니다.
• 스테이징: 커밋하기 전에 "이번 기록에 넣을 변경"을 골라 담는 단계입니다. 여러 파일을 고쳤어도 관련 있는 것만 묶어 커밋할 수 있습니다.
• 브랜치(branch): 원래 코드에 영향을 주지 않고 따로 작업하는 갈래입니다. 새 기능은 브랜치에서 만들고, 완성되면 메인 브랜치에 합칩니다.
• 병합(merge): 브랜치의 작업을 다른 브랜치에 합치는 것입니다. 같은 줄을 서로 다르게 고쳤다면 충돌이 나고, 어느 쪽을 남길지 직접 정해야 합니다.
• 풀 리퀘스트(pull request): GitHub에서 "내 브랜치의 변경을 합쳐 달라"고 요청하는 기능입니다. 팀원이 변경 내용을 보고 의견을 남기는 코드 리뷰가 여기서 이뤄집니다.

처음 한 번 하는 설정

자주 쓰는 명령과 하는 일

1. git init은 지금 폴더를 새 저장소로 만들고, git clone은 GitHub에 있는 저장소를 내 컴퓨터로 복사해 옵니다.
2. git status는 어떤 파일이 바뀌었고 무엇이 스테이징되었는지 보여 줍니다. 헷갈릴 때마다 먼저 쳐 보는 명령입니다.
3. git add는 변경한 파일을 스테이징에 담고, git commit은 담긴 변경을 메시지와 함께 기록합니다.
4. git push는 내 커밋을 원격 저장소로 올리고, git pull은 원격 저장소의 새 변경을 내려받아 합칩니다.
5. git branch는 브랜치 목록을 보거나 새로 만들고, git switch는 다른 브랜치로 옮겨 갑니다.
6. git log는 지금까지의 커밋 기록을 보여 주고, git diff는 아직 커밋하지 않은 변경 내용을 줄 단위로 보여 줍니다.

기본 작업 흐름

1. 작업을 시작하기 전에 메인 브랜치를 최신 상태로 받습니다.
2. 기능 이름으로 새 브랜치를 만들어 옮겨 갑니다.
3. 코드를 고치고, 의미 있는 단위마다 스테이징과 커밋을 합니다.
4. 브랜치를 GitHub에 올리고 풀 리퀘스트를 엽니다.
5. 리뷰 의견을 반영해 추가 커밋을 하고, 승인되면 병합합니다.

좋은 커밋 메시지 습관

• 한 커밋에는 한 가지 변경만 담습니다. 기능 추가와 오타 수정을 섞지 마세요.
• 첫 줄은 짧게, 무엇을 했는지 요약합니다. 필요하면 한 줄 띄우고 왜 바꿨는지 설명을 덧붙입니다.
• "수정", "업데이트"처럼 아무 정보가 없는 메시지는 피합니다. 나중에 기록을 찾을 때 나 자신이 가장 곤란해집니다.
• 팀에 정해진 규칙이 있다면 그것을 따릅니다. 앞에 기능 추가, 버그 수정 같은 종류를 붙이는 방식을 쓰는 팀이 많습니다.

처음에 자주 하는 실수

• 비밀번호나 API 키가 든 파일을 커밋하는 것. .gitignore 파일에 제외할 파일을 미리 적어 두세요. 이미 올라갔다면 해당 키를 바로 폐기하고 새로 발급받는 것이 안전합니다.
• 메인 브랜치에서 바로 작업하다 꼬이는 것
• 충돌이 났을 때 당황해서 폴더를 지우고 다시 받는 것. 충돌 표시를 찾아 남길 내용을 고른 뒤 다시 커밋하면 됩니다.

실수를 되돌리고 싶을 때

• 아직 커밋하지 않은 변경을 버리고 싶다면 git restore로 파일을 마지막 커밋 상태로 돌릴 수 있습니다.
• 이미 올린 커밋을 취소하고 싶다면 git revert가 안전합니다. 기록을 지우지 않고, 그 커밋을 거꾸로 적용한 새 커밋을 만듭니다.
• 기록 자체를 지우는 방법도 있지만, 다른 사람과 함께 쓰는 브랜치에서는 팀원의 기록과 어긋날 수 있으니 피하는 것이 좋습니다.