GitHub - 협업 편

개발 프로젝트를 하게 되면 필수적으로 사용해야 하는게 깃허브이다. 나는 깃허브를 혼자서만 사용할때와 팀원들과 다같이 쓸 때 알아야할 규칙이 달라 처음에 애를 많이 썼던 기억이 나, 이렇게 정리를 하게 되었다.

📌 정리: 협업 흐름 요약

처음 사용하는 repository를 연결한 후 이 명령어 순서들만 알아도 크게 어려울 건 없다.

• repository 연결하기repository의 주소는 메인화면>code(초록색버튼)을 누르면 뜬다.

1. 작업할 폴더 생성
2. 툴에 그 폴더 열기
3. git clone <사용할 리포지토리의 주소>
4. cd <클론된 폴더명 입력>

• 연결이 된 걸 확인 후, 다음과 같은 명령어를 입력해 깃허브에 올린다.

1. git checkout -b feat/기능명 (브랜치 생성)
2. 기능 개발 → commit → push
3. GitHub에서 PR 생성
4. 코드 리뷰 후(생략 가능) merge
5. git pull origin main 받아 최신화
6. git branch로 자신의 브랜치 확인 후 개발 시작

Pull Request란?

내가 수정한 코드를 프로젝트의 메인 코드라인(보통 main 또는 master 브랜치)에 합쳐달라고 요청하는 과정을 말한다.

이 과정을 거치는 이유는 혹시라도 코드가 잘못 올라가면 서로 꼬이게 되면서 코드 충돌 등을 예방할 수 있기 때문이다.

단순히 코드를 옮기는 것이 아니라, 팀원들과 소통하고 검토받는 '관문'이라고 이해해야한다. 

 

PR은 보통 다음과 같은 단계로 진행된다.

1. 브랜치 생성 및 작업: 원본 코드에 영향을 주지 않도록 별도의 '브랜치'를 만들어 기능을 개발하거나 버그를 수정
2. Push: 내 컴퓨터에서 작업한 내용을 깃허브 서버(원격 저장소)로 올린다.
3. PR 생성: 깃허브 웹사이트에서 "내가 이 브랜치에서 이런 내용을 수정했으니, 확인하고 합쳐줘(Merge)!"라고 버튼을 누른다.
4. 코드 리뷰 (Code Review): 동료들이 코드를 보고 피드백을 남깁니다. "이 부분은 이렇게 고치면 좋겠어요" 같은 리뷰를 단다.
5. 머지 (Merge): 리뷰가 끝나고 문제가 없으면 메인 브랜치에 코드를 최종적으로 합친다.

📌 협업 규칙 예시

• PR 제목 컨벤션: feat: 기능명, fix: 버그명, refactor: 리팩토링
• Commit 메시지

커밋 메시지는 타입: 개발한 내용의 형식을 갖추어 작성

*주로 feat, fix를 많이 사용

타입 설명

feat	새로운 기능 추가
fix	버그 수정
refactor	코드 리팩토링
docs	문서 수정 (README 등)
style	코드 스타일 변경 (세미콜론 추가 등)
chore	빌드 및 패키지 설정 변경
test	테스트 코드 추가

ex) git commit -m "feat: 화면 전환 기능" / git commit -m "fix: API 응답 오류 수정"

• 매 작업 전 git pull origin main(main 브랜치 또는 develop 브랜치 따로 만들어서 작업 추천)
• PR 전 rebase 또는 merge로 충돌 확인

📌 Git 충돌(Conflict) 해결 프로세스

1단계: 상황 파악하기

• 발생 시점: 내가 수정한 파일과 깃허브(또는 다른 브랜치)의 수정 사항이 같은 줄을 건드렸을 때 발생.
• 신호: 터미널에 CONFLICT (content): Merge conflict in [파일명] 문구가 뜸.

2단계: 코드 정리

VS Code 같은 에디터에서 충돌이 난 파일을 열면 아래와 같은 기호가 보임

• <<<<<<< HEAD: 현재 내 브랜치의 변경 사항 (로컬)
• =======: 이 선을 기준으로 위아래가 싸우는 중
• >>>>>>> [커밋 해시]: 깃허브에서 넘어온 변경 사항

✅ 해결법: 1. 위 기호들을 포함해서 불필요한 코드를 싹 지우기(옛날에 main 브랜치에 있었지만 수정하면서 지운 코드같은 경우) 2. 최종적으로 남길 코드만 남기기

1. 수정한 파일을 스테이징 
git add [파일명]  # 또는 git add .

2. 해결 완료 커밋 
git commit -m "fix: resolve merge conflict in [파일명]"

3. push해서 브랜치에 다시 올리기 (pull request에서도 merge가 활성화되어있는지 확인)

📌 Git 충돌(Conflict) vscode에서 수정하기

• git checkout main - main 브랜치로 이동
• git pull origin main - main 최신화 내려받기
• git checkout 내브랜치명 - 내 브랜치로 이동
• git merge main - 내 브랜치와 main 합치기
• 충돌된 파일 수정하기

그 후 다시 git add . ->commit->push 순서

자주 뜨는 문제

⚠️ Detached HEAD

• 증상: push 해도 Everything up-to-date라고 뜨면서 반영이 안 됨. ⇒ git branch를 했을때 다음과 같이 뜨면 브랜치 위에 있는게 아닌 특정 커밋 위에 있는 경우임

• 탈출법: git checkout [브랜치명]으로 먼저 돌아온 뒤, 작업했던 커밋을 git merge [커밋번호]로 합치기.

⚠️ 리베이스(Rebase) 중일 때

리베이스 도중 충돌이 나면 이도저도 아닌 상태

충돌난 파일들 수정 후, 커밋 대신

• git rebase --continue

이 명령어 사용하기

너무 꼬여서 뒤로 돌아가야하는 상황 (합치기 전으로 돌아가고 싶을 때)

• git rebase --abort

사용하여 리베이스 시작 전으로 돌아가기

⚠️ 충돌 수정 전으로 돌아가고 싶을 때

• git merge --abort 머지 취소
• git reset --hard HEAD 내 브랜치 상태 초기화( 작업한 내용이 날려도 되는 경우만!! )
• git checkout main
• git pull origin main main 브랜치 최신 정보 가져오기
• git checkout 내브랜치명
• git reset --hard main 내 브랜치로 돌아가서 main 최신 내용 덮어쓰기 : main이랑 똑같은 상태되기(작업한 내용이 없을 경우!!)