Github 2 - release + Git flow

github

동기화

• 집에서 일을 끝마치고 git push
• 회사에 출근해서 git pull와 같은 매커니즘.

https vs SSH

• 통신 방식인데, SSH는 자동 로그인을 지원한다.
• Github - Personal Settings - SSH and GPG keys
• 로 들어가면 SSH Key를 등록해놓을 수 있다.

Local repo vs Remote repo

• refs/heads/master (master)
• refs/remotes/heads/master (origin/master)
• master 브런치와 origin/master 브런치를 연동(-u) 후 push하면 두개의 브런치는 동기화가 된다.

git fetch vs get pull

• fetch
  refs/remotes/heads/master (origin/master) 동기화
  후 refs/heads/master (master)에서 merge를 수행하지 않음(동기화 x)
  • 쉽게 이해하자면 "다운로드만 받아 놓는다"이다.
  • 왜 쓰는가? : (지역 저장소)master와 (원격 저장소)origin/master와의 diff(코드 차이점)을 알아낼 수 있다.
    • 차이점 비교 후 문제가 없다면
    • master : git merge origin/master 수행
• pull
  refs/remotes/heads/master (origin/master) 동기화
  후 refs/heads/master (master)에서 merge 수행
  • 웬만하면 pull을 사용하면 된다.

tag

• releases란?
  
  사용자들에게 제공될 수 있는 의미 있는 버전들을 'releases'로 모아놓는다. '릴리즈 버전' 이다.
• 특정 커밋을 릴리즈할 때(릴리즈 버전으로 만들 때)
  git tag 1.0.0 master(최신 버전에 1.0.0 태그 설정)
  git tag 1.0.0 y7am8ma73465ery9865ayrgawr6(해당 버전에 1.0.0 태그 설정)
• 위의 태그는 'light weight tag'였고, 추가 정보를 달아서 좀 더 자세한 태그를 달고 싶을 땐 'annotated tag'를 사용한다.
  annotation : 주석
  git tag -a 1.1.0 -m "bug fix"
• 단순 git push로 tag 정보까지 push되지 않는다.
  git push --tags 를 해야 한다.
  이후 git hub에서 확인해보면 releases가 업데이트된 것을 알 수 있다.
• 태그를 삭제하는 방법
  git tag -d 1.1.0
• branch vs tag
  branch와 tag가 commit_id를 가리키고 있다는 원리는 동일하다. 가리키는 대상이 다를 뿐이다.
  tag는 특정 commit_id를 가리킨다.
  branch는 checkout한 브랜치의 commit_id 를 가리킨다.

rebase vs merge
merge가 되는 것은 동일하나, merge는 병렬 상태로 commit을 두고, rebase는 병렬을 직렬로 바꾼다.
o < 8 = 8 상태에서
merge o < 8 = 8 > m
rebase o - o - o - o - r
아는 커밋들에 대해서만 rebase를 사용할 것

Git Flow

• master : 가장 기본 브런치(실제 배포된 버전)
• develop : 실질적 개발 필드 브런치
• feature : 별도의 기능 개발 필드 브런치
  feature-login, feature-uploadimage 등
  "develop에서 feature-login 머지" 후 feature-login 삭제
• release : 배포 수준에서의 개발 필드 브런치
  수정 사항들을 모두 수정 후(릴리즈 브런치에서 작업) 배포 직전, master 와 develop 브런치에 머지 후 배포, 이 때 master에서는 해당 릴리즈 버전에 대한 태그 작성
• hotfixes : 긴급 수정 사항

브런치를 새로 만들기 전 pull하여 코드 차이가 나는지 확인해봐야 한다.