git은 왜 기본적으로 빨리 감기 병합을 실행합니까?

git은 왜 기본적으로 빨리 감기 병합을 실행합니까?

저는 수은주 출신이라 나뭇가지를 사용하여 특징을 정리합니다.당연히 이 일의 흐름도 제 역사에서도 보고 싶습니다.

git을 사용하여 새로운 프로젝트를 시작하고 첫 번째 기능을 마쳤습니다.기능을 Marge 할 때 git이 fastforward를 사용하고 있다는 것을 깨달았습니다.즉, 가능하면 마스터 브랜치에 직접 변경을 적용하고 브랜치를 잊어버립니다.

미래에 대해 생각해 봅시다.이 프로젝트는 저 혼자만 하고 있어요.git의 디폴트 어프로치(빠른 머지)를 사용하면, 내 이력은 하나의 거대한 마스터 브랜치가 됩니다.모든 기능에 대해 개별 브랜치를 사용했다는 것은 아무도 모릅니다.결국 그 거대한 마스터 브랜치만 사용하게 되기 때문입니다.프로답지 않게 보이지 않을까요?

이 추론에 따르면, 저는 빨리 감기 병합을 원하지 않으며 왜 그것이 기본인지 알 수 없습니다.그게 뭐가 그리 좋아요?

패스트 포워드 머지는 짧은 브런치에서는 의미가 있지만 복잡한 이력에서는 비퍼스트 포워드 머지를 사용하면 이력을 이해하기 쉬워지고 커밋 그룹을 되돌리기 쉬워집니다.

경고: 비패스트 포워딩에는 잠재적인 부작용도 있습니다.https://sandofsky.com/blog/git-workflow.html,의 'no-ff'를 리뷰하여 이중화 또는 비난이 깨지는 '체크포인트 커밋'을 피하고, 이 방법이 고객의 기본 접근법인지 신중하게 고려하시기 바랍니다.master.

^{(nvie.com에서 Vincent Driessen, "A successful Git branching model" 게시)}

개발에 완성된 기능 포함

종료된 기능은 개발 브랜치에 통합되어 다음 릴리스에 추가할 수 있습니다.

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

--no-ffflag를 지정하면 머지가 패스트포워드로 실행될 수 있는 경우에도 머지는 항상 새로운 커밋개체를 만듭니다.이것에 의해, 기능 브랜치의 이력에 관한 정보가 손실되는 것을 방지해, 기능을 추가한 커밋을 그룹화합니다.

Jakub Narbski 에서는 설정에 대해서도 언급하고 있습니다.

기본적으로 Git은 현재 커밋의 하위인 커밋을 병합할 때 추가 병합 커밋을 생성하지 않습니다.대신 현재 분기의 끝부분이 빨리 감기됩니다.
「 」로 되어 있는 .false 경우 Git에 「Git」 「Git」 「」 「」 「」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git」 「Git--no-ff옵션을 선택합니다).
」로 .only는,됩니다(「, 」의 「마지」의 「마지」의 「마지」의 「마지」의 「마지」의 「마지」의 「마지」의 「마지」의 「마지」의 「마지」의 「마지」의 「마지」에 합니다).--ff-only옵션을 선택합니다).

---

다음과 같은 이유로 패스트포워드가 기본입니다.

• 단명 브랜치는 Git에서 매우 쉽게 만들고 사용할 수 있습니다.
• 단명 브랜치는 종종 그 브랜치 내에서 자유롭게 재구성할 수 있는 많은 커밋을 분리한다
• 이러한 커밋은 실제로 메인 브랜치의 일부입니다.재구성되면 메인 브랜치가 신속하게 그것들을 포함시킬 수 있습니다.

단, 1개의 토픽/기능 브랜치로 반복 워크플로우를 상정하고 있는 경우(즉, 머지 후 이 기능 브랜치로 돌아가서 커밋을 추가하는 경우), 기능 브랜치의 모든 중간 커밋이 아닌 메인 브랜치에 머지만 포함하는 것이 편리합니다.

이 경우, 다음과 같은 종류의 설정 파일을 설정할 수 있습니다.

[branch "master"]
# This is the list of cmdline options that should be added to git-merge 
# when I merge commits into the master branch.

# The option --no-commit instructs git not to commit the merge
# by default. This allows me to do some final adjustment to the commit log
# message before it gets commited. I often use this to add extra info to
# the merge message or rewrite my local branch names in the commit message
# to branch names that are more understandable to the casual reader of the git log.

# Option --no-ff instructs git to always record a merge commit, even if
# the branch being merged into can be fast-forwarded. This is often the
# case when you create a short-lived topic branch which tracks master, do
# some changes on the topic branch and then merge the changes into the
# master which remained unchanged while you were doing your work on the
# topic branch. In this case the master branch can be fast-forwarded (that
# is the tip of the master branch can be updated to point to the tip of
# the topic branch) and this is what git does by default. With --no-ff
# option set, git creates a real merge commit which records the fact that
# another branch was merged. I find this easier to understand and read in
# the log.

mergeoptions = --no-commit --no-ff

---

OP는 코멘트에 다음과 같이 추가합니다.

[단수명] 브런치에서는 fast-forward에 의미가 있다고 생각합니다만, 그것을 디폴트 액션으로 하는 것은 git가 당신을 상정하고 있는 것을 의미합니다.가지치기 쉽다[단명하다]합리적인가요?

Jefromi는 다음과 같이 대답:

지사의 수명은 사용자마다 크게 다르다고 생각합니다.다만, 경험이 풍부한 유저들 사이에서는, 수명이 짧은 브랜치를 훨씬 더 많이 가지는 경향이 있을 것입니다.

단수명 브랜치는 특정 작업(재기성, 가능성이 높거나 패치 적용 및 테스트 속도가 빠름)을 쉽게 하기 위해 작성한 브랜치이며, 작업이 완료되면 즉시 삭제합니다.
즉, 분기된 토픽 브랜치로 흡수되어 토픽 브랜치가 하나의 브랜치로 병합됩니다.그 기능을 실장하는 일련의 커밋을 작성하기 위해서, 내가 내부에서 무엇을 했는지 알 필요는 없습니다.

보다 일반적으로 다음과 같이 덧붙입니다.

실제로 개발 워크플로우에 따라 달라집니다.

• 선형일 경우 하나의 분기가 의미가 있습니다.
• 기능을 분리하여 장기간 작업하고 여러 번 병합해야 하는 경우 여러 분기가 적합합니다.

"언제 분기해야 합니까?"를 참조하십시오.

실제로 Mercurial 브랜치모델을 고려할 때 그 핵심 브랜치는 저장소마다 1개씩 있습니다(익명의 헤드, 북마크, 명명된 브랜치까지 작성할 수 있습니다).
"Git and Mercurial - 비교 및 대비"를 참조하십시오.

Mercurial은 기본적으로 익명의 경량 코드라인을 사용하며, 용어로는 "헤드"라고 합니다.
Git은 원격 저장소의 지점 이름을 원격 추적 지점 이름에 매핑하는 주입 매핑을 통해 경량 명명된 지점을 사용합니다.
Git은 브랜치 이름을 붙이도록 강제합니다(단, 이름 없는 브랜치(Detached HEAD)라는 상황을 제외하고). 그러나 이것은 하나의 저장소 패러다임에서 여러 브랜치를 의미하는 토픽 브랜치 워크플로우와 같은 브랜치 부하가 높은 워크플로우에서 더 잘 작동한다고 생각합니다.

VonC의 매우 포괄적인 답변에 대해 조금 더 자세히 설명하겠습니다.

---

첫째, 내 기억이 정확하다면 Git은 기본적으로 Fast-Forward 케이스에서 병합 커밋을 생성하지 않는다는 사실은 두 개의 저장소를 동기화하기 위해 상호 풀(대부분의 사용자 설명서에서 찾을 수 있는 워크플로우)을 사용하는 단일 브랜치 "동일한 저장소"를 고려하는 데서 비롯되었다."Git 사용자 매뉴얼" 및 "예시에 의한 버전 관리"를 포함합니다.이 경우 풀 기능을 사용하여 완전히 실현된 분기를 병합하지 않고 다른 작업에 보조를 맞추기 위해 사용합니다.나중에 저장하기 위해 저장소에 저장 및 저장된 동기화를 수행했을 때 일시적이고 중요하지 않은 사실이 있으면 안 됩니다.

기능 분기와 단일 저장소에 여러 분기가 있는 것은 나중에야 유용하게 사용되었으며, 병합 지원이 잘되고 다양한 병합 기반 워크플로우를 사용해 볼 수 있습니다.그 때문에, Mercurial은, 「Mercurial:」의 낡은 리비전에 나타나 있듯이, 저장소 마다 브랜치를 1개(및 리모트 브랜치를 추적하기 위한 익명의 힌트)만을 서포트하고 있습니다.최종 가이드」를 참조해 주세요.

---

다음으로 기능 브랜치를 사용하는 베스트 프랙티스를 따를 경우, 즉 기능 브랜치는 모두 안정된 버전(통상은 마지막 릴리스부터)에서 시작해야 합니다.마지할 기능 브랜치를 선택하여 포함할 기능을 선택할 수 있습니다.일반적으로 패스트포워드 상황은 아닙니다.그래서 이 문제는 무의미해졌어요.첫 번째 브런치를 Marge할 때 fastforward가 아닌 진정한 Marge를 작성할 필요가 있습니다(단일 커밋 변경을 'master'에 직접 적용하지 않을 경우). 다른 모든 Marge는 물론 고속화되지 않은 상황에 있습니다.

HTH

언급URL : https://stackoverflow.com/questions/2850369/why-does-git-perform-fast-forward-merges-by-default