Question

我对Git非常满意，我已经使用它超过一年了。更好的是，我终于说服客户切换到它！但是，对于如何完成我将要描述的内容，或者甚至是可能的，我只是被忽视了。即使它可以完成，我想知道它是否可能让我们陷入混乱，无法管理的存储库。

我已经设置了代码库的两个分支。一个是“主人”，另一个是“prod”。 prod的HEAD始终是部署到生产的最新代码，master是主要的开发分支。

这是问题所在：客户端正在从CVS转换，大多数开发人员仍然习惯于git。他们的CVS工作流程涉及为生产标记单个文件的版本，然后使用标记更新服务器。不幸的是，这导致了一些草率的做法，例如将不相关的更改一起提交，然后在事后标记文件，并在其主要工作树中保留大量垃圾文件等等......开发人员想要知道他们如何做以下内容：

在他们的本地回购中，他们破解并承诺他们心中的喜悦，然后在一天结束时，能够运行一个命令，其中列出了一天中的提交与当地产品合并的文件列表 - 并且只有那些文件 - 即使这些提交将更改与其他文件组合在一起。

我知道如何使用git rebase --interactive拆分提交，但我不知道如何自动拆分提交，更别管我想要的方式。

我确实知道最简单的事情就是告诉他们切换他们的prod分支，将文件从他们的主分支签出到工作树然后提交prod。我的问题是在一天中失去了他们的提交历史。

有没有其他人用脚本或其他东西解决这个问题，或者我是否只需要让开发人员采取更好的行为 - 并冒险让他们完全拒绝Git？

这是我最终解决的解决方案。它是一个简单的shell脚本，似乎完全符合我的要求，即使它不是最优雅的解决方案。我只测试了几个场景，但是文件的更改历史记录被保留了，如果dev分支的提交稍后在整个git中合并，那么它似乎干净利落！

#!/bin/sh
set -e
dest_branch=$1
file=$2
current_branch=$(git branch | sed 's/^\* //;/^\s/d')
( 
    set -e 
    git format-patch --stdout --full-index -M -C -B --ignore-if-in-upstream $dest_branch -- $file
    git checkout $dest_branch 
) | git am
git checkout $current_branch

Answer 1

那些开发人员仍然拥有非常“以文件为中心”的愿景，而不是“以存储库为中心”的方法（基于SVN的修订或Git的提交）！他们需要阅读“What are the basic VCS concepts every developer should know?”;）
（它最初是关于ClearCase但仍然面对DVCS的CVS用户）

也就是说，在特定情况下弥合差距的一种方法是：

在黑客攻击当天结束时，从当前的HEAD创建一个特殊的分支
仅针对正确的文件（prod的文件）进行最终修改修改可能是一些kind of special keyword extension，只是为了将它们标记为“要合并为prod”。
将该特殊分支合并到其本地产品：在一次提交中，只合并正确的文件。

这样，就会保留这些文件的历史记录。

如何自动拆分git提交以单独更改单个文件

1 个答案: