我对此做了很多搜索，如果这是一个骗局我道歉，我找不到直接解决我问题的任何答案。
我们有一位客户会暂时考虑一项功能，而这样做会很快批准其他功能。
这意味着我们从master创建功能分支并将它们合并以部署到QA环境，这一切都很好，但是当feature2在feature1之前获得批准时，我们需要将feature2合并到我们的版本分支中而没有任何跟踪feature1。
这听起来不错，但这已经持续了一段时间，主人和发行版之间的提交历史总是不同。
我们尝试了什么;
是否有人为此建议了工作流程？
我认为我们可以在发布分支点从master分支，但后来我认为我们遇到与上面2相同的问题。
修改
请参阅下面的链接二（什么样的Git工作流适合我们的情况？） - 可能一个“临时”分支可以用于部署到开发环境？
一些类似的讨论;
What git branching models actually work?
What kind of Git workflow suits our case?
答案 0 :(得分：1)
尝试git merge --squash branchname (docs)。
它将整个分支转换为单个提交，从而消除了历史问题。这使您可以遵循一种模式，即您拥有持久的主分支和发布分支，以及对彼此一无所知的瞬态功能分支。 master是分支和合并的功能，发布分支是在考虑发布时合并master的地方，而功能分支是发生大部分开发的地方。当某个功能获得批准后，它将与git merge --squash合并为主服务器，这会导致主服务器对整个功能进行一次提交。然后，如果需要，可以删除功能分支。此外，如果没有删除该功能，它似乎会继续与master快速合作，所以你甚至可以保持分支并单独处理该功能，定期使用git merge --squash将其合并到master，git merge将master合并到其中（使其保持最新）。
如果更多的历史记录很重要，那么您可以查看git rebase -i，将功能分支合并到master中，然后使用git rebase -i清除生成的历史记录。按此顺序执行意味着功能分支仍然与其他任何地方分支相同，而主分支有一些额外的提交，表示功能分支上的开发。问这听起来有趣，我会尝试进一步解释。
对于发行版，您可以使用git merge --squash合并到发行版分支中，这样可以使其更加清晰，或者您可以使用git merge将主页的（现在有限的）历史记录发布到发行版中
以下是git log可能显示的结果提交图：
* d779567 master Done
* 298c1c7 master Closer
* 736d826 master Building
| * 4657b01 fdab66dc33 Done!
| * 3af011a fdab66dc33 Closer...
| * 6372833 fdab66dc33 Closer...
| * d345a43 fdab66dc33 Building...
| * 0b64509 fdab66dc33 Building...
| * 9da143c fdab66dc33 Building...
| * c99dbce fdab66dc33 Building...
| * 501a25c fdab66dc33 Building...
| * 4f999ee fdab66dc33 Building new feature
|/
* e891881 master Work on master
| * 3571493 release Releasing version 2!
| |\
| |/
|/|
* | 68f75f0 master Feature 1 done
* | 5dbe17c master Feature 2 done
| * bbcc8e8 release Bugfix on current release
|/
* d5732fd release Work directly on master
* 1098d81 release Initial commit
从底层开始工作：完成了一些初步工作;发布了一个版本，然后我们意识到我们需要修复它中的错误;我们从他们的开始以相反的顺序获得两个功能的批准，另一个版本被削减。然后一些工作直接发生在主人身上。现在事情变得更加混乱了。右边的分支（fdab66dc33实际上是分支名称）是一个功能分支，它已经有很多提交。左边的分支是主分支，顶部的三个提交是将特征分支合并到其中然后使用git rebase -i将一些特征分支的提交压缩在一起的结果。