1주차 branch

1주차의 마지막 수업으로 브랜치를 다뤄봤다. 브랜치를 마지막으로 깃에 대한 기본 실습이 끝난 것 같다. 마지막 답게,,가장 복잡했던 실습이었다.
그래도 강사님 덕분에 잘 따라갈 수 있었다. 하지만 이제 정리하면서 다시 실습해야 하는데,,막막하긴 하다.

---

브랜치 이름 규칙

main branch ex) v1.2.0
-복사 이유(branch 생성 이유)와 이름 예시
1. 기능 개발: feature/login, featrue/select-product
2. 출시 준비: release-1.3, release-1.4
3. 긴급 수정: hotfix-1.2.1

---

브랜치

브랜치 생성

git branch 브랜치이름

-생성 및 목록 확인

브랜치 이동

git checkout 브랜치이름

    -selct 브랜치를 하나 더 만들었음

-select 브랜치에서 test2를 수정했는데, main과 login 브랜치에서도 수정이 적용됨
-즉, 병렬로 기능구현되지 않음
-select에서 test2

-main과 login에서 test2

-해결
-commit
-commit을 해야 그때부터 브랜치라고 할 수 있다!
-커밋 후 select branch

-커밋 후 main, login branch

- 주의
-select 브랜치에서 수정한 경우
-현재 있는 브랜치가 select인지 확인!
-실수로 login브랜치에서 commit하면 login에 저장됨
-이는 수정 및 복구 불가함...

---

깃허브 브랜치 실습

깃허브에 깃 브랜치 올리기

git push 깃허브저장별칭(origin) 깃브랜치명

반대로 깃허브의 브랜치를 깃으로 올릴 경우
git push 깃브랜치명 깃허브저장별칭(origin)

-push 전 깃허브

-push 명령 실행

-실행 후 깃허브

main 브랜치 protect

1. setting의 branch에서 classic branch protection 클릭
   

   

2. 강사님과 똑같이한 세팅
   

   

병합

pull request(PR)

1. 화면의 pull request 초록색 아무거나 클릭
   

   

2. 설명은 마크다운으로 작성
   -작성해야 되는 내용
   

   

3. merge(병합) commit이 별도로 존재
   

   

4. 병합된 브랜치는 삭제
   

   

5. 삭제 확인
   

   

6. 깃허브 commit 히스토리 변화
   

   

깃허브에서 깃으로 merge 동기화

1. 다른 브랜치(main)로 이동
   

   

   
   -log를 확인해 보면 깃허브와 다르게 새로운 commit이 없음
   

   

2. main 동기화
   

   

3. 로컬에서 login 브랜치 삭제
   

   

   
   -확인
   

   

4. 하지만 깃허브 브랜치 목록을 조회하면 그대로 존재함. 따라서 따로 깃허브 목록도 동기화
   -강의에서는 1번을 하기 전에 미리해둠
   -변화 없음
   

   

   
   

   

   
   -목록 동기화
   

   

   
   

   

   충돌할 경우

-다른 브랜치에서 같은 파일을 수정
-이 경우 깃허브 merge 과정에서 안내
-깃허브 내에서 내가 원하는 대로 코드 수정

---

깃브랜치 전략

-fast forward
-3 way

1. fast forward
   -A 브랜치에서 B브랜치 생성한 시점부터
   -A에선 아무런 추가 구현 없음
   -B에서만 추가
   --> 둘이 합침 = A에 B 붙임

2. 3 way
   -A에서 B 생성한 시점부터
   -A와 B 모두 추가 구현
   -A와 B 합치기 --> A와 B 서로 비교해 바꾼것 정리하기