힘내 rebase 명령은 두 개의 소스 코드 분기를 하나로 결합합니다. 힘내 merge 명령도 마찬가지입니다. 우리는 무엇을 설명 rebase 사용 방법 및 사용 시기 merge 대신에.
힘내 폭발
힘내 병합이란 무엇입니까?
힘내 리베이스 란 무엇입니까?
다른 지점으로 리베이스하는 방법
Git 리베이스 대 병합: 어느 것을 사용해야 합니까?
리베이스하거나 리베이스하지 않습니까?
힘내 폭발
다른 버전 제어 시스템과 느린 업데이트 및 커밋에 좌절한 Linux 커널로 유명한 Linus Torvalds는 2005년에 자신의 시스템을 작성하기 위해 한 달을 비워두었습니다. 그는 그것을 Git이라고 명명했습니다.
GitHub, GitLab 및 BitBucket과 같은 사이트는 Git을 공생적으로 홍보하고 혜택을 받았습니다. 오늘날 Git은 전 세계적으로 사용되며 2022년 설문 조사에서 응답자 71,000명 중 98%가 Git를 버전 제어 시스템으로 사용했습니다.
Git의 주요 설계 결정 중 하나는 속도였습니다. 특히 지점과의 작업은 최대한 빨라야 했습니다. 분기는 버전 제어 시스템의 기본 부분입니다. 프로젝트 리포지토리에는 기본 또는 마스터 분기가 있습니다. 이것은 프로젝트의 코드 베이스가 있는 곳입니다. 새로운 기능과 같은 개발은 분리된 사이드 브랜치에서 이루어집니다. 이렇게 하면 분기에서 수행된 작업이 마스터 분기를 엉망으로 만드는 것을 중지하고 코드 기반의 다른 부분에서 동시 개발이 발생할 수 있습니다.
사이드 브랜치의 개발이 완료되면 개발 브랜치를 마스터 브랜치로 병합하여 변경 사항을 마스터 브랜치로 이전합니다. 다른 버전 제어 시스템에서 브랜치로 작업하는 것은 어렵고 계산 비용이 많이 듭니다. Git에서 브랜치 작업은 매우 빠르고 매우 가볍습니다. 한때 지루하고 다른 시스템에서는 자주 피했던 작업이 Git에서는 사소해졌습니다.
힘내 rebase command는 한 분기에서 다른 분기로 변경 사항을 전송하는 또 다른 방법입니다. 그만큼 merge 그리고 rebase 명령은 비슷한 목표를 가지고 있지만 서로 다른 방식으로 목적을 달성하고 약간 다른 결과를 산출합니다.
힘내 병합이란 무엇입니까?
그래서 Git이 뭔데 merge 명령? 라는 브랜치를 만들었다고 가정해 보겠습니다. dev-branch 새로운 기능을 작업합니다.
몇 가지 커밋을 하고 새 기능을 테스트합니다. 모두 잘 작동합니다. 이제 새 기능을 master 나뭇가지. 당신은에 있어야합니다 master 분기하여 다른 것을 병합합니다.
우리는 우리가 master 병합하기 전에 명시적으로 확인하여 분기합니다.
git checkout master
이제 Git에게 다음을 병합하도록 지시할 수 있습니다. dev-branch 현재 브랜치로 master 나뭇가지.
git merge dev-branch
우리의 merge 우리를 위해 완성되었습니다. 체크아웃하면 master 분기하고 컴파일하면 새로 개발된 기능이 포함됩니다. Git이 실제로 수행한 것은 3방향 병합입니다. 가장 최근 커밋을 비교합니다. master 그리고 dev-branch 분기 및 커밋 master 직전 분기 dev-branch 생성되었습니다. 그런 다음 커밋을 수행합니다. master 나뭇가지.
병합은 아무 것도 삭제하지 않고 Git 기록을 변경하지 않기 때문에 비파괴적인 것으로 간주됩니다. 그만큼 dev-branch 여전히 존재하며 이전 커밋은 변경되지 않습니다. 3방향 병합 결과를 캡처하는 새 커밋이 생성됩니다.
병합 후 Git 리포지토리는 대체 줄이 분기된 후 기본 타임라인으로 돌아가는 타임라인처럼 보입니다.
그만큼 dev-branch 지점이 에 편입되었습니다. master 나뭇가지.
한 프로젝트에 많은 분기가 있는 경우 프로젝트 히스토리가 혼란스러울 수 있습니다. 이는 프로젝트에 기여자가 많은 경우에 자주 발생합니다. 개발 노력이 다양한 경로로 분할되기 때문에 개발 이력은 비선형적입니다. 브랜치에 자체 브랜치가 있으면 커밋 히스토리를 푸는 것이 훨씬 더 어려워집니다.
커밋되지 않은 변경 사항이 있는 경우 master 브랜치에 무엇이든 병합하기 전에 이러한 변경 사항에 대해 작업을 수행해야 합니다. 새 분기를 만들고 거기에서 변경 사항을 커밋한 다음 병합을 수행할 수 있습니다. 그런 다음 임시 분기를 다시 마스터 분기로 병합해야 합니다.
그것은 작동하지만 Git에는 새 분기를 만들지 않고도 동일한 작업을 수행하는 명령이 있습니다. 그만큼 stash 명령은 커밋되지 않은 변경 사항을 저장하고 다음을 사용하여 다시 호출할 수 있습니다. stash pop .
다음과 같이 사용합니다.
stash git merge dev-branch stash pop
최종 결과는 저장되지 않은 변경 사항이 복원된 병합된 분기입니다.
힘내 리베이스 란 무엇입니까?
힘내 rebase 명령은 완전히 다른 방식으로 목표를 달성합니다. 리베이스하려는 브랜치에서 모든 커밋을 가져와서 리베이스하려는 브랜치의 끝에서 재생합니다.
이전 예를 들어 어떤 작업을 수행하기 전에 Git 리포지토리는 다음과 같습니다. 라는 지점이 있습니다. dev-branch 이러한 변경사항을 master 나뭇가지.
후 rebase 하나의 완전히 선형적인 변경 일정처럼 보입니다.
그만큼 dev-branch 제거되었으며 커밋이 dev-branch 마스터 브랜치에 추가되었습니다. 최종 결과는 dev-branch 실제로 직접 투입되었다. master 처음에 지점. 커밋은 단순히 master 분기하면 “재생”되고 새로 추가됩니다.
이것이 왜 rebase 명령은 파괴적인 것으로 간주됩니다. 리베이스된 브랜치는 더 이상 별도의 브랜치로 존재하지 않으며 프로젝트의 Git 기록이 다시 작성되었습니다. 나중에 어떤 커밋이 원래 커밋되었는지 확인할 수 없습니다. dev-branch.
그러나 단순하고 선형적인 역사를 남깁니다. 수십 또는 수백 개의 분기 및 병합이 있는 리포지토리와 비교하여 Git 로그를 읽거나 그래픽 git GUI를 사용하여 리포지토리의 그래프를 보는 것과 비교하면 리베이스된 리포지토리는 이해하기 쉽습니다.
다른 지점으로 리베이스하는 방법
시도해 보자 git rebase 예시. 라는 브랜치가 있는 프로젝트가 있습니다. new-feature. 우리는 rebase 그 가지에 master 이렇게 가지.
먼저, 우리는 master 분기에는 눈에 띄는 변경 사항이 없습니다.
git status
우리는 체크 아웃 new-feature 나뭇가지.
git checkout new-feature
우리는 힘내에게 말한다 rebase 현재 분기를 마스터 분기로.
git rebase master
우리는 여전히 두 개의 분기가 있음을 알 수 있습니다.
git branch
우리는 다시 master 나뭇가지
git checkout master
new-feature 브랜치를 현재 브랜치로 병합합니다. master 나뭇가지.
git merge new-feature
흥미롭게도 최종 병합 후에도 여전히 두 개의 분기가 있습니다.
차이점은 이제 new-feature 가지와 머리 master 분기는 동일한 커밋을 가리키도록 설정되며 Git 기록에는 별도의 커밋이 있었다는 것이 표시되지 않습니다. new-feature 브랜치 라벨과 별개로 브랜치.
Git 리베이스 대 병합: 어느 것을 사용해야 합니까?
의 경우가 아니다 rebase 대 merge. 둘 다 강력한 명령이며 아마 둘 다 사용할 것입니다. 즉, 다음과 같은 사용 사례가 있습니다. rebase 그렇게 잘 작동하지 않습니다. 사용 실수로 인한 Unpicking 실수 merge 불쾌하지만 다음으로 인해 발생하는 언피킹 오류 rebase 지옥 같다.
당신이 리포지토리를 사용하는 유일한 개발자라면 rebase 그것은 재앙입니다. 당신은 여전히 수 rebase 예를 들어 잘못된 방향으로 rebase 귀하의 마스터 분기에 new-feature 나뭇가지. 당신의 master 다시 분기하려면 다음을 수행해야 합니다. rebase 다시, 이번에는 당신의 new-feature 당신의 master 나뭇가지. 그것은 당신을 회복시킬 것입니다 master 이상하게 보이는 역사가 있지만 지점.
사용하지 마십시오 rebase 다른 사람들이 작업할 가능성이 있는 공유 브랜치에서. 리베이스된 코드를 원격 저장소로 푸시할 때 저장소 변경으로 인해 많은 사람들에게 문제가 발생할 것입니다.
프로젝트에 기여자가 여러 명인 경우 안전한 방법은 rebase 너의 현지의 공개 지점이 아닌 리포지토리. 마찬가지로 풀 요청이 코드 검토의 일부를 구성하는 경우 rebase. 또는 적어도 사용하지 마십시오 rebase 풀 리퀘스트 생성 후. 다른 개발자가 당신의 커밋을 볼 가능성이 있습니다. 즉, 해당 변경 사항이 퍼블릭 브랜치에 있음을 의미합니다. master 나뭇가지.
위험은 당신이 rebase 이미 원격 리포지토리로 푸시된 커밋과 다른 개발자가 이미 해당 커밋에 기반한 작업을 수행했을 수 있습니다. 당신의 지역 rebase 기존 커밋을 사라지게 만들 것입니다. 이러한 변경 사항을 저장소에 푸시하면 인기를 얻지 못할 것입니다.
다른 기여자들은 지저분한 과정을 거쳐야 할 것입니다. merge 작업을 저장소로 다시 푸시하도록 합니다. 그런 다음 변경 사항을 로컬 리포지토리로 다시 가져오면 중복된 변경 사항을 선택 해제해야 합니다.
리베이스하거나 리베이스하지 않습니까?
Rebase 프로젝트에서 불법일 수 있습니다. 지역적, 문화적 반대가 있을 수 있습니다. 일부 프로젝트 또는 조직은 다음을 고려합니다. rebase 이단의 한 형태이자 모독 행위입니다. 어떤 사람들은 Git 기록이 발생한 일에 대한 불가침의 영구적인 기록이어야 한다고 생각합니다. 그래서, rebase 테이블에서 벗어날 수 있습니다.
그러나 로컬에서 사설 지점에서 사용하면 rebase 유용한 도구입니다.
푸시 ~ 후에 리베이스하고 유일한 개발자인 지점으로 제한합니다. 또는 적어도 모든 개발이 중단되고 다른 누구도 브랜치의 커밋에서 벗어나 다른 작업을 기반으로 하지 않는 경우입니다.
그렇게 하면 문제를 피할 수 있습니다.
관련된: Git 버전 확인 및 업데이트 방법
