[신한투자증권 프로 디지털 아카데미] Github 및 DevOps 환경에 대한 이해(2)

 
 
 

1. git checkout 의 기능들

 

- switch / restore 을 추천하지만 checkout 의 기능도 여전히 남아있음 - 왜? 처음부터 체계적으로 설계된 것이 아니라 자연스럽게 성장해왔기 때문, 아이디어를 계속 추가해옴

• switch : 오직 브랜치 전환에만 사용
• checkout : 브랜치 전환, 파일 체크아웃, 커밋으로 돌아가기(switch, checkout, restore) 등 다양한 용도에서 사용되고 있으므로 직관적이지 않음

 

💡 내가 원하는 단어 뒤에 awesome 혹은 cheatsheet 를 붙이면 좋음 ex. Git awesome

 

 

2. git workflow

 
+) Git-flow
: Git 을 이용해 작업할 때 많은 사람들이 함께 할 때를 위해 워크 플로우가 있음
- 복잡한 프로젝트, 버전 릴리스 중심 개발에 적합 (ex. 대규모 시스템, 온프레미스 배포)
 
- 브랜치 종류

• main : 실제 운영 코드
• develop : 다음 릴리즈를 위한 통합 브랜치
• feature/* : 기능 개발 브랜치, 여기서 작업 후 develop 에 머지
• release/* : 릴리즈 준비 브랜치, 여기서 테스트, QA 해보고 이상 없으면 main(배포), develop(다른 기능을 더 개발해야 할 경우)에 머지
• hotfix/* : 운영 중 긴급 수정하는 브랜치, 문제 발생하면 여기서 수정

- 특징

• 릴리스 기반의 복잡한 흐름
• 병렬적이고 긴 개발 주기
• 수동 릴리스와 QA가 필요한 조직에 적합

 
1) Github-flow
- 민첩하고 단순한 개발, 빠른 배포와 피드백이 중요한 환경, CI/CD 환경에 적합 (ex. 웹서비스, SaaS, 스타트업)
- Trunk-based
- 라벨링을 잘하는 것이 중요함
 
- 브랜치 종류

• main : 운영 중인 코드 - main 브랜치 하나만 운영하고 필요한 경우에만 feature 브랜치 만들어서 개발
• feature/* : 필요한 기능을 직접 main에서 분기하여 작업

- 특징

• 단순함 + 지속적 배포(CD)에 최적화
• 배포가 자동화된 환경에서 사용
• PR(Pull Request) 기반 협업이 중심
• 장점 : 여러 브랜치 관리할 필요 없음
• 단점 : 테스트를 많이 자주 해야 함, main 에 있으니까 바로 배포가 되기 때문에 보통 자동화 해둠 - 그래서 안정화 된 프로젝트들이 씀

 
 
+) GitLab Flow
- GitHub Flow + Git Flow + 이슈 기반 배포 전략의 혼합 모델
 
- 브랜치 종류

• main : 제품 기준 버전
• pre-production : 검수용 배포
• production : 실제 운영
• 각 이슈/기능은 issue/#123-feature-name 형식으로 브랜치 생성

- 특징

• 환경(branch) 기반 + 이슈(issue) 기반 개발 병행
• 배포 대상 환경(dev, staging, production) 별 브랜치 운영
• 이슈 트래킹과 병합 요청(Merge Request)을 강하게 통합
• CI/CD 파이프라인 연계에 최적화

 
+) 비교 정리

	Git-flow	Github-flow	Gitlab-flow
개발 방식	릴리즈 주도	배포 자동화 중심	이슈 기반 + 환경 기반 혼합
브랜치 구조	복잡 (main, develop, feature, release 등)	단순 (main + feature)	유연 (main, staging, production + issue)
릴리즈 브랜치	있음 (release/*)	없음 (main 기준 배포)	선택적 운영 가능 (환경 브랜치로 대응)
핫픽스 브랜치	별도 존재 (hotfix/*)	없음 → 빠른 PR로 해결	production 브랜치에서 직접 처리 가능
PR/MR 중심 협업	덜 중심적 (Git 명령어 중심)	PR 중심 협업	MR 중심 + 이슈/CI/CD 완전 연동
CI/CD 연계	없음 / 수동적	강함 (GitHub Actions 등 연계)	매우 강함 (GitLab CI/CD 완전 내장)
적합한 환경	엔터프라이즈, 릴리스 프로세스가 중요한 팀	스타트업, 빠른 서비스 배포 환경	중~대규모 DevOps 환경, CI/CD + 이슈 동기화 팀

 
 
2) Git 3way merge
: Git은 Base와 HEAD, 병합 대상 브랜치를 비교해서 어떤 내용이 변경되었는지를 분석한 후, 자동으로 병합(Merge Commit)을 시도 - 공통 조상을 기준으로 양쪽 브랜치의 변경사항을 비교해서 병합을 수행한다 

• 공통 조상(Base) : 두 브랜치가 갈라지기 전의 마지막 커밋
• HEAD : 현재 브랜치 (내가 지금 작업 중인 브랜치)
• Merge 대상 브랜치 : 병합하려고 하는 다른 브랜치