我在一个主要的私人Python项目中使用Pycharm进行了几个月的探索性工作。我使用git来跟踪该项目中的更改。我是唯一一个为这个项目做出贡献的人。
通常情况下，我大约每天对该项目进行一次更改。
现在，我想在每次执行代码时跟踪代码的变化(背景是，我有时会丢失使用哪个版本的代码获得的中间结果(。
因此，我想在脚本执行结束时对所有更改的文件执行git提交。
由于现在每个提交都只收到一条"技术"提交消息，我想将这些"技术"的提交与我大约每天进行一次的其他提交区分开来(见上文(。背景是，我仍然希望看到并比较彼此之间的日常差异。每天的技术承诺可能会达到几十次，这会阻碍我看到一段时间内的重大变化。
git提供了哪些技术来区分我所做的技术提交和日常提交？
分支是否是一种有效的方法？如果是，我以后会删除这些分支吗？(我是个新手(
您可以使用一个分支来实现这一点，是的。只需在执行脚本自动提交时使用一个工作分支，然后当您想提交历史记录时，切换到主分支。
要将最终更改重新添加为单个提交，一种方法是在完成更改后软重置历史记录。所以你会：
git reset prev-real-commit
它会将历史记录跳回到新一批wip自动提交之前，但不会触及文件，因此不会丢失工作。然后，您可以正常地对更改进行新的提交。
这种技术在没有分支的情况下也有效。不过，使用分支可能仍然很好，这样您就可以在提交新的wip之前轻松地检查版本。
Git还具有重新定基功能，可以将多个提交压缩为一个并重写消息。但对于您描述的工作流，我认为简单地重新设置自动提交并重新进行正常提交会更好。
此外，在自动提交的消息中添加一些标记的建议也很好。
也就是说，我通常只提交正常开发流程中需要的检查点。有一个承诺可能会更好，例如每小时一次，而不是每天一次。小的原子提交是好的。如果你想记录和管理更大的整体工作，你可以使用功能分支和GitHub上的拉取请求。
我认为，即使您单独处理这个项目，采用典型的github流方法并开始使用分支仍然是一个好主意。
这个想法是你区分你的"；技术性的"；根据使用的Git实体，从您的日常提交(很少不止一次(中提交(一天中发出许多(：
- 您的主代码位于
master分支 - 您的每日提交在进入特定的长期运行分支时保持"正常"提交(
develop是一个常见名称( - 您的"一天一次"提交变为合并提交，将
develop中的所有更改推送到master分支
这允许您保存历史记录，但可以清楚地看到这两种类型之间的区别。您可以选择"无快进"方法，这样每次合并提交都会明显不同于"常规"提交。
如果你真的不希望所有的历史都在那里(正如@antont所说，可能有很多提交(，你可能会考虑在合并或重定基础时"压缩"这些提交，就像这里描述的那样。