[웹 풀사이클 데브코스 TIL] 2주차 Day 1 - Git 고급

1. 브랜치 이름 규칙과 테스트

"메인 브랜치" v1.2

 

-기능 개발 : feature/login, feature/select-product  ...

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

-긴급 수정 : hotfix-1.2.1  ...

 

 // 참고로 저는 팀원들과 프로젝트 할 당시 이슈를 생성해서, 그 이슈 번호를 feat/36 요런식으로 feat뒤에 붙여 사용했어요 ㅎㅎ

 

🌱 브랜치 관련 명령어

// 브랜치 생성
git checkout 브랜치명

// *브랜치 생성과 동시에 체크아웃
git checkout -b 브랜치명

// 현재 브랜치 확인하기 
git branch 

// 브랜치 삭제
git branch -d 브랜치명

 

커밋 없이 저장만 하면 해당 브랜치에서 변경한 사항이 여전히 다른 브랜치에도 존재합니다 ~

 

2. 커밋 해야 그때부터 브랜치!

'포인터'가 아직 안움직인 상태 → 커밋을 안했기 때문에 파일을 수정해도 아무 일도 일어나지 않아요

 

커밋 후

git checkout -

으로 상위 브랜치로 이동했더니 

login 텍스트가 사라진 걸 확인할 수 있어요

 

❗️주의할 점

만약 내가 브랜치1에서 작업을 하고, 브랜치 2로 이동해서 커밋한다면 ? 브랜치 2의 수정상황만 새로 커밋됩니다..

vscode같은 경우 좌측 하단에서 내 브랜치가 어디인지 확인할 수 있으니 작업할때 주의 또 주의  ㅎㅎ

 

 3. 원격 브랜치 실습

git branch -r

깃허브가 가지고 있는 == 원격 저장소에 있는 브랜치 목록 을 보여주는 명령어입니다 !

 

git 브랜치는 3개인데 원격 저장소에는 main 하나만 있는걸 확인할 수 있어요

 

✏️ 깃허브에 브랜치 생성하고 깃 브랜치 복제하기

깃에 만들어둔 (vscode에서 만든) 브랜치를 원격 브랜치로 복제

git push 깃허브저장소별칭 깃브랜치명

 

깃허브에 먼저 생성한 브랜치를 깃으로 받아오기

git push 깃브랜치명 깃허브저장소별칭

 

git push origin feature/login

을 입력하면

이렇게 브랜치가 하나 더 생겼습니다 ~

 

4. 브랜치 전략, fast-forward

깃 브랜치 전략 == 깃 플로우 

 

1.  fast forward

이미지 출처 https://hudi.blog/git-merge-squash-rebase/

my_branch에서만 작업하고 main에서는 추가 작업한게 없으므로 그냥 merge하면 됩니다

 

 

2. 3-way

일반적으로 가장 많이 사용하는 전략입니다.

이미지 출처 https://seokzin.tistory.com/entry/Git-merge%EC%9D%98-%EC%A2%85%EB%A5%98-Fast-forward-3-way-merge

 

 

master 브랜치에서도 추가 구현을 하고, issa53 브랜치에서도 추가 구현을 합니다

공통 조상 commit 을 기준으로 브랜치를 병합하고, 병합 후에는 병합 커밋이 생성돼요 ~

 

사실 위 그림은 master(main)을 같이 병합하고 있는데, 실제로는 main 브랜치는 건드리지 않는게 암묵적인 룰이라고 합니다ㅎ ㅎ

 

→ 브랜치1에서 작업하고 ,, 브랜치2에서 작업하고 .. 바뀐 부분 정리하면서 main브랜치로 merge하고  ... (무한반복) 이라고 생각하면 편할 것 같아요

 

 

5. pull request & merge

These branches can be automaticallu merged → 충돌이 없다는 의미예요

 

merge하기 전에 main 브랜치를 보호해 봅시다!

merge하기 전에 pull request를 받는다고 체크했어요

 

✏️ merge 해봅시다!

이런식으로 merge 내용을 작성해요

 

merge pull request 를 누르면 ~ 성공적으로 병합이 됐습니다 ㅎㅎ 

(merge 후 브랜치는 삭제하는 것이 좋습니다 !)

 

🧐 병합이란 ?

- 브랜치를 생성하는 이유 == '협업'을 위한 것

- main 브랜치 보호

- 추가 브랜치 → main 브랜치로 병합 == Pull Request

- 충돌이 일어나는지 확인

          *PR 메시지*

- merge

          * merge commit * (병합이 일어날때도 커밋이 발생합니다)

- branch 삭제

 

6. merge된 깃허브 → 깃에 동기화하기

git branch -r

삭제한 브랜치가 살아있는걸 확인 할 수 있어요..

git pull origin feature/login

근데 pull 하려니 없답니다 

 

git fetch -p
git branch -r

fetch(깃허브의 브랜치 목록을 동기화하는 명령어)로 동기화 후 다시 확인해 봤더니 

main 브랜치만 남아 있는걸 확인할 수 있어요 

git branch

그러나 여전히 로컬에는 남아있기 때문에, 현재 브랜치를 이동한 후 삭제 해 주어야 합니다!

 

git checkout main
git branch -d feature/login

merge가 안되었으니,, 지우려면 강제로 삭제하던가 하라는 말을 하구있습니다

*main 브랜치도 동기화 해주어야 해요 

 

git pull origin main
git log

상단에 merge commit이 포함되어 있는 걸 볼 수 있습니다

그리고 다시 삭제해봐요

 

git branch -d feature/login

😺

 

✏️ < merge된 깃허브 - 깃 동기화 >

git fetch -p : 깃허브 브랜치 목록 동기화 → (깃 브랜치 삭제) git checkout main (다른 브랜치로 이동) → git pull origin main(동기화) → git branch -d feature/login

 

7. 충돌 해결하기

github에서 브랜치를 생성해서 vscode로 가져가봅시다

현재 main을 기준으로 feature/1과 feature/2가 생성됐어요 ~

 

git fetch -p
git branch -r
git branch

GitTestGUI

FirstRepository

 

git checkout -t origin/feature/1

깃허브에서 브랜치를 받아오는 명령어

 

GitTestGUI, FirstRepository 파일 내용 변경 후 커밋, 푸시까지 해줍니다 

 

이제 main으로 합쳐주어야겠죠?

merge → branch 삭제 → git fetch로 동기화 → main으로 checkout → git pull origin main → git branch -d feature/

 

그리고 feature/2도 merge 하려고 하는데 

자동으로 merge 할 수 없다고 합니다 !!

그래도 merge를 강행 해 보았어요..

두렵따 ~

Resolve conflicts를 눌러보아요

 

test.txt가 두 번 바뀌었으니.. 뭘 살릴지 정해야해요

 

살리고 싶은 코드만 남기고 다 지운 뒤 Mark as resolved를 눌러보아요

그리고 merge → 브랜치 삭제 하면 됩니다 !

 

살아남은 feature2가 제대로 나오고 있습니다 ! feature1아 미안해 ~

 

 

🍀 github로 branch 작업도 몇 번 해봤지만,, 코드가 길어지면 길어질수록 충돌도..  (상상도 하기 싫어요 ㅠㅠ ~~~)

기초를 탄탄히 다질 수 있어서 너무 유익한 강의였습니다 .. !!! 무한감사를 드립니다