깃 브랜치 이름 규칙
브랜치를 만드는 경우 =>기능 개발, 출시 준비, 긴급 수정
- 기능 개발: feature/login , feature/select-product
- 출시 준비: release-1.3 , release-1.4
- 긴급 수정: hotfix-1.2.1
브랜치 생성 후 확인
브랜치 삭제
git branch -d 브랜치명
👩🏻💻 실습해보기
feature/login 브랜치에서 파일 내용 변경 후 commit 했을 때
: Login Branch Commit 이라는 메시지로 커밋이 된 것을 확인할 수 있다.
=> feature/select-product 브랜치에서의 test3.txt 파일은 변경되지 않았음을 확인할 수 있다. 깃 히스토리를 봐도 Login Branch Commit 이라는 커밋 메시지는 없다. 이와 같은 방식으로 브랜치를 통해 병렬로 개발이 가능함을 알 수 있다❗
⚠️ 주의할 점
브랜치는 commit 이후에 제대로 사용할 수 있다. 예를 들어 login 브랜치에서 파일 내용을 변경하고, select-product 브랜치로 이동해도 해당 파일 내용이 변경되어 있음을 확인할 수 있다. 하지만, commit 한 이후에 확인해보면 login 브랜치에서 commit 했을 경우 변경된 내용이 login 브랜치 파일에만 적용되어 있고 다른 브랜치에는 적용되어 있지 않음을 확인할 수 있다. commit 은 한 번 하고 나면 되돌릴 수 없기 때문에, 커밋하기 전에 내가 커밋하고자 하는 브랜치가 맞는지 꼭 확인해야 한다 !
깃허브에 브랜치 생성하고 깃 브랜치 복제하기
: 깃에 만들어 둔 브랜치를 원격 브랜치로 복제
git push 깃허브저장소별칭 깃브랜치명
+) 반대로 깃허브에 브랜치를 먼저 생성하고 깃으로 받아오려면 깃브랜치명과 깃허브저장소별칭을 바꿔서 작성하면 된다.
+) 깃허브에 현재 브랜치가 몇 개가 있는지 확인하는 명령어: git branch -r(remote)
: 깃허브에서 feature/login 브랜치가 생성된 것을 확인할 수 있다.
깃 브랜치 전략 ( 깃 플로우 )
1. fast forward 전략 ( 현업에서 잘 사용 x )
: main branch 에서 feature/login branch 를 생성한 시점부터,
- main branch 에는 아무런 추가 구현을 하지 않고
- feature/login branch만 추가 구현한 뒤
feature/login branch 와 main/branch 를 합치면 👉🏻 main/branch 에 그냥 feature/login branch 가 붙으면 끝남
2. 3-way 전략 ( 일반적으로 가장 많이 사용 )
: main branch 에서 feature/login branch 를 생성한 시점부터,
- main branch 도 추가 구현을 하고
- feature/login branch도 추가 구현을 하고
feature/login branch 와 main/branch 를 합치면 👉🏻 main/branch 와 feature/login branch 가 서로 비교하여 바뀐 것을 정리하여 합치는 전략
➡️ 보통 두 전략을 합쳐서 사용한다!
병합(merge)
병합이란?
: 브랜치를 생성한다는 건, "협업" 을 위한 것
: 그래서 우리는 주로 브랜치 병합(추가 가지 -> base 가지) 을 "깃허브"
: main 브랜치 보호 > 추가 브랜치에서 main 브랜치로 병합 시켜줘( Pull Request) > 충돌 확인 (자동으로 깃허브에서, *PR 메시지*) > merge (*merge commit *) > branch 삭제
1. 깃허브 레퍼지토리에서 Compare & pull request 클릭
2. 설명 작성 후 Create pull request 클릭
: markdown 문법을 사용해서 작성하는 것이 좋음
3. 충돌이 없을 경우 아래와 같은 화면이 나온다. Merge pull request 클릭
4. Confirm merge 클릭
5. merge(병합) 완료
브랜치는 기능을 다 추가하고, merge 를 하고 난 이후에는 삭제해주는 것이 좋다.
merge 가 끝나고 commit 히스토리를 확인하면 위와 같은 화면을 볼 수 있다.
merge된 깃허브 -> 깃에 동기화하기
(해당 상황은 깃허브에서 feature/login 브랜치를 삭제하고, main 에 병합한 이후이다.)
git fetch -p : 깃허브 브랜치 목록 동기화 > (깃 브랜치 삭제) git checkout main > git pull origin main > git branch -d 브랜치이름
1. 깃허브의 브랜치 목록을 동기화한다.
git fetch -p
feature/login 브랜치를 삭제했으므로 깃허브 브랜치를 확인했을 때 main만 뜨는 것을 볼 수 있다.
하지만, 아직 로컬에서는 feature/login 브랜치를 삭제하지 않았으므로 남아있다.
삭제하려고 하니 merge가 되지 않았다고 경고창이 뜬다. 깃허브에서는 merge를 했지만, 아직 동기화하지 않아 발생하는 오류이다.
2. main 브랜치에서 동기화를 수행한다.
git pull origin main
동기화 후 로그를 확인해보면, 깃허브에서 merge 할 때 적었던 커밋 메시지가 뜨는 것을 확인할 수 있다. => 동기화 완료
동기화가 완료되니, 깃에서 feature/login 브랜치가 제대로 삭제되는 것을 볼 수 있다.
충돌(Conflict)
1. 깃허브에서 feature/1 과 feature/2 브랜치 생성하기
2. 같은 원격저장소를 사용하는 파일에서 하나의 파일은 브랜치 feature/1 에서 작업, 하나의 파일은 브랜치 feature/2 에서 작업하기
git checkout -t 원격저장소별칭/브랜치이름
3. 첫 번째 파일의 hyewon.txt 파일 수정 후 feature/1 브랜치에서 add, commit,push 까지 수행
4. 두 번째 파일의 hyewon.txt 파일 수정 후 feature/2 브랜치에서 add, commit,push 까지 수행
5. feature/1 브랜치에서 먼저 Compare & pull request 수행
6. feature/2 브랜치에서도 Compare & pull request 수행
7. 경고창 발생, 무시하고 merge 수행
8. 충돌 발생 ! (똑같은 hyewon.txt 파일을 수정했기 때문)
9. 원하는 내용 남겨두고 나머지 다 지우고 Mark as resolved 클릭 -> Commit merge 클릭
10. 이제 충돌이 일어나지 않음, Merge pull request 클릭
11. Merge 완료
main 브랜치의 hyewon.txt 파일이 feature2 로 내용이 변경되어 있는 것을 확인할 수 있다.
🌟 배운 점
오늘은 브랜치에서도 가장 중요한 병합과 충돌을 해결하는 법을 배웠다. 예전에 학교에서 잠깐 배웠을 때는 이해를 제대로 하지 못한 채 넘어갔었는데 오늘 강의를 들으면서 실습을 하니 이제서야 제대로 이해를 하게 됐다. 이론은 완벽하게 이해를 했으니, 이제 복습을 하면서 CLI 를 통해 git 을 다루고 많은 명령어들에 익숙해지는 것이 필요할 거 같다. 깃을 이렇게까지 자세히 배울 수 있는 기회를 얻어서 너무 좋다. 실수와 오류를 두려워하지 말고 연습을 많이 해야겠다.
'데브코스' 카테고리의 다른 글
| 웹(Web) (0) | 2024.08.20 |
|---|---|
| 협업 Tool (0) | 2024.08.19 |
| 깃(git)에 대하여(2) (1) | 2024.08.14 |
| 깃(git) 에 대하여(1) (0) | 2024.08.13 |
| 프로젝트 관리 (Readme & 버전 관리) (0) | 2024.08.12 |
