Git 기초와 협업 워크플로우

소프트웨어 개발은 결국 코드 변경의 연속입니다.

기능이 추가되고, 버그가 수정되고, 구조가 계속 바뀝니다.

문제는 변경 자체가 아니라, 그 변경을 추적하지 못할 때 발생합니다.

누가 언제 무엇을 바꿨는지 흐름이 끊기면 협업 속도가 급격히 떨어집니다.

버전 관리 시스템(VCS)은 이런 변경 이력을 체계적으로 관리합니다.

그래서 팀이 안전하게 실험하고, 빠르게 복구하고, 안정적으로 배포할 수 있게 해줍니다.

• 변경 이력 추적: 모든 코드 변경 내용을 기록하고, 언제든 특정 시점의 코드로 되돌아갈 수 있습니다.
• 협업 용이: 여러 개발자가 동시에 같은 코드베이스를 안전하게 작업하고, 변경 내용을 병합(Merge)할 수 있습니다.
• 실험과 브랜칭: 새로운 기능을 개발하거나 실험적인 변경을 할 때, 기존 안정적인 코드에 영향을 주지 않고 독립적인 공간에서 작업할 수 있습니다.
• 문제 해결: 버그 발생 시, 어떤 코드 변경 때문에 문제가 발생했는지 쉽게 찾아내고 이전 버전으로 되돌릴 수 있습니다.

Git은 로컬에서도 커밋 이력을 기록하는 분산 버전 관리 시스템(DVCS)입니다. 로컬 커밋과 원격 공유를 따로 설명하면 연결이 없어도 할 수 있는 작업을 구별할 수 있습니다.

파일 내용 A
git add index.html
파일을 B로 다시 편집
commit 대상: A · 작업 파일: B

파일 내용 A
git add index.html
파일을 B로 다시 편집
commit 대상: A · 작업 파일: B

Git 기본 개념

Git 기초와 협업 워크플로우에서는 변경 관리, 도구 설정, 협업 확인 절차를 정리합니다.

Git을 사용하기 위해 알아야 할 핵심 개념들을 정리합니다.

• 저장소 (Repository, Repo)
  • 프로젝트의 모든 파일과 변경 이력이 저장되는 곳입니다. 로컬 저장소(내 컴퓨터)와 원격 저장소(GitHub, GitLab 등)로 나뉩니다.
• 커밋 (Commit)
  • 코드 변경 사항을 저장소에 기록하는 단위입니다. git commit 명령으로 생성되며, 각 커밋은 고유한 해시(Hash) 값을 가집니다.
  • 커밋 메시지는 어떤 변경이 있었는지 명확하게 설명해야 합니다.
• 브랜치 (Branch)
  • 커밋을 가리키는 이동 가능한 참조입니다. 새 브랜치는 폴더 전체를 복사하지 않으며, 체크아웃한 브랜치에 따라 작업 트리의 내용이 바뀝니다. main은 보통 주된 안정적 코드 라인입니다.
  • 여러 개발자가 각자 다른 브랜치에서 작업하며 main 브랜치에 영향을 주지 않습니다.
• 병합 (Merge)
  • 두 개 이상의 브랜치의 변경 내용을 하나로 합치는 작업입니다.
• HEAD
  • 보통 현재 브랜치 참조를 가리키며, detached HEAD에서는 특정 커밋을 직접 가리킵니다.
• 원격 저장소 (Remote Repository)
  • 인터넷에 있는 Git 저장소입니다. 여러 개발자가 코드를 공유하고 협업할 때 사용합니다. GitHub, GitLab, Bitbucket 등이 대표적인 원격 저장소 호스팅 서비스입니다.
• Pull (풀)
  • 원격 변경을 가져온 뒤 현재 브랜치에 통합하는 작업입니다. git fetch 후 설정·옵션에 따라 git merge 또는 git rebase를 수행합니다. 이 절의 실습은 병합 방식을 사용합니다.
• Push (푸시)
  • 로컬 저장소의 변경 내용을 원격 저장소로 올리는(업로드) 작업입니다.

처음에는 작업 파일, 다음 커밋에 담을 스테이징 영역(Index), 이미 만든 커밋을 나누어 생각합니다. 브랜치를 전환했다고 저장하지 않은 변경이 무조건 사라지거나 별도 폴더로 격리되는 것은 아닙니다. 전환이 거절되거나 변경을 유지할 수 있으므로 먼저 상태를 확인하고 어떤 커밋에 담을지 결정합니다.

index.html의 내용을 A로 편집하고 add한 뒤 작업 파일만 B로 바꿨다고 정합니다. add는 호출 당시의 A를 기록하므로 바로 commit하면 커밋은 A이고 작업 파일은 B입니다. 새 변경 B까지 담으려면 의도한 차이를 확인한 뒤 다시 add합니다. Git의 스테이징 설명은 같은 파일에 staged와 unstaged 변경이 함께 있는 경우를 보여 줍니다.

index.html은 B를 add한 뒤 C로 다시 편집했고, 새 login.js는 아직 add하지 않았습니다. 일반 git commit만 한다면 각 파일의 무엇이 기록되고 무엇이 작업 폴더에 남나요? 커밋 직후 아직 push하지 않았다면 원격 저장소가 바뀌었다고 말할 수 있나요?

Git 기본 명령어 (터미널 실습)

Git을 사용하려면 먼저 시스템에 Git이 설치되어 있어야 합니다.

아래 명령은 새 실습 폴더의 순서를 설명합니다. 현재 운영 저장소나 다른 작업자의 브랜치에서 그대로 실행하는 과제가 아닙니다. 예시의 사용자 이름·이메일·원격 주소는 자신의 실습 값으로 준비하고, GitHub에 만드는 대상 저장소는 이 초기 예제와 충돌하는 기존 이력이 없는 상태로 정합니다.

Git 공식 웹사이트에서 다운로드하여 설치할 수 있습니다.

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

cd my-web-project # 프로젝트 폴더로 이동
git init -b main  # 새 실습 저장소의 초기 브랜치를 main으로 지정

# index.html 파일 생성 (예시)
echo "<h1>Hello Git!</h1>" > index.html

git add index.html # 변경된 파일을 스테이징 영역에 추가
git status         # 현재 Git 저장소 상태 확인

git commit -m "feat: Add initial index.html page" # 스테이징 영역의 변경 내용을 커밋

git branch feature/login # feature/login 브랜치 생성
git checkout feature/login # feature/login 브랜치로 전환
# 또는 한 번에: git checkout -b feature/login

# login.js 파일 생성 (예시)
echo "console.log('Login logic here');" > login.js

git add login.js
git commit -m "feat: Implement basic login logic"

git checkout main # main 브랜치로 전환
git merge feature/login # feature/login 브랜치를 main에 병합
git branch -d feature/login # 병합된 feature/login 브랜치 삭제

git remote add origin https://github.com/your-username/your-repo-name.git # 원격 저장소 연결
git push -u origin main # main 브랜치를 원격 저장소로 푸시 (최초 1회 -u 사용)
# 이후부터는 git push 만 사용

git pull --no-rebase origin main # main 브랜치의 최신 내용을 가져와 병합

협업 워크플로우: Git Flow (간략)

Git을 이용한 협업에는 여러 가지 워크플로우(흐름)가 있습니다.

그중 가장 널리 알려진 Git Flow를 간략히 소개합니다.

Git Flow는 명확한 브랜치 전략을 통해 복잡한 프로젝트에서도 체계적인 버전 관리를 가능하게 합니다.

• main (또는 master) 브랜치
  • 프로덕션 배포 가능한 안정적인 버전을 관리합니다.
  • 이 브랜치에는 직접 커밋하지 않고, 다른 브랜치에서 병합(Merge)만 합니다.
• develop 브랜치
  • 다음 출시 버전을 위한 개발 브랜치입니다. 모든 기능 브랜치들은 develop에서 시작하여 develop으로 병합됩니다.
• feature 브랜치 (feature/기능_이름)
  • 새로운 기능 개발을 위한 브랜치입니다. develop 브랜치에서 분기하여 작업하고, 기능 개발이 완료되면 다시 develop 브랜치로 병합됩니다.
  • 여러 개발자가 동시에 여러 feature 브랜치에서 독립적으로 작업할 수 있습니다.
• release 브랜치 (release/버전_번호)
  • 새로운 버전 출시를 준비하기 위한 브랜치입니다. develop에서 분기하여 버그 수정, 최종 테스트 등을 수행합니다.
  • 준비가 완료되면 main과 develop 브랜치 모두에 병합됩니다.
• hotfix 브랜치 (hotfix/버그_이름)
  • main 브랜치(즉, 운영 중인 서비스)에서 발견된 긴급 버그를 수정하기 위한 브랜치입니다. main 브랜치에서 분기하여 작업하고, 수정이 완료되면 main과 develop 브랜치 모두에 병합됩니다.

아래 다이어그램은 브랜치 모델과 별개로, 변경을 검토·검증해 병합하고 복구 단위를 남기는 공통 작업 흐름입니다.

Git Flow의 release·hotfix 분리는 여러 출시 라인을 관리할 때 선택할 수 있습니다. 팀 크기만으로 적합성을 정하지 않고 출시 주기·유지할 버전·검증 비용을 함께 비교합니다.

소규모 팀에서는 main 브랜치와 feature 브랜치만 사용하는 단순한 워크플로우(GitHub Flow 등)를 사용하기도 합니다.

중요한 것은 팀원들이 공통된 워크플로우를 이해하고 따르는 것입니다.

이 절의 첫 터미널 예제는 main에서 feature를 만들고 main으로 직접 병합합니다. 뒤의 Git Flow 예제는 develop에서 기능을 만들고 develop으로 병합합니다. 같은 작업에 두 출발점·병합 대상을 섞지 말고 선택한 모델의 기준 브랜치를 먼저 확인하세요.

Git Flow에서 기능 브랜치는 develop에서 시작했습니다. 기능 리뷰를 통과한 뒤의 1차 병합 대상과, main에서 분기한 긴급 hotfix의 완료 후 두 병합 대상을 써 보세요. 검사가 실패한 PR을 병합한 뒤 태그만 남기는 것으로 검증을 대신할 수 있나요?

실제 협업에서는 명령어 순서보다 어떤 변경을 언제 공유하고 검증할지가 더 중요합니다.

앞의 브랜치 검토·병합 흐름은 개인 작업에서 Pull Request까지 이어지는 안전한 반복 루틴을 정리합니다.

Git 기초와 협업 정리

이번 정리에서는 커밋 품질과 브랜치 전략을 팀 협업 속도와 충돌 관리 관점에서 연결합니다.

이번 장에서는 현대 웹 개발의 필수 도구인 Git의 기초 개념과 효율적인 팀 협업을 위한 워크플로우에 대해 학습했습니다.

Git은 코드 변경 이력을 추적하고 관리하는 버전 관리 시스템입니다.

이 장에서는 저장소, 커밋, 브랜치, 병합, Pull/Push 개념과 로컬 저장소 초기화, 파일 추가, 커밋, 브랜치 생성과 병합 흐름을 실습했습니다.

마지막으로 Git Flow를 통해 협업 브랜치 전략의 기본 형태를 살펴보았습니다.

Git은 코드 변경 이력, 협업 흐름, 되돌림 기준을 관리하는 버전 관리 시스템입니다.

커밋 단위, 브랜치 전략, 충돌 해결 방식을 팀 규칙에 맞춰 유지해야 합니다.

Git 협업에서는 개인 커밋 루틴과 팀 검토 기준을 함께 통과해야 변경이 안전하게 합쳐집니다.

이 장의 두 흐름은 Git 기본 개념을 변경 기록, 검토·병합, 배포 전 확인 순서로 연결합니다.