Git Basic 2

 Branch와 Rebase에 관한 기능이 헷갈려 다시 정리해보았다. 일반적으로 rebase보단 branch를 여러 개 만들어 개발하고, Pull request, merge 하는 것이 이상적이다.

Git Branch
특정 커밋의 해시를 바탕으로 브랜치를 만들어 새 버전을 관리하는 것. 일반적으로 가장 최신 커밋에서 브랜치를 생성하는 것이 편하다. (선형적이어야 관리 용이) 그리고 이름은 항상 소문자로 시작.
이렇게 만든 브랜치를 로컬에서 작업하고, git push를 사용하여 원격 저장소에 브랜치를 추가할 수 있다.
 

보통은 로컬에서 개발하고, 가장 최신 커밋을 원격에 같은 이름의 브랜치에 푸시 하는 식으로 작업하게 된다.
그리고 마지막으로 이렇게 만든 새 브랜치(버전)을 원격 저장소에서 메인 브랜치로 merge 하는 것(pull request)이 일반적인 작업의 흐름이다.
로컬의 커밋이나 브랜치는 정리를 하고, main만 남겨두어 원격 저장소에서 머지를 완료한 메인 브랜치를 git pull 하여 버전을 맞추는 것이 하나의 작업 사이클의 종료 과정이다.


rebase는 일반적으로 잘 안쓰는 게 더 좋고 merge만 사용하는 것이 좋다. 왜냐하면 리베이스 과정은 메인에서 공통 조상(분기점)을 잡고 메인의 뒤에 브랜치 이력을 이어 붙이는 것이기 때문에 충돌 발생이 많다. 로컬에서 커밋 이력 정리 및 선형 관리가 용이해서 사용하는 경우도 있다. (사용하는 것 비추천, 시험 안나옴)
머지는 이와 달리 두 브랜치를 병합하여 최신 병합 커밋이 새로 발생한다. 이 새로운 커밋은 해시 값을 새로 가진다.


Git Pull
pull = fetch (origin의 커밋 이력을 모두 가져옴) + merge
가져올 때는 항상 최신 커밋을 선택. (선형) 이전 것을 선택하면 복잡해지므로 안하는 것이 좋다.

* 커밋 히스토리를 바꾸는 것은 좋지 않다. 그리고 충돌을 피하기 위한 가장 기본적인 부분은 바로 한 파일을 여러명이 건드리지 않게 하는 것이다.
메인에 모든 클래스를 만들어 놓고, 각 클래스를 구현하는 데 브랜치를 만들어 분리하여 작업한다. 이 때 각 브랜치를 다 만들고 메인에서 다시 합칠 때 연관되어 있는 부분에 대해 충돌이 날 확률이 크기 때문에 합칠 때 많은 토의가 필요하다. 그리고 각 브랜치에서도 팀 내에 역할 분담을 통해 브랜치를 추가할 수도 있다. (단, 이런 작업은 local을 파서 하므로 원격 저장소에서 관리하지는 않는다)

커밋을 많이 쌓아서 PR 하는 것은 좋지 않다. 서로 검토할 수 있는 정도의 커밋 개수로 끊어서 풀 하는 것이 좋다. 따라서 중간 중간 git pull request를 통해 커밋 이력을 관리해주는 것이 좋다.


Git submodule
하나의 git 저장소 안에 다른 git 저장소를 포함시키는 기능. 외부 라이브러리, 컴포넌트 등 의존성 관리를 하고 큰 프로젝트를 나눌 때 사용한다. 독립성, 버전 관리, 독립적인 개발/업데이트의 장점이 있다.

일반적으로 외부 라이브러리의 특정 버전을 프로젝트에 연결하여 원본 라이브러리의 업데이트에 상관없이 안정성을 유지하는데 사용한다. 예를 들어 어떤 AI 모델을 지속적으로 개발/업데이트 하는 저장소와, 개발 시연 모델을 만들기 위한 또다른 저장소가 있을 때, 시연에 사용될 특정 버전의 모델을 불러오는 상황에서 사용한다. (버전과 이력, 실제 사용과 개발이 독립적으로 실현될 때, 원본을 건드리지 않고 불러올 때 사용)

git add, init, update 등으로 기존 저장소에 서브 모듈로 다른 저장소를 추가할 수 있다.
오픈소스 깃헙에 Opensource에 computervision 폴더가 바로 서브모듈로 포함된 것.
단, fetch를 해오면 원본이 업데이트 되었을 때 새로운 버전으로 checkout 할 수도 있다. 물론 이전 버전을 가리키도록 checkout 할 수도 있다.


.git & Unit Testing
.git : 로컬에 저장된 숨김파일. log, hook, info 등의 폴더에 커밋 이력 등의 정보가 모두 들어있다.

- git snapshot : 특정 시점에서의 파일/프로젝트의 상태. 커밋할 때마다 그 시점의 모든 파일에 대한 스냅샷을 취하여 저장소에 저장된다. 단, git은 변경사항을 저장하는 것은 아니라 파일의 변경점만 새로 저장하고, 변경되지 않은 부분은 이전 스냅샷을 참조하는 식으로 작동한다.

- hooks : .git 내부의 폴더. unit testing에 사용됨.
커밋과 푸시를 하기 전에 해당 코드가 만들 수 있는 버그를 미연에 방지하려면 아예 추가되지 않도록 하는 것이 좋다.
hooks의 파일에 .sample을 지우면 각 이름에 알맞은 기능을 하기 전에 짠 코드를 유닛 테스팅 할 수 있다. 해당 파일에 원하는 성능, 조건 등을 스크립트로 만들어 놓으면 각 작업을 하기 전에 검사를 하여 적절하지 않으면 해당 작업이 실행되지 않게 만들 수 있다.