Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
Tags
- OPENPATH
- 백엔드 부트캠프
- 국비지원취업
- 패스트캠퍼스
- 백엔드개발자
- 국비지원교육
- API
- Java
- 오픈챌린지
- UXUI기초정복
- Spring
- 디자인챌린지
- 디자인교육
- 내일배움카드
- 환급챌린지
- 오블완
- JPA
- 국비지원
- 오픈패스
- 백준
- Be
- UXUIPrimary
- UXUI챌린지
- 디자인강의
- baekjoon
- mysql
- 시스템설계
- 티스토리챌린지
- KDT
- 부트캠프
Archives
- Today
- Total
군만두의 IT 개발 일지
패스트캠퍼스 백엔드 개발 부트캠프 8기 그룹 스터디 - Git 브랜치 전략과 협업 플로우 실습 본문
목차
⭐ 요약
- 멘토링에서 추천받은 도서관 관리 시스템 개발을 시작하면서, 팀 협업을 위한 Git 사용 방식을 정리한다.
- GitHub 조직 레포지토리 생성, 커밋 컨벤션 적용, PR 템플릿 세팅 등 협업 환경을 구성한다.
- 브랜치 전략과 merge 방법, 충돌 해결 방법을 직접 실습하면서 팀원들이 Git에 적응하는 시간을 가진다.
⭐ 개발 시작 전 협업 규칙 정리
본격적인 개발에 들어가기 전, 팀원들과 함께 협업 방식을 먼저 정했다. 코드보다 협업 규칙이 먼저라는 생각으로 아래 사항들을 합의했다.
- 개발 일정: 우선 월요일 저녁까지 완료를 목표로 하고, 진행이 어려우면 수-목까지 연장한다.
- Git 전략: 현재는 별도의 브랜치 전략(git flow 등)을 사용하지 않고, 개인 브랜치에서 작업 후 PR을 올리는 방식으로 진행한다.
- 커밋 컨벤션: 커밋 메시지 규칙 가이드를 따른다.
- PR 템플릿: 팀장 님이 GitHub PR 템플릿 세팅을 진행했다. ([Git] GitHub pull request template 만들기 참고)
- 레포지토리: GitHub 조직 계정에 도서관 레포지토리를 생성한다.
⭐ 역할 분담
| 담당 도메인 | 담당자 |
| Book (도서 관리) | 팀원A |
| User (회원 관리) | 나 |
| Loan (대출 관리) | 팀장 |
| Reservation (예약 관리) | 팀원B |
⭐ Git 사용법 정리
1. 기본 push 흐름
개인 브랜치(user.branch)에서 작업하면서 아래 순서로 push를 진행했다.
git pull origin main # 원격 main 브랜치의 최신 내용을 먼저 받아온다.
git add .
git commit -m "message"
git push origin user.branch
2. 권장 push 흐름: main을 먼저 최신화한 뒤 merge
위 방식보다 충돌을 사전에 줄이고 더 안전하게 push하는 방법은 아래와 같다. main 브랜치로 먼저 이동해서 최신 내용을 받아온 뒤, 내 브랜치로 돌아와서 main을 merge하고 push하는 것이다.
git checkout main # main 브랜치로 이동한다.
git pull # 원격 main의 최신 내용을 받아온다.
git checkout user.branch # 내 브랜치로 돌아온다.
git add .
git commit -m "message"
git merge main # main 브랜치의 내용을 내 브랜치에 병합한다.
git push origin user.branch
3. PR merge 방법: 팀원A 님이 공유한 내용
팀원A 님이 PR을 merge하는 올바른 방법을 채팅으로 공유해주셨다. 항상 main을 먼저 최신 상태로 만든 뒤 내 브랜치와 merge하는 것이다.
# 1. main 브랜치에서 원격 저장소의 최신 내용을 로컬에 반영한다.
git checkout main
git pull origin main
# 2. 내 브랜치로 이동 후 main을 merge한다.
git checkout user.branch
git merge main
# 3. 충돌이 발생하면 '<<<<' 표시가 있는 부분을 직접 수정한다.
# 수정 완료 후 커밋하고 PR을 올린다.
git add .
git commit -m "message"
git push origin user.branch
4. 최후의 수단: 강제 리셋
충돌이 너무 심하거나 브랜치 상태가 꼬였을 때는 특정 커밋 시점으로 강제 되돌리는 방법을 사용한다. 단, --hard 옵션은 작업 내용이 모두 사라지므로 신중하게 사용해야 한다.
# 특정 커밋 시점으로 강제 리셋한다. (이후 작업 내용은 모두 삭제된다.)
git reset --hard [커밋 해시]
# 이후 원격 main의 최신 내용을 다시 받아온다.
git pull origin main
⭐ 트러블슈팅
문제: 팀원B 님의 git push 오류
23시경 팀원B 님이 git push 하는 과정에서 오류가 발생했다. 팀원A 님이 원인을 파악하고 해결해주셨다.
| 항목 | 내용 |
| 원인 | .idea 폴더가 .gitignore에 등록되지 않아 발생한 충돌 문제 |
| 해결 | .gitignore 파일에 .idea를 추가하여 push |
.gitignore에 아래 항목들을 추가하면 IntelliJ IDEA의 설정 파일이 원격 저장소에 올라가지 않는다.
### IntelliJ IDEA ###
.idea
*.iml
out/
⭐ 어려웠던 점
- 처음 팀 협업으로 Git을 사용하다 보니 브랜치 간 충돌이 발생하는 경우가 잦았다.
<<<<충돌 표시를 직접 수정해본 경험이 없는 팀원도 있어서, 이 부분을 팀 전체가 함께 익히는 시간이 필요했다. - IntelliJ의
.idea폴더가.gitignore에 등록되지 않으면 팀원마다 다른 IDE 설정이 충돌을 일으킬 수 있다. 프로젝트 시작 시.gitignore를 먼저 세팅하는 것이 중요하다는 점을 배웠다. - PR 템플릿, 커밋 컨벤션 등을 팀 전원이 동일하게 적용하려면 초반에 규칙을 맞춰야 한다.
⭐ 후기
- 협업에서는 브랜치 관리와 merge 전략이 코드만큼이나 중요하다는 것을 직접 느꼈다.
- 오류가 생겼을 때 팀원이 바로 도움을 주는 환경이 든든했다. 협업의 장점은 문제를 혼자 끌어안지 않아도 된다는 점인 것 같다.
- 앞으로는
git merge전에 항상git pull로 main을 최신 상태로 만드는 습관을 지킬 예정이다.
이 글은 패스트캠퍼스의 백엔드 개발 캠프에서 공부한 내용을 작성한 것입니다.
'개발일지 > 패스트캠퍼스' 카테고리의 다른 글
| 패스트캠퍼스 백엔드 개발 부트캠프 8기 그룹스터디 - 도서관 시스템 설계 (Java, JDBC, MySQL) (0) | 2024.03.15 |
|---|---|
| [Java] GoF 디자인 패턴 정리 - 팩토리 메소드, 추상 팩토리, 빌더, 프로토타입, 싱글턴 (0) | 2024.03.14 |
| [후기] 패스트캠퍼스 백엔드 개발 부트캠프 8기 네트워킹 데이 (0) | 2024.03.14 |
| 패스트캠퍼스 백엔드 개발 부트캠프 8기 그룹스터디 - 교착 상태, DB 이상현상, 제네릭, HTTP & 암호화 (0) | 2024.03.10 |
| [후기] 패스트캠퍼스 백엔드 개발 부트캠프 8기 취업 준비 특강 (0) | 2024.03.05 |
Comments