当你在编写提交信息时不知道要在单行总结中放置什么内容时,这可能意味着你将太多独立的事情放入了一个提交中。最好使用“git rebase --interactive
”、“git add --interactive
”等命令拆分提交,或者使用类似于“git stash --keep-index
”来测试暂存的更改。
每个提交只包含单一问题会在使用“git bisect
”查找错误时非常有帮助。
这个建议不只是针对git,更是通用的。我看过很多项目都有像“bugfix”、“fix foo”或者“stuff”这样的提交信息。不要这样做,而是使用有意义的提交信息,例如“组件fiz: 修复foo bug[\n\n额外信息]”和“清理空格”。当你无可避免地回顾提交历史时,你会感谢自己没有写“stuff”,因为你不需要问自己:“我提交‘stuff’时到底是什么意思?”
不使用git stash
场景:您正在开发功能A,已经花费了大约2天的时间,距离完成还有一天的时间。您已经写了良好的代码,但还有更多工作要做。您的老板出现并说:“嘿,我现在需要功能B。应该只需要10秒钟。”
当然-10秒钟就可以写完,但是失去了2天的工作。或者花费2个小时来注释和修改过去2天编写的所有代码,以使一切恢复到工作状态。
git stash
来拯救你。只需在项目的根目录下,在命令行中键入git stash
,您最近的更改将进入“stash”,即更改堆栈。现在您回到了2天前的状态,但您的工作没有丢失。您进行10秒钟的更改,检查后,然后键入git stash pop
以获取您的更改(并从堆栈中删除它们)。
显而易见,如果你有糟糕的一天,你可以多次隐藏,尽管显然,你这样做的次数越多,当你最终git stash pop所有内容时,合并将变得不那么有趣。如果你在几个月的工作中累积了很多隐藏内容,你可以使用git stash list
查看它们,使用git stash pop
和git stash drop
挑选出哪些值得带回来,哪些最好直接丢弃,并使用git stash clear
只隐藏可怕的想法。
git commit --amend
或git rebase -i
来修复它。 - rjmunrogit commit
,git push
,git commit
,git push
,git commit
,git push
...... 换句话说,每次提交后都要推送,就像我仍在使用SVN一样。将一个大型代码库从SVN等迁移至一个大型git仓库是一个明显的反模式。由于git的设计,你不能进行部分检出,甚至提交也可能会很慢。最好将其模块化并使用每个组件一个仓库的方式。至少,每个团队一个仓库。绝不是每个组织一个仓库。