Git에서 '--no-ff'병합 옵션을 사용하는 경우

Git에서 '--no-ff'병합 옵션을 사용하는 경우

---

성공적인 Git 분기 모델 은 분기를--no-ff 병합 할 때 사용하도록 권장합니다 .

--no-ff플래그는 병합이 빨리 감기를 수행 할 수있는 경우에도, 항상 새로운 객체를 커밋 만들 병합됩니다. 이렇게하면 기능 분기의 과거 존재에 대한 정보가 손실되는 것을 방지하고 기능을 추가 한 모든 커밋을 함께 그룹화합니다. […]

예, 몇 개의 (빈) 커밋 객체를 더 생성하지만 이득은 그 비용보다 훨씬 큽니다. 불행히도 --no-ff아직 git merge의 기본 동작 을 만드는 방법을 찾지 못했지만 실제로는 그래야합니다.

그러나 Git 워크 플로를 이해 하려면 다음 을 사용 하지 않는 것이 좋습니다 --no-ff.

따라서 새 규칙을 추가합니다. "기능 브랜치에서 병합 할 때를 사용 –-no-ff하여 새 커밋을 강제합니다." 이렇게하면 작업이 완료되고 계속 진행됩니다. […]

--no-ff반창고, 깨진 bisect, 그리고 blame신비 당신은 망치로 드라이버를 모든 증상을 사용하고 있는지. […]

두 가지 방법 모두 차이 시나리오에 대해 합리적으로 보이지만 "좋은 방법"으로 간주되는 것은 무엇입니까?

언제를 사용하고 --no-ff, 언제 사용 하지 않습니까?

---

그것은 당신이하려는 일에 정말로 의존합니다. 내 경험 법칙은 병합이 "무언가를 의미"하는 경우 --no-ff 옵션을 사용한다는 것입니다. 병합이 실제로 아무 의미가없고 리베이스를 사용했을 수있는 경우 --no-ff를 사용할 이유가 없습니다.

git의 장점은 매우 강력한 도구이며 여러 가지 방법으로 사용할 수 있다는 것입니다. 대부분은 잘못된 것이 아닙니다. "올바른 방법"이 무엇인지 묻는 것은 그림을 그리는 올바른 방법이 무엇인지 묻는 것과 같습니다.

적어도 저에게 그것은 제가 좋아하는 방식의 진화입니다. 우리가 코드에 대해 어떻게 협업하고 싶은지에 대한 팀에서 빈번한 토론을 통해 우리는 일종의 "여기서 수행되는 방식"표준을 도출하려고합니다. 우리의 방식 일뿐입니다.

---

단일 커밋으로 완료된 브랜치의 경우 사용하지 말고 --no-ff빨리 감기 만하면됩니다. 왜냐하면 히스토리가 훨씬 간단하고 덜 복잡 할 것이기 때문입니다. --no-ff이 경우에 이점이 있다고 주장하기는 어렵습니다 . 단일 커밋으로 병렬 개발 분기를 보는 것이 순차 라인에서 단일 커밋을 보는 것은 흥미롭지 않기 때문입니다.

# No fast-forward
$ git merge --no-ff awesome-feature
*   3aa649c Merge branch 'awesome-feature'
|\
| * 35ec88f Add awesome feature
|/
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

# versus fast-forward
$ git merge awesome-feature
* 35ec88f Add awesome feature
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

하나 이상의 커밋이있는 완료된 분기의 경우 분기 된 개발이 병렬 또는 순차적으로 발생했다는 사실을 유지할 것인지 여부는 사용자에게 달려 있습니다. 아마 사용하는 것이 --no-ff내가 눈이 분기 작업을 볼 수 너무 더 많은 사람이 커밋보다위한, 그래서 나는 단일로 쉽게 조작 할 수있는 git revert -m 1 <sha-of-merge-commit>I가 있던 경우에.

# No fast-forward
$ git merge --no-ff epic-feature
*   d676897 Merge branch 'epic-feature'
|\
| * ba40d93 Add octocat.txt
| * b09d343 Add bye.txt
| * 75e18c8 Add hello.txt
|/
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

# versus fast-forward
$ git merge epic-feature
* ba40d93 Add octocat.txt
* b09d343 Add bye.txt
* 75e18c8 Add hello.txt
* 89408de Modify feature-001.txt and fix-001.txt
* c1abcde Add feature-003

See how in this case of fast-forward merge, without additional information in the commit messages themselves, it's hard to tell that the last 3 commits actually belong together as one feature?

---

That really depends on your workflow, and how you are using branches.

Let´s say you have a "master" and two feature branches, "foo" and "bar", in development.

In this case, the branches only exist to allow different developer work without conflict, when the features are done, they need to be merged into master, and it is not important to know if those features were implemented in different branches.

But you could have a different workflow, were the branches, "foo" and "bar", refers to independent modules in your system.

In this case, some commits may change files outside the module scope. When you merge those two branches to the master, the log of the files, outside the specific module, may become confusing and hard to know where those changes come from.

You need to decide if the historic of branch´s merge is important to your workflow.

And following the comments, I prefer the rebase, and pull --rebase workflow.

참고URL : https://stackoverflow.com/questions/18126297/when-to-use-the-no-ff-merge-option-in-git