들어가며
이번에 스터디를 하면서 협업시 하는 깃 사용에 대해서 익숙해지기 위해서
어떤 흐름으로 깃을 사용하는지 다같이 공부해봤으면 하는 마음으로 글을 작성합니다.
1. 👥 협업을 위한 필수 도구
Git은 단순한 "버전 관리 도구"가 아닙니다.
여러 명이 함께 작업할 때 코드를 안전하게 관리하고 충돌 없이 합치기 위한 핵심 도구입니다.
2. 🧾 기록과 추적의 이점
모든 커밋은 변경 이력의 기록입니다.
- 누가, 언제, 어떤 이유로 코드를 변경했는지 추적 가능
- 문제가 생기면 이전 상태로 되돌리기 쉬움 (revert, reset, reflog 등)
- 코드 리뷰 시도 중요 참고 자료가 됨
3. 🧪 브랜치를 통한 안전한 관리
- 기능별로 분리작업 후 병합 가능(예 : 로그인 기능, 게시글 기능 등)
- main 브랜치는 배포용, dev는 통합 개발용, feat/*는 각자의 작업 공간.
브랜치를 분리함으로써 내 작업이 팀 전체에 바로 영향을 주지 않도록 작업하려고 합니다.
4. 🔄 코드 리뷰와 협의의 문화
- GitHub의 Pull Request 기능은 단순한 코드 병합이 아니라, 의사소통의 장
- PR을 통해 리뷰하고, 피드백하고, 승인하면서 품질을 올리고 공동 책임을 가질 수 있음
0. 명령어 요약, 용어 설명
| 명령어 | 설명 |
| git clone [URL] | GitHub에서 저장소 복제 |
| git init | 로컬에 Git 저장소 초기화 |
| git remote add origin [URL] | 원격 저장소 연결 |
| git branch | 로컬 브랜치 목록 확인 |
| git branch -r | 원격 브랜치 목록 확인 |
| git checkout [브랜치명] | 해당 브랜치로 이동 |
| git checkout -b [브랜치명] | 새 브랜치 생성 + 이동 |
| git checkout -b dev origin/dev | 원격 dev 브랜치 기반으로 로컬 dev 생성 |
| git pull origin [브랜치 명] | 원격 dev에서 최신 이력 가져오기 |
| git add . | 변경된 모든 파일 스테이징 |
| git commit -m "메시지" | 커밋 생성 |
| git push -u origin [브랜치명] | 원격 브랜치로 푸시 (처음 push 시 -u 필수) |
| git push origin [브랜치명] | 일반적인 브랜치 푸시 |
| git status | 현재 상태 (변경, 커밋 여부 등) 확인 |
1. Clone : 원격 저장소를 자신의 컴퓨터로 복사하는 작업
2. Branch : 코드의 독립된 작업 공간, 기능별로 분리해서 개발 가능
3. Commit : 코드 변경사항을 저장소에 기록하는 작업
4. Push : 로컬에서 만든 commit을 원격 저장소로 업로드
5. Pull : 원격 저장소의 변경 사항을 가져와 로컬과 동기화
6. Merge : 브랜치의 작업 내용을 다른 브랜치에 통합
7. Issue : 버그, 기능 요청 등 작업 항목 등록 (To-Do)
8. PullRequest (PR) : 작업한 브랜치를 main or dev 등에 병합해 달라고 요청하는 과정
9. Review/ Approve : PR의 코드 검토 후 승인
10. Confilct : 같은 파일의 같은 줄을 여러 브랜치가 수정할 경우 충돌 발생
1. GitHub 저장소 생성(제가 했습니다)
- GitHub에서 새 저장소 생성 (예: introduce-team)
2. 로컬 Git 프로젝트 초기화 및 연결
3. 패키지 구조 정리(도메인형)
git add .
git commit -m "init: 프로젝트 초기 세팅"
git push -u origin dev2. 팀원들이 프로젝트를 가져오는 흐름
여기서부터 보시면 될 거 같습니다
🔽 1. GitHub 저장소 복제 (Clone)
git clone https://github.com/seseseseo/introduce-team.git아니면 인텔리제이 파일 > 새로 만들기 > 버전 관리에 있는 프로젝트로 생성
🌱 2. 원격 브랜치 목록 확인 (선택)
git branch : 현재 로컬 브랜치 확인
git branch -r : 원격 브랜치 확인
🔄 3. 로컬 dev 브랜치로 전환
git checkout -b origin/dev
❓ 저희는 이슈 기반으로 작업 브랜치를 생성할겁니다!, 이슈는 어떻게 만드냐?
https://www.notion.so/1e7a0d4faf4a8084b34bd4a39a711ecf
깃 컨벤션 | Notion
📌 GitMoji
www.notion.so
여기서 브랜치 전략 부분을 복붙하여서 `태그 : 제목`의 형태로 제목을 작성하신 후 내용을 작성하시면 됩니다
이런식으로요
이슈가 생성이 되면 다음과 같이 코드를 작성해서 브랜치를 생성하시면 됩니다.
🛠 4. 자신의 작업 브랜치 생성
git checkout -b feat/1-common-response
git checkout -b feat/2-login
git checkout -b feat/3-register
git checkout -b feat/signup
🔁 5. 이후 작업 흐름
- feat/1-common-response 브랜치에서 ApiResponseDto 작업
/**
* 모든 API 응답을 하나의 공통 포맷으로 정의한 DTO
* - 성공/실패 응답 모두 이 포맷을 따른다
* - statusCode, message, data 를 포함한다
*/
@JsonInclude(value = NON_NULL)
@Builder
public record ApiResponseDto<T>( // record: dto를 간결하게 작성하는 방식으로 생성자/getter/equals 를 자동으로 만들어줌, 불변객체임
int statusCode, // HTTP 상태 코드 숫자 (예: 400)
@NotNull String message, // 응답 메시지 (ex: "가게 생성 성공", "잘못된 요청입니다")
T data// 실제 응답 데이터 (nullable), null이면 JSON에서 제외됨
) {
/**
* 성공 응답을 생성하는 메소드 (데이터 O)
* 예를 들면 가게 생성을 성공했을 때, 데이터도 함께 내려주고 싶을 때 사용함
* @param successCode 성공 상태코드/메시지 Enum
* @param data 응답 데이터
* @return ApiResponseDto
*/
public static <T> ApiResponseDto<T> success(final SuccessCode successCode,
@Nullable final T data
) {
return new ApiResponseDto<>(
successCode.getHttpStatus().value(),
successCode.getMessage(),
data
);
}
/**
* 성공 응답을 생성하는 메소드 (데이터 X)
* 예를 들면 로그아웃에 성공했습니다 -> 따로 줄 데이터가 없음
* @param successCode 성공 상태코드/메시지 Enum
* @return ApiResponseDto
*/
public static <T> ApiResponseDto<T> success(final SuccessCode successCode) {
return success(successCode, null);
}
/**
* 실패 응답을 생성하는 메소드 (ErrorCode 기반)
*
* @param errorCode 에러 코드 Enum
* @return ApiResponseDto
*/
public static <T> ApiResponseDto<T> fail(final ErrorCode errorCode) {
return new ApiResponseDto<>(
errorCode.getHttpStatus().value(),
errorCode.getMessage(),
null
);
}
/**
* 실패 응답을 생성하는 메소드 (직접 커스텀 메시지를 줄 경우)
*
* @return ApiResponseDto
*/
public static <T> ApiResponseDto<T> fail(final ErrorCode errorCode, final String message) {
return new ApiResponseDto<>(
errorCode.getHttpStatus().value(),
message,
null
);
}
}git add . //로컬에서 작업 후 커밋
git commit -m "feat: 공통 응답 처리 기능 구현 (#1)"
git push -u origin feat/1-common-response //원격 저장소로 브랜치 푸시| 명령어 | 설명 |
| git push origin feat/1-common-response | 원격에 브랜치를 푸시하지만, 로컬 브랜치와 원격 브랜치 간 추적 관계를 만들지 않음. 이후 git pull 시 브랜치 명을 계속 지정해야 함. |
| git push -u origin feat/1-common-response | 푸시하면서 로컬 브랜치가 원격 브랜치를 추적하도록 설정. 이후에는 git pull, git push만으로 작업 가능. |
✅ 6. Pull Request
커밋하고 푸시를 했으니 깃허브로 가셔서 PR을 작성해 봅시다. 클릭하면 PR 작성 페이지로 이동
PR 컨벤션에 맞게 작성하시면 됩니다.
3. PR이 올라오면 팀원들이 해야 할 일
👀 1. PR 내용 확인
- PR 제목과 본문을 읽고 어떤 기능/이슈인지 이해하기
- Closes #1 등 이슈 연결도 함께 확인
🔍 2. 변경된 코드 리뷰
- GitHub에서 "Files changed" 탭 클릭
💬 3. 리뷰 코멘트 작성 (필요 시)
- 개선이 필요한 부분은 라인별 코멘트로 제안
- 단순 확인일 경우에도 "👍 확인했습니다" 정도는 남기면 좋아요
✅ 4. Approve or Request changes
- Approve: 머지해도 괜찮다면 승인 버튼 클릭
- Request changes: 수정이 필요하다면 사유 코멘트와 함께 요청
팀 보호 규칙에 따라 1명 이상의 approve가 있어야 머지 가능하게 설정되어 있습니다! 모두가 한 번씩은 approve 눌러본 후 merge 해보려고 합니다.
5. 머지 후 할 일
PR이 dev 브랜치에 머지되면:
✅ 각자 작업 브랜치에서 dev의 최신 내용을 반영하는 법
1. merge
git checkout feat/my-feature
git fetch origin
git merge origin/dev- ✔ 현재 내 브랜치로 이동한 뒤,
- git fetch origin → 원격 저장소의 변경 내용을 모두 로컬로 가져오기만 함
- git merge origin/dev → origin/dev의 변경 내용을 로컬 dev 브랜치에 수동 병합
- 협업에서 일반적으로 사용
2. pull
git checkout dev
git pull origin dev- ✔ 현재 dev 브랜치로 이동한 뒤,
- ✔ 원격 저장소(origin)의 dev 브랜치를 가져오고 병합까지 자동으로 수행합니다.
- 빠르게 dev 반영하고 싶을 때
| 구분 | git pull | git fetch + git merge origin/dev |
| 동작 | 원격 저장소에서 변경사항을 가져오고 자동으로 병합까지 함 `fetch` + 자동으로 `merge` 까지 수행 |
원격 저장소에서 변경사항만 가져오고, 병합은 직접 수동으로 해야 함 `fetch`와 `merge`를 명시적으로 분리해서 수행 |
| 병합 여부 | 자동으로 merge (충돌 발생 가능성 ↑) | 작업 내용 보면서 변화 내용을 확인 후 병합할 수 있음 |
| 안전성 | 덜 안전함. 예상치 못한 merge 발생 가능 | 더 안전함. 병합을 수동으로 제어 가능 |
| 주로 언제 사용? | 본인이 혼자 작업 중일 때 빠르게 최신 코드 반영하고 싶을 때 |
협업 중, 병합 전에 변경사항을 검토하고 싶을 때 |