[8/16] merge, fetch, pull, pull request, branch, fast-foward, 3-way

1. 깃 브랜치 이름 규칙

 

메인 브랜치를 복사해가는 경우 (== 새로운 브랜치를 만드는 경우)

 

메인 브랜치는 진짜 사용자들이 사용하고 있는 버전의 브랜치

-> 즉, 현재 사용자들이 사용하고 있는 버전이 1.2 라고 했을 때 1.2 버전이 바로 메인 브랜치의 코드

 

1. 기능 개발

기능 개발을 위해 브랜치를 만드는 경우 예시와 같은 규칙을 가지고 이름을 만드는데, 정확한 규칙은 내가 속해 있는 팀의 규칙에 따라 지으며 된다.

 

ex) feature/login, feature/select-product 

 

2. 출시 준비

 

ex) release-1.3, release-1.34

 

3. 긴급 수정

긴급 수정은 사용자에게 이미 완성 버전을 배포했는데, 버그가 있는 경우를 말한다.

(다음 버전을 기다릴 새 없이 긴급하게 고쳐야 하는 경우)

 

ex) hotfix-1.2.1

 

 

※ 참고 - 깃이 브랜치를 어떻게 관리하는지?

 

브랜치를 복사한다고 바로 병렬이 되는 것은 아니다. 브랜치를 복사 해가도 commit 이 일어나기 전까지는 수정이 일어나도 가만히 있다.

 

- 무슨 말이지...?

main 브랜치를 feature/login 브랜치와 feature/select-product 브랜치에서 각각 복사해 왔다고 하자. 

그리고 feature/login 브랜치에서 코드 수정을 했다. 

이때 feature/select-product 브랜치로 이동해서 복사해온 코드를 봤을 때 feature/login 브랜치에서 수정한 수정 사항이 반영됐을까?

-> YES

브랜치는 병렬 작업이 가능하다고 했는데, 왜 수정 사항이 반영이 됐지? 이러면 병렬 작업이 안되는 것 아닌가? 라는 의문이 들었을 것이다.

브랜치를 브랜치답게, 즉 병렬 작업이 가능하게 사용하려면 커밋을 한 후부터이다!

커밋을 하기 전까지는 수정 사항도 보이고 병렬 작업이 안되는 것처럼 보이지만, 커밋 후부터는 브랜치가 확실하게 나누어져 병렬 작업이 가능해진다. 

 

추가로 브랜치 사용시 주의해야할 점은 커밋은 롤백이 되지 않으니, 브랜치를 나눠서 작업하고 커밋할 때는 내가 지금 올바른 브랜치에서 커밋을 하는지 다시한 번 확인을 하고 커밋하는 것을 추천!

 

 

 

2. 브랜치 명령어

 

git branch - m [브랜치 이름]

브랜치 이름을 수정하는 명령어, 이름을 수정해야 하는 브랜치에서 명령어를 사용하면 됨

feature/A 브랜치를 feature/B 브랜치로 이름을 바꿔야 하는 경우, feature/A 브랜치에서 git branch -m feature/B 명령어 사용

 

git branch -d [지울 브랜치 이름]

브랜치 지우는 명령어

지울 브랜치에 위치한 상태로 이 명령어를 쓰면 에러가 남, 지울 브랜치 말고 다른 브랜치에서 이 명령어를 사용하기 

 

git branch -r

r: remote

원격 저장소에 어떤 브랜치가 있는지 확인하는 명령어

 

git push [원격 저장소 별칭] [브랜치 이름]

깃허브에 브랜치를 생성 + 깃 브랜치 복제하기 (== 현재 내 깃에만 존재하는 브랜치를 원격 브랜치로 복제를 해서 깃허브에 올리기)

사실 별다른 명령어가 아니라 코드 push 할 때 쓰는 명령어랑 똑같다. 깃에 존재하는 브랜치는 그냥 push 해주면 깃허브에 올라간다.

 

 

 

3. merge 의 종류

 

merge 의 종류

• fast-forward
• 3-way

 

3.1. fast-forward 

 

(사실 많이 쓰이는 전략은 아님)

main 브랜치에서 A 브랜치를 생성한 시점부터, 

• main 브랜치에는 아무런 추가 구현을 하지 않고
• A 브랜치만 추가 구현

main 브랜치와 A 브랜치가 합쳐지면, main 브랜치에 A 브랜치가 붙으면 끝난다.

출처: 코딩애플 깃 강의

 

 

3.2. 3-way 

 

일반적으로 가장 많이 사용 전략

main 브랜치에서 A 브랜치를 생성한 시점부터,

• A 브랜치도 추가 구현을 하고
• B 브랜치도 추가 구현을 하고

main 브랜치와 A 브랜치를 합치면, main 브랜치와 A 브랜치를 서로 비교하여 바뀐 것을 정리하여 합치는 전략이다.

출처: 코딩애플 깃 강의

 

 

 

4. 브랜치 병합 - pull request & merge

 

브랜치를 생성하는 것은 "협업" 을 위한 것이다. 

 

브랜치 병합이란?

깃허브가 별도의 브랜치를 base 브랜치 방향으로 병합을 해주는 것 (별도의 브랜치 -> base 브랜치)

 

브랜치 병합을 할 때는 main 브랜치를 보호해 주는 것이 좋다. 협업 환경에서 main 브랜치는 개발이 완료된 버전인데, main 브랜치에 아무나 병합을 해버리면 문제가 생길 수 있기 때문이다. 

 

브랜치 보호 룰은 레포지토리의 Setting -> Rules -> RuleSets 로 들어가서 설정할 수 있다. 

보통 Require a pull request before merging 에 체크해주는데, 코드가 특정 브랜치에 병합되기 전에 pull request 를 요구하는 옵션이다. 이 옵션을 활성화하면, 아무도 해당 브랜치에 직접적으로 커밋을 추가하거나 푸쉬를 할 수 없으며, pull request 를 통해서만 코드에 변경 사항을 병합할 수 있다. 

 

pull request 가 뭐지?

pull request 는 별도의 브랜치에서 작업한 내용을 main 브랜치에 병합해 달라고 깃허브에게 요청하는 것이다.  

요청을 하면 깃허브가 자동으로 충돌이 일어나는지 검사를 하고, 문제가 없다면 merge 된다. merge 가 일어날 때도 커밋이 되는데, 이걸 "merge commit" 이라고 한다. 

 

또 pr 을 날릴 때는 메세지를 신경 쓰는 것이 좋다. 메세지에는 브랜치에 구현한 내용 마크다운 문법을 사용해 적어주면 좋다. (주요 구현 내용, 구현하면서 있었던 이슈 .. )

 

 

병합이 끝나면 아래와 같은 상태가 된다. (pull request close 상태)

 

여기서는 3가지 행동을 할 수 있다. 

• 개발 끝난 브랜치 삭제 (Delete Branch)
• 브랜치를 삭제한 후, 브랜치를 원래대로 돌리기 (Restore, 현재는 버튼이 안보이는데 Delete Branch 버튼을 누르며 생긴다)
• merge 후 원치 않는 결과가 발생한 경우 merge 전 상태로 돌리기 (Revart)

 

 

 

5. merge 된 깃허브 -> 깃에 동기화하기

 

 

깃허브에서 개발이 끝난 feature/test 브랜치를 merge 하고 브랜치를 삭제했지만, 로컬에는 여전히 feature/test 브랜치가 남아있다. 

-> merge 가 끝난 깃허브와 깃(로컬)을 동기화 시켜줘야 하는 상태

 

깃허브

로컬

 

동기화 어떻게 시키지?

1) git fetch -p -> 2) git pull [원격 저장소 별칭] [브랜치 이름] -> 3) git branch -d [삭제할 브랜치 이름]

 

1) git fetch -p

깃허브의 브랜치 목록을 동기화하는 명령어

이 명령어로 동기화 하고 나면, 로컬에서 git branch -r 로 깃허브의 브랜치 목록을 확인했을 때 더 이상 test 브랜치가 뜨지 않는다.

 

2) git pull [원격 저장소 별칭] [브랜치 이름]

 

로컬에 깃허브와 브랜치 목록을 동기화했으니, 로컬에서 test 브랜치를 삭제하면 될까? X

-> 깃허브에서 삭제된 브랜치에 로컬과 동기화 되지 않은 변경 사항이 없다면 바로 삭제할 수 있지만, 지금처럼 로컬과 아직 동기화 되지 않은 변경 사항이 있다면 git pull 을 해서 변경 사항을 로컬에 가져온 뒤에 브랜치를 삭제해야 한다. 

 

만약 변경 사항이 있는 상황에서 git pull 을 하지 않고 브랜치를 삭제하려고 하면, 완벽하지 머지 되지 않았다는 에러 문구가 뜬다. 

사실 git branch -D 라는 명령어를 쓰면 변경 사항을 무시하고 강제로 브랜치를 지워버릴 수 있지만, 뭐든 강제성이 있는 명령은 조심히 써야 하니, 보통의 경우엔 추천하지 않는다!

 

아무튼 git pull 을 마치고 나서, git log 를 조회하면 깃허브에서 머지할 때 생긴 머지 커밋이 조회되는 것을 확인할 수 있다. 

 

3) 브랜치 삭제

git branch -d [삭제할 브랜치 이름]

 

여기까지 하면 동기화 끝!

 

 

6. 충돌 해결하기

 

서로 다른 사람이 각자 feature/1 브랜치와 feature/2 브랜치를 만들어서 같은 코드에서 개발을 하고 main 에 병합하려고 하면 충돌이 일어날 수 있다. (같은 부분을 수정한 경우)

 

그럼 아래와 병합하려고 할 때 아래와 같은 문구가 뜬다.

자동 merge 가 불가능하기 때문에 충돌이 일어난 부분을 보고 수동으로 결정하면 된다. 

 

계속 진행하면 이런 창이 나오는데, 여기서 Resolve conflicts 를 눌러 들어간다. 

 

여기서 충돌이 일어나는 코드는 확인을 하고 결정할 수 있다. 남겨두고 싶은 코드만 남기고 지워주면 된다. 

 

남겨둘 코드만 남겨놓고 Mark as resolved 버튼을 누르면 위쪽에 초록색으로 commit merge 버튼이 뜨는데 그 버튼을 누르면 된다.