#4 실무 IntelliJ+Git 사용

* Portfolio 카테고리에 포스팅한 글들은 경력기술서나 포트폴리오에 첨부한 프로젝트 관련되어 작성한 내용임을 알립니다.

 

* 내용에 대한 댓글은 언제나 환영입니다.

 

1. 관련 프로젝트 및 업무 개요

* 사내 진행했던 프로젝트로 실제 커밋 이력은 비공개이며 포스팅의 모든 사항은 공개 가능한 범위에서만 작성합니다.

---

프로젝트 및 업무 명

협업 내 퍼블리셔/프론트 팀 git 총괄 관리

 

개발 환경

intelliJ

Git, gitLab

2. 문제 분석 및 최초 Revision

* 포스팅에 사용된 사항은 실제 사내 사용 사례가 아닌 전부 예시임

---

문제사항

퍼블리셔/프론트엔드 팀과의 협업 과정에서 생기는 Git 관련 업무 시간 증가

1 Git 관리 환경으로 발생하는 협업 시간 증가
2 잘못된 커밋 푸시로 인한 브랜치 복구 작업
3 Feature 브랜치의 커밋 로그 간소화 작업

 

근거

---

# Redmine 소요 시간 분석

 

사내 업무 관리 툴인 Redmine 대시보드를 통한 분석 결과

퍼블리셔/프론트엔드 팀과의 협업이 포함된 일감들의 경우 통상 일감 대비 최소 20% 이상의 업무 시간이 소요

 

# 팀내 회의 결과

 

협업 과정 중 잘못된 git 사용으로 인한 추가 잔업의 빈도가 퍼블리셔/프론트엔드 팀의 신규 인력 추가 이후 증가했다는 의견

 

분석

1 Git 관리 환경 차이으로 발생하는 협업 시간 증가
> 팀간 사용 IDE의 차이로 인해 git 사용 환경이 다르며 기존의 branch 전략이 git 입문자들에게 다소 어려웠음

2 잘못된 커밋 푸시로 인한 브랜치 복구 작업
> 퍼블리셔/프론트엔드 팀에 git 사용 매뉴얼이 정확히 정착되지 않았음

3 Feature 브랜치의 커밋 로그 간소화 작업
> git 입문자들에게 다소 난이도가 있는 reset 옵션 사용이 필요

 

논의 및 학습

---

 

#1 Git 관리 환경으로 발생하는 협업 시간 증가

 

사내 팀별 메인 업무에 사용되는 IDE는 아래와 같았음

퍼블리셔 : vscode
프론트엔드 : vscode, Android Studio, Xcode
백엔드(유지보수 포함) : IntelliJ 

 

따라서 1 백엔드 팀에서 git을 사용하는 환경인 IntelliJ+git 통합 환경은 퍼블리셔/프론트엔드 팀이 사용하는 vscode의 git 사용과 방식이 많이 달랐으며 2 퍼블리셔/프론트엔드 팀은 상대적으로 cherry-pick, revert 등의 git 터미널을 통한 고급 기능 사용 미숙

 

또한 기존 사용하던 브랜치 전략은 jenkins+AKS를 사용하던 개발/배포 파이프라인에 맞춰 feature - dev - staging - main 으로 이어지는 git flow에 가까운 전략을 사용(release 대신 staging을 사용하며 hotfix 브랜치는 사용하지 않음)

 

이 과정에서 모든 팀이 동일한 권한으로 동일한 gitLab origin을 바라보며 푸시를 진행하므로 배포 속도가 느리기에 업무 시간을 줄이려는 과정에서 머지시 실수가 발생

 

> 최종 논의 결과 : feature - staging - main으로 변경 및 팀별 푸시 권한 조정

 

---

 

#2 잘못된 커밋 푸시로 인한 브랜치 복구 작업

 

백엔드 팀이 사용하는 IntelliJ+Git 통합 환경이므로 기존 git CLI와 다르게 동작

프론트/퍼블리셔 팀이 사용하는 vscode 환경은 기본적으로 GUI만 제공하므로 기존 git CLI 정책과 동일

 

환경	CLI 정책	push 전 자동 동기화 체크 여부	smart checkout 여부	conflict 발생시
IntelliJ	다소 차이남	true	true	전용 3-way merge 툴
vscode	거의 동일함	false	false	CLI 수준 메시지 + 간단 UX

* default configuration이며 intelliJ의 경우 로컬이 뒤쳐진 경우 push시 자동 3-way merge 처리됨

 

따라서 위의 표와 같은 협업시 주요 기능에 차이가 있으므로 vscode를 사용하는 퍼블리셔/프론트엔드 팀은 상대적으로 git에 대한 이해가 적은데 더해 안전 장치를 더해 실수를 줄일 수 있는 IntelliJ와 비교하여 더 잦은 실수가 발생

 

하지만 퍼블리셔/프론트 팀과의 회의에서 팀의 대다수인 주임 이상급에서는 문제 발생이 적기에 이것만으로 Git Lens나 Git graph 등 vscode extension을 사용하는 것은 학습 비용이 더 클 것이라 결정했으며 타 팀이므로 그 결정을 존중하기로 하여 다른 방법을 논의함

 

> 최종 논의 결과 : 

1 fetch - pull - commit - push을 강제하는 매뉴얼을 도입 및 온보딩 교육 강화

2 PR(pull-request) 도입 후 머지 체크 프로세스 강화

3 cherry-pick, revert 등 복구 관련 명령어는 최종 백엔드 팀만 진행

 

 

---

 

#3 Feature 브랜치의 커밋 로그 간소화 작업

 

업무 과정 중 Feature 브랜치에 너무 많은 커밋 로그가 발생하여 충돌이 발생하거나 이전 커밋으로 복구해야하는 경우 변경 이력에 대한 파악 시간이 증가하여 이 경우 로컬 squash를 통해 커밋 로그 간소화를 진행해야 함

* squash의 경우 rebase -i(interactive  rebase) 옵션으로 fix-up과 유사한데 둘의 차이는 커밋 메세지 관리 차이 

 

reset, rebase는 origin push를 잘못할 경우 커밋 유실 및 브랜치 꼬임의 위험성이 너무나도 커서 팀 정책으로 push 이후 커밋은 reset, rebase 절대 금지며 로컬에서만 허용

 

> 최종 논의 결과 : push 이후 reset, rebase 사용 금지 / 단, 로컬에서 사용해야 한다면 반드시 팀간 상의 이후 진행

 

3. 결과

---

 

개선사항

 

#1 Git 관리 환경으로 발생하는 협업 시간 증가

 

@ 브랜치 전략 변경 및 팀별 푸시 권한 조정

 

기존의 git-flow에 가까운 feature - dev - staging - main 전략에서

dev branch를 삭제하여 trunk based + github-flow로 볼 수 있는 feature - staging - main 전략으로 간소화

 

1-1 이렇게 변경할 경우 staging 브랜치 품질 저하와 전체 프로세스의 안정성이 감소하지 않나?

 

그 점을 보완하기 위해 협업 프로젝트의 push 권한을 퍼블리셔/프론트 팀은 feature 까지로 제한했으며 뒤에서 언급하겠지만 PR을 통해 수정된 부분에 대한 테스트가 완료된 커밋을 request시 백엔드 팀에서 머지하는 것으로 논의 완료

 

> 기존 dev 브랜치의 경우 백엔드 팀 입장에선 staging에 푸시 되기 전 로컬 커밋과 프로세스 상 차이가 없으며 dev 브랜치는 직접적인 배포 파이프라인과 연결되어 있지 않으므로 관리 용이와 배포 속도 향상이라는 장점에 대비해 전략 변경의 비용이 거의 없음

* 단, 이 결정은 사내 프로젝트의 특성에 기인하며 환경에 따라 완전히 틀린 결정일 수 있음을 유의

 

---

 

#2 잘못된 커밋 푸시로 인한 브랜치 복구 작업

 

@a fetch - pull - commit - push을 강제하는 매뉴얼을 도입 및 온보딩 교육 강화

 

온보딩 교육 매뉴얼 추가부터 팀내 교육시에도 git 사용시 반드시 fetch - pull - commit - push를 의무화하도록 강조하고 만약 이를 지키지 않아 conflict나 denied 발생시 force push 등 자율적인 해결이 아닌 반드시 상위 직급에게 보고하도록 정책 수정

 

@b PR(pull-request) 도입 후 머지 체크 프로세스 강화

 

앞서 언급한 퍼블리셔/프론트 팀 작업 및 테스트 완료 후 해당 커밋에 대해 reviewer를 백엔드 팀에 지정하도록 PR을 강제하여 잘못된 커밋 푸시 빈도를 줄이고 approve 후 merge 과정에서 한 번 더 체크하여 staging 머지시 생길 충돌을 사전에 예방 

 

프로세스상 작은 PR을 도입하기는 힘드나 1 squash를 통해 커밋 히스토리를 읽기 쉽게 간소화하고 2 퍼블리셔/프론트 팀의 Author는 request시 매뉴얼에 따라 커밋 분류, 커밋 메세지를 작성 을 통해 효율적인 PR 단계가 진행되도록 함

 

@c cherry-pick, revert 등 복구 관련 명령어는 최종 백엔드 팀만 진행

 

팀간 협의 중 앞서 퍼블리셔/프론트 팀은 별도의 extension을 사용하지 않기로 결정했으므로 CLI 자체로는 하기 힘든 git diff 후 수동 복구, revert, cherrypick, fix 등은 intelliJ를 사용하는 백엔드 팀에서 진행

 

---

#3 Feature 브랜치의 커밋 로그 간소화 작업

 

feature의 커밋이 ground rule로 정한 10개를 넘기거나 PR 검토시 적절하지 않다 판단되는 경우 작업 중인 로컬 브랜치 내에서 squash 작업을 진행함

* fix-up은 커밋 메세지 폐기로 인해 사용하지 않음

* remote가 아닌 반드시 로컬 브랜치에서만 reset, rebase 명령어를 수행

4. 추후 이슈 및 대응

---

이슈 발생 사항

#1 stash

 

일반적으로 수정사항이 존재하는데 잠시 다른 브랜치로 checkout하고 싶은 경우 git CLI는 stash라는 명령어를 통해 진행할 수 있습니다. 하지만 IntelliJ+git 통합 환경의 경우 smart checkout을 제공하여 stash를 잘 사용하지 않고 만약 필요하다면 stash 명령어를 대신하여 비슷하게 다음과 같이 사용할 수 있습니다.

* 임시 저장 관련해선 Shelve가 가장 편리하지만 이는 git 기능이 아닌 IntelliJ 단독 제공이므로 제외하였습니다

 

1 다른 브랜치 체크 아웃 전 로컬 변경사항을 우선 작업 중인 브랜치에 커밋(* 푸시하지 않음) 

* untracked 파일이 존재하는 등 smart checkout을 사용하지 못하는 경우

 

2 다른 브랜치에서 작업 후 다시 작업 브랜치로 돌아와서 최신 커밋에 대해 아래 그림과 같이 reset soft 수행

* 아래 이미지는 예시 이미지이며 reset soft시 사용된 브랜치가 아님 

 

stash 명령어의 경우 기본적으로 여러 개가 쌓일 경우 stash list를 사용하더라도 직관성이 떨어지므로 업무시 위와 같은 reset soft를 자주 사용했었는데 병합 충돌이 해결되지 않은 브랜치거나 reset 대상 브랜치를 잘못 선택하는 경우 기대와 다른 동작을 가져옴

 

> 1 반드시 feature 브랜치에만 사용 2 변경 사항이 너무 많은 브랜치는 기존대로 stash를 사용

 * 변경 사항이 적을 경우 어차피 로컬에서의 커밋만 존재하는 브랜치이므로 폐기 후 remote에서 다시 브랜치를 가져와 변경 사항 추가

추가 고려 사항

#1 퍼블리셔/프론트 팀장에게 IntelliJ+git 사용법을 공유하여 더욱 효율적인 프로세스로의 변경 가능성 논의
#2 추후 팀 규모가 커질 경우 다시 git flow(feature-dev-staging-main) 전략 롤백 
#3 프로세스상 PR 크기가 커질 수 밖에 없는 구조이나 이후 작은 PR로의 변경 가능성 논의