Git
GIT의 개발 목표
- 빠른 속도
- 단순한 구조
- 비선형적인 개발(수천 개의 동시다발적인 브랜치)
- 완벽한 분산(DVCS)
- 대형 프로젝트에도 유용할 것
Inside of Git
Git은 기본적으로 파일시스템의 스냅샷을 저장한다.(커밋 당시의 GIT 디렉터리의 모든 파일 정보를 저장) 또한 파일 및 스냅샷을 해시하여 바뀐 버전인지 아닌지 빠르게 체크함
이후 스냅샷들의 크기가 커지면, 주기적으로 git gc(garbage collection)을 통해 delta를 만듦
gitignore
.gitignore 에서는 아래와 같은 glob 패턴을 따름
*.a : 확장자가 .a인 파일을 무시
!lib.a : lib.a 는 무시하지 않도록 함
/TODO : 현재 디렉토리에 있는 TODO 파일은 무시하고, subdir/TODO 처럼 하위 디렉터리에 있는 파일은 무시하지 않음
build/ : build/ 폴더에있는 모든 파일 무시
doc/*.txt : doc/notes.txt는 무시하고, doc/subdir/notes.txt는 무시하지 않음
doc/**/*.pdf : doc 디렉터리 아래의 모든 pdf 파일 무시
Github flow
사용법
main 브랜치는 언제든 배포가능한 상태로
- 가장 최신의 stable 상태로 배포되는 브랜치.
- 이 브랜치에 대해서는 엄격한 role를 주어 사용한다.
새로운 일을 시작하기 위해 브랜치는 main에서 딴다면, 어떤 일을 하는지 이름에 명확히 작성한다.
- 새로운 기능을 추가하거나 버그를 해결하기 위한 브런치의 이름은 자세하게 어떤 일을 하고 있는지에 대해 작성하여야한다.
- github 페이지에서 보면 어떤 일이 진행되고있는지 확실이 알수있도록
원격지 브런치로 수시로 push한다.
- 항상 자신히 하고 있는 일을 올려 다른 사람들도 확인할 수 있도록 해준다.
- 로컬에 문제가 생겨 작업하던 부분이 없어져도 원격지의 소스를 받아서 작업할 수 있도록 해준다.
피드백이 필요할때, 머지 준비가 완료되었을때는
pull request를 생성한다pull request는 코드 리뷰를 도와주는 시스템이다.- 그렇기에 이것을 이용하여 자신의 코드를 공유하고, 리뷰를 받을 수 있도록 한다. 머지 준비가 완료되어 main 브런치로 반영을 요구하여도 좋다.
기능에 대한 리뷰와 사인이 끝난 후 main으로 머지한다.
- 곧장 product로 반영이 될 기능이기에 충분한 논의 후 반영하도록 한다.
main으로 머지되고 푸시 되었을 때는 즉시 배포되어야한다.
- 자동화 기법등을 활용하여 즉시 배포한다.
장점
- 브런치 전략이 단순하다.
- github 사이트에서 제공하는 기능을 모두 사용하여 작업을 진행한다.
- 코드 리뷰를 자연스럽게 할 수 있다.
- CI가 필수적이며, 배포는 자동으로 진행할 수 있다.
단점
- CI와 배포 자동화가 되어있지 않은 시스템에서는 사람이 관련된 업무를 진행한다.
- 많은 것이 올라오면 작업에 부담이 된다.
출처
https://www.slideshare.net/ky200223/git-89251791
https://ujuc.github.io/2015/12/16/git-flow-github-flow-gitlab-flow/