Git使⽤的⼀些命令以及Gitcommit注释格式1、Git 快速教程及命令
流程： 取代码 → 每次⼯作前更新代码到最新版本 → 修改代码 → 提交代码到服务器
1. 取代码及修改全局设置
a. 设置⽤户名与邮箱
git config –global user.name “My Name”
git config –ail “my@email”
b. 从已有的git库中提取代码
git clone git@server:app .git myrepo
1. 每次更改代码的操作
a. 更新本地代码到最新版本（需要merge才能合到本地代码中）
git fetch
b. 合并更新后的代码到本地
git merge
c. 更新代码⽅式的另⼀种⽅法(git pull是git fetch和git merge命令的⼀个组合)git常用指令
git pull
d. 修改代码后，查看已修改的内容
git diff –cached
e. 将新增加⽂件加⼊到git中
git add file1 file2 file3
f. 从Git中删除⽂件
git rm file1
git rm -r dir1
g. 提交修改
git commit -m ‘this is memo’
如果想省掉提交之前的 git add 命令，可以直接⽤
git commit -a -m ‘this is memo’
commit和commit -a的区别, commit -a相当于：
第⼀步：⾃动地add所有改动的代码，使得所有的开发代码都列于index file中
第⼆步：⾃动地删除那些在index file中但不在⼯作树中的⽂件
第三步：执⾏commit命令来提交
h. 提交所有修改到远程服务器，这样，其它团队成员才能更新到这些修改
git push
1. 附注
遇到过的⼀些错误：
Git – fatal: Unable to create ‘/path/my_project/.git/index.lock’: File exists.
fatal: Unable to create ‘/path/my_proj/.git/index.lock’: File exists.
If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
可以试着删除 index.lock
rm -f ./.git/index.lock
2、Git commit 注释格式
Git 本⾝并没有硬性限制注释的格式，不过，对于多⼈参与的项⽬来说， 好的注释风格更加有利于团队合作。 即使是⾃⼰⽤，也应当坚持实⽤好的注释风格， ⼀来是对⾃⼰的⼯作历史负责，⼆来得以养成好的注释习惯。 虽然这⾥标题说的是 Git，其他源代码控制系统也可以参考的。
可以先看看⼀些著名开源项⽬源代码管理系统当中的提交注释， 其中也有⽤ SVN 和 Bazaar 的， Apahe 的源码看不到 logview，可能是使⽤了 CVS ⽂件格式的原因：
Linux Kernel
Apache HTTPD
Mysql Server 5.6
PHP
Git
结合其他参考⽂章，我总结 Git 的 推荐 注释风格如下：
第⼀⾏为对改动的简要总结，建议长度不超过 50，⽤语采⽤命令式⽽⾮过去式。
Vim 很贴⼼，在默认配置下，注释的第⼀⾏⽂字颜⾊是黄⾊，超过 50 列之后就变成⽩⾊了。
第⼀⾏结尾不要英⽂的句号 . ，中⽂的就也不要。吧。
为啥？我给 rst2wp 提交的时候，对⽅也提出了这个要求 [1] [2] ，后来查了查，⼤概原因是，第⼀⾏被认为是⼀个“标题”，也会作为邮件标题，⽽标题是不需要标点的。上⾯那些开源项⽬也都遵守了这⼀规则。不过也有例外的。
第⼆⾏为空⾏。
如果配置了⾃动发送邮件，那么第⼀⾏就⽤来做邮件标题，第三⾏开始的内容是邮件正⽂，第⼆⾏是分隔线，⽤于区分两者。
第三⾏开始，是对改动的详细介绍，可以是多⾏内容，建议每⾏长度不超过 72。
可以包括原因、做法、效果等很多内容，⼀切你认为与当前改动相关的。为何是 72 长度呢？因为 git log 输出的时候能显⽰得⽐较好看，前⾯ 4 个空格作为缩进，后⾯留 4 个空格机动（英⽂按单词排版）。 Vim 的 gq 命令排版很⽅便。
⼀些项⽬还对这个部分的内容有特殊要求，⽐如加⼀些特定标签什么的。
建议全部英⽂，⾸字母⼤写。如果⼀定要⽤中⽂，请尽量使⽤ UTF-8 编码。
⼤项⽬中，可以⽤ module/submodule: 前缀作为第⼀⾏的开头，前缀⾸字母不必⼤写。
前缀的冒号后⾯跟⼀个空格⽐较好看。为了控制字符串长度，⼦模块名称可适当缩写，但应保持统⼀。
我以前喜欢在注释第⼀⾏加上 New: Add: Fix: 这样的前缀， 看来也是没有必要了。
Tips: 提交之前，⽤ git diff –check 可以检查有⽆空⽩字符错误， ⽐如⾏尾留有空⽩什么的。
BTW，在使⽤ Git 或者其他 SCM 时，还应当避免下⾯这些做法：
把 SCM 当做备份⼯具。
SCM 是项⽬/代码管理⼯具，备份功能只是“福利”。随意将未完成测试或临时的⼯作结果进⾏提交，不仅破坏⽇志的“纯洁性”，还不利于⽇后的浏览、整理、汇总等⼯作。在开源项⽬中这么做的话，没⼈会接受这种提交。如果确实需要备份当前⼯作异地继续的话，可以采⽤这样的折衷⽅法：
$ git commit                # 在本地进⾏提交
$ git format-patch -n1      # 导出 Patch
# 这个 Patch 就是你的备份
$ git am Path_To_Patch_File # 如果换了⼯作地点，导⼊ Patch
$ git reset --mixed [hash]  # 撤销提交，保留更改，继续⼯作
⼀个改动不⼀次提交完成。
“提交”的概念是具有独⽴的功能、修正等作⽤。⼩可以⼩到只修改⼀⾏，⼤可以到改动很多⽂件，但划分的标准不变，⼀个提交就是解决⼀个问题的。
对格式的修正，不应该和其他功能修补⼀起提交，这种情况应该考虑使⽤ git add --edit ，git add -p 也可以⽤⽤，更复杂和强⼤⼀些。
注释不清晰。
⽐如只有“修正 BUG”、“改错”、“升级”等，没有其他内容，等于没说。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。