[Git] branch, merge, pull request, fork, rebase, fetch

Branch (브랜치) : 두 명이 동시에 버전 관리를 하기 위해 특정 기준에서 줄기를 나누어 작업할 수 있는 기능

- [master]브랜치 : Git에서 제공하는 기본적인 브랜치. 새로운 커밋을 추가할 때마다 master브랜치의 포인터가 최신 커밋을 가리킨다.

- 최신커밋에서 [새로운] 브랜치를 만들경우 새로운 포인터가 커밋을 가리키고, 새로운 브랜치가 새로운 커밋을 만들면 master브랜치는 따라오지 않는다.

- master브랜치가 새로운 브랜치처럼 커밋을 만들면 거기서부터 master브랜치와 새로운 브랜치는 다른 커밋을 가리키게 된다.

-[Head]포인터 : 현재 작업하고 있는 커밋을 가리키는 포인터. 브랜치 사이를 넘나들며 작업할 수 있도록 함

고양이 브랜치 == 새로운 브랜치

새 브랜치 만들기 규칙 : 하나의 브랜치에는 한 사람만 작업하는 것이 바람직하다

1. [master]브랜치에는 직접 커밋을 올리지 않는다(동시작업 시 꼬일 수 있음)

2. 기능 개발을 하기 전에 [master]브랜치를 기준으로 새로운 브랜치를 만든다

3. 브랜치 이름은 [feature/기능이름]형식으로 하고 한 명만 커밋을 올린다

4. [feature/기능이름]브랜치에서 기능 개발이 끝나면 [master]브랜치에 이를 합친다

 

새 브랜치 만들기

1. 고양이가 detail-page 브랜치 만들기 위해 [브랜치] 아이콘 클릭해 'feature/detail-page' 새 브랜치 체크아웃 선택하고 브랜치생성함 (checkout은 브랜치 이동 명령) 가장 최근 커밋을 가리키고 있음. 왼쪽 하단 [브랜치] - [feature] - [detail-page]표시됨(브랜치 이름에 '/' 삽입 시 폴더처럼 구분됨)

2. VS Code에서 iTshirt-cat폴더에 'detail-page.md' 파일 생성

3. 소스트리에서 커밋 메시지 작성 후 커밋 - 예시로 디테일 페이지 추가 입력

4. History 그래프 확인하면 feature/detail-page브랜치에 커밋 추가된것 확인할수있음

5. vs code에서 feature-list.md 파일 수정 - 예시로 3.디테일 페이지 보여주기 텍스트 추가

6. 소스트리에서 커밋 [~에 바뀐 내용 즉시 푸시]체크박스 체크(커밋과 동시에 원격저장소에 푸시가 된다) - 예시로 기능 명세 3번에 추가 커밋메시지 입력

7. 히스토리 그래프 확인하면 방금 커밋에 로컬저장소를 나타내는 feature/detail-page와, 원격저장소를 나타내는 origin/feature/detail-page 꼬리표가 붙음

8. Github의 원격저장소에서 [feature/detail-page]브랜치 업로드를 확인한다

---

checkout : 브랜치 이동 명령

1. 문어가 작성을 위해 현재 브랜치를 [master]브랜치를 더블클릭해 이동한다

2. [master]브랜치인지 확인 후 [feature/cart]새 브랜치를 생성한다

3. vs code에서 iTshirt-cat 폴더의 feature-list.md 파일을 열면 '3.디테일 페이지 보여주기' 텍스트는 없다.(이것은 고양이가 만든 feature/detail-page 브랜치에 있기때문) 대신 '3.장바구니 담기' 텍스트입력(이제 충돌이 일어난다)

4. 새파일 'cart.md' 추가 작성 내용은 '장바구니 담기' 입력

5. 소스트리에서 방금 수정한 feature-list.md와 cart.md 커밋. 커밋메시지는 '장바구니 담기 기능' 즉시 푸시 체크해준다

6. 히스토리 그래프 확인하면 고양이와 문어의 브랜치가 충돌이 일어났다

7. 현재 브랜치 상황

커밋3은 고양이가 디테일페이지 추가한거

merge : 병합. 브랜치와 브랜치를 합치기

 

merge commit(병합커밋) : 새로운 커밋이 생성

fast-forward(빨리감기) : 후속 커밋으로 변경

conflict(충돌) : 동일한 부분을 변경

 

고양이가 [feature/detail-page]브랜치를 [master]와 합칠 경우

- fast forward merge 수행

결과 = [master]브랜치가 커밋4를 가리킴

빨리감기 병합 하는법

1. [master]브랜치를 기준으로 다른 브랜치를 병합하려면 [master]브랜치로 체크아웃

2. 병합하기를 원하는 커밋에서 우클릭 - 병합

3. [master]브랜치와 해당 브랜치가 같은 커밋을 가리킴

4. [master]에 '2'가 표시되는데 이는, 2개의 커밋이 원격저장소에 안 올라감을 의미

5. push버튼에도 '2'가 표시되는데 [master] 체크박스 체크 후 push

 

문어가 [feature/cart]브랜치를 [master]와 합칠 경우

- 커밋4와 커밋5를 합친 merge commit을 만들어야 함. 새로운 병합커밋의 위치를 [master]브랜치에 둔다

 

conflict(충돌) 해결하기

1. [feature/cart]브랜치로 체크아웃

2. [master]브랜치 우클릭 - 병합 - 충돌병합 알림 나옴

3. '커밋하지 않은 변경사항' 선택 - feature-list.md가 스테이지 아래에 있음(충돌이 발생한 파일)

4. feature-list.md오픈 '======'를 기준으로 위는 베이스브랜치[feature/cart]코드 / 아래는 병합대상[master]코드

5. 개발자끼리 합의해서 수정 후 저장

6. 소스트리에서 feature-list.md 파일의 미리보기에서 확인 후 커밋 - 영문 메시지가 자동생성되며 병합 커밋 생성

7. 병합커밋이 [feature/cart]브랜치에 업로드 됨 충돌해결

8. push - [feature/cart]체크 후 push

9. [master]브랜치에 반영하기 위해 [master]브랜치로 체크아웃

10. [feature/cart] 커밋 우클릭 병합

11. [master]브랜치 push하면 모든 브랜치들이 다 반영

 

---

풀 리퀘스트 (pull reauest) : 협력자에게 브랜치 병합을 요청하는 메시지를 보내는 것

1. 현재브랜치 [master]브랜치에서 브랜치 아이콘 클릭 후 [feature/comment]브랜치 생성

2. vs code 'comment.md' 생성 및 내용 작성 후 iTshirt-cat폴더에 저장

3. 커밋 후 푸시

4. 원격저장소에서 [feature/comment]브랜치 확인

5. compare & pull reaurst 버튼 클릭

6. base브랜치와 compare브랜치 확인. base브랜치:master , compare브랜치 : feature/comment설정

베이스브랜치 : 병합 결과물이 올라갈 기준이 되는 브랜치

비교브랜치 : 현재 기준 브랜치의 비교대상이 되는 브랜치

7. 개발 완료한 기능에 대한 제목 및 설명 추가 후 Create pull request 버튼 클릭

8. 협력자가 pull request 탭 확인 - 원격저장소의 reviewer(협력자)가 풀 리퀘스트를 확인하고 검토.

협력자의 선택

Accept : 풀 리퀘스트 수락

Request change : 수정요청

Merge pull Request : 병합

9. Merge pull request 후 병합 커밋(Confitm merge)클릭

10. 병합 후 닫힘 메시지 병합완료

11. pull request탭의 closed탭 확인(닫혀진 풀 리퀘스트)

12. 소스트리 확인하면 [origin/master]브랜치가 옛날 커밋을 가리키고 있음

13. 패치 아이콘 실행 - 원격과 로컬을 실시간으로 동기화 시켜줌

14. [master]브랜치 이동 후 pull

---

버전

- Major upgrade : sw 사용자가 크게 느낄 변화를 적용한 경우 v2.x -> v3.x

- Minor upgrade : 작은 변화 v2.3 -> v2.4

 

release : 프로그램을 출시하는 것. 버전의 기록:tag

 

tag : 특정 커밋에 포스트잇 붙이기

1. 태그 아이콘 클릭 후 [master]브랜치를 확인하고 'v1.0.0'태그 달기

2. push 하단의 (모든태그푸시)체크박스 체크. 원격저장소로 push

3. 원격저장소의 [1 release] 탭 태그 확인

---

원격저장소에 대한 push 권한을 가진 사람은 원칙적으로 원격저장소 원본저장소를 만든 소유자만 가능하다.

설정 - collaborator(협력자)로 가면 권한을 부여할 협력자를 등록할 수 있다.

원본저장소의 소유자는 협력자가 많아지는 경우 협력자들의 push로 인해 원본저장소를 관리하기 힘들어지고

협력자(개발자)들은 원본저장소에 자신의 수정 내용을 직접 push하는 것에 부담이 됨

- 해결방안 : pull request

 

fork(포크)

- 브랜치를 포함한 원본저장소의 모든 커밋 이력을 새로운 원격저장소로 전체 복사하는 것

- 포크한 원격저장소의 이력은 추가적으로 등록해야 함(새로운 주소이기 때문)

- 브랜치는 5인 이하 협업시 유리, 포크는 50인 이상의 다수  협업시 유리

branch와 fork의 차이점

1. 제3의 인물 너구리 등장 너구리 계정이 고양이와 문어의 iTshirt 원본저장소 접근 후 [fork] 클릭 너구리 계정에 iTshirt 원본저장소 복사

2. 너구리 계정의 iTshirt 원본저장소 이동 후 소스트리에 clone

3. vs code에서 너구리폴더에 like.md 새파일 생성 예시로 '좋아요 기능 추가' 저장 커밋 후 푸시

4. 포크한 원격저장소의 [New pull request]  클릭

5. head의 변경사항을 base에 합치는것 설명 작성 후 [Create pull request] 클릭

[head repository] : 너구리가 포크한 원격저장소

[base repository] : 고양이와 문어의 원본저장소

6. 고양이와 문어의 full request approve(승인)와 merge 대기

7. (고양이계정로그인) 원본저장소의 [Insight] 탭 클릭 > [Forks] 클릭 후 정보확인

8. [pull request] 탭 확인 > [File changed] 탭의 [Review changes]클릭하면 [Write]창이 오픈되는데 [Approve] > [Submit Review]

[Comment] : 댓글만 작성 / [Approve] : 댓글을 달고 바로 병합해도 좋을 경우 / [Request changes] : 수정 요청

9. 리뷰는 풀리퀘스트 하단에 댓글처럼 달린다. [Merge pull request] 클릭하여 병합(원본저장소 주인만 가능) 후 [Confirm merge] 병합완료

---

rebase : 묵은 커밋을 새커밋으로 이력조작

1. 고양이&문어의 원본저장소와 너구리가 fork한 원격저장소를 충돌을 유도하겠다.

2. 너구리가 너구리 저장소의 'like.md'파일을 수정한다. 예시로 2번라인에 '찜하기 기능'을 추가하고 커밋,push

3. 충돌을 위해 고양이가 원본저장소에 'like.md'파일을 수정한다 예시로 2번라인에 '싫어요 기능'을 추가하고 README파일의 개발자목록에 너구리추가하고 커밋,push

4. 너구리가 2번에 한 커밋을 원본저장소에 풀리퀘스트 보냄

5. 빨간색메시지 'Can't automatically merge' 코드가 충돌했다는 의미

현재까지 너구리는 포크한 이후의  고양이의 원본저장소의 상태를 모른다 서로 다른 원격저장소이기 때문이다

add remote : 다른(여러) 원격저장소의 히스토리를 보는 방법은? : 소스트리가 원본저장소와 원격저장소를 동시에 추적하도록 한다

6. 너구리가 소스트리에서 [저장소 - 원격저장소 추가] 클릭

7. [추가]클릭 원격이름:upstream(원본저장소를 지칭하는 관용적 닉네임) / URL경로:고양이 원본저장소 주소 / 확인

8. 왼쪽 사이드바 원격 섹션에 [upstream]추가됨

9. 패치(fetch)수행하기 위해 [upstream]우클릭 -> upstream에서 가져오기 선택(원본저장소에서 히스토리 받아오는 것)

패치 : 원본저장소 이력을 업데이트. 이력만 가져오고 코드에는 영향 없음

pull : 코드까지 가져와서 내 코드에 반영

 

풀리퀘스트 시 충돌해결

(1). 내 브랜치에서 병합커밋 생성 후 풀리퀘스트 보내기 - 병합을 위해 불필요한 커밋이력이 남는 문제점

(2). rebase 후 풀리퀘스트 보내기

reabase : 커밋의 베이스 커밋이력을 조정 - 빨리감기 병합 사용가능, 브랜치의 이력이 간단해지는 장점. 충돌은 rebase작업 도중 해소된다

10. 너구리의 history를 보면 '찜하기 기능 추가'의 베이스가 '좋아요 기능 추가'인데

패치 upstream은 고양이

11. 커밋을 upstream/master의 '개발자 목록에 너구리 추가'로 변경 - 선택 후 우클릭 > 재배치 선택 > 경고창확인

rebase

12. 아직 너구리와 고양이가 서로 수정한 'like.md'의 2번라인의 충돌로 경고팝업이 뜨며 '커밋하지 않은 변경사항'이 나타난다. 너구리가 vs code로 코드를 정리하고 저장한다

13. 'like.md'파일을 스테이지에 올리고 [액션 - 재배치 계속] 클릭(리베이스는 커밋을 하나씩 비교하면서 충돌여부검사 하기때문에 이후에도 추가충돌이 발생할 수 있기 때문에 클릭)

14. '찜하기 기능 추가'의 베이스커밋이 [upstream/master]로 변경되어 rebase에 성공

15. rebase는 이력을 조작하는 위험한 행위라 단독으로 사용하는 브랜치에서만 사용을 권장하여 일반푸시는 안돼, 강제로 푸시해야한다. [도구 - 옵션] 선택

16. [Git]탭에서 [강제 푸시 가능] 체크(푸시할때 강제푸시체크박스를 표현) 확인

17. push > [강제 푸시]체크 > push > 경고창 예 > 원격저장소에도 리베이스 반영(push)

18. 너구리가 너구리 원격저장소에서 [New pull request] 클릭하면 고양이의 원본저장소로 자동변경되어 'Able to merge'표시되어 [Create pull request]클릭을 하면 풀리퀘스트가 된다. 고양이에게 보낼 메시지 작성해서 풀리퀘스트를 만든다

19. 고양이는 승인 및 병합 완성