Git/Github (3)

[ 브랜치 전략 ]

git flow

(hotfix) - master -(release) - develop - feature

주요 브랜치 두개(master, develop)를 사용하는 전략이다. 

가장 많이 적용하고 있고 각 단계과 명확하게 구분된다는 장점이 있지만 복잡할 수 있다는 단점이 있다.

develop 에서 각각 기능을 개발하고 릴리즈를 거쳐서 master 브랜치에 적용된다.

 

github flow

master - feature

git flow가 Github에서 사용하기에는 복잡하다고 해서 등장한 전략이다.

master 브랜치는 항상 최신 상태이고, 항상 배포가 가능한 상태이다.

 

브랜치 모델을 단순화 했다는 장점이 있지만 CI 의존성이 높다는 단점이 있다.

정기적인 릴리즈가 없지만 바로바로 업데이트가 되어야 할 때 주로 사용되는 전략이다.

제품군 보다는 주로 라이브러리에 많이 적용되고 있으며, pull request 기능을 사용하도록 권장하고 있다.

 

gitlab flow

production - pre-production - master - feature

Git flow는 너무 복잡하고 Github flow는 너무 단순하다 라는 요구사항에 나온 전략이다.

---

git-flow-cheatcheet

feature 브랜치를 생성하고 삭제하는 것을 자동화한 툴이다.

https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

git-flow cheatsheet

 

git-flow 설치

# brew 가 설치되어 있는 macOS 라고 가정
# git-flow 를 설치한다.
$ brew install git-flow-avh

# 깃 플로우 초기화
$ git flow init

만약 brew 가 설치되어 있지 않다는 텍스트가 출력된다면

git-flow 설치 명령을 실행하기 전에 미리 brew 를 설치해야 한다.

 

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
...

init 명령어를 실행하면 다음과 같은 내용이 출력된다.

엔터를 눌러 브랜치명을 그대로 설정한다.

브랜치 명은 컨벤션이 따로 없지만 보통 디폴트 값 그대로 사용한다.

 

feature 브랜치

# feature 브랜치 생성하고 해당 feature 브랜치로 이동하기
$ git flow feature start [feature 브랜치명]

# feature 브랜치의 수정사항(commit) 끝내기
# develop 브랜치로 병합되고 feature 브랜치가 자동으로 삭제된다
$ git flow feature finish [feature 브랜치명]

작업이 끝난 브랜치는 삭제하는 것이 좋다.

현재 사용중인 브랜치가 아니라면 항상 정리가 되어 있어야 한다.

또한 브랜치의 이름은 브랜치의 의도를 명확히 전달할 수 있도록 작성해야 나중에 헷갈리지 않는다.

(html-init, style-init, js-init 등)

 

release 브랜치

# release 브랜치 생성하고 해당 release 브랜치로 이동하기
$ git flow release start [release 브랜치 명]

 

 

 

 

# 현재 로컬의 develop 브랜치를 origin develop 에 푸시한다
# -u : 이름만 같은게 아니라 논리적으로 같다는 옵션
$ git push -u origin develop

# main 브랜치로 이동
$ git switch main

# 현재 로컬의 main 브랜치를 origin main 브랜치에 푸시
$ git push origin main

# 버전 태그 확인
$ git tag
v0.1

# 버전 태그 push
$ git push --tags
* [new tag]         v0.1 -> v0.1

깃허브 사이트에서 해당 프로젝트의 오른쪽에 있는 릴리즈 버전을 클릭한다.

릴리즈를 생성하고 메시지를 작성한다.

 

v0.x 는 정식 버전의 이전 버전, v1.x는 정식 버전을 의미한다.

v0.x 이기 때문에 This is a pre-release 에 체크한다.

 

[ tree ]

# 디렉토리의 구조를 트리 형태로 보여주는 명령어 설치
$ brew install tree

---

Revert

이름 변경하기

# 안좋은 방법
# 기존의 파일을 삭제하고 새로 생성된 것으로 인식됨
$ mv server.py main.py

# 좋은 방법
# 이름을 바꾼 것으로 인식됨
# 파일의 history 를 남기기 위해서는 삭제 후 생성이 아닌 이름바꾸기로 추적하기
$ git mv server.py main.py

 

변경사항 되돌리기

# 변경사항 되돌리기 (change 상태에서 변경사항 없는 상태로 변경)
$ git restore [파일명]

# 스테이지에 올린 변경사항 되돌리기 (add 상태에서 change 상태로 변경)
$ git restore --staged [파일명]

--------------------------------------------------------

# 변경사항 되돌리기 (옛날버전)
$ git checkout -- .
# 또는
$ git checkout -- [파일명]

# 스테이지에 올린 변경사항 되돌리기 (옛날버전)
$ git reset HEAD [파일명]

 

직전에 작성한 커밋 메시지 수정하기

$ git commit --amend

 

커밋 되돌리기

# 안좋은 방법 : Reset

# 직전 3개의 commit 을 삭제한 후, remote 에 강제로 push 한다.

$ git reset --hard HEAD~3
$ git push -f origin [브랜치명]

협업할 때 다른 Clone Repository 에 존재하던 Commit log 로 인해서 파일이 다시 만들어지거나

과거의 히스토리가 완전히 사라져서 Commit log 추적이 힘들어진다.

 

잘못한 이력도 commit 으로 기록하고 수정한 이력을 남기는 것이 좋다.

 

# 좋은 방법 : Revert

# 현재 HEAD 에서 직전의 3개의 commit 을 순서대로 거슬러 올라가 
# 해당 내역에 대해서 commit, push 를 수행한다.

$ git revert --no-commit HEAD~3..
$ git commit
$ git push origin [브랜치명]

과거로 돌아가 최신 버전을 유지하면서

되돌렸다는 히스토리를 커밋으로 남김으로써

모든 팀원이 해당 사항을 공유할 수 있다.

 

revert 명령 후에 commit 을 하게 되면 커밋 메시지에 Revert 가 함께 작성된다.

 

$ git revert -m [1 or 2] [merge commit id]

커밋을 따로 안할 때는 —no-edit 플래그를 사용하고,

merge 커밋을 되돌릴 때에는 -m 옵션을 사용한다.

---

협업

# 리모트 추가
$ git remote add updateram [프로젝트]

# 리모트 보기
$ git remote -v

# 해당 리모트의 브랜치를 땡겨오기
$ git pull [리모트명] [브랜치명]