1주차-파트06: 브랜치

Chapter1. 깃 브랜치 이름 규칙

 

"메인브랜치" 1.2.0

메인브랜치를 복사하는 경우

-기능 개발 :  ex) feature/login(로그인 기능), feature/select-pp(상품 조회 기능)

-출시 준비 : release-1.3, release-1.4

-긴급 수정: hotfix-1.2.1

 

 

 

브랜치를 한번 만들어보자. 2개의 브랜치 feature/login과 feature/select-product을 만들었다.

 

 

 

이제 브랜치를 삭제해보자.

git branch -d 브랜치명: 해당 브랜치를 삭제한다.(단 해당 브랜치에 유저가 있으면 안되고 다른 브랜치로 이동 후 삭제 가능)

삭제 후 git branch로 확인해보니 삭제된 것을 알 수 있다.

 

 

 

 

브랜치는 병렬로 구현 가능하다. 그럼 정말 브랜치가 병렬 구조인지 확인해보자. 

git feature/login브랜치로 이동 후 test2.txt파일에 login이라는 문자를 추가해주었다. 병렬이라면 다른 브랜치로 이동시 해당 문자를 추가한 것이 반영 되지 않을 것이다.

 

 

 

 

이제 git feature/select-product브랜치로 이동해보자.

이동했는데 그래도 test2.txt파일에 아까 적은 login문자가 있다. 이게 어떻게 된 일일까?

 

 

 

 

먼저 git status로 상태를 확인해보자. 파일이 수정됐단 알림이 보인다.

 

 

 

 

 

이번에는 다시 이전 feature/login브랜치로 돌아와 상태를 확인해보자. 여기에도 파일이 수정됐단 알림이 보인다.

 

 

 

깃은 커밋을 해야 브랜치가 적용이 된다.

 

 

확인을 위해 Login Branch Commit이란 커밋 메시지를 남기고 커밋을 해보자

 

 

 

 

 

 

커밋을 했으니 확인을 위해 다시 feature/select-product 브랜치로 이동해보자.

 

 

 

 

feature/login브랜치에서 test2.txt파일에 적었던 login문자가 사라진 것을 확인할 수 있다.

 

 

 

 

 

feature/select-product 브랜치의 깃 로그를 봐도 아까의 커밋이 없는 것을 확인할 수 있다. 이로써 브랜치를 이용하여 병렬개발이 가능하다는 것을 확인하였다.

 

 

 

 

브랜치를 헷갈려서 코드 수정 후 커밋을 하게 되면 사고가 발생할 수 있다. 따라서  vs code에서는 현재 어느 브랜치에 위치하고 있는지 GUI를 제공한다. vs code의 가장 왼쪽 하단을 보자.

 

현재 위치한 브랜치가 나와있는 것을 확인할 수 있다.

 

 

 

 

 

 

 

 

 

Chapter2. 깃허브 브랜치 실습

 

git branch -r : 원격으로 깃허브에 어떤 브랜치가 있는지 확인시켜주는 명령어

 

 

 

이제 깃에서 만든 브랜치 feature/login을 깃허브에 올리는 작업을 해보자. 위에서 한 실습에서 만든 브랜치는 깃허브에는 올라가지 않은 상태이다. 

 

 

git push 깃허브저장소별칭 깃브랜치명 : 깃허브 해당 저장소에 깃브랜치명의 브랜치를 올린다.

 

 

 

 

 

 

깃허브를 확인해보니 브랜치가 push됐다 뜨고 브랜치 개수가 1개에서 3개로 늘어났다. (origin/dev에 하나 추가되고, origin/main에 하나 추가되어서 1+2인 상태)

 

 

 

 

 

 

 

 

여기서 main버튼을 눌러 feature/login브랜치로 들어가보자.

 

 

 

아까 feature/login브랜치에 커밋한 Login Branch Commit이 반영되어있는 것을 확인 할 수 있다.

 

 

 

 

 

 

 

 

 

 

Chapter3. 깃 브랜치 전략

 

깃 플로우(git flow)=브랜치 전략: 여러 개발자들이 어떻게 workflow를 짜는지

 

전략은 다양하게 짤 수 있다. 전략은 크게 2가지로 분류 된다.

1) fast forward

2) 3- way

 

먼저 1) fast- forward 전략에 대해 설명하겠다.

 

 

 

1) fast-forward 전략

일단 하나의 브랜치(main)를 가지고 있는 프로젝트가 있다.

main 브랜치

 

 

 

 

 

네모는 새로운 브랜치가 생성된 시점이다. main 브랜치에 feature/login 브랜치를 생성한 시점부터,

-main브랜치는 아무런 추가 구현을 하지 않고

main브랜치에 새로운 브랜치가 추가됨

 

 

 

 

 

 

-feature/login 브랜치만 추가 구현한다. 여기서 오각형은 commit을 뜻한다.

 

 

 

 

 

 

이후 main 브랜치와 feature/login브랜치를 합치면 main브랜치에 그냥 feature/login브랜치가 붙으면서 끝난다.

 

 

 

 

 

2) 3-way 전략