我是git的新手,我正在努力理解壁球和篮板之间的区别.根据我的理解,你做一个篮板时做一个壁球.
自从我的最后一个问题被证实是关于GIT的变基,我已经决定我根本不想变基.相反,我想:
我目前通过将文件复制到新目录然后将它们复制回新分支(与我的工作分支在同一点分支),然后将其合并到master任何地方.
这只是简单的坏事,为什么？更重要的是:有没有更好的/ GIT方式来做到这一点？ git rebase -i迫使我合并(并挑选和压缩).
我有一个'主'分支和几个主题分支.假设主分支主要用作发布候选者,并且在该分支上不进行任何开发工作.
主题分支是多个,由团队共享.一些分支机构有多个开发人员在开发它们.所有主题分支都定期从主分支重新定位.
为了清理'master'分支中的历史记录,我在将代码从主题分支到主分支时进行了'git merge --squash'.这非常好.
现在 - 当主题分支被重新定位时 - 提交正在重复.有没有办法在'git merge --squash'成功后清理主题分支上的提交？
我有两个存储库.不时,我要的内容合并other成main.但是,合并会忽略已删除的文件.让我通过一个例子解释一下:
mkdir -p test/main test/other
cd test/other/
git init
touch one two three
git add .
git commit -m "Add one, two and three."
cd ../main/
git init
touch four
git add .
git commit -m "Add four."
添加other到main远程.
git remote add other ../other/
git fetch other
合并其内容.
git merge --squash other/master
git commit -m "Merge other."
它正确添加文件.现在,删除一个文件other.
cd ../other/
git rm two
git commit -m "Remove two."
合并更改为main …
这看起来应该是一个简单的问题，但我整个早上都在寻找答案，但我就是找不到令我满意的答案。我能找到的最接近的东西是这个问题，Git merge squashrepeated，但这个问题是 11 年前的问题，所以希望“除非你创建临时分支，否则你根本无法做到这一点”的共识已经改变。
我正在从事一个长期项目，我基本上是唯一的贡献者。理想情况下，我希望有一个长期持续的development分支，我可以继续一点一点地修补和工作，并master在我达到稳定的可发布状态时定期对分支进行压缩合并。我不想让完整的提交历史记录可用/可见master，因为我希望能够轻松地向后浏览稳定的官方版本的历史记录。但是，我确实希望完整的提交历史记录可以在某个地方可用，以便它变得相关。
问题是，如果我尝试以直觉上认为应该有效的方式做到这一点，那就行不通。南瓜合并提交创建了一个与master中的任何内容都不匹配的提交development，因此下次我尝试执行南瓜合并时，它会说存在冲突，我需要从合并master到development...并且当我越来越多地重复这个过程，这个问题不断增长，我有六个提交在两个分支之间来回跳动，这些提交实际上并没有更改任何文件，但我似乎无法摆脱。
我想要制作的图形看起来像这样，如果这有意义的话：
B-------------------G-----------J master
/ / /
a---b---c---d---e---f---g---h---i---j development
到目前为止我一直在使用的解决方案非常丑陋：我使用版本号创建一个新分支，例如development_601，然后当我再次稳定时，我从该分支向 master 发出拉取请求，并压缩合并提交，然后我在挤压合并后创建另一个新development_602分支master。development_601被封存。这看起来很混乱、烦人，而且是错误的，特别是因为 Git 似乎暗示我应该在合并拉取请求后删除我的分支，但就像我说的，我想在某个地方记录我完整的混乱历史，我只是不这样做不希望它（轻易）从外部可见。
我一直在使用 Github Desktop 应用程序和 Github 网站；我一直试图避免将控制台命令放入我的工作流程中。
这是一种奇怪的行为吗？development我觉得“拥有一个带有master/分支的长期release分支，定期但不完全地反映它”是一种非常常见的系统，但不知何故，我找不到任何地方可以解释如何实现它。