[개발일지] git 영역(Staging)과 소스관리 | 브랜치 전략, PR과 Merge | 협업 시 git 잘 쓰는 방법

개요

지금까지 프로젝트를 하면서 깃허브를 단순 코드 공유기로만 사용하였는데, 회사에서 github를 통해 협업을 진행하며 깃허브의 다양한 기능과 활용법, 장점에 대해 많이 배웠다. 이러한 내용들을 정리하여, 꾸준히 복기하려 한다.

 

---

git 소스 관리

 

• 소스 상태의 확인은 git status 명령어를 통해 확인할 수 있다.
• 관리 대상 상태
  • untracked: 파일 변경을 감지하지 않음.(아무런 변화 없는 상태)
  • tracked: 파일 변경 감지함.
  • modified: 파일이 변경된 상태지만 staged는 안되었으므로 Working Dir에서만 변한 상태.
  • staged: 커밋할 대상
  • commited: Staging Area에 안전하게 저장됨.

 

보통 github 원격 저장소에 push를 할 때, 다음과 같은 과정을 겪는다

git add .
git commit -m "내용"
git push origin ***


### git add "파일경로/파일 이름"으로 하나의 파일에 대해서만 변경을 감지할 수 있다!!

여기서 git add, git commit은 로컬 브랜치의 변경 이력에 영향을 준다. 다음 과정을 통해 이해해보자.

 

1. git add: 변경 이력들을 staging Area에 추가. 즉, 소스들이 modified 상태에서 staged 상태로 변화.
2. git commit: git add로 추가한 staging 영역에 있는 사항들이 로컬 저장소의 커밋으로 기록. 

 

위 두 단계를 통해 로컬 브랜치에 변경 사항을 기록하는 과정이다.

이후, git push 명령어를 통해 로컬 저장소에서 커밋한 내용을 원격 저장소로 업로드한다.

 

 

---

굳이 Staging Area를 거치는 이유?

*저장소는 크게 3가지 | Working Directory | Staging Area | Remote Repository | 

 

1) 일부분만 반영하여 실수를 줄인다!

 

어떤 기능을 만들거나 수정할 때 Working Directory(로컬 환경)에서는 자유롭게 수정하고 싶지만, 이를 원격 저장소에 반영하여 배포까지 한다는 건 큰 부담을 안겨준다.(그러한 시행착오들이 서비스 운영에 부정적인 영향을 주는 상황을 생각해보았을 때 .... 🙄😨 생각만해도 아찔하다ㅠㅠ)

만약 Staging Area가 없다면 커밋될 예정인 내용들이 한번에 원격 저장소에 반영해야 할 텐데, 그럼 개발자는 로컬 환경에서 코드를 자유롭게 수정하기엔 리스크 부담이 너무 크다. Staging Area를 통해 커밋할 내용들만 골라서 반영하고 로컬 환경에서 따로 테스트가 필요한 부분은 지속적으로 테스트를 해볼 수가 있기에 번거롭더라도 Git에서는 이러한 과정을 겪어 협업에 지장이 없도록 한다.

 

2) 쉬운 수정, 실수를 되돌릴 수 있음..

 

git commit --amend 명령어를 통해 커밋을 재작성하여 수정하면 하나의 커밋으로 다시 기록이 되어 실수로 커밋한 이력을 쉽고 빠르게 수정할 수 있다.

git revert를 통해 이전 커밋으로 되돌리는 방법도 있다.

 

 

---

브랜치 전략(Branch Strategy), PR과 Merge 

깃허브의 브랜치를 활용하는 방법은 다음과 같다.

 

1. 여러 명이 함께 개발을 할 때 각자의 브랜치를 만들어서 개발을 하고 메인 브랜치는 함부로 수정하지 않는다.
2. 혼자 개발을 한다고 하더라도 SW가 배포되거나 퍼블리싱이 된 이후에는 메인 브랜치를 함부로 수정하지 않는다.

 

main 브랜치는 보통 서비스와 직결되는 부분이 많기 때문에 실수가 발생했을 때 서비스 운영에 차질을 줄 수 있으므로 브랜치 전략을 통해 서비스 운영을 효율적으로 진행한다. 이러한 브랜치 전략, git convention은 프로젝트 팀마다 다르므로 개별적으로 확인해야한다. 또한 협업을 시작하기 전 이러한 convention을 정하고 협업을 해야 문서화도 잘 되고 원활한 협업을 진행할 수 있다.

 

예를들어,

지금 회사에서는 크게 main / develop / feature 브랜치로 나눈다.

작업을 할 때 핵심이 되는 목적어 키워드로 브랜치를 파고 작업과 코드 리뷰를 거친 후 develop에 Merge한다.

 

예를 들어 내가 Consultant 관련 개발을 진행한다고 하자.

그럼, git convention에 따라

 

feature/consultant 브랜치 생성 ➡️ 개발 ➡️ Local Test ➡️ 원격 저장소(feature/consultant)에 반영 ➡️ 코드 리뷰 후 approve ➡️ Merge ➡️ 브랜치 삭제

와 같은 과정을 거친다.

이렇게 개발 작업을 진행하면 분기하여 개발한 뒤 코드를 합치고 추적하는 데에 용이하다.

 

 

---

협업 시 git 잘 쓰는 방법

**각자 작업 후 분기되었을 때 코드 합치는 법 추가

** git stash와 pop 활용법 추가

 

---

느낀점

지금까지 무지성으로 git add, commit 등과 같은 과정을 거쳤다면 이제는 Staging Area를 활용하는 방법과 명령어를 통한 효율적이고 정성적인 개발 과정을 겪을 수 있어 좋았다.