head,master,origin区别

HEAD: the current commit your repo is on. Most of the time HEAD points to the latest commit in your branch, but that doesn’t have to be the case. HEAD really just means “what is my repo currently pointing at”. Thanks svick for the heads up on this one (no pun intended)

In the event that the commit HEAD refers to is not the tip of any branch, this is called a “detached head”.

master: The name of the default branch that git creates for you when first creating a repo. In most cases, “master” means “the main branch”. Most shops have everyone pushing to master, and master is considered the definitive view of the repo. But it’s also common for release branches to be made off of master for releasing. Your local repo has its own master branch, that almost always follows the master of a remote repo.

origin: The default name that git gives to your main remote repo. Your box has its own repo, and you most likely push out to some remote repo that you and all your coworkers push to. That remote repo is almost always called origin, but it doesn’t have to be.

HEAD is an official notion in git, HEAD always has a well defined meaning. master and origin are common names usually used in git but they don’t have to be.

Git rebase的作用

多人在同一个分支上协作时,很容易出现冲突。即使没有冲突,后push的童鞋不得不先pull,在本地合并,然后才能push成功。

每次合并再push后,分支变成了这样:

$ git log –graph –pretty=oneline –abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
* e5e69f1 Merge branch ‘dev’
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
| |/
* | 12a631b merged bug fix 101
|\ \
| * | 4c805e2 fix bug 101
|/ /
* | e1e9c68 merge with no-ff
|\ \
| |/
| * f52c633 add merge
|/
* cf810e4 conflict fixed
总之看上去很乱,有强迫症的童鞋会问:为什么Git的提交历史不能是一条干净的直线?

其实是可以做到的!

Git有一种称为rebase的操作,有人把它翻译成“变基”。

rebase

我们从实际问题出发,看看怎么把分叉的提交变成直线。

在和远程分支同步后,我们对hello.py这个文件做了两次提交。用git log命令看看:

$ git log –graph –pretty=oneline –abbrev-commit
* 582d922 (HEAD -> master) add author
* 8875536 add comment
* d1be385 (origin/master) init hello
* e5e69f1 Merge branch ‘dev’
|\
| * 57c53ab (origin/dev, dev) fix env conflict
| |\
| | * 7a5e5dd add env
| * | 7bd91f1 add new env

注意到Git用(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello,本地分支比远程分支快两个提交。

现在我们尝试推送本地分支:

$ git push origin master
To github.com:michaelliao/learngit.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to ‘git@github.com:michaelliao/learngit.git’
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.
很不幸,失败了,这说明有人先于我们推送了远程分支。按照经验,先pull一下:

$ git pull
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:michaelliao/learngit
d1be385..f005ed4 master -> origin/master
* [new tag] v1.0 -> v1.0
Auto-merging hello.py
Merge made by the ‘recursive’ strategy.
hello.py | 1 +
1 file changed, 1 insertion(+)
再用git status看看状态:

$ git status
On branch master
Your branch is ahead of ‘origin/master’ by 3 commits.
(use “git push” to publish your local commits)

nothing to commit, working tree clean
加上刚才合并的提交,现在我们本地分支比远程分支超前3个提交。

用git log看看:

$ git log –graph –pretty=oneline –abbrev-commit
* e0ea545 (HEAD -> master) Merge branch ‘master’ of github.com:michaelliao/learngit
|\
| * f005ed4 (origin/master) set exit=1
* | 582d922 add author
* | 8875536 add comment
|/
* d1be385 init hello

对强迫症童鞋来说,现在事情有点不对头,提交历史分叉了。如果现在把本地分支push到远程,有没有问题?

有!

什么问题?

不好看!

有没有解决方法?

有!

这个时候,rebase就派上了用场。我们输入命令git rebase试试:

$ git rebase
First, rewinding head to replay your work on top of it…
Applying: add comment
Using index info to reconstruct a base tree…
M hello.py
Falling back to patching base and 3-way merge…
Auto-merging hello.py
Applying: add author
Using index info to reconstruct a base tree…
M hello.py
Falling back to patching base and 3-way merge…
Auto-merging hello.py
输出了一大堆操作,到底是啥效果?再用git log看看:

$ git log –graph –pretty=oneline –abbrev-commit
* 7e61ed4 (HEAD -> master) add author
* 3611cfe add comment
* f005ed4 (origin/master) set exit=1
* d1be385 init hello

原本分叉的提交现在变成一条直线了!这种神奇的操作是怎么实现的?其实原理非常简单。我们注意观察,发现Git把我们本地的提交“挪动”了位置,放到了f005ed4 (origin/master) set exit=1之后,这样,整个提交历史就成了一条直线。rebase操作前后,最终的提交内容是一致的,但是,我们本地的commit修改内容已经变化了,它们的修改不再基于d1be385 init hello,而是基于f005ed4 (origin/master) set exit=1,但最后的提交7e61ed4内容是一致的。

这就是rebase操作的特点:把分叉的提交历史“整理”成一条直线,看上去更直观。缺点是本地的分叉提交已经被修改过了。

最后,通过push操作把本地分支推送到远程:

Mac:~/learngit michael$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To github.com:michaelliao/learngit.git
f005ed4..7e61ed4 master -> master
再用git log看看效果:

$ git log –graph –pretty=oneline –abbrev-commit
* 7e61ed4 (HEAD -> master, origin/master) add author
* 3611cfe add comment
* f005ed4 set exit=1
* d1be385 init hello

远程分支的提交历史也是一条直线。

odoo worker 异常Exception(“bus.Bus unavailable”)

odoo worker 异常Exception(“bus.Bus unavailable”)

odoo 在配置workers后会有如下错误

Traceback (most recent call last):

File “/opt/odoo/openerp/http.py”, line 530, in _handle_exception

return super(JsonRequest, self)._handle_exception(exception)

File “/opt/odoo/openerp/http.py”, line 567, in dispatch

result = self._call_function(**self.params)

File “/opt/odoo/openerp/http.py”, line 303, in _call_function

return checked_call(self.db, *args, **kwargs)

File “/opt/odoo/openerp/service/model.py”, line 113, in wrapper

return f(dbname, *args, **kwargs)

File “/opt/odoo/openerp/http.py”, line 300, in checked_call

return self.endpoint(*a, **kw)

File “/opt/odoo/openerp/http.py”, line 796, in __call__

return self.method(*args, **kw)

File “/opt/odoo/openerp/http.py”, line 396, in response_wrap

response = f(*args, **kw)

File “/opt/odoo/addons/bus/bus.py”, line 188, in poll

raise Exception(“bus.Bus unavailable”)

原因:

工人> 0会有很多线程在端口8069上。

你也会有几个cron线程8069(max-cron-threads)。

一个gevent线程在端口8072上(longpolling-port)。

这里的问题就在8072上,web会用8069请求longpolling。所以http出错。

解决方法:

安装返向代理,用http://host:80代理 http://localhost:8069/ 和 http://localhost:8072/longpolling即可

如nginx配置

Conf代码 收藏代码
location / {
proxy_pass http://localhost:8069/;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location /longpolling/ {
proxy_pass http://localhost:8072/longpolling/;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

git核心分支

git的分支是十分的轻量级,git的新建分支,合并分支等操作几乎是瞬间完成。
1、Git 创建一个新的分支仅仅是创建一个新的分支指针。如:git branch testing 创建一个testing分支;会commit 对象上新建一个分支指针并指向当前commit
2、Git 是如何知道当前在哪个分支上工作的呢?有一个名为HEAD 的特别指针,运行git branch 命令,仅仅是建立了一个新的分支,但不会自动切换到这个分支中,所以当前我们仍然在master分支。
3、要切换到其他分支,执行git checkout 命令。我们现在转换到新建的testing 分支:git checkout testing,git仅仅是将HEAD指针指向了testing,几乎瞬间完成。
4、如果这时我们再次修改了文件,并提交(git commit ),仅仅是testing分支指向了最新commit ,而master仍指向在原来的commit
5、使用git checkout master切换回master分支。git做了两件事它把HEAD 指针移回到master 分支,并把工作目录中的文件换成了master 分支所指向的快照内容。
注意:在git中新的commit对象中的parent是指向着上一个commit。
6、在master分支我们修改文件再进行提交,这时项目提交历史产生了分叉。
Git 中的分支实际上仅是一个包含所指对象校验和(40 个字符长度SHA-1 字串)的文件,所以创建和销毁一个分支就变得非常廉价。新建一个分支就是向一个文件写入41 个字节(外加一个换行符)。
如果我们有需要我们可以完全再次checkout到testing分支去开发新的功能。我们可以在分支间随意切换,并且都是瞬间切换完成。这和之前大多数版本控制系统形成了鲜明对比,它们管理分支大多采取备份所有项目文件到特定目录的方式,所以根据项目文件数量和大小不同,可能花费的时间也会有相当大的差别,快则几秒,慢则数分钟。而Git 的实现与项目复杂度无关,它永远可以在几毫秒的时间内完成分支的创建和切换。每次提交时都记录了祖先信息(译注:即parent 对象),所以以后要合并分支时,寻找恰当的合并基础(译注:即共同祖先)的工作其实已经完成了一大半。

Git 中commit、tree、blob三个对象之间的关系

在现有的项目中查看Commit、tree、blob


进入到有git管理的项目所在的磁盘目录下:
执行git log查看版本提交历史:
每个commit都对应唯一的编号
来看上边执行到最后的冒号:这时该怎么退出再次进入书写git命令呢,  直接输一个 q 就可以了
查看就近commit具体的内容:
git cat-file -p 82cfe8
看到了这个commit中有个tree
接着看下这个tree的具体内容:
git cat-file -p 56c3567

对应磁盘中:
没显示的都是被忽略的文件
tree中又包括tree和blob
查看blob的具体内容,也就是上图中 .gitignore的内容
对应磁盘目录下该文件的内容是一模一样的
至此commit、tree、和blob三者之间的关系也就一目了然了。
1.commit存储一次提交的信息,包括所在的tree,parent是谁,以及提交的作者是谁等信息。
2.tag:标签,给重要的commit的一个别名。
3.tree:代表的是目录结构,或者简单理解为代表一个目录
4.blob:用来存储文件内容,或者说表示一个文件

总结
每一次commit对应一个tree,这个tree又记录了整个文档的目录结构,文件的每一次修改又会生成一个blob,blob信息记录在tree下面。

电脑总是弹出SohuNews.exe应用

弹出sohunews.exe应用程序错误的方法一:机智删除

  1、找到搜狗拼音输入法的安装目录,默认的安装目录在c盘的program files→sougoupinyin→7.0.0.9604(这个是版本号,可能不同)。
  2、在这个文件夹里可以发现一个叫sohunews.exe的东西,删掉它。
  3、为了防止它再次出现,新建一个文件夹,并命名为sohunews.exe。系统是不允许文件和文件夹重名的,所以这个东西就不会再出现。可以到回收站里试着还原一下那个文件,可以看到如图弹窗就成功了

弹出sohunews.exe应用程序错误的方法二:暴力卸载
  1、卸载搜狗拼音输入法,简单粗暴但很有效!换其他什么输入法都行。

从一个git仓库拷贝到另一个git仓库

利用git从一个仓库拷贝一个项目到另一个仓库,并且log也能够一起过去。

1、从原地址克隆一份裸版本库,比如原本托管于 GitHub。
git clone –bare http://github….(原始仓库地址)

2、进入克隆下来的目录
cd project.git(project即为你的项目名称)

3、以镜像推送的方式上传代码到新的仓库地址。
git push –mirror http://…(目标仓库地址)

Git切换到指定的提交(commit)

方法一,新分支
1.1Git查找commitId

$git log
commit cbcf45ec166eee4ca0ade2dc78f1445f7d39f0ab

1.2 检出提交

git checkout cbcf45ec166e
检查提交到新的分支
git checkout -b old-state cbcf45ec166e
-b参数会为提交新建一个分支。

方法二,回滚
git reset –hard 046bd7b5c1d134b8123f59ea71b19875a6a2fc3e

git切换到某个tag

git clone 整个仓库后使用,以下命令就可以取得该 tag 对应的代码了。

git checkout tag_name
但是,这时候 git 可能会提示你当前处于一个“detached HEAD” 状态。

因为 tag 相当于是一个快照,是不能更改它的代码的。

如果要在 tag 代码的基础上做修改,你需要一个分支:

git checkout -b branch_name tag_name
这样会从 tag 创建一个分支,然后就和普通的 git 操作一样了。

如果项目上有一个后来新建的分支test,并且使用

git branch -a
看不到该远程分支:

* develop
remotes/composer/develop
remotes/composer/feature/194
remotes/composer/feature/198
remotes/composer/feature/199
remotes/composer/feature/200
remotes/composer/master
remotes/origin/HEAD -> origin/develop
remotes/origin/develop
remotes/origin/feature/194
remotes/origin/feature/198
remotes/origin/feature/199
remotes/origin/feature/200
remotes/origin/master
直接使用命令git checkout test,出现以下错误

error: pathspec ‘origin/XXX’ did not match any file(s) known to git.
项目上有一个分支test,使用git branch -a看不到该远程分支,直接使用命令git checkout test报错如下:
解决方法是:

1、执行命令git fetch取回所有分支的更新

2、执行git branch -a可以看到test分支(已经更新分支信息)

3、切换分支git checkout test