# Git分支模型適合您？

1. Workflows/branching models

Below are the three main descriptions of this I have seen, but they are partially contradicting each other or don't go far enough to sort out the subsequent issues we've run into (as described below). Thus our team so far defaults to not so great solutions. Are you doing something better?

2. Merging vs rebasing (tangled vs sequential history)

Should one pull --rebase or wait with merging back to the mainline until your task is finished? Personally I lean towards merging since this preserves a visual illustration of on which base a task was started and finished, and I even prefer merge --no-ff for this purpose. It has other drawbacks however. Also many haven't realized the useful property of merging - that it isn't commutative (merging a topic branch into master does not mean merging master into the topic branch).

3. I am looking for a natural workflow

Sometimes mistakes happen because our procedures don't capture a specific situation with simple rules. For example a fix needed for earlier releases should of course be based sufficiently downstream to be possible to merge upstream into all branches necessary (is the usage of these terms clear enough?). However it happens that a fix makes it into the master before the developer realizes it should have been placed further downstream, and if that is already pushed (even worse, merged or something based on it) then the option remaining is cherry-picking, with its associated perils. What simple rules like such do you use? Also in this is included the awkwardness of one topic branch necessarily excluding other topic branches (assuming they are branched from a common baseline). Developers don't want to finish a feature to start another one feeling like the code they just wrote is not there anymore

4. How to avoid creating merge conflicts (due to cherry-pick)?

What seems like a sure way to create a merge conflict is to cherry-pick between branches, they can never be merged again? Would applying the same commit in revert (how to do this?) in either branch possibly solve this situation? This is one reason I do not dare to push for a largely merge-based workflow.

5. How to decompose into topical branches?

We realize that it would be awesome to assemble a finished integration from topic branches, but often work by our developers is not clearly defined (sometimes as simple as "poking around") and if some code has already gone into a "misc" topic, it can not be taken out of there again, according to the question above? How do you work with defining/approving/graduating/releasing your topic branches?

6. Proper procedures like code review and graduating would of course be lovely.

But we simply cannot keep things untangled enough to manage this - any suggestions? integration branches, illustrations?

## 最佳答案

DVCS新開發人員需要意識到的最令人不安的功能是關於發布過程

• 您可以導入（獲取/拉取）您需要的任何遠程倉庫
• 您可以發布（推送）到您想要的任何（裸）回購

Workflows/branching models:

Merging vs rebasing (tangled vs sequential history):

I am looking for a natural workflow:

git revert should take care of that, but that is not ideal.

• 如果需要，可以使用多個分支（一個通過明確標識的功能）
• 一個分支內的一系列一致提交（請參閱修剪Git簽名

• 在遠程集成分支（pull --rebase）
• 之上修改他/她的開發
• 解決本地問題
• 將開發推送到該回購
• 與積分器核實不會造成混亂;）