[Git] Git과 GitHub를 활용한 협업

 

프로젝트를 개발하다 보면 코드를 계속 수정하고 새로운 기능을 추가하게 됩니다.

처음에는 파일을 복사해서 백업하는 방식으로도 충분하다고 생각할 수 있지만,

프로젝트 규모가 커지거나 여러 명이 함께 개발하게 되면 어떤 파일이 수정되었는지, 언제 변경되었는지 관리하기가 매우 어려워집니다.

 

이러한 문제를 해결하기 위해 사용하는 것이 Git과 GitHub입니다.

 

Git은 프로젝트의 변경 이력을 관리하는 버전 관리 시스템으로,

개발 과정에서 발생하는 모든 변경 사항을 기록해 줍니다.

덕분에 문제가 발생하더라도 이전 버전으로 쉽게 되돌릴 수 있으며, 어떤 사람이 어떤 코드를 수정했는지도 확인할 수 있습니다.

 

반면 GitHub는 Git으로 관리하는 프로젝트를 인터넷에 저장하고

여러 개발자가 함께 협업할 수 있도록 도와주는 플랫폼입니다.

 

쉽게, Git이 로컬에서 버전을 관리하는 도구라면, GitHub는 그 저장소를 공유하고 협업을 지원하는 공간이라고 이해하면 됩니다.

Repository, Commit 그리고 Branch

Git을 사용하기 위해서는 먼저 몇 가지 개념을 이해해야 합니다.

 

먼저 Repository(레포지토리) 는 프로젝트 전체를 저장하는 공간입니다.

단순히 소스 코드만 저장하는 것이 아니라 지금까지의 모든 변경 이력도 함께 저장됩니다.

내 컴퓨터에 있는 저장소를 Local Repository, GitHub에 올라간 저장소를 Remote Repository라고 합니다.

 

프로젝트를 수정했다면 그 변경 내용을 기록해야 하는데, 이때 사용하는 것이 Commit입니다.

Commit은 현재까지의 작업 내용을 하나의 버전으로 저장하는 과정입니다.

 

이때 함께 작성하는 커밋 메시지는 어떤 작업을 수행했는지를 설명해 주기 때문에,

나중에 프로젝트를 관리하거나 협업할 때 매우 중요한 역할을 합니다.

 

하지만 여러 기능을 동시에 개발해야 하는 경우도 있는데,

기존 코드를 건드리지 않으면서 새로운 기능을 개발하기 위해 사용하는 것이 바로 Branch입니다.

브랜치를 이용하면 독립된 작업 공간에서 원하는 기능을 개발할 수 있고,

작업이 완료되면 다시 메인 프로젝트에 병합하여 적용할 수 있습니다.

 

즉, Repository가 프로젝트를 관리하는 공간이라면,

Commit은 작업 내용을 기록하는 단위이고,

Branch는 여러 작업을 안전하게 나누어 진행하기 위한 공간이라고 이해할 수 있습니다.

Git에서 자주 사용하는 기본 명령어

Git의 개념을 이해했다면 이제 실제로 프로젝트를 관리하는 방법을 알아야겠죠?

 

가장 먼저 Git을 사용할 사용자 정보를 등록하기 위해 git config 명령어를 사용합니다.

git config --global user.name "이름"
git config --global user.email "이메일"

 

이후 작업할 폴더에서 git init을 실행하면 해당 폴더가 Git 프로젝트로 초기화됩니다.

git init

 

프로젝트를 수정한 뒤에는 현재 어떤 파일이 변경되었는지 git status를 통해 확인할 수 있습니다.

git status

 

수정한 파일을  저장할때는, 먼저 커밋할 파일을 선택하기 위해 git add를 사용하여 Staging Area에 올립니다.

git add .

 

이후 git commit을 통해 하나의 버전으로 저장합니다.

git commit -m "회원가입 기능 구현"

 

이렇게 생성된 커밋은 아직 내 컴퓨터에만 존재하는데요.

다른 사람들과 공유하려면 git push를 이용해서 GitHub에 업로드해야 합니다.

git push

 

반대로 다른 개발자가 작업한 최신 내용을 가져오고 싶다면 git pull을 사용하면 됩니다.

git pull

 

이처럼 Git은 수정 → 확인 → 등록 → 커밋 → 공유라는 흐름으로 작업이 진행된다고 할 수 있습니다.

 

브랜치를 활용한 협업

실제 프로젝트에서는 대부분 하나의 브랜치에서만 작업하지 않습니다.

예를 들어, 새로운 로그인 기능을 개발하는 동안 다른 개발자는 게시판 기능을 개발할 수도 있습니다.

이때 모두가 같은 브랜치에서 작업한다면 서로의 코드가 충돌할 가능성이 매우 높아지겠죠.

 

그래서 프로젝트에서는 브랜치를 역할에 따라 나누어 관리합니다.

• main : 실제 서비스에 배포되는 안정적인 코드
• develop(dev) : 여러 기능을 모아 테스트하는 브랜치
• feature/* : 새로운 기능을 개발하는 브랜치
• hotfix/* : 서비스 운영 중 발생한 긴급 오류를 수정하는 브랜치

브랜치를 생성하거나 이동할 때는 다음과 같은 명령어를 사용합니다.

# 브랜치 생성 후 바로 이동
git checkout -b feature/login

# 이미 생성된 브랜치로 이동
git checkout feature/login

 

즉, 브랜치를 활용하면 여러 개발자가 동시에 작업하더라도 서로의 코드에 영향을 주지 않고 독립적으로 개발할 수 있습니다.

브랜치를 병합하는 과정

기능 개발이 끝났다면 작업한 브랜치를 다시 메인 프로젝트에 합쳐야 하는데,

이를 Merge라고 합니다.

 

Merge 방식에는 크게 두 가지가 있습니다.

먼저 Fast-forward Merge는 브랜치가 한 방향으로만 진행되었을 때 사용하는 방식입니다.

새로운 병합 커밋을 생성하지 않고 브랜치 포인터만 앞으로 이동하기 때문에 비교적 간단하게 병합됩니다.

 

반면 3-way Merge는 서로 다른 브랜치에서 각각 작업이 진행된 경우 사용됩니다.

공통 부모 커밋을 기준으로 변경 내용을 비교한 뒤 새로운 Merge Commit을 생성하여 병합하게 됩니다.

 

하지만 두 사람이 같은 파일의 같은 부분을 서로 다르게 수정했다면 Git이 어느 내용을 선택해야 할지 판단할 수 없습니다.

 

이러한 상황을 Merge Conflict라고 하고

개발자가 직접 충돌 내용을 확인하고 수정한 뒤 다시 커밋하여 병합을 완료해야 합니다.

 

따라서 협업에서는 자주 Pull을 받고, 기능별 브랜치를 사용하고, 작은 단위로 자주 Merge하는 습관이 매우 중요합니다.

느낀 점

이번 Git 학습을 통해, 지금까지 팀 프로젝트에서 Git을 자주 사용했음에도,

그동안은 명령어를 사용하는 데에만 익숙했고

Git이 내부적으로 어떻게 동작하는지에 대해서는 깊이 생각해 본 적이 없다는 것을 느꼈습니다.

 

특히 Merge 방식(Fast-forward Merge와 3-way Merge) 에 대해서는 이번에 처음 자세히 알게 되었습니다.

이전에는 브랜치를 병합하면서도 단순히 merge 명령어만 사용했을 뿐,

어떤 상황에서 Fast-forward Merge가 이루어지고

언제 새로운 Merge Commit이 생성되는지 이해하지 못한 채 사용하고 있었습니다.

 

앞으로는 Git을 단순한 버전 관리 도구로 사용하는 것이 아닌,

Merge 방식과 브랜치 전략까지 고려하며 효율적으로 협업할 수 있도록 활용해 보고 싶습니다.