Git

建立独立的分支 当想在项目中使用一个独立分支进行项目文档的管理时，或者当我们想要发布一个软件的开源版本但又不希望将软件的版本历史暴露给外界时，都可以使用以下的方法建立一个独立分支： git help checkout # git checkout --orphan <new-branch> <start-point> 修改提交时间 # 指定本次提交时间 git commit -m "fix..." --date=`date -R` git commit -m "fix..." --date="$(date -R)" git commit -m "fix..." --date="Tue, 11 Jun 2019 17:50:50 +0800" # 修改上次提交时间 git commit --amend --date=`date -R` # 风险操作。会修改 history hash. 忽略文件权限修改 # Git 默认会记录文件权限的修改，可关闭 git config core.filemode false git status 中文文件名乱码 git config --global core.quotepath false 当 core.quotepath 设置为 false 时，Git 将不会对路径名进行 quoting，这意味着路径名中的特殊字符将不被转义。 Git 中文显示问题解决 工作区中删除未跟踪的文件 # 查看文档 git help clean git clean -h # git clean [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] [<pathspec>...] # 【查看】有哪些文件将被删除 git clean -n # 【查看】删除 Git【忽略】的文件与文件夹 git clean -Xn # 【查看】删除【src 路径下】下的【未跟踪】文件以及文件夹 git clean -d -- src # 如果想执行删除 -n 替换为 -f，注意风险。 Git 清除未跟踪文件 | github.io ...

记住密码 Git 记住密码配置后，不用每次 pull、push 都需要输入密码： git config --global credential.helper store 会在 cat ~/.gitconfig 看到： [credential] helper = store 快速检出上一个分支 git checkout - 提交空改动 git commit -m "empty commit" --allow-empty 在如下几种情况下是有意义： 标记一批工作或一个新功能的开始。 记录你对项目进行了跟代码无关的改动。 跟使用你仓库的其他人交流。 作为仓库的第一次提交，因为第一次提交日后是不能被 rebase 的：git commit -m "init repo" --allow-empty。 更直观的 status git status -sb 更直观的 log git log --all --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an %ae>%Creset' --abbrev-commit --date=relative 提交信息查询 找到其中和搜索条件相匹配的最近的一条。query （区别大小写）是你想要搜索的词语。 git show :/query 分支合并 显示所有已经合并到你当前分支的分支列表： git branch --merged 相反地： ...

应该将 vendor 提交到 Git 吗 一般建议是 不。vendor 目录应添加到 .gitignore。 最佳实践是让所有开发人员使用 Composer 来安装依赖项。类似地，构建服务器、CI、部署工具等都应该作为项目启动的一部分来运行 Composer。 虽然在某些环境下这样做很诱人，但也会导致一些问题： 大型 VCS 存储库的大小和更新代码时的差异。 在你自己的 VCS 复制你所有依赖的历史。 将通过 git 安装的依赖项添加到 git repo 中将显示为 submodules。这是有问题的，因为它们不是真正的 submodules，您将会遇到问题。 如果你真的觉得你必须这样做，你有几个选择： 限制自己安装带标记的版本（没有 dev 版本），这样就只能安装压缩版，并避免与 git submodules 有关的问题。 Use --prefer-dist or set preferred-install to dist in your config. Remove the .git directory of every dependency after the installation, then you can add them to your git repo. You can do that with rm -rf vendor/\*\*/.git in ZSH or find vendor/ -type d -name ".git" -exec rm -rf {} \; in Bash. 但这意味着您必须在运行 composer 更新之前从磁盘中删除这些依赖项。 Add a .gitignore rule /vendor/**/.git to ignore all the vendor .git folders. 这种方法不需要在运行编写器更新之前从磁盘删除依赖项。 我的做法 问题解决了，但是不确信做法是否正确。 ...

统计个人增删行数 git config user.name git log --author="zhaoyifan" --pretty=tformat: --numstat | awk '{ add += $1; subs += $2; loc += $1 - $2 } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }' - added lines: 82813, removed lines: 53707, total lines: 29106 统计每个人增删行数 git log --shortstat | grep -E "(Author: )(\s*(\w+)){2}|fil(e|es) changed" | awk ' { if($1 ~ /Author/) { author = $2" "$3 } else { files[author]+=$1 inserted[author]+=$4 deleted[author]+=$6 } } END { for (key in files) { print "Author: " key "\n\tfiles changed: ", files[key], "\n\tlines inserted: ", inserted[key], "\n\tlines deleted: ", deleted[key] } } ' 统计每个人提交次数 git shortlog -sn --no-merges 忽略某些路径的更改 git log -- . ":(exclude)sub" git log -- . ":!sub" cloc AlDanial/cloc - cloc counts blank lines, comment lines, and physical lines of source code in many programming languages. ...

注意：此操作会修改 Git 历史记录，正式工作环境不允许。 查询都有什么： git log --format='%aN %aE' | sort -u 注：一个特殊情况如果 email 没被设置过 OLD_EMAIL 可以填 user.name。 OLD_EMAIL 原来的邮箱 CORRECT_NAME 更正的名字 CORRECT_EMAIL 更正的邮箱 git filter-branch -f --env-filter ' OLD_EMAIL="old@qq.com" CORRECT_NAME="new_name" CORRECT_EMAIL="new@gmail.com" if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ] then export GIT_COMMITTER_NAME="$CORRECT_NAME" export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL" fi if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ] then export GIT_AUTHOR_NAME="$CORRECT_NAME" export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL" fi if [ "$GIT_AUTHOR_NAME" != "$CORRECT_NAME" ] then export GIT_AUTHOR_NAME="$CORRECT_NAME" export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL" fi ' --tag-name-filter cat -- --branches --tags 因为修改了 Git 历史所有要使用强制推送： ...

先去官网看看 Download for Linux and Unix: RHEL and derivatives typically ship older versions of git. You can download a tarball and build from source, or use a 3rd-party repository such as the [IUS Community Project](https://ius.io/) to obtain a more recent version of git. RHEL 和衍生通常提供较老版本的 git。您可以下载 tarball 并从源代码构建，或者使用第三方存储库，如 IUS Community Project 来获得最新版本的 git。 使用 IUS RHEL/CentOS 7 yum install \ https://repo.ius.io/ius-release-el7.rpm \ https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm 安装新版 git： ius 通常会在高版本的软件名后面 + u yum list git 如果你已经装有低版本的 git，你需要先 remove（否则安装的时候会报错） yum remove git 安装 2.0 以上版本的 git ...

git add . warning: CRLF will be replaced by LF in X. CRLF：windows 环境下的换行符 LF：linux 环境下的换行符 这个错误的意思，就是文件中存在两种环境的换行符，git 会自动替换 CRLF 为 LF ，所以提示警告。 首先推荐扩展阅读：配置 Git 处理行结束符 | GitHub 我项目中是配置了 .gitattributes 的： # Set the default behavior, in case people don't have core.autocrlf set. * text=auto # Explicitly declare text files you want to always be normalized and converted # to native line endings on checkout. *.c text *.h text # Declare files that will always have CRLF line endings on checkout. *.sln text eol=crlf # Denote all files that are truly binary and should not be modified. *.png binary *.jpg binary .gitattributes 公式：要匹配的文件模式 属性1 属性2 ...。 ...

commit message 应该清晰明了，说明本次提交的目的。基本公式： <type>(<scope>): <subject> 完整公式： <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer> type 用于说明 commit 的类别，只允许使用下面 7 个标识。 feat：新功能（feature） fix：修补 bug docs：文档（documentation） style：格式（不影响代码运行的变动） refactor：重构（即不是新增功能，也不是修改 bug 的代码变动） test：增加测试 chore：构建过程或辅助工具的变动 scope 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。 subject 是 commit 目的的简短描述，不超过 50 个字符。 以动词开头，使用第一人称现在时，比如 change，而不是 changed 或 changes 第一个字母小写 结尾不加句号 . cli 工具 commitizen cli commitizen/cz-cli 使用它提供的 git cz 命令替代我们的 git commit 命令，帮助我们生成符合规范的 commit message。 除此之外，我们还需要为 commitizen 指定一个 Adapter 比如：commitizen/cz-conventional-changelog（一个符合 Angular 团队规范的 preset）使得 commitizen 按照我们指定的规范帮助我们生成 commit message。 ...

主要内容：【Git 协同模型】 经典 Git 协同模型 集中式协同模型 可以像集中式版本控制系统那样使用 Git，在一个大家都可以访问到的服务器上架设 Git 服务器，每个人从该服务器克隆代码，本地提交推送到服务器上。 金字塔式协同模型 虽然理论上每个开发者的版本库都是平等的，但是会有一个公认的权威的版本库，这个版本库由一个或者多个核心开发者负责维护（具有推送的权限）。 开源社区逐渐发展出金字塔模型，而这也是必然之选。 Topgit 协同模型 笔者注：Topgit 是否已经过时？ 卖主分支 Vendor Branch 是在版本库中专门创建一个和上游同步的分支，一旦有上游代码发布就捡入到卖主分支中。 子模组协同模型 创建子模组 git submodule add /path/to/repos/libA.git lib/lib_a .gitmodules 的内容： cat .gitmodules [submodule "lib/lib_a"] path = lib/lib_a url = /path/to/repos/libA.git 克隆带子模组的版本库 git clone /path/to/repos/super.git /path/to/my/workspace/super-clone 子模组的版本库并不会默认克隆，如果需要克隆出子模组型式引用的外部库，需要执行： git submodule init git submodule update 在子模组中修改和子模组的更新 修改更新的方式和普通仓库一样。如果修改了子模块，要先推送子模块的修改，再推送主仓库，以防止其他人克隆 super 版本库、更新模组时因为找不到该子模组版本库相应的提交而导致出错。 查看子模组状态： git submodule status 子树合并 引入外部版本库 # 注册外部版本库 git remote add util /path/to/repos/util.git git fetch util # 查看所有分支 git branch -a # 从 util/master 远程分支创建一个本地分支 util-branch git checkout -b util-branch util/master 子目录方式合并外部版本库 # 在主分支，将分支 util-branch 读取到当前分支的一个子目录下 git read-tree --prefix=lib util-branch # 将 lib 目录下的文件更新出来 git checkout -- lib 现在还不能忙着提交，因为如果现在进行提交就体现不出来两个分支的合并关系。需要使用 Git 底层的命令进行数据提交。 ...

主要内容：【Git 协议与工作协同】、【冲突解决】、【Git 里程碑】、【Git 分支】、【远程版本库】、【补丁文件交互】 Git 协议与工作协同 Git 支持的协议 SSH、GIT、HTTP、HTTPS、FTP、FTPS、RSYNC 及前面已经看到的本地协议。 SSH 协议： ssh://[user@]example.com[:port]/path/to/repo.git/ [user@]example.com:path/to/repo.git/ GIT 协议，最常用的只读协议： git://example.com[:port]/path/to/repo.git/ HTTP[S] 协议： http[s]://example.com[:port]/path/to/repo.git/ 强制非快进式推送 git push -f 强制推送，会强制刷新服务器中的版本。 禁止非快进式推送 git --git-dir=/path/to/repos/shared.git config receive.denyNonFastForwards true 冲突解决 拉回操作中的合并 git pull = git fetch + git merge 合并策略 Merge Strategis Git 合并操作支持很多合并策略，默认会选择最适合的合并策略。例如，和一个分支进行合并时会选择 recursive 合并策略，当和两个或两个以上的其他分支进行合并时采用 octopus 合并策略。 git merge [-s <strategy>] [-X <strategy-option>] [<commit>...] This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. git merge -s recursive -X ours [<commit>...] Merge branch obsolete into the current branch, using ours merge strategy: ...