git branch기능을 원본(보통 main)에서 복사본을 만들어 원본에 영향없이 기능을 고칠 수 있는 명령어다.
git branch [브랜치 명]
보통 "똑같은 가지를 새로 만든다"고 생각하면 될거같다.
main의 소스코드를 복사해서 다른 브랜치를 만들 때는 보통 다음과 같은 상황에서 일어난다.
밑에 예시를 적어두지만, 통상적으로 팀에서 만든 규칙에 맞게 작성한다.
main브랜치 v1.2.0
- 기능을 개발할 때
ex) feature/login- 출시를 준비할 때
ex) release - 1.3- 긴급 수정할 때
ex) hotfix/1.2.1
git branch // 로컬 브랜치들
git branch -r // 원격 브랜치등
git checkout [가고자 하는 브랜치]
git switch [가고자 하는 브랜치]
두 명령어의 차이점
git switch는 Git2.23 버전에 도입된 만큼 git checkout 명령어의 일부 기능을 더 명확하게, 사용하기 쉽게 만들어준다.
- git checkout
브랜치 전환 뿐만 아니라 파일 체크아웃, 커밋으로 돌아가기 등 다양한 용도로 사용된다.git checkout develop // develop 브랜치로 전환 git checkout -b new-branch // 새 브랜치를 생성하고 그곳으로 전환 git checkout 5d3a123 // 특정 커밋으로 HEAD를 이동 git checkout -- file.txt // 특정 파일을 마지막 커밋 상태로 복원- git switch
오직 브랜치 전환에만 사용되어 기능이 명확하다.git switch develop // develop 브랜치로 전환 git switch -c new-branch // 새 브랜치를 생성하고 그곳으로 전환
git branch -d [브랜치 이름] : 병합이 완료된 브랜치 삭제시엔 -d 이것만 해도 된다.
git branch -D [브랜치 이름] : 병합하지 않은 브랜치 삭제시엔 -D 을 사용해야한다.

바로 위에까지 진행했다면 git(로컬)에는 아직 브랜치가 1개일 것이다.
이는 git branch -r명령어를 통해서 확인할 수 있다.
해당 명령어는 githug(원격)에 있는 브랜치가 무엇이 있는지 알려준다.
이제 git에 올린 커밋을 원격 저장소에 push를 한다면 올라간 것을 확인할 수 있다.

branch를 어떤식으로 나누는게 좋은지에 대한 것이다.
A branch에서 B branch를 생성한 시점부터
B branch와 A branch를 합치면, A branch에 B branch가 붙는다.
일반적으로 가장 많이 사용하는 전략
A branch에서 B branch를 생성한 시점부터
B branch와 A branch를 합치면, A branch와 B branch가 서로 비교하여 바뀐 것을 정리하여 합치는 전략
해당 전략은 merge를 했을 때 github에서 충돌하는 부분이 있다면 알려주게 된다.
충돌이 일어난 부분을 확인하고 반영하여 2개의 branch를 합치는 방법이다.
협업에서 기능 개발을 위해 만든 브랜치를 main 브랜치에 병합을 하게되는데, 이때 충돌이 일어나기도 한다. 보통 github에서 자동적으로 다른 부분을 찾아 확인할 수 있다.
Pull Request를 할때 충돌이 일어나면 PR메세지가 merge할때 입력하는 commit은 merge commit이라고 하며, 병합이 끝난 branch는 일반적으로 삭제한다.
정상적인 병합이라면 github웹 페이지의 Pull requests를 클릭하고 브랜치를 병합할려고 할때 다음과 같이 나온다.

아래 Add a description에는 어떤점들을 수정했는지 적어주는게 좋다.

그렇게 요청하게 되면 다음과 같이 올라오게 된다.
여기서 Merge pull request를 누르면 merge가 된다.

앞에서 말했듯이 github에서 충돌이 일어난 것을 확인해 준다.

이렇게 다른 브런치에 다른 내용으로 만들어서 각각 병합을 해볼려고한다.

먼저 하나를 병합하고 다음꺼를 병합할려고 하면

다음과 같은 메세지가 나오는 것을 볼 수 있다.
이상태에서 pull request를 만들수는 있지만

보는것과 같이 충돌을 해결하라고 나오게 된다.
여기서 Resolve conflicts를 누르면 어떤 부분이 출동되었는지 확인할 수 있다.

여기서 왼쪽은 충돌이 일어난 파일들을, 오른쪽에 어떤 부분이 충돌이 일어났는지를 보여준다.

해당 코드를 수정하고 commit merge로 하면

그림처럼 병합 가능하다고 나오게 되다.
실제로 main에 가서 해당 파일을 확인해보면

수정이 반영되어 있는것을 확인할 수 있다.
코드 에디터에서 병합이 끝난 후 git pull을 했을 때 다음과 같은 커밋 기록을 볼 수 있다.

병합이 끝나고 git에서 확인해 보면 이전 브챈치가 남아있는 것을 알 수 있다.
git branch -d [branch 이름]
를 통해 push한 브랜치를 삭제하면 되는데, 만약 삭제가 되지 않는다면
git checkout main으로 바져나와서 브랜치 삭제git branch -r로 브랜치 목록이 동기화 되었는지 확인git fetch -p: github 브랯니 목록 동기화git checkout main: 삭제할 브랜치에 있다면 main으로 이동git pull origin main: github에서 커밋 받아오기git branch -d [branch 이름]: 이미 삭제된 브랜치를 git 에서도 삭제git fetch랑 pull차이
원격 저장소의 변경사항을 로컬에 반영 또는 확인하기 위한 명령어이다.
git fetch
원격 저장소의 변경사항이 있는지 확인만 하고, 실제로 가져오지는 않는 명령어
fetch는pull이후에 원격 저장소 또는 브랜치에 적용된 변경 사항을 확인할 수 있어서, 위의 브랜치가 삭제되었다는 정보를 가져올 때 사용하였다.
보통pull을 하기전에 내가 없는동안 내가 수정하는 파일이나 브랜치에 어떤 것이 달라졌는지를 확인할 때 쓰인다. 내가 작성하던걸 미루고 다음날 왔을 때, 영향을 끼칠만한 게 있는지 확인하는 용도git pull
원격 저장소에서 변경된 메타데이터 정보를 확인할 뿐만 아니라 최신 데이터를 복사하여 로컬git에 가져오는 명령어
fetch랑은 다르게 로컬에 변경내용을 병합한다.