Git의 기본, 버전 관리 및 협업 관리

Git의 기본

✅ Git 은 스냅샷 기반의 버전 관리 시스템이다.

쉽게 말해, 전체 파일 시스템을 기준으로 비교해 변경된 파일 시스템에 대한 변경 사항들을 저장한다.

변경 사항이 없는 파일은 기존의 파일을 재사용한다.

 

✅ 현재 커밋(파일 상태)에서 git이 추적 관리하고 있는 파일을 변경하면,

이 변경 사항들을 인식하고 있다가 git add 와 같은 명령어를 통해 변경 사항을 commit하기 위해서 추가 한다.

여기서 달라지는 변경사항들을 저장하고, 주석을 다는 것이 commit이고

이를 통해서 프로젝트의 전반적인 파일 관리를 진행한다.

이것이 git의 주요 역할 중 하나이다.

 

 

Git을 통한 협업에서 발생하는 Conflict

➡️ 여기서 A라는 원격 main branch에 대해 1이라는 사람이 feature1 branch에서 A를 B로 바꾼다면

B-A를 변경사항에 추가한 후 이를 저장하고 기록하는 과정이 commit이다.

이 B-A 를 저장하는 것이다. (실제로 변경된 데이터는 B로만 보이지만, 사실 A와 B-A를 저장한 것이다.)

 

➡️ 그리고 2라는 사람이 feature2 브랜치에서 A를 C로 바꿨으면 C-A를 저장한다.

 

만약 1이 main에 현재 B라는 상태를 push 했고,

이후에 2가 main에 C라는 상태를 push하려고 한다면,

2는 C-A라는 변경사항을 추가로 저장한 것인데 이전의 형태가 B가 된다.

이런 상황이 git에서 말하는 conflict 상황이다.

동시에 서로 다른 브랜치에서 같은 파일의 동일한 부분을 수정할 때 자주 발생한다.

 

 

Conflict를 해결하는 두 가지 방법, Merge와 Rebase

여기서 사용하는 방식이 3-way merge나 rebase merge와 같은 방식이 된다.

 

✅ 간단히 설명하면, 3-way merge는 A라는 분기에서 갈라진 B와 C를 병합하는 과정으로

이를 병합해 D라는 커밋을 만들어서 병합하는 과정이고, ( A ➡️ (B + C) ➡️ D )

✅ rebase merge는 B라는 커밋 위에 C라는 커밋을 쌓는 과정이다 ( A ➡️  B ➡️  C )

 

전자는 히스토리에 브랜치가 병합된 흔적이 남는다.

후자는 커밋 히스토리를 사실상 재구성 한 것이기에, 얼핏 보면 깔끔해 보이지만

C라는 사람이 기존에 진행했던 커밋들은 무시될 가능성이 있다.

 

이미지 출처 : https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EC%99%80-Merge-%EC%9D%98-%EA%B8%B0%EC%B4%88

 

 

Git을 통한 버전 관리

이를 통해 버전 관리와 파일 관리가 어떻게 이루어지는지 감이 올 것이다.

위의 설명에서

main branch에서의 파일 상태 A를 1.0.0 버전이라고 한다면

1.0.0을 feature1에서 업데이트한 파일 상태 B가 1.0.1이 되는 셈이고

1.0.0을 feature2에서 업데이트한 상태 C가 1.0.2가 되는데,

1.0.1과 1.0.2를 통합한 상태 D가 1.1.0 이라는 형태가 되는 것이다.

 

이러한 방식으로 서로 다른 개발자들이 새로운 버전에 대한 협업과 파일의 관리를 쉽게 할 수 있게 된다.

 

https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EC%99%80-Merge-%EC%9D%98-%EA%B8%B0%EC%B4%88

Git - 브랜치와 Merge 의 기초