在pull远程主分支代码时，出现了如下错误：
|
1 2 |
git-lfs filter-process: git-lfs: command not found fatal: The remote end hung up unexpectedly |
解决方案
|
1 |
$ brew install git-lfs |
分类： Git
利用git format-patch和git send-email通过新浪邮箱把修改的patch文件发送给ipfire-devel
1. 下载源码
|
1 |
$ git clone git://git.ipfire.org/ipfire-2.x.git |
2. 设置git用户的邮箱和姓名
|
1 2 3 |
$ git config --global user.email "email@sina.com" $ git config --global user.name "name" |
3. 修改文件后commit
|
1 2 3 4 5 6 7 |
$ git commit -m "Simple Chinese language" commit 74179cda78a4fcbdbb94e0bb8e5ce0c03f38b5fc (HEAD -> master) Author: name <email@sina.com> Date: Mon Oct 7 16:17:03 2019 +0800 Simple Chinese language |
4. 生成patch文件
|
1 |
$ git format-patch -1 74179cda78a4fcbdbb94e0bb8e5ce0c03f38b5fc --stdout > zh_language.patch |
5. 设置git的smtp参数
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
$ git config --global sendemail.from "name <email@sina.com>" $ git config --global sendemail.smtpServer smtp.sina.com $ git config --global sendemail.smtpUser email@sina.com # 邮箱的实际登录密码 $ git config --global sendemail.smtpPass pass # 新浪邮箱要求登陆认证之后才能发送邮件 $ git config --global sendemail.smtpAuth "LOGIN" # 新浪邮箱建议使用BASE64编码 $ git config --global sendemail.transferEncoding "BASE64" $ git config --global sendemail.smtpEncryption tls $ git config --global sendemail.chainReplyTo false $ git config --global sendemail.smtpServerPort 587 |
6. 发送邮件给development@lists.ipfire.org
|
1 |
$ git send-email zh_language.patch --smtp-debug=1 |
输入ipfire-devel邮箱地址development@lists.ipfire.org, 回车两次就完成.
7.查看是否提交成功
发送邮件过一段时间后,在这里能查到https://lists.ipfire.org/mailman/listinfo/development，不同的模块有对应的邮件列表地址。
8.常见错误
测试中发现有时候 git apply 应用git format-patch创建的补丁文件的时候，可能报告如下错误：
|
1 |
git apply patch doesn't work: no such file or directory |
也就是应用补丁的时候会失败,造成这种情况的原因一般是同一份代码配置了多个远程仓库导致的。
比如我同步了一份代码到自己的服务器上，这样就容易出现这种情况。
解决方法一般是克隆一份独立的代码，单独在这个独立的代码中创建代码补丁。
参考链接
使用Git Hooks(Pre-Commit)实现代码提交的时候自动格式化代码
钩子文件在项目目录下
git 的钩子放在 git 项目下的 .git/hooks 目录。
|
1 |
$ ls -l .git/hooks |
如果我们所有项目都需要一个通用的钩子，那么我们需要在所有的项目中都放置钩子文件。挨个复制显然不是一个可行的方案。
模板目录
我们可用模板目录来解决这个问题。
在 git init 或者 git clone时，如果指定有模板目录，会使用拷贝模板目录下的文件到 .git/ 目录下。
|
1 2 3 |
$ git init --template "path-to-template-dir" $ git clone --template "path-to-template-dir" |
好了，那么解决方案就是：把统一的钩子文件放到模板目录，然后在 git init / git clone 时候指定模板目录？
不行，这样还是太麻烦了。
模板目录写入全局配置
模板目录固定在一个地方，我们可以把模板目录写入全局配置。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
# 定义模板目录，模板目录下的钩子目录 $ template_dir=$HOME/.git-templates $ tempalte_hooks_dir=$template_dir/hooks # 拷贝全局钩子文件目录到模板目录下 $ mkdir -p $template_dir $ cp -rf $root_dir/sample/git-template/hooks/ $template_dir/ # 修改模板目录下钩子目录权限 $ chmod -R a+x $tempalte_hooks_dir # 设置全局模板目录 $ git config --global init.templatedir $template_dir |
在 git init 或者 git clone 时，会自动拷贝钩子文件到项目的钩子目录。 已有项目，执行 git init 重新初始化项目即可。
代码提交时候，自动格式化的参考代码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
#!/bin/bash # https://stackoverflow.com/questions/12881975/git-pre-commit-hook-failing-in-github-for-mac-works-on-command-line export PATH=$PATH:/usr/local/bin:/usr/local/sbin STYLE=$(git config --get hooks.clangformat.style) if [ -n "${STYLE}" ] ; then STYLEARG="-style=${STYLE}" else # try source root dir STYLE=$(git rev-parse --show-toplevel)/.clang-format if [ -n "${STYLE}" ] ; then STYLEARG="-style=file" else STYLEARG="" fi fi format_file() { file="${1}" clang-format -i ${STYLEARG} ${1} git add ${1} } case "${1}" in --about ) echo "Runs clang-format on source files" ;; * ) for file in `git diff-index --cached --name-only HEAD` ; do format_file "${file}" done ;; esac |
使用的时候，简单的拷贝到.git/hooks 目录下，并重新命名为pre-commit。然后执行:
|
1 2 3 4 |
# macOS Mojave (10.14.3) $ brew install clang-format $ chmod +x .git/hooks/pre-commit |
这样，每次提交代码的时候，都会自动格式化代码了。
参考链接
Git Hooks
Git 钩子
和其它版本控制系统一样，Git 能在特定的重要动作发生时触发自定义脚本。 有两组这样的钩子：客户端的和服务器端的。 客户端钩子由诸如提交和合并这样的操作所调用，而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。 你可以随心所欲地运用这些钩子。
安装一个钩子
钩子都被存储在 Git 目录下的 hooks 子目录中。 也即绝大部分项目中的 .git/hooks 。 当你用 git init 初始化一个新版本库时，Git 默认会在这个目录中放置一些示例脚本。这些脚本除了本身可以被调用外，它们还透露了被触发时所传入的参数。 所有的示例都是 shell 脚本，其中一些还混杂了 Perl 代码，不过，任何正确命名的可执行脚本都可以正常使用 —— 你可以用 Ruby 或 Python，或其它语言编写它们。 这些示例的名字都是以 .sample 结尾，如果你想启用它们，得先移除这个后缀。
把一个正确命名且可执行的文件放入 Git 目录下的 hooks 子目录中，即可激活该钩子脚本。 这样一来，它就能被 Git 调用。 接下来，我们会讲解常用的钩子脚本类型。
客户端钩子
客户端钩子分为很多种。 下面把它们分为：提交工作流钩子、电子邮件工作流钩子和其它钩子。
|
Note
|
需要注意的是，克隆某个版本库时，它的客户端钩子 并不 随同复制。 如果需要靠这些脚本来强制维持某种策略，建议你在服务器端实现这一功能。（请参照 使用强制策略的一个例子 中的例子。）
|
提交工作流钩子
前四个钩子涉及提交的过程。
pre-commit 钩子在键入提交信息前运行。 它用于检查即将提交的快照，例如，检查是否有所遗漏，确保测试运行，以及核查代码。 如果该钩子以非零值退出，Git 将放弃此次提交，不过你可以用 git commit --no-verify 来绕过这个环节。 你可以利用该钩子，来检查代码风格是否一致（运行类似 lint 的程序）、尾随空白字符是否存在（自带的钩子就是这么做的），或新方法的文档是否适当。
prepare-commit-msg 钩子在启动提交信息编辑器之前，默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项：存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用；然而对那些会自动产生默认信息的提交，如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它，动态地插入信息。
commit-msg 钩子接收一个参数，此参数即上文提到的，存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出，Git 将放弃提交，因此，可以用来在提交通过前验证项目状态或提交信息。 在本章的最后一节，我们将展示如何使用该钩子来核对提交信息是否遵循指定的模板。
post-commit 钩子在整个提交过程完成后运行。 它不接收任何参数，但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。 该钩子一般用于通知之类的事情。
电子邮件工作流钩子
你可以给电子邮件工作流设置三个客户端钩子。 它们都是由 git am 命令调用的，因此如果你没有在你的工作流中用到这个命令，可以跳到下一节。 如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。
第一个运行的钩子是 applypatch-msg 。 它接收单个参数：包含请求合并信息的临时文件的名字。 如果脚本返回非零值，Git 将放弃该补丁。 你可以用该脚本来确保提交信息符合格式，或直接用脚本修正格式错误。
下一个在 git am 运行期间被调用的是 pre-applypatch 。 有些难以理解的是，它正好运行于应用补丁 之后，产生提交之前，所以你可以用它在提交前检查快照。 你可以用这个脚本运行测试或检查工作区。 如果有什么遗漏，或测试未能通过，脚本会以非零值退出，中断 git am 的运行，这样补丁就不会被提交。
post-applypatch 运行于提交产生之后，是在 git am 运行期间最后被调用的钩子。 你可以用它把结果通知给一个小组或所拉取的补丁的作者。 但你没办法用它停止打补丁的过程。
其它客户端钩子
pre-rebase 钩子运行于变基之前，以非零值退出可以中止变基的过程。 你可以使用这个钩子来禁止对已经推送的提交变基。 Git 自带的 pre-rebase 钩子示例就是这么做的，不过它所做的一些假设可能与你的工作流程不匹配。
post-rewrite 钩子被那些会替换提交记录的命令调用，比如 git commit --amend 和 git rebase（不过不包括 git filter-branch）。 它唯一的参数是触发重写的命令名，同时从标准输入中接受一系列重写的提交记录。 这个钩子的用途很大程度上跟 post-checkout 和 post-merge 差不多。
在 git checkout 成功运行后，post-checkout 钩子会被调用。你可以根据你的项目环境用它调整你的工作目录。 其中包括放入大的二进制文件、自动生成文档或进行其他类似这样的操作。
在 git merge 成功运行后，post-merge 钩子会被调用。 你可以用它恢复 Git 无法跟踪的工作区数据，比如权限数据。 这个钩子也可以用来验证某些在 Git 控制之外的文件是否存在，这样你就能在工作区改变时，把这些文件复制进来。
pre-push 钩子会在 git push 运行期间， 更新了远程引用但尚未传送对象时被调用。 它接受远程分支的名字和位置作为参数，同时从标准输入中读取一系列待更新的引用。 你可以在推送开始之前，用它验证对引用的更新操作（一个非零的退出码将终止推送过程）。
Git 的一些日常操作在运行时，偶尔会调用 git gc --auto 进行垃圾回收。 pre-auto-gc 钩子会在垃圾回收开始之前被调用，可以用它来提醒你现在要回收垃圾了，或者依情形判断是否要中断回收。
服务器端钩子
除了客户端钩子，作为系统管理员，你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。 这些钩子脚本在推送到服务器之前和之后运行。 推送到服务器前运行的钩子可以在任何时候以非零值退出，拒绝推送并给客户端返回错误消息，还可以依你所想设置足够复杂的推送策略。
pre-receive
处理来自客户端的推送操作时，最先被调用的脚本是 pre-receive。 它从标准输入获取一系列被推送的引用。如果它以非零值退出，所有的推送内容都不会被接受。 你可以用这个钩子阻止对引用进行非快进（non-fast-forward）的更新，或者对该推送所修改的所有引用和文件进行访问控制。
update
update 脚本和 pre-receive 脚本十分类似，不同之处在于它会为每一个准备更新的分支各运行一次。 假如推送者同时向多个分支推送内容，pre-receive 只运行一次，相比之下 update 则会为每一个被推送的分支各运行一次。 它不会从标准输入读取内容，而是接受三个参数：引用的名字（分支），推送前的引用指向的内容的 SHA-1 值，以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出，只有相应的那一个引用会被拒绝；其余的依然会被更新。
post-receive
post-receive 挂钩在整个过程完结以后运行，可以用来更新其他系统服务或者通知用户。 它接受与 pre-receive 相同的标准输入数据。 它的用途包括给某个邮件列表发信，通知持续集成（continous integration）的服务器，或者更新问题追踪系统（ticket-tracking system） —— 甚至可以通过分析提交信息来决定某个问题（ticket）是否应该被开启，修改或者关闭。 该脚本无法终止推送进程，不过客户端在它结束运行之前将保持连接状态，所以如果你想做其他操作需谨慎使用它，因为它将耗费你很长的一段时间。
参考链接
解决git clone --recursive部分失败后继续检出代码
在使用如下命令检出Vulkan的时候，发生失败，Vulkan的代码已经成功检出，但是子模块没有完成
|
1 |
$ git clone --recursive https://github.com/SaschaWillems/Vulkan.git |
提示的出错信息如下：
|
1 2 3 |
warning: 克隆成功，但是检出失败。 您可以通过 'git status' 检查哪些已被检出，然后使用命令 'git checkout -f HEAD' 重试 |
可以使用如下命令继续检出子模块：
|
1 |
$ git submodule update --init --recursive --progress |
ubuntu 16.04执行git clone时失败“RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received.”
前几天从github下载代码的时候，一直失败，提示如下：
|
1 2 3 4 5 6 7 |
$ git clone http://github.com/myriadrf/LimeSuite.git 正克隆到 'LimeSuite'... remote: Counting objects: 13921, done. error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received. fatal: The remote end hung up unexpectedly fatal: 过早的文件结束符（EOF） fatal: index-pack failed |
如果操作系统的语言是英文的话，输出如下内容：
|
1 2 3 4 |
error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received. fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed |
刚刚开始以为是由于GnuTLS的BUG导致的。
当时的解决方法是翻墙出去进行克隆。或者用Windows进行克隆操作。
然而，从最近的新闻来看，更像是遭受了攻击导致的。
github上如何删除fork的项目
在github上如果看到有很不错的项目和作品，一般我们可以进行三种操作：那就是watch, star和fork.
Ubuntu 16.04下同步github中fork出来的分支
在github上fork出一些感觉比较好的项目，已经做了部分修改，由于某些原因，无法通过pull request合并到原作者的分支，但是想把原项目的最近更新代码合并进来，可以通过git fetch原始项目到本地，通过git merge的进行代码合并。
以fork出来的pyseeta项目为例
- 检出自己的代码
|
1 |
$ git checkout https://github.com/wangqiang1588/pyseeta.git |
- 把原作者项目地址添加到刚刚检出的项目
|
1 |
$ git remote add upstream https://github.com/TuXiaokang/pyseeta.git |
- 从原作者仓库获取到分支，及相关的提交信息
|
1 |
$ git fetch upstream |
- 切换到想合并代码的分支
|
1 |
$ git checkout master |
- 代码合并,并解决冲突
|
1 |
$ git merge upstream/master |
- 提交合并后的代码
|
1 |
$ git commit -m "merge ......." |
- 推送提交到远程服务器
|
1 |
$ git push |
参考链接
使用Git Submodule管理子模块
我们经常会引用第三方的开源项目或者其他人的项目到自己的项目中来，如果直接拷贝代码，那么就需要每次他人修改后，手工同步代码，导致整个的工作量非常大。
检出主工程代码后，初始化子模块（需要手工执行）
更新同步子模块的代码：
删除子模块的代码：
git submodule使得我们可以把他人的项目作为我们自己的子项目来进行管理，当对方修改后，一个简单的同步命令就可以完成代码的自动同步，方便我们的开发。添加一个项目到我们的工程中，比如：|
1 |
$ git submodule add git@github.com:jjz/pod-library.git pod-library |
检出主工程代码后，初始化子模块（需要手工执行）
|
1 |
$ git submodule update --init --recursive |
更新同步子模块的代码：
|
1 |
$ git submodule update --recursive --remote |
删除子模块的代码：
|
1 2 3 4 5 |
$ git submodule deinit pod-library $ git rm -f pod-library $ rm -rf .git/modules/pod-library |
参考链接
git删除未监视的文件(untracked files)命令用法
git在Linux下删除未监视的文件(untracked files)，一般通过命令来执行更方便，具体执行如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# 删除 untracked files $ git clean -f # 连 untracked 的目录也一起删掉 $ git clean -fd # 连 gitignore 的untrack 文件/目录也一起删掉 （慎用，一般这个是用来删掉编译出来的 .o之类的文件用的） $ git clean -xfd # 在用上述 git clean 前，建议加上 -n 参数来先看看会删掉哪些文件，防止重要文件被误删 $ git clean -nxfd $ git clean -nf $ git clean -nfd |
一般执行
|
1 |
$ git clean -xfd |
即可。