git flow 운영방식 정리

설정 etc

git flow 운영방식 정리

까마귀코딩 2023. 1. 10. 14:41

운영 방식

git-flow는 총 5가지의 브랜치를 사용하여 운영한다.

- main : 제품으로 출시될 수 있는 브랜치

- dev : 다음 출시 버전을 개발하는 브랜치

- feature : 기능을 개발하는 브랜치

- release : 이번 출시 버전을 준비하는 브랜치

- hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

깃 플로우 뭔지 알아보면 꼭 나오는 진짜 뭐라는지 모르겠는 그림

그래서 하나씩 찢어 정리해보았다 !

두 브랜치는 항시 운영되어야 하는 브랜치 인데,

main브랜치는 제품으로 출시될수 있는 브랜치 이기 때문에 항시배포가능상태

즉,

ready상태 여야 한다.

dev는 개발을 위한 브랜치 이며 이또한 항시 운영되어야 하는 브랜치이다.

feature 브랜치는 어떤 개발 브랜치일까??

단위기능을 개발하는 브랜치 이다.

만약 기능개발 작업을 하다가 완료되면?

dev 브랜치와 합친다.

== dev 브랜치에 merge 되는것이다.

dev 브랜치는 모든 팀원이 공유하는 브랜치이고,

feature 브랜치는 각자가 맡아서 작성한 코드들이 들어있는 브랜치 이다.

그렇기 때문에 merge 작업전에 팀원들간의 지속적인 코드리뷰가 필요하겠다 !!

Pull Request 를 사용하여 merge 작업전 리뷰어들에게 코드리뷰를 받고 반영사항을 수정하여

commit후에 merge 한다.

이부분이 협업에서 가장 중요한 부분이다 !

realese 브랜치는 또 뭘까??

--> 배포전에 충분한 검증을 위해 생성하는 브랜치이다.

배포가능한 상태가 되면 main 브랜치로 merge 작업을 거친다.

또한 dev 에도 반영사항을 모두 merge 시켜야 한다.

이제 정말 마지막인 hotfix 브랜치이다.

hotfix 브랜치는 색깔표기에서도 알수있듯이,

배포중에 버그가 생겨서 긴급수정해야 하는 브랜치이다.

배포 이후에 이뤄지는 브랜치이고,

반영사항을 main과 dev에 모두 적용시켜야 한다ㅏㅏㅏ

언급했듯이, main 과 dev는 항시 운영된다고 했지않는가?

이 둘을 제외한 나머지 브랜치들은 제역할이 마무리 되어 merge 작업이 완료되면 브랜치를 삭제해서 정리를 해준다.

적 용 해 보 기

1. organization에 생성한 repository 에 fork 를 해준다.

그러면 upstream remote repository 를 기반으로 원격 개인저장소에 fork 된다 !

2. 깃 클론으로 클론해온다.

git clone https://github.com/{개인 github 이름}/{repository 이름}.git

3. 클론받은 로컬 리포지토리를

git remote -v 로 확인해보자

그러면 원격 저장소가 등록되있음을 확인가능하다.

매번 최신의 코드를 pull받으려면 upstream 도 등록해줘야 한다.

$ git remote -v

origin  https://github.com/{github 사용자 이름}/{repository 이름}.git (fetch)
origin  https://github.com/{github 사용자 이름}/{repository 이름}.git (push)

4. git remote add upstream

하면 upstream 이 등록이 된다.

이제 작업할때마다 해주ㅓ야 할일이 있다 ==> 바로 브랜치를 생성하고 최신코드를 git pull받아오는 것이다.

$ git remote add upstream https://github.com/{organization 이름}/{repository 이름}.git

$ git remote -v

origin  https://github.com/{github 사용자 이름}/{repository 이름}.git (fetch)
origin  https://github.com/{github 사용자 이름}/{repository 이름}.git (push)
upstream        https://github.com/{organization 이름}/{repository 이름}.git
upstream        https://github.com/{organization 이름}/{repository 이름}.git

5. #이슈번호를 붙여서 github 의 issue에 등록한다

그리고 그 번호를 기반으로 브랜치를 생성시킬거다

6. 그 이슈번호를 기반으로 local repository 에서 feature 브랜치를 생성하자

$ git branch feature/{repository 이름}-18
$ git checkout feature/{repository 이름}-18

7. 이제 upstream 에 있는 remote repository에서 최신 소스코드를 받아오자

$ git fetch upstream
$ git rebase upstream/dev

8. git pull 사용해서 등록한 upstream dev 에서 commit 기록을 병합한다.

9. 이제 씐나게 작업을 진행하고 자신의 원격 저장소인 origin remote repository 에 git push 한다.

$ git push origin feature/healthner-18

그다음 리포지토리에 가보면 ????

pull request 보낼건지 탭이 나와있을것이다.

feature/{repository 이름}-18 브랜치를 dev에 merge하기 위한 pull request를 진행하는 예시이다.

작성한 코드를 리뷰해줄 팀원들을 선택하고,

commit한 코드의 내용을 간단히 요약해서 작성하자

이제 생성한 PR을 기반으로 코드리뷰를 진행한다. 변경 사항이 적용되면 dev에 반영하기 위해 merge한다.

여기서 pr은 풀리퀘스트이다.

추가 고민 사항

만약에 내가 최신것을 git pull 받아와서 작업을 하고 있었는데,

다른 팀원이 그 중간에 PULL REQUEST를 진행하였고,

dev가 최신화 다시 되어버리면????

내가 작업하고 있던 브랜치는 도대체 어떻게 해야되는걸까???

그림설명이다. 진짜 이런경우 짜증 제대로 날듯 싶다. .. ..... ... ^"^

분명 내 작업을 마친뒤에 merge 작업을 하게 되면

충돌 100%로 일어날께 뻔하다.

그러면 어떻게 해야되는것일까....ㅠㅠㅠㅠㅠㅠ?????

-- > local 에서 merge작업을 거치고 난 후에 계속 작업을 이어나가야 한다.

매번 팀원들의 pull request가 있을 때마다

자신이 작업하던 branch를 dev 코드를 최신화 시키기 위해서는 ?????

처음 브랜치를 생성했을 때와 마찬가지로 간단히 git 명령어를 작성하면 된다.

$ git fetch upstream
$ git rebase upstream/dev

각자 local repository에서 적절하게 충돌을 해결하여 최신 코드를 반영한다.

그 다음 -f를 사용하여 강제로 remote repository에 push 하여 그래프를 정리한다.

$ git push origin -f feature/{repository}-{issue 번호}

티스토리