git分支模型的疑问

Question

如上图的一个成功分支模型。

我的疑问就是，在其他一些辅助性分支merge到develop分支之前，develop分支有改变，那么辅助性分支应该merge develop分支，与develop分支保持同步，但是从图上并看不出这个动作。

如果其他辅助性分支需要实时同步develop分支，那么用merge --no-ff，还是直接merge或者rebase呢？

那么这样一来图形是不是会变乱？

---

这是我本地测试的情况，都用的merge --no-ff模式合并

---

目前又遇到一个问题是，同一个分支不同人clone到本地，做开发，然后在push的时候，偶尔会发生一个merge动作，大概是这样的，在本地git push 的时候，提示需要先pull，此时git pull会自动执行一个merge动作，不知道大家遇到过这个问题没？

还有多人开发的时候，大家是不是都自己创建一个branch分支开发，而不是直接在远程的分支上做开发，比如develop是个远程分支，那么多人开发的时候clone到本地，直接在develop上开发，还是git checkout -b local branch开发？
ps:不知道描述清楚没.

Answer 1

제가 하라고 하면 할게요.
개발 전용 교환 코드에서 개발을 통해 분기된 여러 분기가 있으며 서로 병합되지 않습니다.

각 브랜치가 개발 브랜치를 동기화할 때 --rebase 옵션을 사용하여 개발의 최신 커밋을 개발 브랜치에 동기화한 다음 --no-ff 옵션을 사용하여 개발 브랜치를 다시 병합하여 개발을 유지합니다. 단일 브랜치의 무결성을 보장합니다.

Answer 2

이것은 merge --no-ff 모드를 사용하여 병합하는 내 로컬 테스트 상황입니다.

Answer 3

내가 교정한 이 글을 참고하시길 권합니다

http://fanyi.jobbole.com/2214/

예를 들어 hotfix 브랜치의 경우 개발 브랜치로 체크아웃하고 마지막에 병합해야 합니다

Hotfix 브랜치는 마스터 브랜치에서 빌드되며 개발 브랜치와 마스터 브랜치에 다시 병합되어야 합니다. Hotfix 브랜치는 hotfix-*

와 같이 이름을 지정할 수 있습니다.

Hotfix 브랜치는 릴리즈 브랜치와 어느 정도 유사합니다. 둘 다 새 버전 출시를 준비하기 위한 것이며, 둘 다 미리 알 수 없습니다. Hotfix 브랜치는 현재 프로덕션 환경을 기반으로 제품의 버그를 해결하기 위해 긴급히 필요하며 반드시 생성되어야 하는 브랜치입니다. 특정 버전의 제품에 즉시 해결해야 할 심각한 버그가 있는 경우, 마스터 브랜치의 버전에 해당하는 태그에서 Hotfix 브랜치를 빌드해야 합니다. 이 태그가 제품 버전을 표시하기 때문입니다

핫픽스 브랜치 생성

Hotfix 브랜치는 마스터 브랜치에서 생성됩니다. 예를 들어, 현재 온라인 버전 1.2 제품은 서버측 버그로 인해 시스템 문제가 발생하고 있습니다. 하지만 개발 브랜치에서 변경하는 것은 신뢰할 수 없으므로 핫픽스 브랜치를 만들고 문제 해결을 시작해야 합니다.

으아아아

브랜치를 생성한 후 버전 번호를 수정하는 것을 잊지 마세요.

그런 다음 버그를 해결하고 한 번 이상 제출하세요.

으아아아

핫픽스 브랜치 종료

작업을 완료한 후 해결된 버그 코드를 다시 마스터 브랜치에 병합해야 하지만, 다음 버전에서 버그가 해결되었는지 확인하기 위해 개발 브랜치에도 병합해야 합니다. 이것은 릴리스 브랜치와 매우 유사합니다.

먼저 마스터 브랜치를 병합하고 업데이트한 후 태그를 지정하세요.

으아아아

참고: -s 또는 -u 매개변수를 사용하여 태그의 태그 서명을 설정할 수 있습니다.

다음으로, bugfix 코드를 개발 브랜치에 병합하세요

으아아아

여기에는 몇 가지 예외가 있을 수 있습니다. 릴리스 브랜치가 있는 경우 핫픽스 브랜치를 개발 브랜치가 아닌 릴리스 브랜치에 병합해야 합니다. 릴리스 브랜치의 임무가 완료되면 릴리스 브랜치에 다시 병합된 버그 수정 코드는 결국 개발 브랜치에 병합됩니다. (개발 브랜치가 이러한 버그를 긴급하게 해결해야 하고 릴리스 브랜치가 끝날 때까지 기다릴 수 없는 경우 버그 수정 코드를 개발 브랜치에 안전하게 병합할 수 있습니다. 이 방법도 가능합니다.)

마지막으로 임시 지점을 삭제하세요

으아아아