[데브툰] Git 활용하여 자신있게 프로젝트 협업하기

목차

그래서 어떤 협업을 진행했는가

  팀 프로젝트의 시작

  협업 관련 회의 진행 ♾️

 

간단 소개

  코드 컨벤션 및 우리만의 약속 

  GitHub Projects를 통한 형상관리

 

이걸로 Git + 협업 종결

  임시 저장, stash 

  git 충돌 해결, 수시로 develop pull 습관화 

  commit 히스토리 정리, rebase

  

회고

  만족한 점

  아쉬운 점

  다음에는 이렇게

 

그래서 어떤 협업을 진행했는가

개인 프로젝트를 세 번 진행하며 Git을 사용했지만, 단순히 기능(feature)만 나누는 것에 그쳐 아쉬움이 있었다. 팀 프로젝트를 하면서 Git을 제대로 활용하고자 협업 관련 회의를 지속적으로 진행했다. 기획 단계에서 우리만의 코드 컨벤션과 약속을 정했고, 이는 앞으로의 개발을 일관성 있게 진행할 수 있도록 도왔다. 

 

이슈 단위로 브랜치를 생성하고, PR 단위로 코드 리뷰를 진행했다. 또한, GitHub Projects를 통해 형상관리도 진행해 실무 경험을 간접적이나마 해볼 수 있었다. 진행 중 종종 발생하는 충돌을 해결하기도 했고 stash, rebase 등을 통해 커밋 내역을 관리하기도 하면서 팀 프로젝트를 제대로 경험할 수 있었다.

 

이제 데브툰 프로젝트를 진행하면서 어떤 약속들을 했는지 소개하고, 회고로 마무리해보려 한다.

 

간단 소개

코드 컨벤션 및 우리만의 약속

굳이 진행한 이유

두 명이 진행한 팀 프로젝트였지만, 제3자가 보거나 시간이 지나 우리가 다시 보더라도 마치 한 사람이 작업한 것처럼 코드의 일관성을 유지하고 싶었다. 이는 추후 원활한 유지보수에도 도움이 될 것이라 생각했다.

 

코드 컨벤션

1. 코딩 스타일

 

2. Response 양식: API 응답 형식 통일

 

더 자세한 내용은 아래에 있습니다.

3. 예외처리: 공통된 예외 처리 방식

4. 메서드명 규칙

- 등록 : register

- 조회 : retrieve

- 삭제 : delete

5. import 자바 코드 컨벤션

아래는 팀원의 코드 리뷰 일부입니다.

구글 java 컨벤션에서는 와일드카드 import문 사용을 지양하라고 나와있습니다.

저는 mport내용을 구체적으로 명시해야지 패키지 경로 관리도 수월하고, 명확한 클래스 명을 알 수 있어서 좋다고 생각해요 :)
또한 와일드카드 import문을 사용했을 때 컴파일러가 동일한 클래스 이름을 찾을 때 문제가 발생할 수도 있다고 합니다

 

우리만의 약속

 

더 자세한 내용은 아래에 있습니다.

2. 브랜치 전략

 

3. 커밋 메시지 작성: Git Flow 전략

4. 이슈 생성 → 브랜치 생성 → PR 단위로 코드 리뷰 진행 → merge 일련의 과정 

GitHub Projects를 통한 형상관리

간략하게 Todo, In Progress, Done 세 단계로 나누어 진행했다. 현재 진행 과정을 한눈에 확인할 수 있어 회의 없이도 파악이 가능했다.

 

이걸로 Git + 협업 종결

임시저장 stash 및 충돌 해결 과정

stash란

커밋 전에 다른 branch로 이동해야 하는 상황이 생길 때 사용한다.

 

나는 stash를 언제 사용했나

• PR을 올리고 merge 되기 전까지 기다리는 시간이 아까워 브랜치를 생성하고 작업하고 싶은 마음이 솟구칠 때
• 특정 브랜치에서 작업을 하다가 사전 작업이 필요해 브랜치 이동이 필요할 때
  • 예: 특정 회원의 쿠키 결제 내역 조회 api 테스트하기 위해, 사전 작업으로 쿠키 정책 등록이 필요함
  • 브랜치를 옮겨서 작업을 마저 하기로 결정

과정

1. stash 하고 싶은 모든 파일이 staged 된 상태인지 확인

 

2. 터미널 작업

git stash save [파일 저장명]

 

3. 커밋 내역에 아무것도 없는지 확인 후 → 브랜치 이동

 

4. 2번에서 stash 했던 것 적용

git stash apply [stash이름]

 

stash 적용하면서 파일 충돌 시 해결과정도 간단하게 알아보자

• 왼쪽: 예전에 해당 브랜치에서 작업한 내용 → 적용하고 싶으면, Accept Yours
• 오른쪽: 다른 브랜치에서 수정한 내역 → 적용하고 싶으면, Accept Theirs
• 수동으로 작업하고 싶으면 Merge… 클릭

 

stash에 대한 더 자세한 내용은 아래를 클릭하면 된다. 이것만 알면 자신 있게 브랜치를 자유자재로 이동할 수 있다!

stash 저장

# 현재 작업을 임시저장소에 저장한다.
$ git stash

# 설명을 적는 것도 가능하다.
$ git stash save "설명"

ㄴ stash 하려는 파일은 전부 staged 된 상태여야 한다! (git add . 해야 함)

 

stash 목록 → 이때 나오는 이름(stash@{2})으로 stash 적용해야 함

# statsh 목록
$ git stash list

 

stash 적용

# 가장 최근의 stash를 가져와 적용한다.
$ git stash apply

# stash 이름(ex. stash@{2})에 해당하는 stash를 적용한다.
$ git stash apply stash@{2}

 

stash 삭제

apply 옵션은 단순히 stash를 적용하는 것으로, 해당 stash는 스택에 여전히 남아있다. 스택에 남아 있는 stash는 아래의 명령어를 사용하여 제거할 수 있다.

# 가장 최근의 stash를 제거한다.
$ git stash drop

# stash 이름(ex. stash@{2})에 해당하는 stash를 제거한다.
$ git stash drop stash@{2}

# 전체 삭제
$ git stash clear

 

stash 롤백

실수로 잘못 stash 적용한 것을 되돌리고 싶으면 아래의 명령어를 이용한다.

# 가장 최근의 stash를 사용하여 패치를 만들고 그것을 거꾸로 적용한다.
$ git stash show -p

# stash 이름(ex. stash@{2})에 해당하는 stash를 이용하여 거꾸로 적용한다.
$ git stash show -p [stash 이름]

 

충돌을 알아본 김에,  git 충돌 시 어떻게 해결했는지 같이 살펴보자

상황

PR을 날렸는데 팀장님께서 이거 충돌 나니까 충돌해결하고 와!라고 하면 어떻게 해야 할까?

 

해결

당황하지 말고 깃헙에서 친절하게 알려주는 그대로 진행하면 된다.

우선 develop에 #feature를 PR로 붙이려고 하다가 충돌이 났으니까 두 브랜치 간의 충돌을 해결해야 한다.

1. 로컬에 가서 develop를 #feature에다가 붙인다.(반대로 하면 안 됨 - 실무에서는 안 되도록 설정할 듯)
   1. 로컬 develop 체크아웃해서 최신화(git pull)
   2. 충돌난 브랜치로 체크아웃 → git merge develop (pull이 아니다)
   3. 그럼 충돌난 부분을 알려줌
2. 해결한 결과를 그대로 커밋 후 푸시한다.(이미 해당 브랜치는 PR 날려진 상태이기 때문에 push 하면 PR에 덧붙여진다.)
3. 이렇게 하면 develop과 브랜치 간의 충돌 부분이 해결된 상태로 PR이 최신화되기 때문에 깃헙단에서 충돌 없이 merge 할 수 있게 된다.

 

나는 커밋 히스토리도 관리한다, rebase

사용 이유

개발할 때는 작은 단위로 작업 후 커밋하고 푸시 전 관련 커밋을 하나로 합칠 때 사용한다.

• 장점 1: 커밋 히스토리를 깔끔하게 관리 가능
  • 한 브랜치 내에서 여러 작은 커밋을 하나로 합치면, 불필요한 커밋을 제거하여 커밋 히스토리를 단순하게 유지할 수 있다.
• 장점 2: 코드 리뷰하는 리뷰어 입장에서도 이해하기 쉬움.

 

상황을 예로 들어 rebase를 하는 방법과 결과적으로 어떻게 보이는지 살펴보도록 하자

 

문제 상황

작은 단위로 커밋을 하면서 개발하면 좋겠지만 쭉 개발하다 정신 차리면 아래와 같이 파일이 쌓여있는 것을 볼 수 있다.

그렇다고 이대로 커밋하면 리뷰어 입장에서 코드리뷰 시 부담이 되고 추후에 코드를 작성한 개발자가 확인하기도 어려울 것이다. 

 

1. 그래서 푸시 전 rebase를 진행하기로 결정했다. 

 

2. 작은 단위로 나누기

나는 위의 13개의 파일을 관련성 있게 5개로 묶어서 커밋을 진행했다.

• refactor: 필요 없는 파일 삭제
• refactor: 쿠키 및 비속어 정책 엔티티 및 리포지토리 구현
• refactor: 쿠키 및 비속어 정책 컨트롤러 구현
• refactor: 쿠키 및 비속어 정책 서비스 구현
• test: 정책 등록 통합 테스트 구현

3. 이제 rebase를 진행해 보자

인텔리제이 Git으로 들어가서 기준으로 잡고자 하는 [커밋 번호]를 기억해 준다.

• 명령어: git rebase -i [커밋 번호]
• 밑으로 갈수록 최신 커밋

 

rebase 하고 싶은 부분 → pick을 지우고 sqash로 작성 → 그럼 아래 커밋이 바로 위로 붙는다

• 내용 수정을 위해 i를 눌러주고
• 변경을 다했으면 esc
• 해당 창을 나가고 싶으면 :wq을 적으면 저장 후 나간다

 

4. 이제 최종적으로 정리를 하고 다시 인텔리제이 Git을 확인해 보면 바뀌어져 있는 것을 확인할 수 있다

 

5. 이 상태로 pr을 올리면 커밋 내역이 아래와 같이 깔끔하게 보인다

 

회고

만족한 점

나와 잘 맞는 팀원을 만난 점이 가장 감사하다. 초반에는 매일 회의를 진행하고 사소한 것도 맞춰가려 했는데, 한 번도 귀찮은 내색도 하지 않고 오히려 둘이 신나서 개발 문서 작성을 했다. 덕분에 개발을 계속 재미있게 할 수 있었다. 지금도 ~ing

 

초반에 우리만의 약속을 잘 정립한 덕분에 추후 개발 진행 시에도 길을 잃지 않을 수 있었다.

사소해 보이는 것들까지 규칙을 정해두니 다른 팀원의 코드를 이해하는 데 어려움이 없었다.

이전에는 Git 충돌이 나면 어쩌나 막막했지만 stash, rebase 활용과 충돌 시 git이 알려주는 대로 해결해 보니 더 이상 두려울 것이 없었고 자신감이 붙으니 개발 속도도 더 빨라짐을 경험했다.🔥🔥

 

아쉬운 점

팀 프로젝트를 진행하면서 아쉬운 점이 있을 법도 한데, 돌이켜봐도 특별히 아쉬운 점이 없었다. 다시 한 번 팀원에게 감사하다는 말을 전하고 싶다. 😀

 

다음에는 이렇게

이번 경험을 바탕으로, 다음 팀 프로젝트에서는 더 신속하게 진행하고 틀을 더 간결하게 만들어 나갈 수 있을 것 같다.

그리고 시간을 확보한 만큼 개발이 원활히 진행 될 수 있도록 추가적으로 협업에 어떤 것들이 도움이 될지 조사도 하고 적용해 봐야겠다.