缘起
之前按照教程系统学习了git, 自以为掌握, 但是在实际工作中却发现许多超出普通教程的操作需求.
忽略某些文件
情境
某些文件不需要纳入git进行管理, 比如缓存文件, 比如用于本地测试的设置
解决
创建一个.gitignore文件, 列出需要忽略的文件, 其配置语法是:
- 以斜杠
/开头表示目录; - 以星号
*通配多个字符, 比如*.DS_Store表示忽略所有以.DS_Store结尾的文件; - 以问号
?通配单个字符; - 以方括号
[]包含单个字符的匹配列表; - 以叹号
!表示不忽略某个特定文件或目录;
注意
- .gitignore是从上到下进行规则匹配的, 也就是说如果前面的规则匹配的范围更大, 则后面的规则将不会生效;
- 设置"文件夹忽略"时要注意:
/myDir/*表示忽略根目录下的"myDirname"文件夹, 如果是myDir/*则表示只要文件夹名字是"myDirname", 不管它是在根目录, 还是其它层次(比如/parentDir/myDir/*)都会被忽略! - 如果在开发过程中, 需要修改忽略列表, 会发现没有生效, 那是因为
.gitignore对已经被 track 的文件是无效的，换句话说, 如果文件已经被纳入 git 版本管理，则修改.gitignore是无效的.
解决办法是先把本地缓存删除, 使其变成 "未 track" 的状态, 然后再提交. 注意, 执行这项操作要非常谨慎! 因为很可能发生这种情况: 如果之前设置了错误的忽略规则, 因为没有生效, 所以没有对项目造成影响, 但是让这些错误规则真的生效, 会破坏项目! 第一, 要反复检查 '.gitignore' 规则; 第二, 执行这项操作后, 在提交到远程仓库之前, 要git status查看被影响的文件是否符合预期.
git rm -r --cached .
git add .
git commit -m '由于 .gitignore 无法忽略已经 track 的文件, 所以删除缓存重新提交, 使 .gitignore 生效'
解决办法是把本地缓存中打算忽略但是已经被 track 的文件删除, 使其变成 "未 track" 的状态.
git rm --cached <file>
暂存工作区的内容
情境
在dev分支工作到一半, 但是需要紧急修复一个bug(需要从master中新建一个bug分支), 但是dev分支的工作进行到一半, 还没到commit提交的程度.
解决
- 在dev分支中使用
git stash将未完成的工作暂存起来(stash在英文中是"隐藏"的意思); - 按照正常的步骤去修复bug -- 从master中新建一个bug分支, 然后修复, 修复完后合并到master分支;
- 切换回dev分支, 使用
git stash pop就可以将之前隐藏的修改恢复到dev分支了;
注意
如果是新增文件, 不能直接git stash, 必须先git add添加到缓存区(纳入git版本管理)才可以.
让 Git 跟踪重命名的文件
情境
直接修改文件名, 会导致 Git 中的记录是"删除文件, 而重命名后的文件被当作新增的文件".
那么如何让 Git 跟踪重命名的文件, 保持记录的可追溯?
解决
使用 git mv 命令, 即 "move/移动"命令
比如, 要将 PosterModel.php 修改为 Poster.php:
git mv src/models/PosterModel.php src/models/Poster.php
拉取远程仓库的特定分支
情境
需要拉取公司远程仓库中的某一个特定分支.
解决
- 执行
git fetch, 将远程仓库的所有分支信息获取到本地; - 执行
git checkout -b local_branch_name origin/remote_branch_name将该远程分支("origin/remote_branch_name")映射到本地名为"local-branchname"的分支; - 之后再执行拉取
git pull origin local-branchname
(PS. 执行git fetch后, 可以使用git branch -r查看拉取到本地的所有分支名称)
删除远程仓库的分支
情境
因为 Git "分支"功能强大易用, 也间接导致公司远程仓库的分支非常多, 而其中大部分分支是已经开发完毕, 可以废弃的.
解决
git push origin --delete <branchName>, 比如git push origin --delete dev_msg
PS. 删除 tag 也是类似的: git push origin --delete <tagName>
克隆时的文件夹层次问题
情境
git clone时会以项目名称建立文件夹, 比如公司的远程仓库名称是"OwnerName/RepoName", 克隆后会在当前文件夹新建一个"RepoName"的文件夹.
如何把代码直接放在根目录, 而不是新建并且放在"RepoName"文件夹下呢?
解决
在git clone后面加上./, 比如git clone https://git.oschina.net/xxxx/xxxx.git ./
commit时如何书写message
情境
(如题)
(部分)解决
暂时还没有形成系统的解决办法, 不过有2个心得:
团队协助时, 用户名称要修改成自己的名字, 方便别人识别;
之前使用 "patiencing" 做为 git 上的用户名, 在阅读 git 记录时发觉识别度很低, 可以预见别人看到这个名字时的困惑 -- 查看 git 记录时无法第一时间得知是谁修改了代码.
之后改为了自己的真实名字git config --global user.name yourrealname(PS. 如果你不想全局修改, 只要去掉--global, 也就是执行git config user.name yourname, 则只修改当前 git 仓库的用户名)-
在 commit 的 message 头部添加"代码修改范围"和"代码修改类别", 方便别人和自己查阅 Git 记录时能够很快理解代码修改的目的.
个人使用并且试验有效的分类是:-
[@优惠券#修补](表示本次提交是针对"优惠券",任务类型是修补Bug,而 message 描述建议是对 Bug 的具体情形) -
[@优惠券#排版](用于调整缩进等排版, 方便阅读; 不涉及功能性变动) [@优惠券#新增][@优惠券#删除][@优惠券#修改]-
[@优惠券#体验](优化用户体验) -
[@优惠券#优化](优化代码, 重构, 删除冗余代码)
-
撤销之前的操作
情境
后悔, 需要撤销之前的操作.
解决
- 想要撤销"工作区"中的修改
可以使用git checkout -- /path/file来撤销指定文件的工作区的修改, 恢复到上一次commit的状态
(PS. 可以执行git checkout -- .来撤销当前工作文件夹的所有变动) - 想要撤销已经
add提交到了缓存区的修改
先用git reset HEAD /path/file将文件从缓存区重新放回工作区
再执行git checkout -- /path/file撤销该文件的修改 - 想要修改
commit的"message"
如果commit后没有进行新的commit, 可以直接使用git commit --amend对上一次的message进行修改 - 撤销意外添加到缓存区的文件
类似上文中在开发过程中更新".gitignore"的操作:
git rm --cached -r dir
作用是删除缓存区中的文件
(PS. --cached表示"git的缓存", -r等于"recursive/递归", 表示递归删除文件夹中的所有文件)
查看指定文件的版本记录
情境
想查看某个指定文件的修改记录
解决
git log <file>
比如
git log config/database.php
题外
之前从事的是传统行业的设计工作, 使用"给文件名添加版本或者日期 / 文件封面的版本记录以及扉页的版本更新说明 / 云雾线 / 公用盘 ..."来进行版本控制 (大型工程公司也有在使用专业的文件管理系统来解决版本控制问题; 之前和英国的工程公司合作, 对方使用的就是这种系统, 我的体会就是"异常严谨, 同时操作反人性, 异常难用")
现在转行到程序员, 用着 git 这个版本管理工具, 回首以前面对版本控制的痛苦, 不得不感慨"程序员这个行业虽然辛苦, 但是更容易享受到工作带来的"心流 flow ".
参考文章
StackOverflow - How to make Git “forget” about a file that was tracked but is now in .gitignore?
文章历史
- 2016.12.14 (第一次发布)
- 2017.03.04 增加"删除远程仓库的分支"
- 2017.03.09 增加对"删除 git 缓存重新提交, 使中途修改的 .gitignore 生效"的操作的风险提醒
- 2017.03.09 修改"使中途修改的 .gitignore 生效"的操作, 从删除全部缓存, 更新为删除指定文件的缓存, 杜绝风险
- 2017.03.10 增加"查看指定文件的版本记录"
- 2017.03.17 增加"让 Git 跟踪重命名的文件"
- 2017.04/30 修改"commit时如何书写message", commit message 头部增加"范围"和"类别"
- 2017.05.03 修改润色
如果你觉得我的文章对你有用, 请打个"喜欢", 或者给些改进的建议 _
