[Git] Head? Stage? Branch?

프로젝트 리팩토링 중 git bash로 커밋 로그를 확인하다가 'HEAD -> main, origin/main'의 정확한 의미를 알지 못한다는 것을 깨달아 git에 대해 다시 처음부터 배웠다. 그리고 하나의 브랜치에서 git pull, git add, git commit, git push만 반복하며 사용해왔는데, 실무에서는 여러 브랜치를 이동하고 머지해가며 작업하는 것으로 보여 이러한 경우에 대한 공부도 했다. 이 포스트에서는 다시 공부한 git 기초 지식과 작업 방식에 대해 적어보고자 한다.

 

 

 

• Stage?

git status

작업 디렉토리(=작업 트리) : 파일 생성, 저장 등의 작업이 실제로 수행되는 폴더 (HEAD 이동 시 작업 트리도 함께 변화함)

스테이징 영역(=스테이지) : 새로운 버전으로 만들 파일이 대기하는 영역 

로컬 저장소 : 파일이 버전으로 저장되는 개별 PC 내 개인 저장소

원격 저장소 : 파일이 전용 서버(ex.Github)에서 관리되는 공유 저장소

 

※ 버전 : 파일 수정, 저장할 때 생성되는 것

 

 

 

• Head?

HEAD : 현재 속한 브랜치의 가장 최신 커밋

origin/main : 원격 브랜치의 main 브랜치

HEAD -> main, origin/main : 해당 커밋이 로컬 & 원격 main 브랜치의 가장 최신 커밋임을 가리킴

 

 

 

• Branch?

1. merge

: A브랜치를 B브랜치에 병합

 

Main 브랜치를 Feature 브랜치에 병합

사진 출처

 

ex) 급히 해결해야 하는 오류 발생할 경우

→ main 브랜치의 파생 브랜치 hotfix 생성

→ hotfix 브랜치에서 코드 수정, 테스트 등 작업 수행

→ hotfix 브랜치를 main 브랜치에 merge해 수정사항 적용

=> 기존 버전에 영향끼치지 않고 다른 브랜치에서 안전히 작업 후 merge

 

 

2. rebase

: (또다른 병합 방식) 파생 브랜치의 base(파생 지점)를 이동

 

Feature 브랜치를 Main 브랜치로 rebase

사진 출처

 

=> 병합 시 새로운 커밋이 생성되는 merge와 달리, 브랜치의 커밋들을 이동만 시키면서 깔끔한 커밋 히스토리 만듦

 

장점) 시간 순의 커밋 이력 확인 가능, merge 시 발생하는 불필요한 병합 커밋 제거 가능

단점) 여러 사람들이 사용 중일 때 rebase 실행하면 커밋 히스토리가 변경돼 재작업해야 할 수 있으므로 유의해야 함

 

 

3. cherry-pick

: 다른 브랜치의 특정 커밋을 현재 작업 중인 브랜치에 반영

 

 

4. stash

: 로컬 저장소에 임시 저장 (다른 브랜치에서 불러오기 가능)

 

 

 

• + 브랜치 전략 (대표적인 2가지)

1. Git-flow

 

• 메인 브랜치

• main : 제품으로 출시될 수 있는 브랜치 (배포 가능한 상태)
• develop : 다음 출시 버전을 개발하는 브랜치

 

 

• 보조 브랜치

보통 로컬 저장소에만 생성

기능 완성할 때까지 유지(완성 시 main 또는 develop 브랜치로 merge 후 삭제)

네이밍 ex) hotfix-1, feature/logout

 

 

• feature : 추가 기능을 개발하는 브랜치

develop에서 파생

develop에 merge

 

 

• release : 이번 출시 버전을 준비하는 브랜치 (배포 전 QA 테스트)

develop에서 파생

main, develop에 merge

 

 

• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치 (배포 버전에서 발생한 긴급한 버그 수정) 

main에서 파생

main, develop에 merge

 

 

 

2. Github-flow

• 메인 브랜치

• main 

github-flow에서 유일하게 stable한 브랜치

 

 

 

• 보조 브랜치

• feature/..

추가 기능 개발, 버그 해결 등의 경우 main에서 분기된 새로운 브랜치 생성 (=> 명확한 네이밍 필요)

이슈 완료 시 브랜치 삭제 

 

 

 

커밋에 의존하므로 상세한 커밋 메세지 작성 후 수시로 원격 브랜치로 push

→ 피드백 필요할 때 또는 merge 준비됐을 때 pull request 생성, 코드 리뷰 받음

→ 라이브 서버(또는 테스트 환경)에 배포해 테스트 진행

→ 테스트 통과 시 main 브랜치에 merge (자동 배포)

 

 

 

• Git-flow와 Github-flow 비교

• Git-flow 

장점 : 브랜치별 명확한 역할을 가지며 이력 관리 쉬움

단점 : 브랜치가 많아 규칙 학습하는 시간 필요, 사용하지 않는 브랜치가 있을 수 있음

 

명시적인 버전관리가 필요한 프로젝트에 적합 ex) 스마트폰 어플리케이션, 오픈소스 라이브러리/프레임워크

1개월 이상의 긴 호흡으로 개발하고 주기적으로 배포와 테스트 등 수행하는 경우 적합

 

 

 

• Github-flow 

장점 : Git-flow보다 간단한 규칙을 가짐. 지속적 개발, 배포에 효과적 

단점 : 프로젝트가 커질수록 개발 프로세스 관리하기 어려워짐

 

웹 어플리케이션에 적합 (비교적 잦은 배포, 사용자는 최신의 단일 버전만 사용함)

소규모 프로젝트에서 수시로 배포, 테스트 진행해야 하는 경우 적합

 

 

 

프로젝트를 진행할 당시에는 브랜치 전략에 대해 아는 바가 없었기 때문에 특정 전략을 선택하기 보다는 각 팀원들 브랜치 - develop - main 순으로 merge 해나갔다. 예를 들어 프로젝트 진행 중에는 팀원들이 개인 브랜치에서 각자 도메인에 대한 개발을 진행해가며 테스트 시행했고, 이후 develop 브랜치로 pull request 해 코드 리뷰 및 merge를 진행했다. 프로젝트 완료 후에는 develop 브랜치에서 리팩토링을 진행했고, main 브랜치에 merge 시 github actions를 통해 자동 배포되도록 설정했다. 

 

만약 브랜치 전략을 적용했다면 소규모 웹 애플리케이션 프로젝트에 적합한 github-flow 방식이 효율적이었을 것 같다. 우리가 실행한 협업 방식으로는 사실 개인 브랜치 삭제 시점도 헷갈려 배포한 후로도 개인 브랜치-develop-main 으로 두 차례의 불필요한 merge 작업을 해나갔다. 빠르고 효율적인 작업을 위해 다음 번엔 체계적으로 git 협업을 해나가야겠다.

 

 

 

 

출처:

https://parodev.tistory.com/45

https://programforlife.tistory.com/99

https://programforlife.tistory.com/100

https://yumyumlog.tistory.com/271

https://hayden-archive.tistory.com/225

https://gmlwjd9405.github.io/2017/10/27/how-to-collaborate-on-GitHub-1.html

https://cross-the-line.tistory.com/m/20#:~:text=Git%20Rebase%20%EB%9E%80%20%EB%A7%90%20%EA%B7%B8%EB%8C%80%EB%A1%9C,%EB%A5%BC%20%EC%9E%AC%EC%84%A4%EC%A0%95%ED%95%98%EB%8A%94%20%EA%B2%83%EC%9E%85%EB%8B%88%EB%8B%A4.

https://escapefromcoding.tistory.com/746#:~:text=GitHub%2DFlow%EB%8A%94%20%EB%A7%A4%EC%9A%B0%20%EA%B0%84%EB%8B%A8,%ED%95%9C%EB%8B%A4%EB%A9%B4%20Git%20Flow%EA%B0%80%20%EC%A2%8B%EC%8A%B5%EB%8B%88%EB%8B%A4.

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

https://sungjk.github.io/2023/02/20/branch-strategy.html

https://techblog.woowahan.com/2553/

https://hudi.blog/git-branch-strategy/#:~:text=Git%20%EB%B8%8C%EB%9E%9C%EC%B9%98%20%EC%A0%84%EB%9E%B5%EC%9D%80%20%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8,%EB%AA%A8%EB%B2%94%20%EC%82%AC%EB%A1%80%EB%93%A4%EC%9D%B4%20%EC%A1%B4%EC%9E%AC%ED%95%9C%EB%8B%A4.