오늘은 브랜치를 어떻게 사용하면 좋을지, 네이밍과 깃 플로우, 병합과 PR에 대해 배워볼 것이에요.
브랜치의 이름은 해당 브랜치에서 하고자 하는 것을 명확히 나타내야해요
feature/#4 처럼 브랜치를 파서 개발해요."뒤처져 있던 브랜치가 앞서 나간 브랜치의 위치로 이동하는 것"을 말해요.

main 브랜치에서 feature 브랜치를 만들어서 작업을 하고 있었다고 가정해볼게요
feature에서 커밋하는 동안, main 브랜치에는 아무런 새로운 커밋이 생기지 않았어요.
이 상태에서 머지를 하면, Git은 별도의 새로운 커밋 없이 그냥 main의 head를 feature 브랜치 head의 위치로 옮겨요!


git merge {병합할 브랜치명}
여러 개의 자잘한 커밋들을 꽉 눌러서 '커다란 커밋 하나'로 합쳐버리는 기능이에요
다음과 같은 장점이 있어요
스쿼시 머지를 쓰면 의미 있는 기능 단위로만 기록이 남아서 보기에 아주 편안해져요.
만약 해당 구현사항을 되돌려야해도 하나로 합쳐진 그 커밋 하나만 revert하면 되니까 번거롭지 않아요.
AI가 다음과 같은 비유로 설명해줬어요.
시장에서 장을 본다고 생각해 봐요!

우선 pull-request-test 라는 브랜치를 만든 후 origin/pull-request-test로 커밋을 푸쉬해봤어요.

노란색으로 새로운 브랜치에서 push가 들어왔다고 알림이 왔어요. 눌러봅시다.

해당 pr이 했던 것을 깔끔하게 작성해서 pr을 생성해줍시다.

pr를 생성하면 깃허브에서 충돌이 나지 않나 확인해봐요


git fetch -p (prune)
원격 레포에 없지만 로컬에 남아있는 브랜치들을 이 명령어로 없애줄 수 있어요.

방금 병합은 충돌이 나지 않았지만, 만약 병합하려는 두 커밋이 같은 파일을 건드렸으면 어떻게 될까요?
pull-request-test 브랜치에서 programmers.yaml을 수정하고, 병합하고 싶은 main 브랜치에서도 programmers.yaml을 수정해봤어요.

이번에는 충돌이 있어서 수동으로 병합을 해줘야 해요

이 중에서 어떤 코드를 사용할 건지 직접 에디터로 수정해줄거에요

저는 이렇게 남기고 병합할거에요.

이렇게 병합된 것을 볼 수 있어요.

오늘 pull request와 merge를 실습하고 난 뒤의 커밋 히스토리에요.

깃허브에도 커밋 히스토리가 다음과 같이 남아있어요