GIt의 기본 개념 및 work flow

Git은 분산 버전 관리 시스템(DVCS)으로, 여러 개발자가 함께 작업할 때 코드와 파일의 변경 사항을 기록하고 관리하는 데 유용합니다. Git은 로컬에서 작업하는 구조와 브랜칭 기능으로 유명하며, 각 개발자가 전체 코드 이력을 자신의 컴퓨터에 클론해 두고 독립적으로 작업할 수 있습니다.

 

기본 개념과 기능을 Perforce와 비교하여 설명드리겠습니다.

1. 저장소(Repository)와 클론(Clone): Git에서는 각 개발자가 서버로부터 프로젝트의 전체 이력을 복사해 로컬 저장소를 만듭니다. Perforce에서 작업 공간을 설정하는 것과 유사하나, Git은 서버 없이도 로컬에서 모든 버전 관리 기능을 사용할 수 있다는 점이 차이입니다.
2. 브랜치(Branch): Git의 브랜치는 독립적인 작업 공간을 만드는 방식으로, 보통 Git의 강점으로 꼽힙니다. Git에서는 브랜치 생성이 매우 가볍고 빠릅니다. Perforce에서도 작업 영역을 나눌 수 있지만, Git은 특정 기능 개발이나 버그 수정 시 브랜치를 쉽게 만들어 독립적으로 작업할 수 있어 효율적입니다.
3. 커밋(Commit): Git의 커밋은 특정 시점의 변경 사항을 기록하는 기능입니다. Perforce의 체크인과 유사하나, Git은 커밋을 로컬 저장소에 저장하고 나중에 서버에 푸시(Push)할 수 있습니다. 즉, 로컬에서 커밋 작업을 여러 번 해둔 후, 한꺼번에 원격 저장소에 올리는 방식입니다.
4. 푸시(Push)와 풀(Pull): Git에서는 변경 사항을 서버로 푸시하고, 다른 개발자가 작업한 내용을 풀(Pull)하여 로컬에 반영합니다. Perforce의 경우 파일을 체크아웃하고 서버에 체크인해야 하지만, Git에서는 이와 별개로 로컬에서 커밋한 후 나중에 필요할 때 서버와 동기화할 수 있습니다.
5. 머지(Merge)와 충돌(Conflict): Git은 브랜치 기반이므로 여러 작업이 하나의 코드로 병합되는 경우가 많습니다. 이때 Git이 자동으로 병합해주지만, 충돌이 발생하면 사용자가 해결해야 합니다. Perforce에서 충돌 해결 시와 비슷하게 Git에서도 충돌 파일을 수동으로 수정하고 병합 커밋을 만들어 최종 반영합니다.
6. Git의 워크플로우: 일반적으로 Git은 다음과 같은 순서로 사용됩니다.
   • 로컬 저장소 클론(Clone)
   • 브랜치 생성 후 작업 수행
   • 커밋
   • 푸시(Push)를 통해 원격 저장소로 업로드
   • 풀 리퀘스트(Pull Request) 또는 머지(Merge Request)를 통해 변경 사항 병합

Perforce와는 다르게 Git은 분산형 구조여서 로컬과 원격 저장소가 명확히 나뉘며, 로컬에서 충분히 작업을 완료한 후 서버와 동기화하는 구조입니다.

 

질문 1) 프로그램에서 파일을 읽고 쓰는 기능을 추가하려고 합니다. 이 때 원래의 기본 main? 프로젝트라고 부르나요? 여기에서 브랜치를 새로 생성해서 작업 -> 커밋 -> 푸시를 한 다음에 브랜치를 삭제하나요?

 

네, Git에서는 기본 프로젝트를 메인 브랜치(main branch) 또는 메인(master) 라고 부릅니다. 일반적으로 이 메인 브랜치는 안정적인 버전의 코드가 유지되는 공간입니다. 새로운 기능을 개발하려고 할 때는, 메인 브랜치에서 새로운 **기능 브랜치(feature branch)**를 생성하여 작업하게 됩니다. 작업 흐름은 다음과 같습니다:

 

1. 브랜치 생성: 메인 브랜치에서 새로운 브랜치를 생성합니다. 예를 들어, 파일 읽기/쓰기 기능을 추가하는 경우 브랜치 이름을 feature/file-io와 같이 붙이는 것이 좋습니다.

 

git checkout -b feature/file-io

 

2. 작업 및 커밋: 생성한 브랜치에서 코드를 작성하고, 작업이 완료될 때마다 커밋합니다.

git add .
git commit -m "Add file read/write functionality"

 

3. push: 로컬에서 작업을 마친 후 원격 저장소로 브랜치를 푸시합니다.

git push origin feature/file-io

 

4. 풀 리퀘스트(Pull Request) 또는 병합(Merge): GitHub이나 GitLab 같은 플랫폼에서는 풀 리퀘스트를 열어 메인 브랜치에 병합 요청을 합니다. 메인 브랜치로 병합할 준비가 되면, 리뷰 후 승인 과정을 거쳐 병합합니다.

브랜치 삭제: 병합이 완료되면 작업 브랜치를 삭제하여 정리합니다. 로컬과 원격에서 삭제할 수 있습니다.

# 로컬 브랜치 삭제
git branch -d feature/file-io # 원격 브랜치 삭제 git push origin --delete feature/file-io

 

이렇게 하면 새로운 기능을 위한 코드가 메인 브랜치에 병합되고, 작업했던 브랜치도 깔끔하게 정리할 수 있습니다.

 

질문2) 원격 저장소로 'push'를 한다는건 이해했습니다. 그리고 "Pull request"라는 용어가 이해가 안되는데요. 이게 master에 변경사항을 반영을 요청하는건가요? 그 이후 리뷰를 통하여 완전히 승인되면 master에 반영이 되는건가요?

 

맞습니다! Pull Request(줄여서 PR)는 메인 브랜치(보통 main 또는 master)에 자신이 작업한 브랜치를 병합해 달라고 요청하는 것입니다. 이 과정을 통해 팀원들이 해당 변경 사항을 검토할 수 있는 기회를 제공합니다.

Pull Request의 단계는 다음과 같습니다:

1. 변경사항 제출: 작업을 완료한 후 해당 브랜치를 원격 저장소에 푸시하고, GitHub이나 GitLab과 같은 플랫폼에서 Pull Request를 엽니다. 이 Pull Request는 메인 브랜치로 병합하고 싶다고 알리는 신호입니다.
2. 리뷰: 팀원들은 PR을 검토하고, 코드 품질, 버그 가능성 등을 확인합니다. 만약 수정이 필요하다면, 리뷰어가 피드백을 남기고, 작성자는 이를 반영하여 추가 커밋을 올릴 수 있습니다.
3. 승인과 병합(Merge): 리뷰어가 변경 사항을 승인하면, PR을 병합하여 메인 브랜치에 반영합니다. 이 병합은 PR 페이지에서 버튼을 눌러 간단하게 수행할 수 있습니다.
4. 브랜치 삭제: 병합이 완료되면 작업 브랜치를 삭제하여 깔끔하게 관리할 수 있습니다.

이와 같은 PR 절차는 팀 협업 시 코드 품질을 높이고, 중요한 변경 사항이 메인 코드에 무분별하게 반영되는 것을 방지하는 중요한 절차입니다.