프로덕션을 위한 Git 마스터링: 브랜칭, 머징 & 스쿼시 전략, 모든 엔지니어가 알아야 할 것
Source: Dev.to
위에 제공된 내용만으로는 번역할 텍스트가 없습니다. 번역을 원하는 본문을 알려주시면 한국어로 번역해 드리겠습니다.
현대 소프트웨어 개발 및 Git 기본
현대 소프트웨어 개발은 코드 변경을 관리하고 협업을 지원하며 안정성을 유지하기 위해 버전 관리 시스템에 크게 의존합니다. Git은 팀이 서로의 진행 상황을 덮어쓰지 않고 동시에 작업할 수 있게 해주는 업계 표준 분산 버전 관리 시스템입니다.
Git의 강력함의 핵심은 브랜칭, 병합, 스쿼시, 리베이스와 같은 브랜치와 히스토리 관리 기능입니다. 이러한 개념을 이해하는 것은 깔끔하고 추적 가능하며 프로덕션에 바로 투입할 수 있는 코드베이스를 유지하는 데 필수적입니다.
이 글을 읽고 나면 엔지니어는 다음을 수행할 수 있게 됩니다:
- 안전하게 작업하기 위해 브랜치를 생성
- 다양한 전략을 사용해 브랜치를 병합
- 병합 충돌을 해결
- 여러 커밋을 하나로 스쿼시
- 전체 프로젝트를 GitHub에 푸시
프로젝트 설정 – 파트 1
| 단계 | 명령 | 목적 | 결과 |
|---|---|---|---|
| 1️⃣ | mkdir git-merge-lab | 프로젝트 폴더를 생성하여 기존 파일과의 충돌을 방지하고 Git‑merge 연습을 위한 제어된 환경을 제공하는 격리된 작업 공간을 마련합니다. | 새 디렉터리 git-merge-lab 가 생성됩니다. |
| 2️⃣ | cd git-merge-lab | 터미널 세션을 프로젝트 디렉터리로 이동시켜 해당 폴더를 현재 작업 환경으로 설정합니다. | 쉘의 작업 디렉터리가 이제 git-merge-lab 가 됩니다. |
| 3️⃣ | git init | 새 Git 저장소를 초기화합니다. | 숨김 .git 폴더가 생성되고, 디렉터리가 Git 저장소가 됩니다. |
| 4️⃣ | echo "# Team Project" > README.md | README.md 파일을 생성하고 초기 내용을 채웁니다. | # Team Project 를 포함하는 README 파일이 폴더에 추가됩니다. |
| 5️⃣ | git add README.md | 다음 커밋을 위해 파일을 스테이징합니다. | 파일이 인덱스(스테이징 영역)에 배치됩니다. |
| 6️⃣ | git commit -m "Initial commit" | 프로젝트 상태의 스냅샷을 저장소 기록에 기록합니다. | “Initial commit” 메시지를 가진 커밋이 생성됩니다. |
| 7️⃣ | git branch -M main | 기본 브랜치 이름을 main 으로 변경합니다. | 현재 브랜치 이름이 main 으로 바뀝니다. |
FAST‑FORWARD MERGE – 파트 2
| 단계 | 명령 | 목적 | 결과 |
|---|---|---|---|
| 8️⃣ | git checkout -b feature-login | 새로운 feature-login 브랜치를 만들고 그 브랜치로 전환합니다. | main에서 새로운 feature-login 브랜치가 생성되고 체크아웃됩니다. |
| 9️⃣ | echo "Login page created" > login.txt | 로그인 기능과 관련된 소스 파일을 추가합니다. | 텍스트 Login page created가 들어 있는 login.txt 파일이 생성됩니다. |
| 🔟 | git add login.txtgit commit -m "Add login feature" | git add는 파일을 스테이징하고, git commit은 스테이징된 변경을 새로운 스냅샷으로 기록합니다. | feature-login 브랜치에 **“Add login feature”**라는 커밋이 생성됩니다. |
| 1️⃣1️⃣ | git checkout main | main 브랜치로 다시 전환합니다. | 작업 디렉터리가 이제 main을 반영합니다. |
| 1️⃣2️⃣ | git merge feature-login | fast‑forward 병합을 수행합니다: main 포인터가 feature-login의 커밋들을 포함하도록 앞당겨집니다. | main에 로그인 기능이 포함되고, 원한다면 feature-login 브랜치를 삭제할 수 있습니다. |
Source: …
3‑WAY MERGE (Parallel Work) – Part 3
13️⃣ Profile 기능 만들기
git checkout -b feature-profile
echo "Profile page created" > profile.txt
git add profile.txt
git commit -m "Add profile feature"프로필 기능을 위한 격리된 개발 컨텍스트를 생성합니다.
14️⃣ Settings 기능 만들기
git checkout main
git checkout -b feature-settings
echo "Settings page created" > settings.txt
git add settings.txt
git commit -m "Add settings feature"이제 코드베이스가 분기되었습니다: 두 개의 독립적인 브랜치(feature‑profile와 feature‑settings)가 각각 별도의 커밋을 포함합니다.
15️⃣ Profile을 main에 병합
git checkout main
git merge feature-profile히스토리에 따라 fast‑forward 또는 일반 병합이 수행되어 프로필 작업이 통합됩니다.
16️⃣ Settings(3‑Way) 를 main에 병합
git checkout main
git merge feature-settingsmain에 이미 feature‑profile의 변경 사항이 포함되어 있기 때문에, Git은 두 히스토리를 조정하는 merge commit을 생성합니다.
Note: 병합 편집기(Vim 기본)가 열리면 커밋 메시지를 입력하고 Esc를 누른 뒤
:wq를 입력해 저장하고 종료합니다.
| 단계 | 명령 | 목적 | 결과 |
|---|---|---|---|
| 16️⃣ | git merge feature-settings | feature‑profile와 feature‑settings의 분기된 히스토리를 결합하는 병합 커밋을 생성합니다. | main에 두 기능이 모두 포함된 병합 커밋이 추가됩니다. |
MERGE CONFLICT – Part 4
17️⃣ Bug‑Fix Branch (updates README)
git checkout -b bugfix-title
echo "# Team Project Version 2" > README.md
git add README.md
git commit -m "Update title in bugfix"18️⃣ Feature Branch (also updates README)
git checkout main
git checkout -b feature-title-update
echo "# Awesome Team Project" > README.md
git add README.md
git commit -m "Update title in feature"19️⃣ Trigger Conflict
git checkout main
git merge bugfix-title
git merge feature-title-updateGit은 README.md에 대한 두 개의 서로 다른 변경을 자동으로 병합할 수 없으며 작업을 중단합니다.
20️⃣ Resolve Conflict
-
충돌이 발생한 파일을 Vim(또는 원하는 편집기)으로 엽니다:
vim README.md -
충돌 표시(
>>>>>>>,<<<<<<<,=======)를 제거하고 원하는 최종 내용을 유지합니다:# Awesome Team Project Version 2 -
저장하고 종료합니다(
:wq). -
해결된 파일을 스테이징하고 해결 커밋을 만듭니다:
git add README.md git commit -m "Resolve merge conflict"
| 단계 | 명령 | 목적 | 결과 |
|---|---|---|---|
| 20️⃣ | git add README.mdgit commit -m "Resolve merge conflict" | 수동 충돌 해결을 저장소 기록에 기록합니다. | 충돌이 해결되었습니다; main에 이제 병합된 README가 포함됩니다. |
스쿼시 머지 – 파트 5
21️⃣ 다수 커밋으로 기능 만들기 및 스쿼시하기
git checkout -b feature-dashboard| 커밋 | 명령 |
|---|---|
| Add dashboard layout | bash\n echo "Dashboard layout" > dashboard.txt\n git add dashboard.txt\n git commit -m "Add dashboard layout"\n |
| Add charts | bash\n echo "Add charts" >> dashboard.txt\n git add dashboard.txt\n git commit -m "Add charts"\n |
| Fix alignment | bash\n echo "Fix alignment" >> dashboard.txt\n git add dashboard.txt\n git commit -m "Fix alignment"\n |
이제 세 개의 커밋을 하나의 깔끔한 커밋으로 스쿼시한 뒤 main에 병합합니다:
# 현재 피처 브랜치에 있는지 확인
git checkout feature-dashboard
# 마지막 세 커밋을 스쿼시하기 위한 인터랙티브 리베이스
git rebase -i HEAD~3열린 편집기에서:
- 두 번째와 세 번째 줄의 pick을 s(또는 squash)로 바꿉니다.
- 저장하고 종료합니다 (
:wq).
Git이 세 개의 커밋을 하나로 합칩니다. 원한다면 최종 커밋 메시지를 편집하고, 다시 저장하고 종료합니다.
스쿼시된 기능을 main에 다시 병합하기
git checkout main
git merge --no-ff feature-dashboard # fast‑forward가 가능해도 병합 커밋을 생성합니다요약
| 개념 | 일반적인 명령 | 사용 시점 |
|---|---|---|
| 브랜치 생성 | git checkout -b <branch> | 격리된 작업을 시작할 때 |
| Fast‑forward 병합 | git merge <branch> (히스토리가 분기되지 않았을 때) | 단순한 선형 통합 |
| 3‑way 병합 | git merge <branch> (히스토리가 분기되었을 때) | 병렬 작업을 결합할 때 |
| 충돌 해결 | 충돌 파일 편집 → git add <file> → git commit | Git이 자동으로 병합하지 못할 때 |
| 커밋 스쿼시 | git rebase -i HEAD~N → squash | 병합 전 잡다한 히스토리를 정리하고 싶을 때 |
| 원격에 푸시 | git push origin <branch> | GitHub, GitLab 등 원격 저장소에 작업을 공유할 때 |
이제 브랜치를 만들고, (fast‑forward, 3‑way, 스쿼시) 병합을 수행하며, 충돌을 처리하고, 프로젝트를 원격 저장소에 푸시하기 위한 전체 단계별 가이드를 갖추었습니다. 즐거운 코딩 되세요!
22. 히스토리 보기
git log --oneline --graph --all이 명령은 수행된 병합 유형을 시각적으로 검사하고 검증하여, 결과 커밋 히스토리가 의도된 통합 전략과 일치하도록 합니다.
GitHub에 푸시 – 파트 6
23. GitHub에 저장소 만들기
원격 저장소는 푸시 작업을 수행하기 전에 생성되고 접근 가능해야 합니다. Git은 로컬 커밋을 받아 저장할 유효한 원격 엔드포인트가 필요하기 때문입니다.
Do NOT 체크: Add README, Add .gitignore
24. 로컬을 GitHub에 연결하기
git remote add origin https://github.com/YOUR_USERNAME/git-merge-lab.git이 명령은 원격 엔드포인트를 정의하여, 로컬 커밋과 브랜치를 전송할 대상 저장소를 Git에 알려줍니다.
25. 모든 브랜치 푸시
git push -u origin --all마무리 메모
브랜칭, 머징, 스쿼싱은 효율적인 Git 워크플로우의 핵심을 이룹니다.
- 브랜칭은 안전한 실험을 가능하게 합니다.
- 머징은 작업을 통합합니다.
- 스쿼싱은 히스토리를 읽기 쉽게 유지합니다.
각 기술을 언제, 어떻게 사용할지 숙달하면 엔지니어링 팀이 협업을 확장하면서도 안정적이고 유지보수 가능한 코드베이스를 유지할 수 있습니다. 자동화, 빠른 릴리즈, 분산 팀이 일반적인 현대 DevOps 환경에서는 이러한 실천이 고품질 소프트웨어 전달의 기반이 됩니다.