git
github首页Maximum retries exceeded Please add an env variable called PAT_1 with your token
网络 • 马化云 发表了文章 • 0 个评论 • 1870 次浏览 • 2023-01-18 11:12
最近登录github后，发现之前显示的状态都不正常了。
正常的时候是这样的：
但现在提示是这样的：
Something went wrong! file an issue at https://tiny.one/readme-statsMaximum retries exceeded Please add an env variable called PAT_1 with your github token in vercel
有两个办法可以解决。
1. Set it up yourself using Vercel (requires some step)
2. Use URL provided by others (The easiest step)
翻译成中文：
1. 自己到vercel上部署一个这样的app （复杂）
2. 换一个其他人部署好的链接 （容易)
一般人就别折腾第一种方法了，直接使用第二种方法就好了。
笔者找了一些其他人部署好的链接：
拿去用就可以了：https://github-readme-stats-git-masterrstaa-rickstaa.vercel.app
By Unknown
https://github-readme-stats-ruby-one.vercel.app
By Claudio Tancredi
https://github-readme-stats-ten-gilt.vercel.app
By Unknown
https://github-readme-stats-61 ... l.app
By Fanwang Meng
https://github-readme-stats.zohan.tech
By Zohan Subhash
https://readme-stats.clckblog.space
By Kevin Zhong
查看全部
正常的时候是这样的：
但现在提示是这样的：
Something went wrong! file an issue at https://tiny.one/readme-statsMaximum retries exceeded Please add an env variable called PAT_1 with your github token in vercel
有两个办法可以解决。
1. Set it up yourself using Vercel (requires some step)
2. Use URL provided by others (The easiest step)
翻译成中文：
1. 自己到vercel上部署一个这样的app （复杂）
2. 换一个其他人部署好的链接 （容易)
一般人就别折腾第一种方法了，直接使用第二种方法就好了。
笔者找了一些其他人部署好的链接：
拿去用就可以了：https://github-readme-stats-git-masterrstaa-rickstaa.vercel.app
By Unknown
https://github-readme-stats-ruby-one.vercel.app
By Claudio Tancredi
https://github-readme-stats-ten-gilt.vercel.app
By Unknown
https://github-readme-stats-61 ... l.app
By Fanwang Meng
https://github-readme-stats.zohan.tech
By Zohan Subhash
https://readme-stats.clckblog.space
By Kevin Zhong
查看全部
最近登录github后，发现之前显示的状态都不正常了。
正常的时候是这样的：
但现在提示是这样的：
有两个办法可以解决。
1. Set it up yourself using Vercel (requires some step)
2. Use URL provided by others (The easiest step)
翻译成中文：
1. 自己到vercel上部署一个这样的app （复杂）
2. 换一个其他人部署好的链接 （容易)
一般人就别折腾第一种方法了，直接使用第二种方法就好了。
笔者找了一些其他人部署好的链接：
拿去用就可以了：
正常的时候是这样的：
但现在提示是这样的：
Something went wrong! file an issue at https://tiny.one/readme-statsMaximum retries exceeded Please add an env variable called PAT_1 with your github token in vercel
有两个办法可以解决。
1. Set it up yourself using Vercel (requires some step)
2. Use URL provided by others (The easiest step)
翻译成中文：
1. 自己到vercel上部署一个这样的app （复杂）
2. 换一个其他人部署好的链接 （容易)
一般人就别折腾第一种方法了，直接使用第二种方法就好了。
笔者找了一些其他人部署好的链接：
拿去用就可以了：
https://github-readme-stats-git-masterrstaa-rickstaa.vercel.app
By Unknown
https://github-readme-stats-ruby-one.vercel.app
By Claudio Tancredi
https://github-readme-stats-ten-gilt.vercel.app
By Unknown
https://github-readme-stats-61 ... l.app
By Fanwang Meng
https://github-readme-stats.zohan.tech
By Zohan Subhash
https://readme-stats.clckblog.space
By Kevin Zhong
linux下好用的git gui工具 推荐！
Linux • 李魔佛 发表了文章 • 0 个评论 • 3104 次浏览 • 2022-06-11 17:37
之前写过一篇免费版的kranken
ubuntu下最好的图形git管理工具kranken (免费版本)
用了一个月之后，发现免费版不支持私有仓库，这。。。。。
那自己的私有仓库还得专门找软件管理。
突然看到ubuntu下平时用的不多的vs code，发现里面git的插件可真多。
把最多星的git相关插件装上后，它的功能基本大部分都可以覆盖了95%kraken的可视化功能了！
查看全部
ubuntu下最好的图形git管理工具kranken (免费版本)
用了一个月之后，发现免费版不支持私有仓库，这。。。。。
那自己的私有仓库还得专门找软件管理。
突然看到ubuntu下平时用的不多的vs code，发现里面git的插件可真多。
把最多星的git相关插件装上后，它的功能基本大部分都可以覆盖了95%kraken的可视化功能了！
查看全部
之前写过一篇免费版的kranken
ubuntu下最好的图形git管理工具kranken (免费版本)
用了一个月之后，发现免费版不支持私有仓库，这。。。。。
那自己的私有仓库还得专门找软件管理。
突然看到ubuntu下平时用的不多的vs code，发现里面git的插件可真多。
把最多星的git相关插件装上后，它的功能基本大部分都可以覆盖了95%kraken的可视化功能了！
ubuntu下最好的图形git管理工具kranken (免费版本)
用了一个月之后，发现免费版不支持私有仓库，这。。。。。
那自己的私有仓库还得专门找软件管理。
突然看到ubuntu下平时用的不多的vs code，发现里面git的插件可真多。
把最多星的git相关插件装上后，它的功能基本大部分都可以覆盖了95%kraken的可视化功能了！
Got recursion not available from 8.8.8.8
网络 • 李魔佛 发表了文章 • 0 个评论 • 2361 次浏览 • 2022-05-26 12:18
github被墙，然后改dns也不管用。
返回的报错：Got recursion not available from 8.8.8.8
返回的github的ip地址还是为127.0.0.1
只能直接修改hosts文件了 查看全部
返回的报错：Got recursion not available from 8.8.8.8
返回的github的ip地址还是为127.0.0.1
只能直接修改hosts文件了 查看全部
github被墙，然后改dns也不管用。
返回的报错：
返回的github的ip地址还是为127.0.0.1
只能直接修改hosts文件了
返回的报错：
Got recursion not available from 8.8.8.8
返回的github的ip地址还是为127.0.0.1
只能直接修改hosts文件了
github上私有仓库提交的星星是不会显示
每日总结 • 李魔佛 发表了文章 • 0 个评论 • 2264 次浏览 • 2021-02-26 18:58
一个是登录状态后查看的自己的星星数，一个是没有登录状态下的星星数
登录后
登录前
登录后
登录前
一个是登录状态后查看的自己的星星数，一个是没有登录状态下的星星数
登录后
登录前
登录后
登录前
git命令行查看图形化的分支信息与commit 缩写id
Linux • 李魔佛 发表了文章 • 0 个评论 • 6220 次浏览 • 2020-06-21 16:56
在命令行下面，有时候需要可视化的观察git的分支情况以及commit id的缩写值。
可以使用 git log 加若干参数
git log --graph --pretty=oneline --abbrev-commit
效果是这样的：
而实际在source tree中是这样的：
查看全部
可以使用 git log 加若干参数
git log --graph --pretty=oneline --abbrev-commit
效果是这样的：
而实际在source tree中是这样的：
查看全部
在命令行下面，有时候需要可视化的观察git的分支情况以及commit id的缩写值。
可以使用 git log 加若干参数
效果是这样的：
而实际在source tree中是这样的：
可以使用 git log 加若干参数
git log --graph --pretty=oneline --abbrev-commit
效果是这样的：
而实际在source tree中是这样的：
最流行的版本控制软件：git 个人笔记
python • 李魔佛 发表了文章 • 0 个评论 • 3314 次浏览 • 2019-04-16 23:37
最流行的版本控制软件：git
========================
git已经是当前最流行的版本控制软件之一了。全世界的程序员都在使用它。它出自linus大神之手，现在被用于内
核的版本控制。在最流行的代码托管软件github，你几乎可以找到所有开源项目的代码。
版块控制软件：我需要吗？
-----------------------
的确对于许多人——尤其是非程序员，他们可能不会想到已经出现了专门的版本控制的软件。但其实多人对版本控
制其实都有类似的需求，举个例子，Tom是社团的秘书处成员，他们经常需要做的事情就是写活动文档，然后不停地
改改到大家都觉得可以了。
不幸运的话，Tom可能有个文件夹叫“openSUSE活动策划"，里面有这样的一堆文件”openSUSE活动策划", "活动策
划1", "活动策划2", "活动策划3", "活动策划4" ... "活动策划20" （可怜的Tom，一份文档改了不少于20次）
这种作法很有效，因为我们可能发现第5个版本的策划有问题，我们准备在第3个版本上面重新来过。但是也看到，
这个作法有些很丑陋的地方：一份文件，我们留了20个备份，而且还要注意文件名。
如果可以这样就好了：文件夹上只有一个“openSUSE活动策划"，但当我需要第5个版本的时候，我来一个”给我还
原到第5个版本吧！“，然后这时候我们打开这个文件，它就是第5个版本的了。类似的，我们可以取出任意的版本
。
这就是版本控制。这种事情在程序里面发生的太多了，于是出现了各种版本控制软件。事实上，有些项目已经发展
到第1000+甚至更高的版本数了……
单线的工作流
------------
我们可以把我们的一个项目想象为一个仓库，然后我们可以把我们的东西塞进仓库里面，也可以把想要的东西拿出
来。而git则是仓库的管理员。下面是一个例子，希望有一个直观的印象，不求完全的理解和掌握。
```bash
mkdir myproject // 假设myproject是工作目录
cd myproject
git init // git <- (init) ，告诉仓库管理员，在当前目录初始化
echo 'Eat the banana' > file // 编辑了一个文件
git add file // 加入仓库
git commit -m 'add first file' // 提交更改
echo 'Eat the apply' > file // 修改了这个文件
git add file // 加入仓库
git commit -m 'update first file' // 再提交更改
```
这时候我们就有两个commit了，我们来看看工作日志：
```bash
git log
# 以下是输出
# commit ac1371173b4e630ddaebda3f9f5d948b36146c07
# Author: Norman Mo <LTaoist@@@>
# Date: Thu Jun 27 21:59:10 2013 +0800
#
# update first file
#
# commit 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0
# Author: Norman Mo <LTaoist6@@@@>
# Date: Thu Jun 27 21:58:48 2013 +0800
#
# add first file
```
看到了，我们提交了两次。我们来看看现在file里面是什么：
```bash
cat file # 显然输出是 'Eat the apply'
# 现在，我们来拿回第一个版本的file文件
git checkout 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0 -- file
cat file # 这时候就是eat banana了
```
这种工作的方式是单人使用最常见的方式，写一点代码，提交一下到仓库里面。写一点，提交到仓库里面。然后出
问题的时候就回退过去。git非常强大，基本上你想到的他都可以做到，提交到仓库的数据基本不会丢失，像时间机
器一样控制着代码。
多人协作
--------
git非常强大，上面只是一个功能。考虑Tom的秘书处有两个人，他们在同时写。其中Tom写前6章，他的同伴写第7～
12章。
这时候可以考虑用这种工作的方式：设立一个公共的仓库。Tom维护自己的版本，他的同伴维护自己的版本。然后大
家定期把代码合并到公共仓库上面，然后定期把新的版本取回来合并再提交到公共仓库。
如果他们用纯文本，得益于一些文本分析的方法，几乎不需要校对就可以做到。
```
git commit -m 'finish ch5' // 假设此时Tom写完了第5章
git push // Tom将代码推送到远程仓库
```
```
git commit -m 'finish ch11' // 假设此时Tom的同伴完成了第11章
git pull // pull会将最新版本拉下来，合并，然后推送到远程仓库
```
实际上工作中，为了不混淆，会新开一个分支来开发新的特性，然后对分支进行合并。
代码自动发布
-----------
另一个很强大的功能是可以实现代码的自动发布。事实上，很多云就有使用这个。具体来说，利用git的hooks，当
服务器收到一个push，服务器可以自动运行一些脚本。也可以在客户端使用hooks，当客户端准备push的时候，客户
端先运行一些脚本。
例如，我们希望在每次服务器收到push以后，杀死全部的 `p` 进程，然后重开 `p` 进程。我们可以修改 `hooks/
post-receive` :
```
echo "Killing all p process..."
killall -9 p
echo "Restart p process..."
p
```
更多更多更多……
---------------
这份教程就到这里了，更多的自己马上动手去试试吧！
在openSUSE的安装方法：
```
sudo zypper in git
```
默认应该就装了。
一般linux命令查看帮助都是 `--help` 选项：
```
git --help
```
此外，对一个子命令也是有help看的：
```
git init --help
```
这里有一个交互教程，在浏览器上面跑的模拟git的运行的，有兴趣的试试：
<http://try.github.io/>
github的help文档写得很不错，推荐一下：
<https://help.github.com/>
书籍有个远近闻名的《Pro Git》，而且有中文版的，虽然我认为这本书太厚了。。。但似乎就这么一本书……
<http://git-scm.com/book/zh>
国内有个gitcafe，也是做git托管的，他们也有整理一份help：
<https://gitcafe.com/GitCafe/Help>
记得，上面只是一个演示，多试试push，多尝试。有一天你会喜欢用这个有效的工具的。
很有用！！！ 查看全部
========================
git已经是当前最流行的版本控制软件之一了。全世界的程序员都在使用它。它出自linus大神之手，现在被用于内
核的版本控制。在最流行的代码托管软件github，你几乎可以找到所有开源项目的代码。
版块控制软件：我需要吗？
-----------------------
的确对于许多人——尤其是非程序员，他们可能不会想到已经出现了专门的版本控制的软件。但其实多人对版本控
制其实都有类似的需求，举个例子，Tom是社团的秘书处成员，他们经常需要做的事情就是写活动文档，然后不停地
改改到大家都觉得可以了。
不幸运的话，Tom可能有个文件夹叫“openSUSE活动策划"，里面有这样的一堆文件”openSUSE活动策划", "活动策
划1", "活动策划2", "活动策划3", "活动策划4" ... "活动策划20" （可怜的Tom，一份文档改了不少于20次）
这种作法很有效，因为我们可能发现第5个版本的策划有问题，我们准备在第3个版本上面重新来过。但是也看到，
这个作法有些很丑陋的地方：一份文件，我们留了20个备份，而且还要注意文件名。
如果可以这样就好了：文件夹上只有一个“openSUSE活动策划"，但当我需要第5个版本的时候，我来一个”给我还
原到第5个版本吧！“，然后这时候我们打开这个文件，它就是第5个版本的了。类似的，我们可以取出任意的版本
。
这就是版本控制。这种事情在程序里面发生的太多了，于是出现了各种版本控制软件。事实上，有些项目已经发展
到第1000+甚至更高的版本数了……
单线的工作流
------------
我们可以把我们的一个项目想象为一个仓库，然后我们可以把我们的东西塞进仓库里面，也可以把想要的东西拿出
来。而git则是仓库的管理员。下面是一个例子，希望有一个直观的印象，不求完全的理解和掌握。
```bash
mkdir myproject // 假设myproject是工作目录
cd myproject
git init // git <- (init) ，告诉仓库管理员，在当前目录初始化
echo 'Eat the banana' > file // 编辑了一个文件
git add file // 加入仓库
git commit -m 'add first file' // 提交更改
echo 'Eat the apply' > file // 修改了这个文件
git add file // 加入仓库
git commit -m 'update first file' // 再提交更改
```
这时候我们就有两个commit了，我们来看看工作日志：
```bash
git log
# 以下是输出
# commit ac1371173b4e630ddaebda3f9f5d948b36146c07
# Author: Norman Mo <LTaoist@@@>
# Date: Thu Jun 27 21:59:10 2013 +0800
#
# update first file
#
# commit 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0
# Author: Norman Mo <LTaoist6@@@@>
# Date: Thu Jun 27 21:58:48 2013 +0800
#
# add first file
```
看到了，我们提交了两次。我们来看看现在file里面是什么：
```bash
cat file # 显然输出是 'Eat the apply'
# 现在，我们来拿回第一个版本的file文件
git checkout 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0 -- file
cat file # 这时候就是eat banana了
```
这种工作的方式是单人使用最常见的方式，写一点代码，提交一下到仓库里面。写一点，提交到仓库里面。然后出
问题的时候就回退过去。git非常强大，基本上你想到的他都可以做到，提交到仓库的数据基本不会丢失，像时间机
器一样控制着代码。
多人协作
--------
git非常强大，上面只是一个功能。考虑Tom的秘书处有两个人，他们在同时写。其中Tom写前6章，他的同伴写第7～
12章。
这时候可以考虑用这种工作的方式：设立一个公共的仓库。Tom维护自己的版本，他的同伴维护自己的版本。然后大
家定期把代码合并到公共仓库上面，然后定期把新的版本取回来合并再提交到公共仓库。
如果他们用纯文本，得益于一些文本分析的方法，几乎不需要校对就可以做到。
```
git commit -m 'finish ch5' // 假设此时Tom写完了第5章
git push // Tom将代码推送到远程仓库
```
```
git commit -m 'finish ch11' // 假设此时Tom的同伴完成了第11章
git pull // pull会将最新版本拉下来，合并，然后推送到远程仓库
```
实际上工作中，为了不混淆，会新开一个分支来开发新的特性，然后对分支进行合并。
代码自动发布
-----------
另一个很强大的功能是可以实现代码的自动发布。事实上，很多云就有使用这个。具体来说，利用git的hooks，当
服务器收到一个push，服务器可以自动运行一些脚本。也可以在客户端使用hooks，当客户端准备push的时候，客户
端先运行一些脚本。
例如，我们希望在每次服务器收到push以后，杀死全部的 `p` 进程，然后重开 `p` 进程。我们可以修改 `hooks/
post-receive` :
```
echo "Killing all p process..."
killall -9 p
echo "Restart p process..."
p
```
更多更多更多……
---------------
这份教程就到这里了，更多的自己马上动手去试试吧！
在openSUSE的安装方法：
```
sudo zypper in git
```
默认应该就装了。
一般linux命令查看帮助都是 `--help` 选项：
```
git --help
```
此外，对一个子命令也是有help看的：
```
git init --help
```
这里有一个交互教程，在浏览器上面跑的模拟git的运行的，有兴趣的试试：
<http://try.github.io/>
github的help文档写得很不错，推荐一下：
<https://help.github.com/>
书籍有个远近闻名的《Pro Git》，而且有中文版的，虽然我认为这本书太厚了。。。但似乎就这么一本书……
<http://git-scm.com/book/zh>
国内有个gitcafe，也是做git托管的，他们也有整理一份help：
<https://gitcafe.com/GitCafe/Help>
记得，上面只是一个演示，多试试push，多尝试。有一天你会喜欢用这个有效的工具的。
很有用！！！ 查看全部
最流行的版本控制软件：git
========================
git已经是当前最流行的版本控制软件之一了。全世界的程序员都在使用它。它出自linus大神之手，现在被用于内
核的版本控制。在最流行的代码托管软件github，你几乎可以找到所有开源项目的代码。
版块控制软件：我需要吗？
-----------------------
的确对于许多人——尤其是非程序员，他们可能不会想到已经出现了专门的版本控制的软件。但其实多人对版本控
制其实都有类似的需求，举个例子，Tom是社团的秘书处成员，他们经常需要做的事情就是写活动文档，然后不停地
改改到大家都觉得可以了。
不幸运的话，Tom可能有个文件夹叫“openSUSE活动策划"，里面有这样的一堆文件”openSUSE活动策划", "活动策
划1", "活动策划2", "活动策划3", "活动策划4" ... "活动策划20" （可怜的Tom，一份文档改了不少于20次）
这种作法很有效，因为我们可能发现第5个版本的策划有问题，我们准备在第3个版本上面重新来过。但是也看到，
这个作法有些很丑陋的地方：一份文件，我们留了20个备份，而且还要注意文件名。
如果可以这样就好了：文件夹上只有一个“openSUSE活动策划"，但当我需要第5个版本的时候，我来一个”给我还
原到第5个版本吧！“，然后这时候我们打开这个文件，它就是第5个版本的了。类似的，我们可以取出任意的版本
。
这就是版本控制。这种事情在程序里面发生的太多了，于是出现了各种版本控制软件。事实上，有些项目已经发展
到第1000+甚至更高的版本数了……
单线的工作流
------------
我们可以把我们的一个项目想象为一个仓库，然后我们可以把我们的东西塞进仓库里面，也可以把想要的东西拿出
来。而git则是仓库的管理员。下面是一个例子，希望有一个直观的印象，不求完全的理解和掌握。
```bash
mkdir myproject // 假设myproject是工作目录
cd myproject
git init // git <- (init) ，告诉仓库管理员，在当前目录初始化
echo 'Eat the banana' > file // 编辑了一个文件
git add file // 加入仓库
git commit -m 'add first file' // 提交更改
echo 'Eat the apply' > file // 修改了这个文件
git add file // 加入仓库
git commit -m 'update first file' // 再提交更改
```
这时候我们就有两个commit了，我们来看看工作日志：
```bash
git log
# 以下是输出
# commit ac1371173b4e630ddaebda3f9f5d948b36146c07
# Author: Norman Mo <LTaoist@@@>
# Date: Thu Jun 27 21:59:10 2013 +0800
#
# update first file
#
# commit 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0
# Author: Norman Mo <LTaoist6@@@@>
# Date: Thu Jun 27 21:58:48 2013 +0800
#
# add first file
```
看到了，我们提交了两次。我们来看看现在file里面是什么：
```bash
cat file # 显然输出是 'Eat the apply'
# 现在，我们来拿回第一个版本的file文件
git checkout 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0 -- file
cat file # 这时候就是eat banana了
```
这种工作的方式是单人使用最常见的方式，写一点代码，提交一下到仓库里面。写一点，提交到仓库里面。然后出
问题的时候就回退过去。git非常强大，基本上你想到的他都可以做到，提交到仓库的数据基本不会丢失，像时间机
器一样控制着代码。
多人协作
--------
git非常强大，上面只是一个功能。考虑Tom的秘书处有两个人，他们在同时写。其中Tom写前6章，他的同伴写第7～
12章。
这时候可以考虑用这种工作的方式：设立一个公共的仓库。Tom维护自己的版本，他的同伴维护自己的版本。然后大
家定期把代码合并到公共仓库上面，然后定期把新的版本取回来合并再提交到公共仓库。
如果他们用纯文本，得益于一些文本分析的方法，几乎不需要校对就可以做到。
```
git commit -m 'finish ch5' // 假设此时Tom写完了第5章
git push // Tom将代码推送到远程仓库
```
```
git commit -m 'finish ch11' // 假设此时Tom的同伴完成了第11章
git pull // pull会将最新版本拉下来，合并，然后推送到远程仓库
```
实际上工作中，为了不混淆，会新开一个分支来开发新的特性，然后对分支进行合并。
代码自动发布
-----------
另一个很强大的功能是可以实现代码的自动发布。事实上，很多云就有使用这个。具体来说，利用git的hooks，当
服务器收到一个push，服务器可以自动运行一些脚本。也可以在客户端使用hooks，当客户端准备push的时候，客户
端先运行一些脚本。
例如，我们希望在每次服务器收到push以后，杀死全部的 `p` 进程，然后重开 `p` 进程。我们可以修改 `hooks/
post-receive` :
```
echo "Killing all p process..."
killall -9 p
echo "Restart p process..."
p
```
更多更多更多……
---------------
这份教程就到这里了，更多的自己马上动手去试试吧！
在openSUSE的安装方法：
```
sudo zypper in git
```
默认应该就装了。
一般linux命令查看帮助都是 `--help` 选项：
```
git --help
```
此外，对一个子命令也是有help看的：
```
git init --help
```
这里有一个交互教程，在浏览器上面跑的模拟git的运行的，有兴趣的试试：
<http://try.github.io/>
github的help文档写得很不错，推荐一下：
<https://help.github.com/>
书籍有个远近闻名的《Pro Git》，而且有中文版的，虽然我认为这本书太厚了。。。但似乎就这么一本书……
<http://git-scm.com/book/zh>
国内有个gitcafe，也是做git托管的，他们也有整理一份help：
<https://gitcafe.com/GitCafe/Help>
记得，上面只是一个演示，多试试push，多尝试。有一天你会喜欢用这个有效的工具的。
很有用！！！
pycharm Failed with error: Could not read from remote repository. git push 操作
回复python • 李魔佛 回复了问题 • 1 人关注 • 1 个回复 • 5847 次浏览 • 2018-03-14 00:31
git 比较两个分支的不同
Linux • 李魔佛 发表了文章 • 0 个评论 • 5956 次浏览 • 2016-07-28 22:31
git diff [branchA] [branchB]用以上这个命令可输出两个分支的区别，但是不同的文件太多，在命令行查看不是很方便，想输出到文件中查看，不知道如何加参数？
===================================
补充：找到答案：// >> 后加输出文件的路径、文件名和后缀名 git diff [branchA] [branchB] >>d:/diff/exportname.diff
查看全部
===================================
补充：找到答案：// >> 后加输出文件的路径、文件名和后缀名 git diff [branchA] [branchB] >>d:/diff/exportname.diff
查看全部
git diff [branchA] [branchB]用以上这个命令可输出两个分支的区别，但是不同的文件太多，在命令行查看不是很方便，想输出到文件中查看，不知道如何加参数？
===================================
补充：找到答案：// >> 后加输出文件的路径、文件名和后缀名 git diff [branchA] [branchB] >>d:/diff/exportname.diff
git冲突 解决
Linux • 李魔佛 发表了文章 • 0 个评论 • 4888 次浏览 • 2016-07-28 22:06
Fatal: cannot do a partial commit during a merge
在提交单个文件的时候出现这个错误.
意思是不能部分提交代码.
原因是git认为你有部分代码没有做好提交的准备,比如没有添加
解决方法是
1. 提交全部
git commit -a
2. 如果不想提交全部,那么可以通过添加 -i 选项
git commit file/to/path -i -m "merge"
上述情况一般出现在解决本地working copy冲突时出现, 本地文件修改(手工merge)完成后,要添加并提交,使得本地版本处于clean的状态.
这样以后git pull就不再会报错.
冲突处理
当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。
比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：[复制代码]
<<<<<<< HEAD test in master ======= test in dev >>>>>>> dev
[复制代码]
<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。
HEAD指向当前分支末梢的提交。
=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。
>>>>>>>之后的dev是该分支的名字。
对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。 查看全部
在提交单个文件的时候出现这个错误.
意思是不能部分提交代码.
原因是git认为你有部分代码没有做好提交的准备,比如没有添加
解决方法是
1. 提交全部
git commit -a
2. 如果不想提交全部,那么可以通过添加 -i 选项
git commit file/to/path -i -m "merge"
上述情况一般出现在解决本地working copy冲突时出现, 本地文件修改(手工merge)完成后,要添加并提交,使得本地版本处于clean的状态.
这样以后git pull就不再会报错.
冲突处理
当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。
比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：[复制代码]
<<<<<<< HEAD test in master ======= test in dev >>>>>>> dev
[复制代码]
<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。
HEAD指向当前分支末梢的提交。
=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。
>>>>>>>之后的dev是该分支的名字。
对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。 查看全部
Fatal: cannot do a partial commit during a merge
在提交单个文件的时候出现这个错误.
意思是不能部分提交代码.
原因是git认为你有部分代码没有做好提交的准备,比如没有添加
解决方法是
1. 提交全部
git commit -a
2. 如果不想提交全部,那么可以通过添加 -i 选项
git commit file/to/path -i -m "merge"
上述情况一般出现在解决本地working copy冲突时出现, 本地文件修改(手工merge)完成后,要添加并提交,使得本地版本处于clean的状态.
这样以后git pull就不再会报错.
冲突处理
当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。
比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：[复制代码]
<<<<<<< HEAD test in master ======= test in dev >>>>>>> dev
[复制代码]
<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。
HEAD指向当前分支末梢的提交。
=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。
>>>>>>>之后的dev是该分支的名字。
对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。
在提交单个文件的时候出现这个错误.
意思是不能部分提交代码.
原因是git认为你有部分代码没有做好提交的准备,比如没有添加
解决方法是
1. 提交全部
git commit -a
2. 如果不想提交全部,那么可以通过添加 -i 选项
git commit file/to/path -i -m "merge"
上述情况一般出现在解决本地working copy冲突时出现, 本地文件修改(手工merge)完成后,要添加并提交,使得本地版本处于clean的状态.
这样以后git pull就不再会报错.
冲突处理
当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。
比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：[复制代码]
<<<<<<< HEAD test in master ======= test in dev >>>>>>> dev
[复制代码]
<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。
HEAD指向当前分支末梢的提交。
=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。
>>>>>>>之后的dev是该分支的名字。
对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。
win7下 设置 sourcetree full/fetch github文件
Linux • 李魔佛 发表了文章 • 0 个评论 • 3606 次浏览 • 2016-06-23 16:48
默认sourcetree使用putty的priva key来和github通讯。
因为之前win7系统安装的github使用的openssh来管理github的文件推送，所以在sourcetree中修改成openssh就可以了。
在Tool-> option， 在菜单下，把ssh key改成 openssh就可以了。 查看全部
因为之前win7系统安装的github使用的openssh来管理github的文件推送，所以在sourcetree中修改成openssh就可以了。
在Tool-> option， 在菜单下，把ssh key改成 openssh就可以了。 查看全部
默认sourcetree使用putty的priva key来和github通讯。
因为之前win7系统安装的github使用的openssh来管理github的文件推送，所以在sourcetree中修改成openssh就可以了。
在Tool-> option， 在菜单下，把ssh key改成 openssh就可以了。
因为之前win7系统安装的github使用的openssh来管理github的文件推送，所以在sourcetree中修改成openssh就可以了。
在Tool-> option， 在菜单下，把ssh key改成 openssh就可以了。
mac os x 下 git gui 好用的图形工具
Linux • 李魔佛 发表了文章 • 0 个评论 • 5341 次浏览 • 2016-06-22 17:10
在GUI下，对分支管理更加地直观。
试了几个工具，最好用的还是sourcetree。 跨平台，win和mac都可以用，而且注册账号后还可以在云上同步。
https://www.sourcetreeapp.com/download/ 查看全部
试了几个工具，最好用的还是sourcetree。 跨平台，win和mac都可以用，而且注册账号后还可以在云上同步。
https://www.sourcetreeapp.com/download/ 查看全部
在GUI下，对分支管理更加地直观。
试了几个工具，最好用的还是sourcetree。 跨平台，win和mac都可以用，而且注册账号后还可以在云上同步。
https://www.sourcetreeapp.com/download/
试了几个工具，最好用的还是sourcetree。 跨平台，win和mac都可以用，而且注册账号后还可以在云上同步。
https://www.sourcetreeapp.com/download/
ubuntu git 彩色显示
Linux • 李魔佛 发表了文章 • 0 个评论 • 3695 次浏览 • 2016-06-20 11:01
ubuntu下需要手动配置一下的
可以在终端里敲入以下命令
alec@PC$ git config --global color.status auto
alec@PC$ git config --global color.diff auto
alec@PC$ git config --global color.branch auto
alec@PC$ git config --global color.interactive auto 查看全部
可以在终端里敲入以下命令
alec@PC$ git config --global color.status auto
alec@PC$ git config --global color.diff auto
alec@PC$ git config --global color.branch auto
alec@PC$ git config --global color.interactive auto 查看全部
ubuntu下需要手动配置一下的
可以在终端里敲入以下命令
alec@PC$ git config --global color.status auto
alec@PC$ git config --global color.diff auto
alec@PC$ git config --global color.branch auto
alec@PC$ git config --global color.interactive auto
推荐一个很详细的git教程
默认分类 • 李魔佛 发表了文章 • 0 个评论 • 3705 次浏览 • 2016-05-21 19:40
http://www.open-open.com/lib/view/open1328069889514.html
非常详细。
刚开始开github的官方教程，一开始看完了，就以为自己学会了。
殊不知，自己平时写项目的碰到各种莫名其妙的问题，只好东爬西摸，靠着搜索，不懂一点搜一点。 不过这种效果不好，只知道怎么做，却不知道为什么要这么做。
偶尔看到上面的一份教程，国人写的，非常详细，比廖雪峰写的都还好。
如果耐心看完的话，以后使用git是没啥大问题的啦。 查看全部
非常详细。
刚开始开github的官方教程，一开始看完了，就以为自己学会了。
殊不知，自己平时写项目的碰到各种莫名其妙的问题，只好东爬西摸，靠着搜索，不懂一点搜一点。 不过这种效果不好，只知道怎么做，却不知道为什么要这么做。
偶尔看到上面的一份教程，国人写的，非常详细，比廖雪峰写的都还好。
如果耐心看完的话，以后使用git是没啥大问题的啦。 查看全部
http://www.open-open.com/lib/view/open1328069889514.html
非常详细。
刚开始开github的官方教程，一开始看完了，就以为自己学会了。
殊不知，自己平时写项目的碰到各种莫名其妙的问题，只好东爬西摸，靠着搜索，不懂一点搜一点。 不过这种效果不好，只知道怎么做，却不知道为什么要这么做。
偶尔看到上面的一份教程，国人写的，非常详细，比廖雪峰写的都还好。
如果耐心看完的话，以后使用git是没啥大问题的啦。
非常详细。
刚开始开github的官方教程，一开始看完了，就以为自己学会了。
殊不知，自己平时写项目的碰到各种莫名其妙的问题，只好东爬西摸，靠着搜索，不懂一点搜一点。 不过这种效果不好，只知道怎么做，却不知道为什么要这么做。
偶尔看到上面的一份教程，国人写的，非常详细，比廖雪峰写的都还好。
如果耐心看完的话，以后使用git是没啥大问题的啦。
pycharm Failed with error: Could not read from remote repository. git push 操作
回复python • 李魔佛 回复了问题 • 1 人关注 • 1 个回复 • 5847 次浏览 • 2018-03-14 00:31
github首页Maximum retries exceeded Please add an env variable called PAT_1 with your token
网络 • 马化云 发表了文章 • 0 个评论 • 1870 次浏览 • 2023-01-18 11:12
最近登录github后，发现之前显示的状态都不正常了。
正常的时候是这样的：
但现在提示是这样的：
Something went wrong! file an issue at https://tiny.one/readme-statsMaximum retries exceeded Please add an env variable called PAT_1 with your github token in vercel
有两个办法可以解决。
1. Set it up yourself using Vercel (requires some step)
2. Use URL provided by others (The easiest step)
翻译成中文：
1. 自己到vercel上部署一个这样的app （复杂）
2. 换一个其他人部署好的链接 （容易)
一般人就别折腾第一种方法了，直接使用第二种方法就好了。
笔者找了一些其他人部署好的链接：
拿去用就可以了：https://github-readme-stats-git-masterrstaa-rickstaa.vercel.app
By Unknown
https://github-readme-stats-ruby-one.vercel.app
By Claudio Tancredi
https://github-readme-stats-ten-gilt.vercel.app
By Unknown
https://github-readme-stats-61 ... l.app
By Fanwang Meng
https://github-readme-stats.zohan.tech
By Zohan Subhash
https://readme-stats.clckblog.space
By Kevin Zhong
查看全部
正常的时候是这样的：
但现在提示是这样的：
Something went wrong! file an issue at https://tiny.one/readme-statsMaximum retries exceeded Please add an env variable called PAT_1 with your github token in vercel
有两个办法可以解决。
1. Set it up yourself using Vercel (requires some step)
2. Use URL provided by others (The easiest step)
翻译成中文：
1. 自己到vercel上部署一个这样的app （复杂）
2. 换一个其他人部署好的链接 （容易)
一般人就别折腾第一种方法了，直接使用第二种方法就好了。
笔者找了一些其他人部署好的链接：
拿去用就可以了：https://github-readme-stats-git-masterrstaa-rickstaa.vercel.app
By Unknown
https://github-readme-stats-ruby-one.vercel.app
By Claudio Tancredi
https://github-readme-stats-ten-gilt.vercel.app
By Unknown
https://github-readme-stats-61 ... l.app
By Fanwang Meng
https://github-readme-stats.zohan.tech
By Zohan Subhash
https://readme-stats.clckblog.space
By Kevin Zhong
查看全部
最近登录github后，发现之前显示的状态都不正常了。
正常的时候是这样的：
但现在提示是这样的：
有两个办法可以解决。
1. Set it up yourself using Vercel (requires some step)
2. Use URL provided by others (The easiest step)
翻译成中文：
1. 自己到vercel上部署一个这样的app （复杂）
2. 换一个其他人部署好的链接 （容易)
一般人就别折腾第一种方法了，直接使用第二种方法就好了。
笔者找了一些其他人部署好的链接：
拿去用就可以了：
正常的时候是这样的：
但现在提示是这样的：
Something went wrong! file an issue at https://tiny.one/readme-statsMaximum retries exceeded Please add an env variable called PAT_1 with your github token in vercel
有两个办法可以解决。
1. Set it up yourself using Vercel (requires some step)
2. Use URL provided by others (The easiest step)
翻译成中文：
1. 自己到vercel上部署一个这样的app （复杂）
2. 换一个其他人部署好的链接 （容易)
一般人就别折腾第一种方法了，直接使用第二种方法就好了。
笔者找了一些其他人部署好的链接：
拿去用就可以了：
https://github-readme-stats-git-masterrstaa-rickstaa.vercel.app
By Unknown
https://github-readme-stats-ruby-one.vercel.app
By Claudio Tancredi
https://github-readme-stats-ten-gilt.vercel.app
By Unknown
https://github-readme-stats-61 ... l.app
By Fanwang Meng
https://github-readme-stats.zohan.tech
By Zohan Subhash
https://readme-stats.clckblog.space
By Kevin Zhong
linux下好用的git gui工具 推荐！
Linux • 李魔佛 发表了文章 • 0 个评论 • 3104 次浏览 • 2022-06-11 17:37
之前写过一篇免费版的kranken
ubuntu下最好的图形git管理工具kranken (免费版本)
用了一个月之后，发现免费版不支持私有仓库，这。。。。。
那自己的私有仓库还得专门找软件管理。
突然看到ubuntu下平时用的不多的vs code，发现里面git的插件可真多。
把最多星的git相关插件装上后，它的功能基本大部分都可以覆盖了95%kraken的可视化功能了！
查看全部
ubuntu下最好的图形git管理工具kranken (免费版本)
用了一个月之后，发现免费版不支持私有仓库，这。。。。。
那自己的私有仓库还得专门找软件管理。
突然看到ubuntu下平时用的不多的vs code，发现里面git的插件可真多。
把最多星的git相关插件装上后，它的功能基本大部分都可以覆盖了95%kraken的可视化功能了！
查看全部
之前写过一篇免费版的kranken
ubuntu下最好的图形git管理工具kranken (免费版本)
用了一个月之后，发现免费版不支持私有仓库，这。。。。。
那自己的私有仓库还得专门找软件管理。
突然看到ubuntu下平时用的不多的vs code，发现里面git的插件可真多。
把最多星的git相关插件装上后，它的功能基本大部分都可以覆盖了95%kraken的可视化功能了！
ubuntu下最好的图形git管理工具kranken (免费版本)
用了一个月之后，发现免费版不支持私有仓库，这。。。。。
那自己的私有仓库还得专门找软件管理。
突然看到ubuntu下平时用的不多的vs code，发现里面git的插件可真多。
把最多星的git相关插件装上后，它的功能基本大部分都可以覆盖了95%kraken的可视化功能了！
Got recursion not available from 8.8.8.8
网络 • 李魔佛 发表了文章 • 0 个评论 • 2361 次浏览 • 2022-05-26 12:18
github被墙，然后改dns也不管用。
返回的报错：Got recursion not available from 8.8.8.8
返回的github的ip地址还是为127.0.0.1
只能直接修改hosts文件了 查看全部
返回的报错：Got recursion not available from 8.8.8.8
返回的github的ip地址还是为127.0.0.1
只能直接修改hosts文件了 查看全部
github被墙，然后改dns也不管用。
返回的报错：
返回的github的ip地址还是为127.0.0.1
只能直接修改hosts文件了
返回的报错：
Got recursion not available from 8.8.8.8
返回的github的ip地址还是为127.0.0.1
只能直接修改hosts文件了
github上私有仓库提交的星星是不会显示
每日总结 • 李魔佛 发表了文章 • 0 个评论 • 2264 次浏览 • 2021-02-26 18:58
一个是登录状态后查看的自己的星星数，一个是没有登录状态下的星星数
登录后
登录前
登录后
登录前
一个是登录状态后查看的自己的星星数，一个是没有登录状态下的星星数
登录后
登录前
登录后
登录前
git命令行查看图形化的分支信息与commit 缩写id
Linux • 李魔佛 发表了文章 • 0 个评论 • 6220 次浏览 • 2020-06-21 16:56
在命令行下面，有时候需要可视化的观察git的分支情况以及commit id的缩写值。
可以使用 git log 加若干参数
git log --graph --pretty=oneline --abbrev-commit
效果是这样的：
而实际在source tree中是这样的：
查看全部
可以使用 git log 加若干参数
git log --graph --pretty=oneline --abbrev-commit
效果是这样的：
而实际在source tree中是这样的：
查看全部
在命令行下面，有时候需要可视化的观察git的分支情况以及commit id的缩写值。
可以使用 git log 加若干参数
效果是这样的：
而实际在source tree中是这样的：
可以使用 git log 加若干参数
git log --graph --pretty=oneline --abbrev-commit
效果是这样的：
而实际在source tree中是这样的：
最流行的版本控制软件：git 个人笔记
python • 李魔佛 发表了文章 • 0 个评论 • 3314 次浏览 • 2019-04-16 23:37
最流行的版本控制软件：git
========================
git已经是当前最流行的版本控制软件之一了。全世界的程序员都在使用它。它出自linus大神之手，现在被用于内
核的版本控制。在最流行的代码托管软件github，你几乎可以找到所有开源项目的代码。
版块控制软件：我需要吗？
-----------------------
的确对于许多人——尤其是非程序员，他们可能不会想到已经出现了专门的版本控制的软件。但其实多人对版本控
制其实都有类似的需求，举个例子，Tom是社团的秘书处成员，他们经常需要做的事情就是写活动文档，然后不停地
改改到大家都觉得可以了。
不幸运的话，Tom可能有个文件夹叫“openSUSE活动策划"，里面有这样的一堆文件”openSUSE活动策划", "活动策
划1", "活动策划2", "活动策划3", "活动策划4" ... "活动策划20" （可怜的Tom，一份文档改了不少于20次）
这种作法很有效，因为我们可能发现第5个版本的策划有问题，我们准备在第3个版本上面重新来过。但是也看到，
这个作法有些很丑陋的地方：一份文件，我们留了20个备份，而且还要注意文件名。
如果可以这样就好了：文件夹上只有一个“openSUSE活动策划"，但当我需要第5个版本的时候，我来一个”给我还
原到第5个版本吧！“，然后这时候我们打开这个文件，它就是第5个版本的了。类似的，我们可以取出任意的版本
。
这就是版本控制。这种事情在程序里面发生的太多了，于是出现了各种版本控制软件。事实上，有些项目已经发展
到第1000+甚至更高的版本数了……
单线的工作流
------------
我们可以把我们的一个项目想象为一个仓库，然后我们可以把我们的东西塞进仓库里面，也可以把想要的东西拿出
来。而git则是仓库的管理员。下面是一个例子，希望有一个直观的印象，不求完全的理解和掌握。
```bash
mkdir myproject // 假设myproject是工作目录
cd myproject
git init // git <- (init) ，告诉仓库管理员，在当前目录初始化
echo 'Eat the banana' > file // 编辑了一个文件
git add file // 加入仓库
git commit -m 'add first file' // 提交更改
echo 'Eat the apply' > file // 修改了这个文件
git add file // 加入仓库
git commit -m 'update first file' // 再提交更改
```
这时候我们就有两个commit了，我们来看看工作日志：
```bash
git log
# 以下是输出
# commit ac1371173b4e630ddaebda3f9f5d948b36146c07
# Author: Norman Mo <LTaoist@@@>
# Date: Thu Jun 27 21:59:10 2013 +0800
#
# update first file
#
# commit 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0
# Author: Norman Mo <LTaoist6@@@@>
# Date: Thu Jun 27 21:58:48 2013 +0800
#
# add first file
```
看到了，我们提交了两次。我们来看看现在file里面是什么：
```bash
cat file # 显然输出是 'Eat the apply'
# 现在，我们来拿回第一个版本的file文件
git checkout 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0 -- file
cat file # 这时候就是eat banana了
```
这种工作的方式是单人使用最常见的方式，写一点代码，提交一下到仓库里面。写一点，提交到仓库里面。然后出
问题的时候就回退过去。git非常强大，基本上你想到的他都可以做到，提交到仓库的数据基本不会丢失，像时间机
器一样控制着代码。
多人协作
--------
git非常强大，上面只是一个功能。考虑Tom的秘书处有两个人，他们在同时写。其中Tom写前6章，他的同伴写第7～
12章。
这时候可以考虑用这种工作的方式：设立一个公共的仓库。Tom维护自己的版本，他的同伴维护自己的版本。然后大
家定期把代码合并到公共仓库上面，然后定期把新的版本取回来合并再提交到公共仓库。
如果他们用纯文本，得益于一些文本分析的方法，几乎不需要校对就可以做到。
```
git commit -m 'finish ch5' // 假设此时Tom写完了第5章
git push // Tom将代码推送到远程仓库
```
```
git commit -m 'finish ch11' // 假设此时Tom的同伴完成了第11章
git pull // pull会将最新版本拉下来，合并，然后推送到远程仓库
```
实际上工作中，为了不混淆，会新开一个分支来开发新的特性，然后对分支进行合并。
代码自动发布
-----------
另一个很强大的功能是可以实现代码的自动发布。事实上，很多云就有使用这个。具体来说，利用git的hooks，当
服务器收到一个push，服务器可以自动运行一些脚本。也可以在客户端使用hooks，当客户端准备push的时候，客户
端先运行一些脚本。
例如，我们希望在每次服务器收到push以后，杀死全部的 `p` 进程，然后重开 `p` 进程。我们可以修改 `hooks/
post-receive` :
```
echo "Killing all p process..."
killall -9 p
echo "Restart p process..."
p
```
更多更多更多……
---------------
这份教程就到这里了，更多的自己马上动手去试试吧！
在openSUSE的安装方法：
```
sudo zypper in git
```
默认应该就装了。
一般linux命令查看帮助都是 `--help` 选项：
```
git --help
```
此外，对一个子命令也是有help看的：
```
git init --help
```
这里有一个交互教程，在浏览器上面跑的模拟git的运行的，有兴趣的试试：
<http://try.github.io/>
github的help文档写得很不错，推荐一下：
<https://help.github.com/>
书籍有个远近闻名的《Pro Git》，而且有中文版的，虽然我认为这本书太厚了。。。但似乎就这么一本书……
<http://git-scm.com/book/zh>
国内有个gitcafe，也是做git托管的，他们也有整理一份help：
<https://gitcafe.com/GitCafe/Help>
记得，上面只是一个演示，多试试push，多尝试。有一天你会喜欢用这个有效的工具的。
很有用！！！ 查看全部
========================
git已经是当前最流行的版本控制软件之一了。全世界的程序员都在使用它。它出自linus大神之手，现在被用于内
核的版本控制。在最流行的代码托管软件github，你几乎可以找到所有开源项目的代码。
版块控制软件：我需要吗？
-----------------------
的确对于许多人——尤其是非程序员，他们可能不会想到已经出现了专门的版本控制的软件。但其实多人对版本控
制其实都有类似的需求，举个例子，Tom是社团的秘书处成员，他们经常需要做的事情就是写活动文档，然后不停地
改改到大家都觉得可以了。
不幸运的话，Tom可能有个文件夹叫“openSUSE活动策划"，里面有这样的一堆文件”openSUSE活动策划", "活动策
划1", "活动策划2", "活动策划3", "活动策划4" ... "活动策划20" （可怜的Tom，一份文档改了不少于20次）
这种作法很有效，因为我们可能发现第5个版本的策划有问题，我们准备在第3个版本上面重新来过。但是也看到，
这个作法有些很丑陋的地方：一份文件，我们留了20个备份，而且还要注意文件名。
如果可以这样就好了：文件夹上只有一个“openSUSE活动策划"，但当我需要第5个版本的时候，我来一个”给我还
原到第5个版本吧！“，然后这时候我们打开这个文件，它就是第5个版本的了。类似的，我们可以取出任意的版本
。
这就是版本控制。这种事情在程序里面发生的太多了，于是出现了各种版本控制软件。事实上，有些项目已经发展
到第1000+甚至更高的版本数了……
单线的工作流
------------
我们可以把我们的一个项目想象为一个仓库，然后我们可以把我们的东西塞进仓库里面，也可以把想要的东西拿出
来。而git则是仓库的管理员。下面是一个例子，希望有一个直观的印象，不求完全的理解和掌握。
```bash
mkdir myproject // 假设myproject是工作目录
cd myproject
git init // git <- (init) ，告诉仓库管理员，在当前目录初始化
echo 'Eat the banana' > file // 编辑了一个文件
git add file // 加入仓库
git commit -m 'add first file' // 提交更改
echo 'Eat the apply' > file // 修改了这个文件
git add file // 加入仓库
git commit -m 'update first file' // 再提交更改
```
这时候我们就有两个commit了，我们来看看工作日志：
```bash
git log
# 以下是输出
# commit ac1371173b4e630ddaebda3f9f5d948b36146c07
# Author: Norman Mo <LTaoist@@@>
# Date: Thu Jun 27 21:59:10 2013 +0800
#
# update first file
#
# commit 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0
# Author: Norman Mo <LTaoist6@@@@>
# Date: Thu Jun 27 21:58:48 2013 +0800
#
# add first file
```
看到了，我们提交了两次。我们来看看现在file里面是什么：
```bash
cat file # 显然输出是 'Eat the apply'
# 现在，我们来拿回第一个版本的file文件
git checkout 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0 -- file
cat file # 这时候就是eat banana了
```
这种工作的方式是单人使用最常见的方式，写一点代码，提交一下到仓库里面。写一点，提交到仓库里面。然后出
问题的时候就回退过去。git非常强大，基本上你想到的他都可以做到，提交到仓库的数据基本不会丢失，像时间机
器一样控制着代码。
多人协作
--------
git非常强大，上面只是一个功能。考虑Tom的秘书处有两个人，他们在同时写。其中Tom写前6章，他的同伴写第7～
12章。
这时候可以考虑用这种工作的方式：设立一个公共的仓库。Tom维护自己的版本，他的同伴维护自己的版本。然后大
家定期把代码合并到公共仓库上面，然后定期把新的版本取回来合并再提交到公共仓库。
如果他们用纯文本，得益于一些文本分析的方法，几乎不需要校对就可以做到。
```
git commit -m 'finish ch5' // 假设此时Tom写完了第5章
git push // Tom将代码推送到远程仓库
```
```
git commit -m 'finish ch11' // 假设此时Tom的同伴完成了第11章
git pull // pull会将最新版本拉下来，合并，然后推送到远程仓库
```
实际上工作中，为了不混淆，会新开一个分支来开发新的特性，然后对分支进行合并。
代码自动发布
-----------
另一个很强大的功能是可以实现代码的自动发布。事实上，很多云就有使用这个。具体来说，利用git的hooks，当
服务器收到一个push，服务器可以自动运行一些脚本。也可以在客户端使用hooks，当客户端准备push的时候，客户
端先运行一些脚本。
例如，我们希望在每次服务器收到push以后，杀死全部的 `p` 进程，然后重开 `p` 进程。我们可以修改 `hooks/
post-receive` :
```
echo "Killing all p process..."
killall -9 p
echo "Restart p process..."
p
```
更多更多更多……
---------------
这份教程就到这里了，更多的自己马上动手去试试吧！
在openSUSE的安装方法：
```
sudo zypper in git
```
默认应该就装了。
一般linux命令查看帮助都是 `--help` 选项：
```
git --help
```
此外，对一个子命令也是有help看的：
```
git init --help
```
这里有一个交互教程，在浏览器上面跑的模拟git的运行的，有兴趣的试试：
<http://try.github.io/>
github的help文档写得很不错，推荐一下：
<https://help.github.com/>
书籍有个远近闻名的《Pro Git》，而且有中文版的，虽然我认为这本书太厚了。。。但似乎就这么一本书……
<http://git-scm.com/book/zh>
国内有个gitcafe，也是做git托管的，他们也有整理一份help：
<https://gitcafe.com/GitCafe/Help>
记得，上面只是一个演示，多试试push，多尝试。有一天你会喜欢用这个有效的工具的。
很有用！！！ 查看全部
最流行的版本控制软件：git
========================
git已经是当前最流行的版本控制软件之一了。全世界的程序员都在使用它。它出自linus大神之手，现在被用于内
核的版本控制。在最流行的代码托管软件github，你几乎可以找到所有开源项目的代码。
版块控制软件：我需要吗？
-----------------------
的确对于许多人——尤其是非程序员，他们可能不会想到已经出现了专门的版本控制的软件。但其实多人对版本控
制其实都有类似的需求，举个例子，Tom是社团的秘书处成员，他们经常需要做的事情就是写活动文档，然后不停地
改改到大家都觉得可以了。
不幸运的话，Tom可能有个文件夹叫“openSUSE活动策划"，里面有这样的一堆文件”openSUSE活动策划", "活动策
划1", "活动策划2", "活动策划3", "活动策划4" ... "活动策划20" （可怜的Tom，一份文档改了不少于20次）
这种作法很有效，因为我们可能发现第5个版本的策划有问题，我们准备在第3个版本上面重新来过。但是也看到，
这个作法有些很丑陋的地方：一份文件，我们留了20个备份，而且还要注意文件名。
如果可以这样就好了：文件夹上只有一个“openSUSE活动策划"，但当我需要第5个版本的时候，我来一个”给我还
原到第5个版本吧！“，然后这时候我们打开这个文件，它就是第5个版本的了。类似的，我们可以取出任意的版本
。
这就是版本控制。这种事情在程序里面发生的太多了，于是出现了各种版本控制软件。事实上，有些项目已经发展
到第1000+甚至更高的版本数了……
单线的工作流
------------
我们可以把我们的一个项目想象为一个仓库，然后我们可以把我们的东西塞进仓库里面，也可以把想要的东西拿出
来。而git则是仓库的管理员。下面是一个例子，希望有一个直观的印象，不求完全的理解和掌握。
```bash
mkdir myproject // 假设myproject是工作目录
cd myproject
git init // git <- (init) ，告诉仓库管理员，在当前目录初始化
echo 'Eat the banana' > file // 编辑了一个文件
git add file // 加入仓库
git commit -m 'add first file' // 提交更改
echo 'Eat the apply' > file // 修改了这个文件
git add file // 加入仓库
git commit -m 'update first file' // 再提交更改
```
这时候我们就有两个commit了，我们来看看工作日志：
```bash
git log
# 以下是输出
# commit ac1371173b4e630ddaebda3f9f5d948b36146c07
# Author: Norman Mo <LTaoist@@@>
# Date: Thu Jun 27 21:59:10 2013 +0800
#
# update first file
#
# commit 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0
# Author: Norman Mo <LTaoist6@@@@>
# Date: Thu Jun 27 21:58:48 2013 +0800
#
# add first file
```
看到了，我们提交了两次。我们来看看现在file里面是什么：
```bash
cat file # 显然输出是 'Eat the apply'
# 现在，我们来拿回第一个版本的file文件
git checkout 3c43cc913454f92bb4b80c56ba45e4ffaf556fc0 -- file
cat file # 这时候就是eat banana了
```
这种工作的方式是单人使用最常见的方式，写一点代码，提交一下到仓库里面。写一点，提交到仓库里面。然后出
问题的时候就回退过去。git非常强大，基本上你想到的他都可以做到，提交到仓库的数据基本不会丢失，像时间机
器一样控制着代码。
多人协作
--------
git非常强大，上面只是一个功能。考虑Tom的秘书处有两个人，他们在同时写。其中Tom写前6章，他的同伴写第7～
12章。
这时候可以考虑用这种工作的方式：设立一个公共的仓库。Tom维护自己的版本，他的同伴维护自己的版本。然后大
家定期把代码合并到公共仓库上面，然后定期把新的版本取回来合并再提交到公共仓库。
如果他们用纯文本，得益于一些文本分析的方法，几乎不需要校对就可以做到。
```
git commit -m 'finish ch5' // 假设此时Tom写完了第5章
git push // Tom将代码推送到远程仓库
```
```
git commit -m 'finish ch11' // 假设此时Tom的同伴完成了第11章
git pull // pull会将最新版本拉下来，合并，然后推送到远程仓库
```
实际上工作中，为了不混淆，会新开一个分支来开发新的特性，然后对分支进行合并。
代码自动发布
-----------
另一个很强大的功能是可以实现代码的自动发布。事实上，很多云就有使用这个。具体来说，利用git的hooks，当
服务器收到一个push，服务器可以自动运行一些脚本。也可以在客户端使用hooks，当客户端准备push的时候，客户
端先运行一些脚本。
例如，我们希望在每次服务器收到push以后，杀死全部的 `p` 进程，然后重开 `p` 进程。我们可以修改 `hooks/
post-receive` :
```
echo "Killing all p process..."
killall -9 p
echo "Restart p process..."
p
```
更多更多更多……
---------------
这份教程就到这里了，更多的自己马上动手去试试吧！
在openSUSE的安装方法：
```
sudo zypper in git
```
默认应该就装了。
一般linux命令查看帮助都是 `--help` 选项：
```
git --help
```
此外，对一个子命令也是有help看的：
```
git init --help
```
这里有一个交互教程，在浏览器上面跑的模拟git的运行的，有兴趣的试试：
<http://try.github.io/>
github的help文档写得很不错，推荐一下：
<https://help.github.com/>
书籍有个远近闻名的《Pro Git》，而且有中文版的，虽然我认为这本书太厚了。。。但似乎就这么一本书……
<http://git-scm.com/book/zh>
国内有个gitcafe，也是做git托管的，他们也有整理一份help：
<https://gitcafe.com/GitCafe/Help>
记得，上面只是一个演示，多试试push，多尝试。有一天你会喜欢用这个有效的工具的。
很有用！！！
git 比较两个分支的不同
Linux • 李魔佛 发表了文章 • 0 个评论 • 5956 次浏览 • 2016-07-28 22:31
git diff [branchA] [branchB]用以上这个命令可输出两个分支的区别，但是不同的文件太多，在命令行查看不是很方便，想输出到文件中查看，不知道如何加参数？
===================================
补充：找到答案：// >> 后加输出文件的路径、文件名和后缀名 git diff [branchA] [branchB] >>d:/diff/exportname.diff
查看全部
===================================
补充：找到答案：// >> 后加输出文件的路径、文件名和后缀名 git diff [branchA] [branchB] >>d:/diff/exportname.diff
查看全部
git diff [branchA] [branchB]用以上这个命令可输出两个分支的区别，但是不同的文件太多，在命令行查看不是很方便，想输出到文件中查看，不知道如何加参数？
===================================
补充：找到答案：// >> 后加输出文件的路径、文件名和后缀名 git diff [branchA] [branchB] >>d:/diff/exportname.diff
git冲突 解决
Linux • 李魔佛 发表了文章 • 0 个评论 • 4888 次浏览 • 2016-07-28 22:06
Fatal: cannot do a partial commit during a merge
在提交单个文件的时候出现这个错误.
意思是不能部分提交代码.
原因是git认为你有部分代码没有做好提交的准备,比如没有添加
解决方法是
1. 提交全部
git commit -a
2. 如果不想提交全部,那么可以通过添加 -i 选项
git commit file/to/path -i -m "merge"
上述情况一般出现在解决本地working copy冲突时出现, 本地文件修改(手工merge)完成后,要添加并提交,使得本地版本处于clean的状态.
这样以后git pull就不再会报错.
冲突处理
当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。
比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：[复制代码]
<<<<<<< HEAD test in master ======= test in dev >>>>>>> dev
[复制代码]
<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。
HEAD指向当前分支末梢的提交。
=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。
>>>>>>>之后的dev是该分支的名字。
对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。 查看全部
在提交单个文件的时候出现这个错误.
意思是不能部分提交代码.
原因是git认为你有部分代码没有做好提交的准备,比如没有添加
解决方法是
1. 提交全部
git commit -a
2. 如果不想提交全部,那么可以通过添加 -i 选项
git commit file/to/path -i -m "merge"
上述情况一般出现在解决本地working copy冲突时出现, 本地文件修改(手工merge)完成后,要添加并提交,使得本地版本处于clean的状态.
这样以后git pull就不再会报错.
冲突处理
当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。
比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：[复制代码]
<<<<<<< HEAD test in master ======= test in dev >>>>>>> dev
[复制代码]
<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。
HEAD指向当前分支末梢的提交。
=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。
>>>>>>>之后的dev是该分支的名字。
对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。 查看全部
Fatal: cannot do a partial commit during a merge
在提交单个文件的时候出现这个错误.
意思是不能部分提交代码.
原因是git认为你有部分代码没有做好提交的准备,比如没有添加
解决方法是
1. 提交全部
git commit -a
2. 如果不想提交全部,那么可以通过添加 -i 选项
git commit file/to/path -i -m "merge"
上述情况一般出现在解决本地working copy冲突时出现, 本地文件修改(手工merge)完成后,要添加并提交,使得本地版本处于clean的状态.
这样以后git pull就不再会报错.
冲突处理
当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。
比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：[复制代码]
<<<<<<< HEAD test in master ======= test in dev >>>>>>> dev
[复制代码]
<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。
HEAD指向当前分支末梢的提交。
=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。
>>>>>>>之后的dev是该分支的名字。
对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。
在提交单个文件的时候出现这个错误.
意思是不能部分提交代码.
原因是git认为你有部分代码没有做好提交的准备,比如没有添加
解决方法是
1. 提交全部
git commit -a
2. 如果不想提交全部,那么可以通过添加 -i 选项
git commit file/to/path -i -m "merge"
上述情况一般出现在解决本地working copy冲突时出现, 本地文件修改(手工merge)完成后,要添加并提交,使得本地版本处于clean的状态.
这样以后git pull就不再会报错.
冲突处理
当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。
比如当前在master分支，想把dev分支merge过来，结果产生了一个冲突，打开文件内容可以看到这么一个冲突：[复制代码]
<<<<<<< HEAD test in master ======= test in dev >>>>>>> dev
[复制代码]
<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。
HEAD指向当前分支末梢的提交。
=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。
>>>>>>>之后的dev是该分支的名字。
对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。
win7下 设置 sourcetree full/fetch github文件
Linux • 李魔佛 发表了文章 • 0 个评论 • 3606 次浏览 • 2016-06-23 16:48
默认sourcetree使用putty的priva key来和github通讯。
因为之前win7系统安装的github使用的openssh来管理github的文件推送，所以在sourcetree中修改成openssh就可以了。
在Tool-> option， 在菜单下，把ssh key改成 openssh就可以了。 查看全部
因为之前win7系统安装的github使用的openssh来管理github的文件推送，所以在sourcetree中修改成openssh就可以了。
在Tool-> option， 在菜单下，把ssh key改成 openssh就可以了。 查看全部
默认sourcetree使用putty的priva key来和github通讯。
因为之前win7系统安装的github使用的openssh来管理github的文件推送，所以在sourcetree中修改成openssh就可以了。
在Tool-> option， 在菜单下，把ssh key改成 openssh就可以了。
因为之前win7系统安装的github使用的openssh来管理github的文件推送，所以在sourcetree中修改成openssh就可以了。
在Tool-> option， 在菜单下，把ssh key改成 openssh就可以了。
mac os x 下 git gui 好用的图形工具
Linux • 李魔佛 发表了文章 • 0 个评论 • 5341 次浏览 • 2016-06-22 17:10
在GUI下，对分支管理更加地直观。
试了几个工具，最好用的还是sourcetree。 跨平台，win和mac都可以用，而且注册账号后还可以在云上同步。
https://www.sourcetreeapp.com/download/ 查看全部
试了几个工具，最好用的还是sourcetree。 跨平台，win和mac都可以用，而且注册账号后还可以在云上同步。
https://www.sourcetreeapp.com/download/ 查看全部
在GUI下，对分支管理更加地直观。
试了几个工具，最好用的还是sourcetree。 跨平台，win和mac都可以用，而且注册账号后还可以在云上同步。
https://www.sourcetreeapp.com/download/
试了几个工具，最好用的还是sourcetree。 跨平台，win和mac都可以用，而且注册账号后还可以在云上同步。
https://www.sourcetreeapp.com/download/
ubuntu git 彩色显示
Linux • 李魔佛 发表了文章 • 0 个评论 • 3695 次浏览 • 2016-06-20 11:01
ubuntu下需要手动配置一下的
可以在终端里敲入以下命令
alec@PC$ git config --global color.status auto
alec@PC$ git config --global color.diff auto
alec@PC$ git config --global color.branch auto
alec@PC$ git config --global color.interactive auto 查看全部
可以在终端里敲入以下命令
alec@PC$ git config --global color.status auto
alec@PC$ git config --global color.diff auto
alec@PC$ git config --global color.branch auto
alec@PC$ git config --global color.interactive auto 查看全部
ubuntu下需要手动配置一下的
可以在终端里敲入以下命令
alec@PC$ git config --global color.status auto
alec@PC$ git config --global color.diff auto
alec@PC$ git config --global color.branch auto
alec@PC$ git config --global color.interactive auto
推荐一个很详细的git教程
默认分类 • 李魔佛 发表了文章 • 0 个评论 • 3705 次浏览 • 2016-05-21 19:40
http://www.open-open.com/lib/view/open1328069889514.html
非常详细。
刚开始开github的官方教程，一开始看完了，就以为自己学会了。
殊不知，自己平时写项目的碰到各种莫名其妙的问题，只好东爬西摸，靠着搜索，不懂一点搜一点。 不过这种效果不好，只知道怎么做，却不知道为什么要这么做。
偶尔看到上面的一份教程，国人写的，非常详细，比廖雪峰写的都还好。
如果耐心看完的话，以后使用git是没啥大问题的啦。 查看全部
非常详细。
刚开始开github的官方教程，一开始看完了，就以为自己学会了。
殊不知，自己平时写项目的碰到各种莫名其妙的问题，只好东爬西摸，靠着搜索，不懂一点搜一点。 不过这种效果不好，只知道怎么做，却不知道为什么要这么做。
偶尔看到上面的一份教程，国人写的，非常详细，比廖雪峰写的都还好。
如果耐心看完的话，以后使用git是没啥大问题的啦。 查看全部
http://www.open-open.com/lib/view/open1328069889514.html
非常详细。
刚开始开github的官方教程，一开始看完了，就以为自己学会了。
殊不知，自己平时写项目的碰到各种莫名其妙的问题，只好东爬西摸，靠着搜索，不懂一点搜一点。 不过这种效果不好，只知道怎么做，却不知道为什么要这么做。
偶尔看到上面的一份教程，国人写的，非常详细，比廖雪峰写的都还好。
如果耐心看完的话，以后使用git是没啥大问题的啦。
非常详细。
刚开始开github的官方教程，一开始看完了，就以为自己学会了。
殊不知，自己平时写项目的碰到各种莫名其妙的问题，只好东爬西摸，靠着搜索，不懂一点搜一点。 不过这种效果不好，只知道怎么做，却不知道为什么要这么做。
偶尔看到上面的一份教程，国人写的，非常详细，比廖雪峰写的都还好。
如果耐心看完的话，以后使用git是没啥大问题的啦。
git是一个版本控制系统。对于你有多台电脑，或者多人合作写代码很有用。
