협업에 익숙해 지기 위한 Git 사용 방법

카테고리 없음

협업에 익숙해 지기 위한 Git 사용 방법

에그마요샌드위츼 2025. 5. 2. 12:19

들어가며

이번에 스터디를 하면서 협업시 하는 깃 사용에 대해서 익숙해지기 위해서

어떤 흐름으로 깃을 사용하는지 다같이 공부해봤으면 하는 마음으로 글을 작성합니다.

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 프로젝트 초기화 및 연결

`git init`

`git remote add origin https://github.com/seseseseo/introduce-team.git `

3. 패키지 구조 정리(도메인형)

git add .
git commit -m "init: 프로젝트 초기 세팅"
git push -u origin dev

2. 팀원들이 프로젝트를 가져오는 흐름

여기서부터 보시면 될 거 같습니다

🔽 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 발생 가능	더 안전함. 병합을 수동으로 제어 가능
주로 언제 사용?	본인이 혼자 작업 중일 때 빠르게 최신 코드 반영하고 싶을 때	협업 중, 병합 전에 변경사항을 검토하고 싶을 때