Git 브랜치를 안전하게 마스터에 병합하려면 어떻게 해야 합니까?

Git 브랜치를 안전하게 마스터에 병합하려면 어떻게 해야 합니까?

의 새로운 master우리는 그것을 창조라고 부릅니다.test.

다음을 약속하는 여러 개발자가 있습니다.master또는 다른 분기를 만들고 나중에 에 병합합니다.master.

작업을 수행합니다.test며칠이 걸리고 계속 유지하기를 원합니다.test master.

는 그게요를 할 입니다.git pull origin mastertest.

질문 1: 올바른 접근 방식입니까?다른 개발자들도 제가 작업했던 것과 같은 파일을 쉽게 작업할 수 있었을 것입니다.

---

에 대한 의 작업test완료되었으며 다시 통합할 준비가 되었습니다.master제가 생각할 수 있는 두 가지 방법은 다음과 같습니다.

A:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B:

git checkout test
git pull origin master
git checkout master
git merge test

사용하지 않습니다.--rebase내가 알기로는, 리베이스는 변화를 얻을 것이기 때문입니다.master다른 사람들이 변경한 내용을 덮어쓸 수 있도록 내 것을 쌓아 올립니다.

질문 2: 이 두 가지 방법 중 올바른 방법은 무엇입니까?그곳의 차이점은 무엇입니까?

이 모든 것의 목표는 나를 지키는 것입니다.test에서 일어나는 일들로 업데이트된 지점.master그리고 나중에 나는 그들을 다시 통합할 수 있었습니다.master타임라인을 가능한 한 직선으로 유지하기를 희망합니다.

어떻게 하면 좋을까요?

git checkout master
git pull origin master
git merge test
git push origin master

원격 지점에서 로컬 지점을 사용하는 경우 이 지점이 아닌 다른 지점을 원격 지점과 병합하는 것이 불편합니다.또한 저는 제가 추진하고자 하는 것에 만족할 때까지 변경사항을 추진하지 않을 것이며 저와 로컬 저장소만을 위한 것을 전혀 추진하지 않을 것입니다.당신의 설명에 따르면, 그것은test오직 당신만을 위한 것입니까?그래서 그것을 출판할 이유가 없습니다.

의 것을 변화도 그럴 입니다.--rebase적절하게 설명할 수 없을 것 같으니 Git book - Rebasing orget-ready: 약간의 설명을 위해 기본 재배치에 대해 소개합니다.꽤 멋진 기능입니다.

이것은 매우 실용적인 질문이지만, 위의 모든 답변은 실용적이지 않습니다.

맘에 들다

git checkout master
git pull origin master
git merge test
git push origin master

이 접근 방식에는 두 가지 문제가 있습니다.

1. 테스트 브랜치와 마스터 브랜치 간에 충돌이 있는지 알 수 없기 때문에 안전하지 않습니다.

2. 그러면 모든 테스트 커밋이 마스터에서 하나의 병합 커밋으로 "스퀴즈"됩니다. 즉, 마스터 분기에서는 테스트 분기의 모든 변경 로그를 볼 수 없습니다.

따라서 충돌이 발생할 것으로 예상되는 경우 다음과 같은 GIT 작업을 수행할 수 있습니다.

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

험merge 앞에commit에의 을피결함에 의한 .--no-ff,

충돌이 발생하면, 우리는 실행할 수 있습니다.git status 사항을 하고 해결하려고 합니다.

git status

일단 우리가 갈등을 해결하거나, 갈등이 없다면, 우리는commit그리고.push그들.

git commit -m 'merge test branch'
git push

그러나 이렇게 하면 테스트 브랜치에 기록된 변경 내역이 손실되고 마스터 브랜치는 다른 개발자가 프로젝트의 내역을 이해하기 어렵게 됩니다.

그래서 가장 좋은 방법은 우리가 사용해야 하는 것입니다.rebase에 merge(따라서 이 시점에서 분기 충돌을 해결했습니다.)

다음은 간단한 샘플입니다. 고급 작업은 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
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 checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

다른 분기에서 여러 번 커밋을 수행했을 수 있으며, 이는 마스터 분기에서 하나의 커밋이어야 합니다.커밋 기록을 최대한 깨끗하게 유지하려면 테스트 분기의 모든 커밋을 마스터 분기의 하나의 커밋으로 압축할 수 있습니다(다음 항목 참조).Git: 스쿼시를 할 것인가, 안 할 것인가?그런 다음 커밋 메시지를 매우 표현적인 것으로 다시 작성할 수도 있습니다.코드를 파고들지 않고 읽고 이해하기 쉬운 것.

편집: 관심이 있을 수 있습니다.

• git에서 병합 --squash와 rebase의 차이점은 무엇입니까?
• 병합 대.리베이스
• 꺼내기 요청의 기본값을 변경하는 방법

GitHub에 과 같은 작업을 .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에 푸시합니다.그러면 꺼내기 요청을 합니다.

꺼내기 요청을 병합한 후 로컬에서 삭제할 수 있습니다.

$ git branch -d mybranch

GitHub에서

$ git push origin :mybranch

오래된 실입니다만, 아직 방법을 찾지 못했습니다.기본 재배치로 작업하고 마스터 위에 있는 (기능) 분기의 모든 커밋을 병합하려는 사용자에게 유용할 수 있습니다.도중에 충돌이 발생하면 모든 커밋에 대해 충돌을 해결할 수 있습니다.프로세스 중에는 완전한 제어를 유지하며 언제든지 중단할 수 있습니다.

마스터 및 분기를 최신 상태로 가져오기:

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

선택 사항:기본 재배치 중에 충돌이 발생하는 경우:

먼저 파일에서 충돌을 해결합니다.그러면:

git add .
git rebase --continue

다음을 사용하여 언제든지 보강 철근을 중단할 수 있습니다.

git rebase --abort

재배치된 분기 푸시:

git push origin <branch_name>

이전에 이 분기를 푸시한 경우 강제 푸시를 사용하여 브랜치를 재정의해야 합니다.

git push origin -f <branch_name>

강제 푸시는 원격 저장소의 이전 브랜치를 재정의하므로 이 작업을 수행하기 전에 현재 로컬 브랜치가 예상과 일치하는지 항상 확인하십시오.

이제 두 가지 옵션이 있습니다.

• PR(예: GitHub)을 만들고 UI를 통해 PR을 병합합니다.
• 명령줄로 돌아가서 분기를 마스터로 병합

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

이렇게 하면 테스트 분기를 변경한 사용자가 자신이 변경한 내용을 알고 있기 때문에 더 잘 수행할 수 있습니다.

저는 리베이스 방법을 사용할 것입니다.대부분 의미론적으로 사례를 완벽하게 반영하기 때문입니다. 즉, 현재 지점의 상태를 새로 고치고 최신 지점에 기반을 둔 것처럼 "가장"하는 것이 좋습니다.

그래서, 체크아웃도 하지 않고,master제가 할 일:

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

물론, 단지 원점에서 가져온다고 해서 로컬 상태가 새로 고쳐지는 것은 아닙니다.master(합병을 수행하지 않기 때문에) 그러나 우리의 목적에 완벽하게 부합합니다. 우리는 시간을 절약하기 위해 전환하는 것을 피하고 싶습니다.

@킹크런치의 대답은 많은 경우에 효과가 있을 것입니다.한 가지 문제가 발생할 수 있는 것은 테스트에서 최신 정보를 가져와야 하는 다른 컴퓨터에 있을 수 있다는 것입니다.그래서 저는 먼저 당기기 테스트를 추천합니다.개정 내용은 다음과 같습니다.

git checkout test
git pull
git checkout master
git pull origin master
git merge test
git push origin master

개발 및 기능 분기에 따라 답변을 드리겠습니다.

기능 분기에 있고 develop으로 업데이트해야 하는 경우 다음 명령을 사용합니다.

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] -- 인내도 참조하십시오.

용도:

git fetch
git merge -s recursive -X patience origin/master

깃 별칭

이 경우 항상 별칭을 사용합니다(예: 한 번 실행:

 git config --global alias.pmerge 'merge -s recursive -X patience'

이제 다음을 수행할 수 있습니다.

git fetch
git pmerge origin/master

다음 작업을 수행할 때 항상 병합 충돌이 발생합니다.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

풀링은 마스터에 병합되는 것을 의미하기 때문에 풀링하려면 분기를 체크아웃해야 하며 병합할 워크 트리가 필요합니다.

git checkout master
git pull

먼저 체크아웃할 필요가 없습니다. 기본 재배치는 두 개의 인수로 올바른 작업을 수행합니다.

git rebase master test  

git checkout master
git merge test

git push는 기본적으로 원격과 여기에 존재하는 모든 분기를 푸시합니다.

git push
git checkout test

GitLab에서 제공하는 내용입니다. 지침을 따르십시오.

여기에 이미 좋은 답변들이 많이 있습니다.나는 단지 내가 하는 단계를 추가하는 것입니다.

git fetch -p
git checkout master
git rebase origin/master
git checkout test
git rebase master

설명.

git fetch -p하고 "" " " " " 은 검색됩니다.-p오래된 분기를 삭제하여 분기를 자릅니다.

git checkout master branch를 해 보세요.

git rebase origin/master업데이트합니다.master브랜치. 여기서 당기면 같은 결과를 얻을 수 있습니다.

git checkout test을 경한지확에서 하세요.

git rebase master업데이트합니다.test에 변경 master "" " " " " " " " " " " " 를 .git rebase --continue또는git rebase --abort

언급URL : https://stackoverflow.com/questions/5601931/how-do-i-safely-merge-a-git-branch-into-master