[TIL] 2024-12-31_Git 협업

1. 브랜치 활용하기

브랜치

• 브랜치(branch): 가지, 분기 == 복사본
• git branch 브랜치이름 : 브랜치 생성
• git branch : 브랜치 확인 명령어 (원래 터미널로 빠져나오려면 'q' 입력)

브랜치 이동 명령어

• git switch 브랜치이름
• git checkout 브랜치이름 : '체크아웃'이라는 명령어가 불명확하여 혼란

🍯 브랜치 한 번에 생성 & 이동

• git switch -c 브랜치이름
• git checkout -b 브랜치이름

💾 새로운 브랜치에서 수정한 코드 저장

• git add .
• git commit -m "메세지"

👀 login 브랜치에서 main 브랜치로 이동하면 수정한 코드가 보이지 않는다.

• login → main 으로 합치기

  1. git switch 최종 브랜치이름(main)
  2. git merge 합칠 브랜치이름(login)

• main 에 합치는 이유 : main 브랜치 = 최종 브랜치
  각자 브랜치에서 개발한 기능을 최종적으로 main 브랜치에 합친다. (협업)
  

사실 git merge 는 현업에서 잘 사용하지 않는다. → 터미널 말고 github(온라인 저장소)에서 합친다.

2. Pull Request(PR) 활용하기

• Github에서 합치는 이유?
  코드 비교 가능 (코드 리뷰) : 다른 사람이 작성한 코드를 확인할 수 있다.

Pull: 당겨서 합치는 것(merge) + Request: 요청하다

🔙 다시 login 브랜치에서 수정, 저장한 상태에서 main에 합치기 전 상태

• git push origin 브랜치명
• github에서 [Compare & Pull Request]
  좌측 상단 base: main ← compare:login : Files changed 변경사항 확인
• [Merge pull request] > [Comfirm merge] : 합치기 확인

✨ github에 권한 설정으로 Contributors에게 pull request 에 merge 권한을 줄 수 있다.

• git pull origin main : Github 코드 반영

정리

1. 브랜치 생성 및 이동
2. 기능 개발 및 코드 저장
3. 코드 업로드 및 Pull Request 생성
4. github에서 merge
5. 내 로컬에도 반영 ex) git pull origin main

---

Main 브랜치 머지의 문제점

Main 브랜치 === 배포용
Main은 보통 실제 고객이 이용하는 서비스

🚨 문제점 1) 완벽하게 기능 개발해야 merge 가능

• main ← merge ← (회원가입, 로그인, 로그아웃)
• 작은 기능을 개발하여 합치고 테스트하며 디버깅

✅ 해결책 1) 개발용 브랜치

🚨 문제점 2) 그냥 합치면 위험함

각자 다른 브랜치에서 개발하는데 같은 변수명(String name)을 사용
→ 혼자 개발할 때는 에러가 없었지만 합치고 나니 컴파일 오류 발생

✅ 해결책 2) 로컬에서 먼저 테스트

---

3. 협업 실전 가이드

1️⃣. 초기 세팅

1. 팀장: 초기코드 작성 및 github 업로드

a. 폴더 생성
b. 초기 코드 작성
c. git init, add, commit
d. github 레포지토리 생성
e. github 업로드 (git push)

2. 팀장: dev(혹은 develop) 브랜치 생성

a. git swtich -c dev (로컬에서 dev 브랜치 생성)
b. git push origin dev (github에도 반영)

3. Github 에서 dev 브랜치를 default로 설정

• Settings > General > Default branch
  → dev [Update]: main으로 머지하는 실수를 줄일 수 있다

4. 팀원들을 Collaborator로 등록

5. 팀원 : git clone 하기

• 작업 폴더 위치에서 터미널 열기
• git clone 주소 .

2️⃣. 기능 개발 시작

1. 기능 브랜치 생성 및 기능 개발

• git switch -c feature/signup

2. Pull Request 생성

코드 저장 및 업로드

• git add.
• git commit -m ""
• git push origin 브랜치명

3. 코드 작성자: 리뷰 요청하기

• [Reviewers] : Collaborator 선택하여 요청 → 🔔 팀원에게 별도로 요청 알려주기
• [Start your review]
  • Comment : 리뷰 작성 → 영역마다 지정하여 리뷰 작성 가능
  • Approve : 승인
  • Request changes : 변경 요청
• [Finish your review]

4. 코드 리뷰어: 리뷰하기

PR 권한 : Confirm merge

5. 합치기 전 내 로컬 브랜치에서 충돌 확인

• 기능 브랜치에서 git pull origin dev 하여 테스트 진행
  충돌이 나면 github에서 해결하지 말고 충돌난 브랜치를 한번 pull 받아와서 수정 후 다시 push 하기
  

3️⃣. 추가 기능 개발

1. 내 로컬에 dev 에도 변경 사항 반영

a. dev 브랜치로 이동 (git checkout dev 혹은 git switch dev)
b. git pull origin dev

2. 다음 기능 개발

a. 기능 브랜치 생성 및 코드 작성
b. git add, commit, push
c. Pull request 생성 및 코드 리뷰
d. 내 로컬에서 충돌 해결 및 테스트
e. 코드 업로드 및 merge

+) 추가

• .gitignore 환경 세팅
  https://www.toptal.com/developers/gitignore/
• git stash, git reset & revert 명령어
• 비밀번호 대신 git token 설정하는 법

---

📝 TO-DO

1. Java 문법 종합반 수강
2. 알고리즘 코드카타
3. 기술 아카이브 정리
4. 운동하기 🏃

💭 Diary

1주차가 끝나고 2주차 프로그래밍 기초 주차가 시작되었다. 개인 학습 위주로 진행될 예정이지만 집중 놓지 않고 열심히 공부해야겠다. 하루에 모든 강의를 모두 들으려니 자바 강의 초반 부분은 집중이 어렵다. 공부의 밀도를 높여야 하는데 정신 바짝 차리자 🥲

그리고 특강으로 git 기초 2차 특강에서 git을 현업에서 어떻게 활용하는지 다른 사람들과 협업할 때 버전 관리와 코드 리뷰를 어떤 식으로 진행하는지 알 수 있었다. 1주차에서 미니 프로젝트를 진행하기 전에 잘 알고 있었더라면 팀원들에게 Merge 권한을 주어 다 같이 실습해 볼 수 있었을 텐데 그 점이 조금 아쉬웠다. 다음번에는 Dev 브랜치를 따로 두고 팀플을 진행하면서 좀 더 현업에서 사용하는 것처럼 실습해 볼 수 있었으면 좋겠다.✨