我是一个小型项目的自由职业者，所有这些都是我独自完成的，没有团队。
我尝试使用Git Flow。起初，一切都很好。有功能分支，有意义描述的小提交，合并。
但是这个过程总是以非常大的提交结束，直接到主分支，有“大更新”，“一些更新”等描述。
你是如何处理的？在我的情况下我是否需要Git Flow？
答案 0 :(得分：5)
但是这个过程总是以非常大的提交结束，直接指向主分支，其中的描述如＆＃34;大更新＆＃34;，＆＃34;一些更新＆＃34;。
这是[2015-05-26 15:41:39,216] INFO tickTime set to 3000 (org.apache.zookeeper.server.ZooKeeperServer)
[2015-05-26 15:41:39,216] INFO minSessionTimeout set to -1 (org.apache.zookeeper.server.ZooKeeperServer)
[2015-05-26 15:41:39,216] INFO maxSessionTimeout set to -1 (org.apache.zookeeper.server.ZooKeeperServer)
[2015-05-26 15:41:39,235] INFO binding to port 0.0.0.0/0.0.0.0:2181 (org.apache.zookeeper.server.NIOServerCnxnFactory)
和git rebase --interactive的用途。
这是你要做的第一件事：你必须让自己成为一个疯狂的人。不，两个疯狂的人，每个人都说服对方是别人。不，等等，那不对。 三个疯狂的人。
您已经知道的（目前是理智的），谁完成了这项工作，并且没有任何其他可以说的内容。所以：一个疯狂的你和一个理智的历史的第一步是你的代码审查员的新的（但纯粹想象的片段），他对你所做的改变一无所知，直到她看到提交消息和补丁。你需要尊重那个人的时间。第三部分，从有用的怪癖到全面的精神错乱，是the rubber duck。这是一个悬而未决的问题，无论是携带一只真正的橡皮鸭还是只是想要一只恰好是橡皮鸭的假想的红颜知己，对其他人来说更令人不安。现实感（更不用说你自己了）。
所以，两个疯子和一个鸭子。
如果橡皮鸭不能理解您的解释，或者评论者无法理解您的代码，那么请尽量简化。将提交分解为不会破坏构建的独立部分，不要让审阅者或者鸭子想知道为什么每个部分都需要在那里保持一切正常。
看，如果你进行了设置，那么做正确的事情具有巨大的娱乐价值，世界将是美好的。如果你不相信，它至少会令人不愉快和无聊。唯一不这样做的时候，你已经可以感觉到在几个月内你需要做这件事有多糟糕，那只是浪费时间。但如果你想失去它，请确保你获得更有价值的东西作为交换。
无论你是否有乐趣，都必须进行改装和添加。
答案 1 :(得分：3)
我猜这是纪律问题。
对我来说，使用描述其中包含的确切更改的小提交非常有用。我在我与团队合作的工作环境中使用此流程，但也用于我作为业余爱好或项目的项目。
如果您有图形用户界面，这会有所帮助。我使用Atlassian SourceTree，它可以很容易地选择对行的更改。所以有时候我已经编写了一段时间，进行了很多更改，我仍然会逐个进行编写，并使用有用的消息提交每个更改。
但最好一次做一次更改，验证它是否有效并提交。如果你经常提交，如果你犯了很大的错误，你总会有一些东西要回去。
就个人而言，我不使用git flow的开发，发布和其他动词，尽管我为我开发的不同功能创建了单独的分支。这允许我在进行中时将更改放在一边并进行单独的拉取请求（这在团队中可能更有用）。