我需要一些关于 GIT 的帮助。我们刚刚开始使用 GIT，只是现在我们公司还没有一个好的设置，所以在我看来一切都是一团糟。我提供了我的历史来帮助你们更好地理解我想要做什么。
所以今天我试图发布到我们的支持和主服务器。我们首先发布到 Sup，然后将 Sup 合并到 Live/master 系统中。
如果您查看历史记录并找到分支“130029”，我正在尝试将其合并到支持中，但想看看我是否可以“压缩”所有分支/提交，我想今天将其发布到一个包中。
我已经阅读了关于 re-basing 并在分支“130029”上尝试过我按照代码执行的操作
git checkout DEV.130029
git rebase SUPPORT -i
这将我带到了 rebase 编辑器，它列出了所有提交，但我希望这些提交是其他分支，所以我可以压缩它们然后合并到 Support。我没有比上面的代码更进一步，我只是中止了，因为我似乎迷路了。有没有其他方法可以选择我想发布的所有分支，然后将所有分支合并为一个提交到 Sup/master 中？
提前致谢！
我认为你的问题，如果你有一个，是工作流程。任何使用功能分支的足够复杂的项目都会有一个混乱的图表。如果你想要一个好的例子，看看git.git，git 源本身。这是从字面上编写有关 git 工作流的文档的项目，如果您将当前快照master放入gitkor tig，它在第一次通过时看起来会相当混乱。
关于您的图表的问题不在于它本身看起来像地铁地图。这是它没有显示上游与下游分支的清晰概念，或者从上游分支到下游分支的有序毕业。事实上，它看起来非常像我们从 SVN 迁移到 git 时在我的雇主那里使用的工作流程：高度集中，依赖于多个不经常相互合并的“永久”分支，它们的集成已经完成完全是临时的。这也可能是完全错误的。很难从一些历史快照中推断出贵公司的工作流程策略。
如果您觉得这不容易解释，并且您的团队也有这种感觉，那么可能是时候采用新的工作流程了。版本控制可以让你的生活更轻松，而不是浪费你所有的时间。那里存在许多成功的 git 工作流程：
Pro git概述了一些。我们最终使用集成管理器抓取了类似于 SVN 的工作流程，以得到一个看起来几乎与git 相同的工作流程。
谷歌将返回其他受欢迎的。那个特别的，Gitflow，在 SO 上非常流行，并且有一些很好的git 扩展，使使用它变得轻而易举。
相当多的 SO 问题描述了成功的工作流程，包括一些链接大量研究并有一些很好的答案的问题。
至少，如果您没有修复可用的最旧的上游分支中的错误，没有使下游开发分支与上游祖先的更改保持同步，或者在分支之间定期挑选樱桃，那么是时候改变。
最后，在没有关于您的工作流程的任何其他信息的情况下，如果您在白天处理一个功能分支，并希望将其与SUPPORT分支合并，首先压缩，这是执行此操作的众多方法之一：
git checkout DEV.130029
git rebase -i --onto SUPPORT <branch_DEV_was_cut_from> DEV.130029 ;# squash what you want here
git checkout SUPPORT
git merge DEV.130029
如果您只是为了让图表看起来更简单而重新设置基准，那么请把时间花在工作流程上。