Git 的origin和master分析(转)

本文详细介绍了Git的基本操作流程,包括从远程仓库获取数据、修改代码及推送更改回远程仓库的过程。文章深入解析了本地仓库与远程仓库之间的关系,并通过实例说明了如何使用各种Git命令进行有效管理。

转:http://lishicongli.blog.163.com/blog/static/1468259020132125247302/

首先要明确一点,对git的操作是围绕3个大的步骤来展开的(其实几乎所有的SCM都是这样)

1.     git取数据(git clone

2.     改动代码

3.     将改动传回gitgit push

3个步骤又涉及到两个repository,一个是remote repository,再远程服务器上,一个是local repository,再自己工作区上。其中

1, 3两个步骤涉及到remote server/remote repository/remote branch

2涉及到local repository/local branchgit clone 会根据你指定的remote server/repository/branch,拷贝一个副本到你本地,再git push之前,你对所有文件的改动都是在你自己本地的local repository来做的,你的改动(local branch)remote branch是独立(并行)的。Gitk显示的就是local repository

 

clone完成之后,Git 会自动为你将此远程仓库命名为originorigin只相当于一个别名,运行git remote –v或者查看.git/config可以看到origin的含义),并下载其中所有的数据,建立一个指向它的master 分支的指针,我们用(远程仓库名)/(分支名这样的形式表示远程分支,所以origin/master指向的是一个remote branch(从那个branch我们clone数据到本地),但你无法在本地更改其数据。

同时,Git 会建立一个属于你自己的本地master 分支,它指向的是你刚刚从remote server传到你本地的副本。随着你不断的改动文件,git add, git commitmaster的指向会自动移动,你也可以通过mergefast forward)来移动master的指向。

 $git branch -a (to show all the branches git knows about)

* master

  remotes/origin/HEAD -> origin/master

  remotes/origin/master

 

$git branch -r (to show remote branches git knows about)

  origin/HEAD -> origin/master

  origin/master

 

可以发现,master就是local branch,origin/master是remote branch(master is a branch in the local repository. remotes/origin/master is a branch named master on the remote named origin

$git diff origin/master master (show me the changes between the remote master branch and my master branch).

需要注意的是,remotes/origin/master和origin/master的指向是相同的

$git diff origin/master remotes/origin/master

 

git push origin master

origin指定了你要push到哪个remote

master其实是一个“refspec”,正常的“refspec”的形式为”+<src>:<dst>”,冒号前表示local branch的名字,冒号后表示remote repository下 branch的名字。注意,如果你省略了<dst>,git就认为你想push到remote repository下和local branch相同名字的branch。听起来有点拗口,再解释下,push是怎么个push法,就是把本地branch指向的commit push到remote repository下的branch,比如

$git push origin master:master (在local repository中找到名字为master的branch,使用它去更新remote repository下名字为master的branch,如果remote repository下不存在名字是master的branch,那么新建一个)

$git push origin master (省略了<dst>,等价于“git push origin master:master”)

$git push origin master:refs/for/mybranch (在local repository中找到名字为master的branch,用他去更新remote repository下面名字为mybranch的branch)

$git push origin HEAD:refs/for/mybranch (HEAD指向当前工作的branch,master不一定指向当前工作的branch,所以我觉得用HEAD还比master好些)

$git push origin :mybranch (再origin repository里面查找mybranch,删除它。用一个空的去更新它,就相当于删除了)

转载于:https://www.cnblogs.com/fatt/p/6296605.html

<think>好的,用户现在问的是git pullgit pull origin master的区别。首先我需要回忆一下git pull的基本用法。git pull通常用于从远程仓库获取最新提交并合并到当前分支。默认情况下,git pull会根据当前所在的分支,自动确定要拉取的远程分支本地分支。 首先,git pull的一般形式是git pull <远程仓库> <远程分支>:<本地分支>,如果省略参数,Git会使用配置中的默认值。比如,当你在本地的master分支时,通常远程仓库是origin,远程分支也是master,所以git pull等价于git pull origin master。不过可能用户的问题在于,是否在所有情况下两者都等价,或者是否有不同的情况。 接下来,需要解释两者的默认行为。git pull如果不带参数,会从当前分支的上游(upstream)配置中获取远程仓库远程分支。上游配置可以通过git branch -u来设置,通常在克隆仓库时,本地分支会自动跟踪远程的对应分支,比如本地master跟踪origin/master。这时候,git pull就相当于拉取origin/master并合并到当前的本地master分支。 而git pull origin master则是显式指定了远程仓库为origin,远程分支为master,然后合并到当前分支。这里需要注意的是,合并的目标分支是当前所在的分支,而不是本地的master分支,除非当前分支就是master。例如,如果当前在dev分支,执行git pull origin master,会将远程的origin/master分支合并到本地的dev分支,而不是master分支。 然后,需要指出两者的主要区别:是否显式指定远程仓库分支,以及合并的目标分支。默认情况下,git pull依赖于当前分支的上游配置,而显式指定参数可以覆盖这些默认值。 另外,可能需要提到git pull的底层操作是git fetch + git merge,而git pull origin master相当于git fetch origin master,然后将下载的origin/master合并到当前分支。而默认的git pull则是根据上游配置来执行fetchmerge的分支。 还需要考虑特殊情况,比如当本地分支没有设置上游跟踪时,git pull可能需要显式参数,否则会报错。而git pull origin master则可以在这种情况下工作,因为显式指定了远程分支。 总结来说,两者的主要区别在于是否使用默认的上游配置,以及合并的目标分支是否由当前分支决定。需要明确说明默认情况下的等价性,以及在不同分支或配置下的差异。 </think>`git pull` `git pull origin master` 的核心区别在于**是否显式指定远程仓库、远程分支及合并目标**。以下是具体分析: ### 一、`git pull` 的默认行为 `git pull` 是 **“拉取并合并”** 的简写操作,底层等价于 `git fetch`(拉取远程更新) + `git merge`(合并到当前分支)。其行为依赖本地分支的**上游跟踪配置(Upstream Tracking)**: #### 1. 上游配置的作用 当本地分支(如 `master`)设置了上游跟踪(通常通过 `git clone` 或 `git branch -u origin/master` 自动配置),`git pull` 会: - 自动识别远程仓库为 `origin`(默认远程名称)。 - 自动识别远程分支为 `origin/master`(与本地分支同名的远程分支)。 - 将拉取的 `origin/master` 合并到当前所在的本地分支(如当前在 `master` 分支,则合并到本地 `master`)。 ### 二、`git pull origin master` 的显式行为 `git pull origin master` 显式指定了远程仓库远程分支,格式为 `git pull <远程名称> <远程分支>`。其行为逻辑为: - **拉取远程仓库 `origin` 中的 `master` 分支**(即 `origin/master` 的最新提交)。 - **合并到当前所在的本地分支**(而非本地 `master` 分支!)。 ### 三、关键区别对比 | 操作 | 远程仓库指定方式 | 远程分支指定方式 | 合并目标分支 | 依赖条件 | |---------------------|------------------------|------------------------|----------------------------|------------------------------| | `git pull` | 默认使用上游配置的远程(如 `origin`) | 默认使用上游配置的远程分支(如 `origin/master`) | 当前所在的本地分支(需与上游分支同名) | 本地分支必须设置上游跟踪(否则报错) | | `git pull origin master` | 显式指定远程为 `origin` | 显式指定远程分支为 `master` | 当前所在的本地分支(可能与远程分支不同名) | 无依赖(直接拉取指定远程分支) | ### 四、示例说明 假设当前在本地 `dev` 分支,且本地 `dev` 的上游跟踪为 `origin/dev`: #### 场景1:执行 `git pull` - 拉取 `origin/dev` 的提交 → 合并到本地 `dev` 分支(与上游配置一致)。 #### 场景2:执行 `git pull origin master` - 拉取 `origin/master` 的提交 → 合并到当前所在的 `dev` 分支(即使本地 `dev` 与远程 `master` 无关)。 ### 五、注意事项 - 若本地分支未设置上游跟踪(如新建的 `feature` 分支),直接执行 `git pull` 会报错(提示“no upstream configured”),此时必须显式指定远程分支(如 `git pull origin feature`)。 - `git pull` 支持更复杂的语法(如 `git pull origin master:dev`),表示将远程 `master` 分支合并到本地 `dev` 分支(目标分支为 `dev`)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值