假如我开发一个软件需要用到git来管理,这个软件有很多的功能模块,请问:
1、每实现一个功能功能就只commit一次吗?
2、只要觉得有commit的必要就commit,比如修改个小bug,然后commit
我是新手,每次提交修改的文件都很多,很乱,有些修改还是和这次commit无关的文件。
请问各位是怎么做的呢? 谢谢。
学习是最好的投资!
可以参考下git flow 我觉得可以从大的点上解决你的疑惑
http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html
一般会有这么几种分支 master develop 各种feature分支 bug_fix分支 hot_fix分支 master一般是正式线上版,develop不用说,开发的,不过放在develop里面的也已经是相对稳定的分支,而你要开发新的特性的时候,确保你在develop分支上新建一条feature_XXX分支,各种commit commit commit, 如果后期发现之前的版本有某个bug,不影响线上的会建立一条bug_fix_XXX分支,而影响线上的严重bug则新建hot_fix分支,hot_fix与bug_fix不同,解决bug后会将hot_fix分支merge到master注意是master。
另外,如果你想保持你分支整洁干净,你可能需要用到rebase来合并代码,而不是merge
git的玩意儿推荐看下progit吧,非常之全面。
我一般是
即使只是加了一行代码,也可一作为一个 commit。 无关的代码不要提交到本次 commit。
你要知道你要达到的效果是,如果有一天我要你回滚到某个历史状态,你能很快的找到那次提交并回滚。如果做不到这一点,你怎么 commit 都无所谓了。 比如某一次你将一个默认值由50改为100,那么,这就应该作为一次提交。如果你顺手修了一个 bug,也不能放在这次提交里,要不然要怎么回滚到 50 呢?难道你回滚了之后还要重新修复那个 bug 吗?
你不知道怎么提交是因为你没有一个确定的目的。
我是这么认为的。
要很详细的话,就只能一个具体的功能地提交了。 不过好费事儿啊。 另外,也可以使用git gui 中文提交,描述清楚点。
这个随意啊,主要还是为了以后自己或是别人看起来方便,能知道你commit的信息代码里改了那些,,,,与功能无关的页面commit 信息里我也会说清楚的。反正勤于commit的吧,一个功能提交一次肯定不够的
多用rebase,少用merge
可以参考下git flow 我觉得可以从大的点上解决你的疑惑
http://danielkummer.github.io/git-flow-cheatsheet/index.zh_CN.html
一般会有这么几种分支 master develop 各种feature分支 bug_fix分支 hot_fix分支
master一般是正式线上版,develop不用说,开发的,不过放在develop里面的也已经是相对稳定的分支,而你要开发新的特性的时候,确保你在develop分支上新建一条feature_XXX分支,各种commit commit commit,
如果后期发现之前的版本有某个bug,不影响线上的会建立一条bug_fix_XXX分支,而影响线上的严重bug则新建hot_fix分支,hot_fix与bug_fix不同,解决bug后会将hot_fix分支merge到master注意是master。
另外,如果你想保持你分支整洁干净,你可能需要用到rebase来合并代码,而不是merge
git的玩意儿推荐看下progit吧,非常之全面。
我一般是
即使只是加了一行代码,也可一作为一个 commit。
无关的代码不要提交到本次 commit。
你要知道你要达到的效果是,如果有一天我要你回滚到某个历史状态,你能很快的找到那次提交并回滚。如果做不到这一点,你怎么 commit 都无所谓了。
比如某一次你将一个默认值由50改为100,那么,这就应该作为一次提交。如果你顺手修了一个 bug,也不能放在这次提交里,要不然要怎么回滚到 50 呢?难道你回滚了之后还要重新修复那个 bug 吗?
你不知道怎么提交是因为你没有一个确定的目的。
我是这么认为的。
要很详细的话,就只能一个具体的功能地提交了。
不过好费事儿啊。
另外,也可以使用git gui 中文提交,描述清楚点。
这个随意啊,主要还是为了以后自己或是别人看起来方便,能知道你commit的信息代码里改了那些,,,,与功能无关的页面commit 信息里我也会说清楚的。反正勤于commit的吧,一个功能提交一次肯定不够的
多用rebase,少用merge