git 정리

버전관리 시스템 왜필요한가.

• 잘못된 변경을 복구
• 특정 시점으로 버전을 돌릴수 있다.
• 소스코드의 변경사항을 추적할 수 있다.
• 누가 수정했는지 추적가능
• 여러사람이 수정한 변경을 효과적으로 동기화 할 수 있다.

version control system

• 과거 서브버전의 경우 브랜치가 중복머지가 되는 문제점이 존재, 머지 정보가 없었다.
• 종류를 보면
  • local VCS - RCS 라는 유닉스베이스 툴
  • centralized VCS - CVS, SVN
  • distributed VCS - GIT, 머큐리얼?

용어 정리

• change - 버전 컨트롤 하의 문서의 수정을 의미
• change list -
• brahch
• tag
• trunk - mainline, master 개발을 위한 베이스라인
• repository
• working copy - 틀정 시점의 로컬 카피
• checkout
• clone
• commit
• merge
• conflict, resolve

git

• 리눅스 토발즈 형이 개발 10년전

• bitkeeper(DVCS) 와 분쟁으로 개발시작함.

• 토발즈형이 기초를 잡아주고 다른형이 실개발 했다고 함.

• 데이터 무결성 파일 디렉토리등 모든것이 체크섬(SHA-1)으로 관리

• 저장 구조

  • working directory -> staging area -> .git directory

• 저장소 만들기

  • git repo
  • git init
  • touch README.md
  • git add README.md
  • git commit

HEAD의 개념

• 로컬 리포지토리가 어딜보고 있는지 포인터 개념

머지개념

• fast-forward
  • head만 옮겨가도 가능한 경우라고 보면됨
• none fast-forward
  • 두개의 브랜치가 다른길을 가고 있는 경우
• 3way-mege
  • 합치려는 포인트 2곳과 가장가까운 공통 조상을 참조

branch workflow

• long-running branch - master, develop 은 안정적, 지속적으로 유지
• topic branch - feature 등 짧은 브랜치 단위

rebase vs merge

• 정책적으로 rebase를 사용할지는 팀/그룹 논의 해야 함. 보통

• rebase - 말그대도 베이스를 변경하는것

• rebase 동작 및 사용이유

  • master, experiment 일때

  • git checkout experiment

  • git rebase master

  • 위와 같은 처리면 experiment 의 master 베이스 시작점을 바꾼다.

  • 브랜치가 많을때 머지로 처리시 커밋로그가 지져분하다.

  • 메인라인만이라도 1라인으로 히스토리를 남기고 싶을 때 rebase를 쓰는 편이다.

  • 가령 공개 깃헙 프로젝트에서 fork를 통한 merge 요청이 오거나 개발 대상자가 많을 경우 사용한다고 함.

설정

• git config -help
• 개발팀단위로 일부설정은 통일하자 (white space, indent 등등)
• gitignore.io 사이트를 활용해서 이그노어 파일 만들수 있음 (인텔리제이 생성시 문제가 가끔 있음)
• git LFS - 깃헙이 100메가가 한계라서 더쓰고 싶을 경우 쓰는 툴

기타

• fork한 repo는 관례대로 origin 으로 네이밍 지정
• fork 원본 repo는 upstream 으로 네이밍 지정
• git stash - 현재 상태를 임시 저장하는 기능
• git submodule - gradle 서브프로젝트와 비슷하고 submodule의 head를 관리

anti pattern

• 서버에서 직접 수정 커밋 하지말것
• 빌드와 배포를 분리하자. 빌드서버에서 빌드처리를 하고 배포하도록 분리 GIT서버도 과한 트래픽에 약하다?

sw 형상관리

• sw 생명주기 전반에 대한 관리
• 코드의 변경, 빌드, 테스트, 배포 까지의 포괄적인 관리

a successful git branching model

• git flow의 가장 기본이 되는 패턴 (구글 검색하면 나오는)
• 메인스트림을 두개로 가는 것 master, develop
• 마스터에는 검증되지 않는 코드는 넣지 않는다.
• 마스터로 머지될때 배포

supporting branches

• 마스터와 develop 외의 브랜치를 지칭

• feature 브랜치

  • develop 에서 시작해서 머지된다. -no-ff 로 fasr-forward 되지 않도록 한다.

• release 브랜치

  • 새로운 릴리즈를 준비할때 사용하는 브랜치, 테스트/QA 시에 진행
  • 릴리즈 준비가 끝나면 master, develop 에 merge되고 삭제된다.
  • 릴리즈 버전에 대한 태그를 생성한다.

• hotfix 브랜치

  • master 에서 생성하고 master, develop에 머지한다.
  • 단 release 가 있을 경우 release에 머지

git flow

- git 용 flow 플러그인으로 보며됨
- https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html
- 쓰면 편하다.

github-flow

- https://guides.github.com/introduction/flow/
- git-flow 를 더욱 단순화한 구조
- 메인스트림을 master 만 가지는 구조
- Pull request 로 협업 머지
- merge 되면 master는 바로 배포
- 단순한 브랜치 전략
- ci, 자동화 배포를 구성한 경우 적합

github

• 2008년 런칭
• 오픈소스 프로젝트 호스팅의 몰락(소스포지 등)으로 인한 인기?
• MS인수 발표

깃헙이 인기인 이유

• git 자체
• 웹UI 협업 기능들
• 공짜
• 오픈소스 개발 문화를 바꾼 Fork & Pull request
• 기업용 솔루션 제공

fork

• 리포지토리 통째로 복사 히스토리 전체가 복사되고 프로젝트와 연결됨
• 포크해서 코드를 수정한 후에 원래 저장소에 보내는 pull request 형태로 프로젝트에 기여

pull request

• 저장소의 브랜치의 내용을 승인 하며 머지 커밋하는 방식
• 변경된 내용을 승인 요청을 통해서 적용하는 기능
• 온라인으로 코드리뷰를 하는 좋은 도구중 하나

END