오늘은 팀원분들과의 팀프로젝트 마지막 날이었습니다.
거의 하루종일 git & github 때문에 어려웠던 날이었습니다. ㅜ. ㅜ
우리는 각각 branch 를 나눠 작업하고 main 에 병합하는 방법으로 진행해보기로 했는데,
아직 익숙하지 않다보니 계속 에러와 마주쳤습니다.
특히 pull, merge 등 병합 상황에서 conflict가 발생했을 때
충돌 부분을 수정하는 것이 무언가 아직은 부담스럽고 어렵게 느껴졌습니다.
그러나 어려움 끝에 각각 작업한 결과들을 main에 성공적으로
병합할 수 있었고 시간 내에 프로젝트를 완성하였습니다.
물론 여러가지 부족한 점이 많지만 첫 팀프로젝트를 무사히 완료한 것에 뿌듯함을 느낍니다.
마지막으로 오늘 겪었던 git 문제 해결 상황을 정리합니다.
■ 개인branch 에 main 을 병합하는 상황
1. 먼저, 현재 branch 를 확인하세요
git branch
2. 최신 상태로 업데이트: main 브랜치를 최신 상태로 업데이트합니다.
git checkout main
git pull origin main
3. 브랜치로 다시 이동하여 main 브랜치를 병합합니다.
git checkout test01
git merge main
※ git rebase 와 git merge 의 차이
git merge와 git rebase는 두 가지 다른 방법으로 브랜치에서 발생한 변경 사항을 다루기 위해 사용되지만, 이 두 명령은 커밋 히스토리를 관리하는 방식에서 차이가 있습니다.
1. git Merge
git merge는 두 브랜치의 변경 사항을 통합하는 가장 흔히 사용되는 방법입니다.
>>>merge는 원본 브랜치의 히스토리를 그대로 유지합니다. 즉, 모든 커밋 로그와 그 순서가 원래대로 보존됩니다.
>>>새로운 'merge commit' 생성: 두 브랜치를 병합할 때 새로운 commit이 생성되어 두 브랜치의 변경 사항이 통합됩니다. 이 커밋은 두 브랜치의 모든 변경 사항과 충돌을 해결한 결과를 담습니다.
2. git Rebase
git rebase는 한 브랜치의 변경 사항을 다른 브랜치의 끝에 다시 적용(재배치)하는 방법으로,
커밋 히스토리를 보다 깔끔하게 관리할 수 있습니다. rebase의 주요 특징은 다음과 같습니다
커밋 히스토리 변경: rebase는 기존 브랜치의 커밋 히스토리를 변경합니다.
이 과정에서 기존 커밋들이 새로운 베이스(기준점)에 맞추어 재배치되고, 커밋 ID가 새로 생성됩니다.
사용 상황
Merge : 협업 환경에서 여러 사람이 작업하는 주요 브랜치에는 merge를 사용하는 것이 좋습니다.
이는 원본 브랜치의 커밋 히스토리를 보존하고, 모든 참여자의 기여를 명확하게 보여줍니다.
Rebase : 개인 작업 브랜치에서는 rebase를 사용하여 베이스 브랜치와의 히스토리를 깔끔하게 유지할 수 있습니다.
커밋 히스토리를 깨끗하게 유지하고 싶다면 rebase를,
변경사항을 명확히 남기고자 한다면 merge를 사용하는 것이 적절합니다.
'TIL' 카테고리의 다른 글
[240422 TIL] 좋은 함수 (0) | 2024.04.22 |
---|---|
[240421 WIL 1주차] 웹디자인, github, env (0) | 2024.04.21 |
[240419 TIL]첫 팀 프로젝트 회고 (1) | 2024.04.19 |
[240417 TIL] env 생각보다 어렵다ㅜㅜ (0) | 2024.04.17 |
[240416 TIL] 첫 TIL (0) | 2024.04.16 |