美文网首页
Git 的非常规操作

Git 的非常规操作

作者: patiencing | 来源:发表于2017-04-05 03:46 被阅读0次
    git

    缘起

    之前按照教程系统学习了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提交的程度.

    解决

    1. 在dev分支中使用git stash将未完成的工作暂存起来(stash在英文中是"隐藏"的意思);
    2. 按照正常的步骤去修复bug -- 从master中新建一个bug分支, 然后修复, 修复完后合并到master分支;
    3. 切换回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
    

    拉取远程仓库的特定分支

    情境

    需要拉取公司远程仓库中的某一个特定分支.

    解决

    1. 执行git fetch, 将远程仓库的所有分支信息获取到本地;
    2. 执行git checkout -b local_branch_name origin/remote_branch_name将该远程分支("origin/remote_branch_name")映射到本地名为"local-branchname"的分支;
    3. 之后再执行拉取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个心得:

    1. 团队协助时, 用户名称要修改成自己的名字, 方便别人识别;
      之前使用 "patiencing" 做为 git 上的用户名, 在阅读 git 记录时发觉识别度很低, 可以预见别人看到这个名字时的困惑 -- 查看 git 记录时无法第一时间得知是谁修改了代码.
      之后改为了自己的真实名字 git config --global user.name yourrealname (PS. 如果你不想全局修改, 只要去掉 --global , 也就是执行 git config user.name yourname, 则只修改当前 git 仓库的用户名)

    2. 在 commit 的 message 头部添加"代码修改范围"和"代码修改类别", 方便别人和自己查阅 Git 记录时能够很快理解代码修改的目的.
      个人使用并且试验有效的分类是:

      • [@优惠券#修补] (表示本次提交是针对"优惠券",任务类型是修补Bug,而 message 描述建议是对 Bug 的具体情形)
      • [@优惠券#排版] (用于调整缩进等排版, 方便阅读; 不涉及功能性变动)
      • [@优惠券#新增]
      • [@优惠券#删除]
      • [@优惠券#修改]
      • [@优惠券#体验] (优化用户体验)
      • [@优惠券#优化] (优化代码, 重构, 删除冗余代码)

    撤销之前的操作

    情境

    后悔, 需要撤销之前的操作.

    解决

    1. 想要撤销"工作区"中的修改
      可以使用git checkout -- /path/file来撤销指定文件的工作区的修改, 恢复到上一次commit的状态
      (PS. 可以执行git checkout -- .来撤销当前工作文件夹的所有变动)
    2. 想要撤销已经add提交到了缓存区的修改
      先用git reset HEAD /path/file将文件从缓存区重新放回工作区
      再执行git checkout -- /path/file撤销该文件的修改
    3. 想要修改commit的"message"
      如果commit后没有进行新的commit, 可以直接使用git commit --amend对上一次的message进行修改
    4. 撤销意外添加到缓存区的文件
      类似上文中在开发过程中更新".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 修改润色

    如果你觉得我的文章对你有用, 请打个"喜欢", 或者给些改进的建议 _

    相关文章

      网友评论

          本文标题:Git 的非常规操作

          本文链接:https://www.haomeiwen.com/subject/ggctattx.html