A. 배경
이 글은 git을 사용해 본적 없이 첫 프로젝트를 진행하시는 분을 위해 준비했습니다. 저 역시 처음에는 협업을 하면 코드를 어떻게 하는거지 이게 그냥 된다고? 라는 신기함과 내가 잘못해서 코드를 날리면 어쩌지라는 두려움으로 시작했던 것 같습니다. 그래서 저와 같은 사람들을 위해 이론부터 실습까지 소개하는 글을 쓰려고 합니다.
B. Git
1. Git 이란?
처음엔 "그냥 파일 저장하는 거 아닌가?" 싶었지만, Git은 단순한 저장이 아니라 코드의 모든 변경 이력을 남기고, 여러 명이 동시에 작업해도 충돌을 최소화해주는 협업 도구다.
내가 작업한 내용이 언제, 왜, 어떻게 바뀌었는지 추적할 수 있고, 실수했을 때 이전 상태로 쉽게 되돌릴 수 있다.
특히, 팀 프로젝트에서 누가 어떤 기능을 만들고 있는지 한눈에 파악할 수 있어서, "내가 뭘 해야 하지?"라는 불안감이 줄어들었다.
(자연스레 기여도를 추적 할 수도 있달까...? 하지만 Git에 있는 기여도가 전부라고는 생각하지 않습니다.)
2. clone
clone의 영어를 해석해면 똑같은 걸 여러개 만드는 거다.
처음에는 "이게 뭘 복사해온다는 거지?" 싶었는데, 실제로 해보니 원격 저장소(GitHub 등)에 올라가 있는 프로젝트 전체를 내 컴퓨터로 통째로 복제해오는 작업이었다.
인터넷 상에 있는거를 내 로컬(컴퓨터)로 똑같은걸 옮겨오는 작업이라는 게 핵심이다.
사용 방법
1. 터미널에서 내가 원하는 컵퓨터의 파일로 이동한다.
2. git clone <사진의 github 주소> 복사해서 붙여 넣으면 된다.
3. .git 디렉토리가 자동으로 생성되어, 바로 Git 명령어를 사용할 수 있었다..git이라는 것은
여러분이 Git을 사용해서 파일을 추적하거나, 이전 상태로 되돌리거나, 여러 명이 함께 작업할 때 ‘무슨 일이 있었는지’ 기록해두는 역할을 합니다.
2년전 Git과제에서 clone이 뭔지 몰라서 과제에서 힘들었던 경험이 있네요...
3. add
add는 "이 파일을 다음 커밋에 포함시켜줘!"라고 Git에게 알려주는 단계였다.
실제로는 git add .로 전체 파일을 올리기도 하고, git add 파일명으로 특정 파일만 올릴 수도 있다.
처음엔 add와 commit을 헷갈리기 쉽지만, add는 "준비", commit은 "저장"이라고 생각하면 이해가 쉬웠다.
꿀팁: 실수로 필요 없는 파일까지 add했다면, git reset으로 스테이징을 해제할 수 있다.
4. commit
commit은 Git에서 변경된 파일을 “로컬 저장소”에 저장하는 작업입니다.
쉽게 말해, 내 컴퓨터 안에서 “이 시점의 변경사항을 기록해!” 라고 명령하는 것과 같습니다.
commit을 하면, 변경 내용과 함께 “커밋 메시지”를 남기게 되며, 이 메시지는 나중에 변경 이력을 추적할 때 큰 도움이 됩니다.
처음 커밋할 때는 "메시지는 아무거나 써도 되겠지?"라고 생각했다가, 나중에 변경 이력을 볼 때 후회했다.
git commit -m "메시지"로 커밋할 때, 어떤 변경을 했는지 명확하게 적는 습관이 정말 중요하다.
예를 들어, "회원가입 기능 추가", "버그 수정: 로그인 오류"처럼 구체적으로 작성하면, 나중에 팀원들과 소통할 때도 편하다.
커밋 메시지는 나중의 나에게 보내는 메모라고 생각하면, 더 신경 쓰게 된다.
커밋은 github에 올리는게 아니라 나의 로컬에 버전을 업데이트 하는 것!!이라고 생각을 하면 좋을 것 같스습니다.
5. push
push라는 것은 로컬 저장소에 업데이트 된 커밋들을 원격 저장소에 올리는 명령어입니다[1][2][4].
내가 처음 push를 할 때, "왜 내 코드가 깃허브에 안 올라가지?"라며 당황했던 기억이 난다.
git push origin 브랜치명으로 로컬에서 작업한 내용을 원격 저장소(깃허브 등)에 올릴 수 있다.
origin은 그냥 "내 깃허브 주소"라고 생각하면 쉽습니다.
그래서 push를 할 때는
git push origin 이렇게 해야 하고,
이게 "브랜치명이라는 원격 저장소에 올려줘"라는 뜻이라고 생각하시면 좋을 것 같습니다.
꿀팁: push 전에 항상 git pull로 다른 사람의 변경사항을 먼저 받아오면, 충돌을 줄일 수 있다.
처음엔 push가 무서웠지만, 익숙해지면 협업의 핵심이 된다.
6. fetch
git fetch는 원격 저장소(GitHub 등)에 있는 최신 변경사항을 내 컴퓨터(로컬 저장소)로 가져오는 명령어입니다.
이 과정에서 내 작업 디렉토리(내가 실제로 보고 있는 파일들)는 바뀌지 않고, 가져온 변경사항이 바로 적용되지 않습니다.
즉, 원격 저장소의 이력만 업데이트하고, 실제 내 코드에는 아무 변화가 없습니다.
fetch는 “원격 저장소에 새로운 내용이 있나?”를 확인하고, 그 내용을 내 로컬 저장소에 ‘다운로드’만 해둡니다.
내 작업 폴더에는 아무 영향이 없으니, 안전하게 최신 상태를 확인할 수 있습니다.
이후에 git merge나 git rebase 등으로 원격 변경사항을 내 작업에 반영할 수 있습니다.
pull과의 차이점
- git pull은 내부적으로 git fetch + git merge를 한 번에 실행합니다.
즉, 원격 변경사항을 가져오고 바로 내 작업에 합쳐버립니다. - git fetch는 가져오기만 하고, 합치지는 않는다는 점이 다릅니다.
"가져오기만 하고, 합치지는 않는다"는 점이 pull과 fetch의 가장 큰 차이입니다.
처음 fetch를 썼을 때, "pull이랑 뭐가 다르지?"라는 의문이 들었다.
git fetch는 원격 저장소의 변경사항을 내 로컬 저장소에 가져오지만, 바로 내 작업에 반영되지는 않는다.
즉, "가져오기만 하고, 합치지는 않는다"는 점이 다르다.
7. merge
git merge는 서로 다른 브랜치(작업 흐름)를 하나로 합치는 명령어입니다.
쉽게 말해, “각자 작업한 내용을 한데 모아, 하나의 결과물로 만드는 과정”입니다.
여러 명이 동시에 작업해도, 각자 브랜치에서 개발한 뒤 마지막에 merge로 합치면 협업이 가능합니다.
하지만 같은 파일의 같은 부분을 여러 명이 수정했다면, 충돌(conflict)이 발생할 수 있습니다.
처음 merge를 할 때는 충돌(conflict)이 무서울 수 있지만, 충돌 메시지를 보고 직접 수정하고 add, commit을 다시 하면 해결됩니다.
충돌이 날 때마다 "내가 뭘 잘못했나?" 생각하지 말고, 차분히 변경 내용을 비교해보면 금방 익숙해진다.
pull하면 오류가 뜨는데 fetch + merge를 하면 잘 되는 이유
-
git pull은 내부적으로 git fetch + git merge를 한 번에 실행합니다.
즉, 원격 변경사항을 가져오고 곧바로 내 작업과 합칩니다. 이 과정에서 충돌이 발생하면, 바로 충돌 해결 단계로 넘어가게 됩니다.
하지만 pull은 모든 과정을 한 번에 처리하기 때문에, 변경사항을 충분히 검토하지 못하고 충돌이 발생하는 경우가 많습니다. -
git fetch + git merge는,
먼저 fetch로 원격 저장소의 최신 커밋을 내 로컬 저장소로만 가져오고,
그 다음 merge를 통해 실제로 내 작업과 합치면서 충돌이 발생하면, 내가 직접 충돌난 파일을 확인하고 꼼꼼히 비교·수정할 수 있습니다.
충돌을 모두 해결한 뒤에만 병합이 완료됩니다.
C. Git으로 협업 하기.
1. Oranization
GitHub에서 여러 명이 함께 프로젝트를 관리할 때, 조직(Organization) 기능을 사용하면 팀 단위로 저장소를 만들고 권한을 체계적으로 관리할 수 있습니다.
개인 계정이 아니라, 회사·동아리·스터디 등 단체 차원의 공간을 만드는 것과 비슷합니다.
처음에는 그냥 개인 깃허브에 저장소를 만들고 초대해서 썼는데, 팀원들 파트별 저장소를 만들고, 프로젝트가 많아지니 관리가 너무 힘들었다.
Organization을 사용하게 되면, 저장소를 한 곳에 모아두고, 팀원별로 권한도 쉽게 설정할 수 있어서 협업이 훨씬 편해졌습니다.
- 팀 프로젝트를 장기적으로 하거나, 여러 저장소를 관리할 땐 꼭 Organization을 사용해보세요.
- 팀원 초대는 이메일이나 깃허브 아이디로 간단하게 할 수 있습니다.
- Organization 내에서는 저장소별로 권한을 다르게 줄 수 있어, 실수로 중요한 코드가 지워질 걱정이 줄어듭니다.
2. Issue
issue(이슈) 는 프로젝트에서 발생하는 문제, 버그, 개선사항, 질문 등을 기록하고 관리하는 기능입니다.
일종의 “할 일 목록” 또는 “토론 게시판” 역할을 합니다.
카카오톡이나 슬랙으로만 할 일을 공유하면, 금방 잊히거나 누락되는 경우가 많았습니다.
반면, GitHub Issue를 활용하면 프로젝트 기간 동안 GitHub를 자주 사용하게 되어, 누가 어떤 일을 맡았는지와 어떤 버그가 있는지 한눈에 파악할 수 있어 프로젝트를 훨씬 체계적으로 진행할 수 있었습니다.
진행 상황도 카톡으로 일일이 물어보지 않아도, GitHub에서 바로 "아, 이 부분을 진행하고 있구나" 하고 쉽게 확인할 수 있습니다.
구체적인 제목과 내용 작성
예시: 단순히 “로그인 오류 발생”이 아니라, “로그인 시 500 에러 발생, 재현 방법 첨부”처럼 문제 상황과 재현 방법까지 명확히 적으면, 다른 팀원도 빠르게 이해하고 대응할 수 있습니다.
라벨(Label) 활용
이슈에 버그, 기능, 질문 등 다양한 라벨을 붙여 분류하면 관리가 훨씬 쉬워집니다.
라벨별로 이슈를 필터링해서 필요한 항목만 한눈에 볼 수 있어, 우선순위나 담당 영역을 정할 때 유용합니다.
담당자 지정
각 이슈에 담당자를 지정하면, 누가 어떤 일을 맡았는지 명확해집니다.
책임 소재가 분명해져서, 진행 상황을 추적하거나 업무 분배를 할 때 혼란이 줄어듭니다.
브랜치와의 연동
이슈와 브랜치를 연결해두면, 실제 작업 브랜치가 어떤 이슈와 관련되어 있는지 쉽게 파악할 수 있습니다.
관련 브랜치에서 작업하다가 PR을 만들 때도 자동으로 이슈와 연결되어, 관리가 편리해집니다.
체크리스트 활용
이슈 본문에 Checklist(체크박스 목록)를 만들어두면, 세부 작업 항목별로 진행 상황을 표시할 수 있습니다.
각 항목이 완료될 때마다 체크하면, 팀원 모두가 실시간으로 진척도를 확인할 수 있어 협업이 한층 더 효율적입니다.
Issue를 잘 활용하면, 프로젝트의 모든 할 일과 문제, 개선사항을 체계적으로 관리할 수 있습니다.
구체적인 작성, 라벨과 담당자 지정, 브랜치 연동, 체크리스트 등 다양한 기능을 적극적으로 사용해보세요.
이렇게 하면 협업의 투명성과 효율성이 크게 높아집니다.
3. Pull Request
Pull Request(PR) 는 “내가 작업한 내용을 메인 저장소에 합쳐주세요!”라고 요청하는 기능입니다.
협업에서 각자 브랜치에서 작업한 뒤, 최종적으로 코드 리뷰와 승인을 거쳐 메인 브랜치에 반영할 때 사용합니다.
내가 push를 했다고 끝나는 것이 아니라, 보통 push는 브랜치에 올리는 개념이고, Issue와 연결된 브랜치에 할 일을 다 했을 때 메인브랜치에 나의 브랜치 내역을 합치는 과정을 말합니다.
Comment
Comment(댓글) 는 Pull Request(또는 Issue)에 달 수 있는 의견, 질문, 제안, 피드백입니다.
팀원들이 내 코드를 보고 자유롭게 의견을 남길 수 있습니다.
댓글은 단순히 글로 남길 수도 있고, 코드의 특정 줄에 직접 달 수도 있어서, 어떤 부분을 이야기하는지 명확하게 전달할 수 있습니다.
Approve
Approve(승인) 는 리뷰어(팀원)가 “이제 이 코드는 메인 브랜치에 합쳐도 괜찮다!”고 공식적으로 OK 사인을 주는 기능입니다.
Approve가 완료되어야만 메인 브랜치로 코드를 합칠 수 있도록(병합) 설정하는 경우가 많습니다.
즉, Approve는 “코드 검토가 끝났으니, 이제 합쳐도 안전하다”는 신호입니다.
4. Template
이슈, PR 등에서 반복적으로 작성하는 내용을 미리 양식(Template)으로 만들어두는 기능입니다.
덕분에 팀원 모두가 일관된 형식으로 내용을 작성할 수 있습니다.
사용법 :
- .github/ISSUE_TEMPLATE/ 폴더에 템플릿 파일을 만들어두면, 새 이슈/PR 작성 시 자동으로 양식이 적용됩니다.
제목, 내용, 체크리스트 등 자주 쓰는 항목을 미리 넣어두면, 실수도 줄고 협업 효율이 올라갑니다.
팀원들과 함께 템플릿을 개선해가며, 프로젝트에 맞는 양식을 만들어보세요.
리뷰 할때도 형식이 같아 휠씬 편리합니다.
C. 마무리
처음에는 git과 GitHub가 어렵고 막막하게 느껴질 수 있지만, 한 번 구조와 흐름을 익혀두면 협업이 훨씬 편해지고 내가 만든 코드가 ‘기록’으로 남는 재미도 느낄 수 있습니다.
처음엔 실수도 하고, 충돌도 겪으면서 조금씩 익숙해지는 과정이 필요합니다. 하지만 분명히, "이런 식으로 협업이 돌아가는구나!"라는 감각이 생기면 혼자 개발할 때보다 훨씬 더 성장할 수 있습니다.
저 역시 처음엔 두려움이 컸지만, 프로젝트를 거듭할수록 git과 GitHub의 진짜 힘을 느끼게 되었고, 지금은 오히려 없으면 불안할 정도로 든든한 도구가 됐습니다.
이 글이 여러분의 첫 git 협업에 조금이나마 도움이 되었기를 바랍니다. 함께 성장하는 협업, git과 함께 시작해보세요!
궁금한 점이 있거나, 더 알고 싶은 내용이 있다면 언제든 댓글이나 질문 남겨주세요.
다음 글은 실습편을 작성해보려고 합니다. 이번글과 이어지니 다음글도 읽어주세요..
