git이 기본값으로 fast-forward merges을 수행하는 이유

질문 : git이 기본적으로 빨리 감기 병합을 수행하는 이유는 무엇입니까?

---

수은에서 왔기 때문에 가지를 사용하여 기능을 구성합니다. 당연히 내 역사에서도이 작업 흐름을보고 싶습니다.

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

그래서 미래를 생각 해보자.이 프로젝트에서 일하는 사람은 나 뿐이다. git의 기본 접근 방식 (빨리 감기 병합)을 사용하면 내 기록이 하나의 거대한 마스터 브랜치가됩니다. 내가 모든 기능에 대해 별도의 브랜치를 사용했다는 사실은 아무도 모릅니다. 왜냐하면 결국에는 거대한 마스터 브랜치 만 갖게 될 것이기 때문입니다. 전문가답지 않게 보이지 않습니까?

이 이유 때문에 나는 빨리 감기 병합을 원하지 않으며 이것이 기본값 인 이유를 알 수 없습니다. 그것에 대해 무엇이 그렇게 좋은가요?

답변

---

빨리 감기 병합은 수명이 짧은 분기에 적합하지만 더 복잡한 기록 에서는 빨리 감기가 아닌 병합으로 기록을 더 쉽게 이해하고 커밋 그룹을 쉽게 되돌릴 수 있습니다.

경고 : 비 빨리 감기는 잠재적 인 부작용도 있습니다. https://sandofsky.com/blog/git-workflow.html을 검토하고 양분 또는 비난을 깨뜨리는 "체크 포인트 커밋"으로 'no-ff'를 피하고 이것이 master 대한 기본 접근 방식이어야하는지 신중하게 고려하십시오.

^{( nvie.com , Vincent Driessen , " 성공적인 Git 분기 모델 "게시)}

완성 된 기능을 개발에 통합

완성 된 기능은 다음 릴리스에 추가하기 위해 개발 브랜치에 병합 될 수 있습니다.

$ 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-ff 플래그는 병합이 빨리 감기로 수행 될 수 있더라도 병합이 항상 새 커밋 객체를 생성하도록합니다. 이렇게하면 기능 분기의 과거 존재에 대한 정보가 손실되는 것을 방지하고 기능을 추가 한 모든 커밋을 함께 그룹화합니다.

Jakub Narębski 는 config merge.ff 대해서도 언급 합니다.

기본적으로 Git은 현재 커밋의 후손 인 커밋을 병합 할 때 추가 병합 커밋을 생성하지 않습니다. 대신 현재 분기의 끝이 빨리 감 깁니다.
false 설정되면이 변수는 이러한 경우에 추가 병합 커밋을 생성하도록 Git에 지시합니다 (명령 줄에서 --no-ff
only '로 설정하면 이러한 빨리 감기 병합 만 허용됩니다 (명령 줄에서 --ff-only

빨리 감기는 다음과 같은 이유로 기본값입니다.

• 수명이 짧은 브랜치는 Git에서 생성하고 사용하기가 매우 쉽습니다.
• 수명이 짧은 분기는 종종 해당 분기 내에서 자유롭게 재구성 할 수있는 많은 커밋을 분리합니다.
• 이러한 커밋은 실제로 메인 브랜치의 일부입니다. 일단 재구성되면 메인 브랜치가이를 포함하도록 빨리 감 깁니다.

그러나 하나의 주제 / 기능 브랜치에서 반복적 인 워크 플로가 예상되는 경우 (예 : 병합 한 다음이 기능 브랜치로 돌아가서 커밋을 더 추가합니다), 기본 브랜치보다는 병합 만 포함하는 것이 유용합니다. 기능 브랜치의 모든 중간 커밋.

이 경우 이러한 종류의 구성 파일을 설정할 수 있습니다.

[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는 주석에 추가합니다.

나는 [짧은] 브랜치에 대해 빨리 감기에서 어떤 의미가 있음을 알지만, 이것을 기본 동작으로 만든다는 것은 git이 당신을 가정한다는 것을 의미합니다 ... 종종 [짧은] 브랜치를 가지고 있습니다. 합리적입니까?

Jefromi는 다음과 같이 대답합니다.

브랜치의 수명은 사용자마다 크게 다릅니다. 그러나 숙련 된 사용자들 사이에는 훨씬 더 짧은 분기를 갖는 경향이있을 것입니다.

나에게 단기 브랜치는 특정 작업을 더 쉽게 (리베이스, 가능성 또는 빠른 패치 및 테스트)하기 위해 만든 다음, 완료되면 즉시 삭제하는 브랜치입니다.
즉 , 분기 된 토픽 브랜치에 흡수되어야하며 토픽 브랜치는 하나의 브랜치로 병합됩니다. 주어진 기능을 구현하는 일련의 커밋을 만들기 위해 내가 내부적으로 무엇을했는지 아무도 알 필요가 없습니다.

더 일반적으로 다음을 추가합니다.

실제로 개발 워크 플로 에 따라 다릅니다.

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

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

실제로 Mercurial 브랜치 모델을 고려할 때 저장소 당 하나 의 핵심 브랜치에 있습니다 ( 익명 헤드, 북마크 및 명명 된 브랜치를 만들 수 있더라도).
"Git 및 Mercurial-비교 및 대비"를 참조하십시오.

Mercurial은 기본적으로 익명의 경량 코드 라인을 사용하며 용어로는 "헤드"라고합니다.
Git은 원격 리포지토리의 분기 이름을 원격 추적 분기의 이름에 매핑하는 인젝 티브 매핑과 함께 경량의 명명 된 분기를 사용합니다.
Git은 브랜치에 이름을 지정하도록 "강제"하지만 ( " 분리 된 HEAD "라는 상황 인 이름이 지정되지 않은 단일 브랜치를 제외하고) 이것이 토픽 브랜치 워크 플로와 같은 브랜치가 많은 워크 플로에서 더 잘 작동한다고 생각합니다. 단일 저장소 패러다임의 여러 분기.

출처 : https://stackoverflow.com/questions/2850369/why-does-git-perform-fast-forward-merges-by-default