Git Branch를 마스터에 병합하는 가장 좋은 (그리고 안전한) 방법은 무엇입니까?
질문
마스터에서 새 지점이 만들어지고, 우리는 테스트를 호출합니다.
다른 지사를 마스터하거나 작성하도록 커밋하고 나중에 마스터에 병합하는 몇 가지 개발자가 있습니다.
테스트 작업이 며칠이 걸리고 마스터 내부의 커밋으로 테스트를 계속 업데이트하고 싶습니다.
나는 기원을 테스트에서 당겨주는 것을 할 것입니다.
질문 1 :이게 올바른 접근이 있습니까?다른 개발자는 BTW를 사용한 것처럼 동일한 파일에서 쉽게 작동했을 수 있습니다.
테스트에 대한 나의 작품이 완료되고 마스터로 병합 할 준비가되어 있습니다.다음은 내가 생각할 수있는 두 가지 방법이 있습니다.
ㅏ:
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test
비:
git checkout test
git pull origin master
git checkout master
git merge test
저는 나의 이해로부터 rebase가 마스터와 스택의 변화를 얻을 것이므로 다른 사람들이 만든 다른 사람들을 덮어 쓸 수 있습니다.
질문 2 :이 두 가지 방법 중 어느 것이 맞습니까?그 차이점은 무엇입니까?
이 모든 것의 목표는 마스터에서 일어나는 일들과 함께 테스트 브랜치를 업데이트하고 나중에 타임 라인을 가능한 한 선형으로 유지하기 위해 마스터를 희망하는 마스터로 되돌릴 수 있습니다.
답변
어떻게해야할까요?
git checkout master
git pull origin master
git merge test
git push origin master
리모컨에서 로컬 지점이있는 경우, 나는 원격이있는 것보다 다른 지점을 병합하는 데 편안하지 않습니다.또한 나는 내가 추진하고 싶은 것에 만족할 때까지 나는 내 변화를 푸시하지 않을 것입니다. 나는 나와 나의 로컬 리포지토리만을 위해서만 할 것입니다.귀하의 설명에서 테스트는 단지 당신을위한 것 같습니다.그래서 그것을 게시 할 이유가 없습니다.
Git은 항상 당신과 다른 사람들이 변화를 존중하기를 시도합니다. 그래서 --rebase.나는 그것을 적절하게 설명 할 수 있다고 생각하지 않으므로 Git Book - Rebasing 또는 Git-Ready를 살펴보십시오. 조금 묘사를 위해 자랑으로 자랑하십시오.그것은 아주 멋진 기능입니다
답변
이것은 매우 실용적인 질문이지만 위의 모든 답변은 실용적이지 않습니다.
처럼
git checkout master
git pull origin master
git merge test
git push origin master
이 접근법에는 두 가지 문제가 있습니다.
It's unsafe, because we don't know if there are any conflicts between test branch and master branch.
It would "squeeze" all test commits into one merge commit on master; that is to say on master branch, we can't see the all change logs of test branch.
그래서, 우리가 상충되는 것에 의심되는 것으로 의심되는 경우, 우리는 다음 git 작업을 수행 할 수 있습니다 :
git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test
Commit 전에 테스트 병합, --no-ff의 Fast-Forward Commit을 피하십시오.
충돌이 발생하면 Git 상태를 실행하여 충돌에 대한 세부 사항을 확인하고 해결하려고 시도 할 수 있습니다.
git status
일단 갈등을 해결하거나 충돌이없는 경우, 우리는 그들을 저지고 밀어 넣습니다.
git commit -m 'merge test branch'
git push
그러나이 방법은 테스트 지점에 기록 된 변경 내역을 잃어 버리고 다른 개발자가 프로젝트의 역사를 이해하기 위해 마스터 브랜치가 어려울 것입니다.
따라서 가장 좋은 방법은 병합 대신 리베이스를 사용해야합니다 (이 시간에 우리는 지사 충돌을 해결했습니다).
다음은 고급 작업을 위해 간단한 샘플 하나뿐입니다. http://git-scm.com/book/en/v2/git-branching-rebasing을 참조하십시오.
git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test
네, 업포가 끝나면 모든 테스트 분기의 커밋이 마스터 지점의 머리로 옮겨집니다.리베이징의 주요 이점은 선형적이고 훨씬 청결한 프로젝트 기록을 얻는 것입니다.
피해야 할 유일한 것은 다음과 같습니다. 마스터 지점과 같은 공공 지점에서 Rebase를 사용하지 마십시오.
다음과 같이 운영을하지 마십시오.
git checkout master
git rebase -i test
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing에 대한 세부 정보
부록:
리베이식 작업에 대해 확실하지 않은 경우 https://git-scm.com/book/en/v2/git-branching-rebasing을 참조하십시오.
답변
오래된 스레드,하지만 나는 그것을하는 방법을 찾지 못했습니다.리베이즈와 함께 일하는 사람에게 귀중한 일과 마스터 맨 위에있는 (특징) 지점에서 모든 커밋을 병합하려고합니다.갈등이있는 경우 모든 커밋을 위해 해결할 수 있습니다.프로세스 중에 완전한 제어를 유지하고 언제든지 중단 할 수 있습니다.
마스터와 브랜치를 최신 정보 가져 오기 :
git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>
마스터 맨 위에있는 분기 병합 :
git checkout <branch_name>
git rebase master
선택 사항 : Rebase 동안 충돌로 실행되는 경우 :
첫째, 충돌을 파일로 해결하십시오.그 다음에:
git add .
git rebase --continue
언제든지 Rebase를 중단 할 수 있습니다.
git rebase --abort
리베이제 지점을 밀어 넣으십시오.
git push origin <branch_name>
이 분기가 이전에 푸시 된 경우, 힘 푸시로 재정의해야합니다.
git push origin -f <branch_name>
그렇게하기 전에 강제 푸시가 원격 저장소의 이전 버전을 무시하기 때문에 현재 로컬 지점이 귀하의 기대치와 일치하는지 여부를 확인하십시오.
이제 두 가지 옵션이 있습니다.
a) PR (예 : gitHub)을 만들고, UI를 통해 거기서 병합하십시오 b) 명령 줄에서 돌아가서 브랜치를 마스터에 병합하십시오.
git checkout master
git merge --no-ff <branch_name>
git push origin master
완료.
답변
먼저 가능한 한 깨끗한 분기를 먼저 만들 것입니다.테스트를 실행하고 상태가 원하는대로 확인하십시오.GIT 스쿼시로 새로운 커밋을 정리하십시오.
Kingcrunches 답변 외에도 사용하는 것이 좋습니다
git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master
다른 지점에서만 많은 커밋을했을 수도 있습니다. 이는 마스터 브랜치에서만 하나의 커밋 만해야합니다.Commit History를 가능한 한 청결하게 유지하려면 테스트 브랜치에서 테스트 브랜치의 모든 커밋을 마스터 브랜치에서 하나의 커밋으로 스쿼시 할 수 있습니다 (또한 : git : 스쿼시를 스쿼시 할 수 없거나 스쿼시하지 않으려면).그런 다음 커밋 메시지를 매우 표현적으로 쓸 수 있습니다.읽고 이해하기 쉽고, 코드를 파고하지 않고도 읽는 것이 쉽지 않습니다.
편집 : 관심이있을 수 있습니다
GIT에서는 병합과 리베이즈의 차이점은 무엇입니까? vs.bsing. 끌어 오기 요청을 리베이스하는 방법
그래서 GitHub에서는 Feature Branch MyBranch에 대해 다음을 수행합니다.
원산지에서 최신 정보를 얻으십시오
$ git checkout master
$ git pull origin master
병합베이스 해시를 찾으십시오.
$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f
$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f
이제 첫 번째가 선택되어 있는지 확인하십시오. 나머지는 다음과 같습니다.
pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better
다음으로 아주 좋은 커밋 메시지를 선택하고 GitHub에 밀어 넣으십시오.당김 요청을하십시오.
끌어 오기 요청을 병합 한 후에는 로컬로 삭제할 수 있습니다.
$ git branch -d mybranch
그리고 github에
$ git push origin :mybranch
답변
Rebase 또는 Merge는 누군가의 변경 사항을 덮어 쓰지 않아도됩니다 (충돌을 해결할 때 그렇게하도록 선택하지 않는 한).
개발 중 일반적인 접근 방식은입니다
git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier
마스터에 다시 병합 할 준비가되면,
git checkout master
git log ..test # if you're curious
git merge test
git push
병합에서 무언가를 깨는 것에 대해 걱정하는 것에 대해 걱정하면 Git Merge - 활성화가 있습니다.
푸시를 사용하여 병합 수단으로 당기는 방법은 어리 석다.또한 왜 당신이 테스트를 원산지로 밀어 넣는지 확신하지 못합니다.
답변
@ Kingcrunch의 대답은 많은 경우에 작동해야합니다.발생할 수있는 한 가지 문제는 최신 테스트를 눌러야하는 다른 시스템에있을 수 있습니다.테스트를 먼저 당기는 것이 좋습니다.개정판은 다음과 같습니다.
git checkout test
git pull
git checkout master
git pull origin master
git merge test
git push origin master
최근댓글