2013-07-25 3 views
29

git repo에 개발 분기와 기능 분기가 있습니다. 개발 커밋을 추가 했으므로 커밋을 내 지사에 병합하고 싶습니다. 내가 이렇게하면개발 분기에서 git 커밋을 기능 분기로 병합하는 방법

git checkout feature 
git merge develop 

나는 병합 커밋으로 끝난다. 새 커밋을 내 기능 분기로 자주 병합 할 것이므로 이러한 모든 불필요한 병합 커밋을 피하고 싶습니다. git rebase develop을 제안한이 answer을 보았지만 너무 멀리 내 브랜치를 되감 으면 끝나고 rebase가 실패합니다.

는 업데이트 : 내가하고 결국 무엇 는

git checkout feature 
git merge develop # this creates a merge commit that I don't want 
git rebase # this gets rid of the merge commit but keeps the commits from develop that I do want 
git push 

업데이트했다 : 난 그냥 내가 다음 기능 분기로 리베이스 병합 할 때 원래의 개발에 다른 해시를 가져옵니다 커밋 것으로 나타났습니다. 나는 그것이 내가 원하는 것을 생각하지 않는다. 왜냐하면 결국 나는 기능을 다시 개발하게 될 것이고 나는 이것이 훌륭하게 작동하지 않을 것이라고 생각한다.

+0

음, 잘 브랜치에 많은 커밋을하지 않는 방법으로 rebase 할 때 커밋을 "스쿼시"할 수 있다는 것을 잘 알고 있습니다. http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html을 확인하십시오. – Houdini

+4

Rebasing * is * 대답입니다. 작동하지 않는 경우, 왜 작동하지 않는지 물어 보는 또 다른 질문이 있습니다. – meagar

답변

29

한 브랜치를 다른 브랜치에 통합하려면 병합하거나 리베이스해야합니다. 다른 곳에서 참조되지 않은 커밋을 리베이스하는 것은 안전하기 때문에 (다른 로컬 브랜치에 병합되지 않고 원격에 푸시되지 않음) 일반적으로 병합하는 것이 좋습니다.

지형지 물 지점이 순수 로컬 인 경우 개발 단계에서 리베이스 할 수 있습니다. 그러나 rebase가 작동하는 방법을 이해하는 데는 시간이 걸리며 실수하기 전에 실수로 중복되거나 삭제 된 커밋을 생성하기가 쉽습니다. 병합 커밋은 시끄러운 것처럼 보일 수 있지만 병합은 항상 안전하고 예측 가능하도록 보장됩니다.

더 나은보기를 들어, 그래프에서 모든 것을 함께 로그인을 시도 :

git log --all --graph --oneline --decorate 

그것은 당신이 정말 필요develop에 커밋 feature에 병합 여부를 고려하고도 가치가있다. 종종 그들은 feature이 나중에 develop에 합병 될 때까지 분리 될 수있는 것들입니다.

정기적으로 featuredevelop 코드가 필요하다고 판단되는 경우 기능 분기가 너무 오래 실행되는 징후 일 수 있습니다. 이상적인 기능은 길을 따라 정기적으로 통합 할 필요없이 독립적으로 작업 할 수있는 방식으로 분할되어야합니다.

11

당신은 단지 하나가 develop 지점에서 커밋하려는 경우 당신은 당신의 feature 지점에서 그것을 벚꽃 - 선택할 수 있습니다 :

(가) 지사의 상단에 새로 적용됩니다 커밋
git checkout feature 
git cherry-pick -x <commit-SHA1> 

(그것은 아무튼 제공 충돌을 일으키지 않습니다.) 그리고 feature 브랜치를 병합하면 Git은 충돌없이이를 처리 할 것입니다.