[GIT] Git flow / Rebase / Upstream

 

 

 

 

---

 

 

 

 

Git flow

 

 

 

 

 

 

🔻 main과 개인 브랜치 사이에 중간 브랜치를 생성한다.

? 아직 확인이 제대로 되지않은 feature branch를 세상밖에 바로 내보낼 수 없기 때문에,

   개발자들끼리 merge하여 기능을 테스트하고 확인하는 branch를 생성한다.

 

 

 

 ✔️  main > develop > feature

 

main branch

  : main은 실제로 상품 단계에서 구동되고 있는 단계의 코드들이 모여있다. (production release에 사용되는 branch)

develop branch

  : 다음 release에 포함되기 위해 생성된 feature branch 코드가 병합되는 브랜치이다.

feature brnach

  : 새로 생성하는 기능을 개발할 때 사용되는 브랜치이다.

 

 

 

 

 

 

✔️ main으로 병합하기전에 크게 2단계를 거친다.

    develop 머지된 기능들이 안정화 되있는 코드라고 판단되면 release branch를 생성한다.

 

 

 

Release 

버그를 찾고, 버그를 고치는 branch

develop 에서는 계속해서 다른 기능들이 merge되고 있다. 

 fix는 release branch에서만 이루어진다. 

 버그가 다 고쳐지면 해당 release branch가 main에 병합된다.

 

 

 

Hotfix

: production release 이후에 발견된 오류 사항을 신속하게 수정

  오류 발생 시 main에서 바로 hotfix branch를 생성하고, 병합도 바로 main으로 한다.

 

 

 

전체적인 흐름

 

 

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Gitflow Workflow | Atlassian Git Tutorial

 

 

 

 

 

 

---

 

 

 

 

 

 

Merge / Rebase

 

 

 

 

📌   git merge는 commit을 옮겨오는 동작 방식이다.

      commit의 head가 같다는 가정하에, 시간을 기준으로 commit이 옮겨진다.

 

feature/signup 에서 main으로 merge

main에서 feature/sign-in으로 merge

 

1. feature/signup (4개의 commit) 에서 main으로 merge

    (signup의 4개의 commit이 main으로 병합되었다. = 한 브랜치에 있는 commit을 다른브랜치로 가져간다.)

2. feature/sign-in의 연두색 commit 사이로 sign-up의 분홍색과 main의 검정 commit이 들어갔다.

 

 

> 문제

1. 복잡한 project history

    : 독립된 브랜치에서 로직하나 수정하더라도, merge이후에 다른 commit 내역과 겹쳐 구분하기 어렵다.

2.  불필요한 merge commit

    : 모든 feature branch마다 merge commit이 남으므로, 

     많은 개인 branch로 진행되는 작업이 main으로 모일 시 branch history가 지저분해진다.

 

 

 

 

 

 

Git rebase

re + base = commit의 base를 다시 재설정한다.

공통 base를 가진 두 브랜치에서 하나의 브랜치의 base를 다른 브랜치의 최신 commit으로 rebase하는 것이다.

 

 

 

 

Squash

여러개의 commit을 하나의 commit으로 합친다.

 

 

 

 

[Rebase과정]

 

1. develop 브랜치로 이동하여 git pull origin develop

2. push 할 작업 브랜치로 돌아온다.

3. `git rebase -i develop` 를 진행한다.

4. squash 창이 뜨면 가장 오래된 commit을 pick 한다.

5. 다른 커밋 메세지는 가장 오래된 commit을 기준으로 squash 한다.

6. Esc -> :wq! 로 창에서 빠져나온다.

7. 수정용 에디터가 하나 더 나타난다.

8. 불필요한 내용을 제거하고 현재 수정 내역에 대한 커밋 메세지를 정성껏 작성한다.

9. Esc -> :wq! 저장하고 에디터에서 빠져나온다.

10. 성공했다면 git log로 깔끔해진 커밋 메세지를 한 번 감상하고 푸쉬한다.

11. 만약 git이 history가 다른branch의 push를허용하지않는 상태라면 

        `git push origin feature/branchname  -f`

        -f 옵션을 사용하여 force push를 진행한다. 

 

 

 

 

 

 

---

 

 

 

 

 

 

Upstream / Downstream

 

 

 

 

[개념]

git remote add origin ...

init 햇을 때 origin을 직접 add하는데,  여기서 origindl github에 존재하는 repository 즉, remote를 의미한다.

remote = origin

 

upstream과 downstream은 상대적인 개념이다.

origin과 local기준으로 생각하면 origin이 up, local이 down이 된다.

git push -u origin main

여기서 -u 옵션이 --set-upstream의 줄임으로 upstream을 설정한다는 뜻이다.

upstream을 한번 설정하고 나면 다음부터는 git push 또는 git pull 명령어만 입력해도 자동으로 origin의 main 브랜치로부터 push와 pull이 실행된다. (up과 down의 관계가 설정되어서)

 

 

 

 

---

[설정]

 

fork한 repository clone

git remote add origin [fork한URL]

 

 

upstream repository 연결

git remote add upstream [URL]

//확인
git remote
>origin
>upstream

 

 

 

 

 

---

 

 

 

 

 

Forking Workflow

 

 

GitHub에서 오픈소스 프로젝트에 기여하거나, 협업을 진행할 때 fork를 이용하게 된다.

fork는 다른 사람의 repository를 내 소유의 repository로 복사하는 것이다.

원래 소유자의 remote가 upstream, 내가 fork한 remote가 origin이라는 용어를 사용하게된다.

 

 

 

 

[협업시 프로세스]

1. upstream : 원본 remote repository를 github에서 fork

2. origin : fork한 remote repository를 git client로 clone

3. origin에서 작업 [반복]

      1. clone한 repository (local)에 commit (branch)

      2. local(branch)에서 origin으로 push 

git push -u origin branchname

4. upstream에 반영

     - PR등록 전 upstream에서 바뀐내용 없는 경우

         : origin에서 upstream으로 PR

     - 바뀐내용 있을 경우

 

         1. upstream을 local로 pull

git pull upstream main

       

         2. local에서 origin으로 push

git push origin main

     

        3. origin에서 upstream으로 PR