질문자 :moe
master 에서 새 분기가 생성되고 이를 test 라고 합니다.
master 커밋하거나 다른 분기를 만든 다음 나중에 master 병합하는 개발자가 여러 명 있습니다.
test 작업에 며칠이 걸리고 master 내부의 커밋으로 test 를 지속적으로 업데이트하려는 경우를 가정해 보겠습니다.
test 에서 git pull origin master 를 할 것입니다.
질문 1: 이것이 올바른 접근 방식입니까? 다른 개발자는 내가 btw에서 작업한 것과 동일한 파일에서 쉽게 작업할 수 있습니다.
test 작업 master 에 병합할 준비가 되었습니다. 다음은 내가 생각할 수 있는 두 가지 방법입니다.
NS:
git checkout test git pull origin master git push origin test git checkout master git pull origin test
NS:
git checkout test git pull origin master git checkout master git merge test
내 이해에서 rebase는 master 의 변경 사항을 가져오고 그 위에 내 스택을 쌓아서 다른 사람들이 만든 변경 사항을 덮어쓸 수 --rebase 사용하지 않습니다.
질문 2: 이 두 가지 방법 중 어느 것이 옳습니까? 그곳의 차이점은 무엇입니까?
이 모든 것의 목표는 내 test master 에서 일어나는 일들로 업데이트하는 것이며 나중에 타임라인을 가능한 한 선형으로 유지하기 위해 master 로 다시 병합할 수 있습니다.
어떻게 하면 좋을까
git checkout master git pull origin master git merge test git push origin master
원격 지점의 로컬 지점이 있는 경우 이 지점이 아닌 다른 지점을 원격 지점과 병합하는 것이 불편합니다. 또한 내가 푸시하고 싶은 것에 만족할 때까지 변경 사항을 푸시하지 않을 것이고 또한 전혀 푸시하지 않을 것입니다. 이는 저와 제 로컬 저장소에만 해당됩니다. 설명에 따르면 그 test 는 당신만을 위한 것입니까? 그래서 공개할 이유가 없습니다.
git은 항상 당신과 다른 사람들의 변경 사항을 존중하려고 시도하며 --rebase 입니다. 나는 그것을 적절하게 설명할 수 없다고 생각합니다. 그래서 Git 책 - Rebasing or git-ready: Intro into rebasing for a little description을 참조하십시오. 상당히 멋진 기능입니다
이것은 매우 실용적인 질문이지만 위의 모든 답변은 실용적이지 않습니다.
좋다
git checkout master git pull origin master git merge test git push origin master
이 접근 방식에는 두 가지 문제 가 있습니다.
테스트 브랜치와 마스터 브랜치 사이에 충돌이 있는지 알 수 없기 때문에 안전하지 않습니다.
모든 테스트 커밋을 마스터에 대한 하나의 병합 커밋으로 "압축"합니다. 즉, 마스터 브랜치에서는 테스트 브랜치의 모든 변경 로그를 볼 수 없습니다.
따라서 충돌이 있을 것으로 의심되면 다음과 같은 git 작업을 수행할 수 있습니다.
git checkout test git pull git checkout master git pull git merge --no-ff --no-commit test
commit 하기 전에 merge 을 테스트 --no-ff 로 빨리 감기 커밋을 피하십시오.
충돌이 발생하면 git status 를 실행하여 충돌에 대한 세부 정보를 확인하고 해결을 시도할 수 있습니다.
git status
충돌을 해결하거나 충돌이 없으면 commit 하고 push 합니다.
git commit -m 'merge test branch' git push
그러나 이렇게 하면 테스트 브랜치에 기록된 변경 내역이 손실되고 마스터 브랜치가 다른 개발자가 프로젝트 내역을 이해하기 어렵게 됩니다.
따라서 가장 좋은 방법은 merge rebase 를 사용해야 하는 것입니다(이때 분기 충돌을 해결했다고 가정).
다음은 고급 작업에 대한 간단한 샘플입니다. 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에 대한 세부 정보
부록:
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 --abort 가 당신을 위해 있습니다.
병합의 수단으로 푸시 및 풀을 사용하는 것은 어리석은 일입니다. 또한 테스트를 원점으로 밀어 넣는 이유를 잘 모르겠습니다.
먼저 병합할 분기를 가능한 한 깨끗하게 만듭니다. 테스트를 실행하고 원하는 상태인지 확인하십시오. git squash 로 새 커밋을 정리합니다.
KingCrunches 답변 외에도 다음을 사용하는 것이 좋습니다.
git checkout master git pull origin master git merge --squash test git commit git push origin master
다른 브랜치에서 많은 커밋을 수행했을 수 있으며 이는 마스터 브랜치에서 단 하나의 커밋이어야 합니다. 커밋 기록을 가능한 한 깨끗하게 유지하려면 테스트 브랜치의 모든 커밋을 마스터 브랜치의 하나의 커밋으로 스쿼시할 수 있습니다( Git: 스쿼시 또는 스쿼시하지 않음? 참조 ). 그런 다음 커밋 메시지를 매우 표현적인 것으로 다시 작성할 수도 있습니다. 코드를 파헤칠 필요 없이 읽고 이해하기 쉬운 것.
편집: 관심이 있을 수 있습니다
mybranch 기능 분기에 대해 다음을 수행합니다.
출처에서 최신 정보 받기
$ git checkout master $ git pull origin master
병합 기본 해시를 찾습니다.
$ git merge-base mybranch master c193ea5e11f5699ae1f58b5b7029d1097395196f $ git checkout mybranch $ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f
이제 첫 번째만 pick 이고 나머지는 s 인지 확인하십시오.
pick 00f1e76 Add first draft of the Pflichtenheft s d1c84b6 Update to two class problem s 7486cd8 Explain steps better
다음으로 아주 좋은 커밋 메시지를 선택하고 GitHub에 푸시합니다. 그런 다음 pull 요청을 합니다.
pull 요청을 병합한 후 로컬에서 삭제할 수 있습니다.
$ git branch -d mybranch
그리고 GitHub에서
$ git push origin :mybranch
오래된 스레드,하지만 나는 그것을하는 방법을 찾지 못했습니다. rebase로 작업하고 (기능) 분기의 모든 커밋을 마스터 위에 병합하려는 사람에게 유용할 수 있습니다. 도중에 충돌이 있으면 커밋할 때마다 해결할 수 있습니다. 프로세스 중에 모든 권한을 유지하고 언제든지 중단할 수 있습니다.
마스터 및 브랜치를 최신 상태로 유지:
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
다음을 사용하여 언제든지 리베이스를 중단할 수 있습니다.
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
완료.
이것은 내가 팀과 함께 일할 때 사용하는 워크플로입니다. 시나리오는 설명한 대로입니다. 첫째, test test 브랜치에서 작업하는 동안 마스터에 추가된 모든 것을 가져오기 위해 마스터로 리베이스합니다.
git pull -r upstream master
test 분기를 분기한 이후 변경 사항을 마스터로 가져와 적용한 다음 마스터의 현재 상태 "위에서" 테스트하기 위해 변경한 사항을 적용합니다. 테스트에서 편집한 것과 동일한 파일을 다른 사람이 변경한 경우 여기에 충돌이 있을 수 있습니다. 있는 경우 수동으로 수정하고 커밋해야 합니다. 이 작업을 완료하면 마스터 브랜치로 전환하고 문제 없이 test
git checkout master git pull origin master # Merge branch test into master git merge test
병합 후 파일이 변경된 경우 병합할 때 "충돌 해결" 오류가 발생합니다.
따라서 먼저 모든 충돌을 해결한 다음 모든 변경 사항을 다시 커밋한 다음 푸시해야 합니다.
git push origin master
테스트 브랜치에서 변경을 수행한 사람은 자신이 수행한 변경 사항을 알고 있었기 때문에 이렇게 하는 것이 좋습니다.
나는 rebase 방법을 사용할 것입니다. 대부분 의미 론적으로 귀하의 사례를 완벽하게 반영하기 때문입니다. 당신이하고 싶은 것은 현재 분기의 상태를 새로 고치고 최신 분기를 기반으로하는 것처럼 "척"하는 것입니다.
master 확인하지도 않고 다음을 수행합니다.
git fetch origin git rebase -i origin/master # ...solve possible conflicts here
master 의 로컬 상태가 새로 고쳐지지는 않지만(병합을 수행하지 않기 때문에), 우리의 목적에는 완벽하게 괜찮습니다. 시간을 절약하기 위해 전환을 피하고 싶습니다.
@KingCrunch의 답변은 많은 경우에 작동해야 합니다. 발생할 수 있는 한 가지 문제는 테스트에서 최신 정보를 가져와야 하는 다른 컴퓨터에 있을 수 있다는 것입니다. 따라서 먼저 풀링 테스트를 권장합니다. 개정판은 다음과 같습니다.
git checkout test git pull git checkout master git pull origin master git merge test git push origin master
나는 개발 및 기능 분기에 따라 대답 할 것입니다.
기능 분기에 있고 개발로 업데이트해야 하는 경우 아래 명령을 사용하십시오.
git checkout develop git pull git checkout feature/xyz git merge develop
이제 feature/xyz develop 분기로 업데이트되고 feature/xyz 로 푸시할 수 있습니다.
제목이 "Best way" 처럼 인내 병합 전략을 생각해보는 것도 좋은 생각이라고 생각합니다.
발신: https://git-scm.com/docs/merge-strategies
이 옵션을 사용하면 'merge-recursive'는 중요하지 않은 일치 라인(예: 고유한 함수의 중괄호)으로 인해 가끔 발생하는 병합 오류를 피하기 위해 약간의 추가 시간을 소비합니다. 병합할 가지가 심하게 갈라졌을 때 사용합니다. git-diff[1] --patience도 참조하십시오.
용법:
git fetch git merge -s recursive -X patience origin/master
Git 별칭
나는 이것을 위해 항상 별칭을 사용합니다. 예를 들어 한 번 실행:
git config --global alias.pmerge 'merge -s recursive -X patience'
이제 다음을 수행할 수 있습니다.
git fetch git pmerge origin/master
풀링은 마스터에 병합을 의미하고 병합할 작업 트리가 필요하기 때문에 풀하려면 분기를 체크아웃해야 합니다.
git checkout master git pull
먼저 체크아웃할 필요가 없습니다. rebase는 두 개의 인수로 올바른 작업을 수행합니다.
git rebase master test git checkout master git merge test
git push 기본적으로 여기와 원격에 존재하는 모든 분기를 푸시합니다.
git push git checkout test
이것은 GitLab에서 가져온 것입니다. 지침을 따르십시오.
git merge feature-branch 만 수행하면 항상 병합 충돌이 발생합니다. 이것은 나를 위해 작동하는 것 같습니다 :
git checkout -b feature-branch
많은 코드 변경을 수행하십시오 ...
git merge -s ours master
git checkout master
git merge feature-branch
또는
git checkout -b feature-branch
많은 코드 변경을 수행하십시오 ...
git checkout master
git merge -X theirs feature-branch
출처 : http:www.stackoverflow.com/questions/5601931/what-is-the-best-and-safest-way-to-merge-a-git-branch-into-master