Git 的origin和master解析

本文详细解析了Git操作的三大步骤:获取数据、代码修改及推送变更。阐述了远程仓库(remote repository)与本地仓库(local repository)的概念,以及两者间的交互方式。特别介绍了Git clone与Git push的工作原理,包括分支(branch)的同步与更新过程。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

https://blog.youkuaiyun.com/qq_15037231/article/details/77878275

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

1. 从git取数据(git clone)

2. 改动代码

3. 将改动传回git(git push)

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

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

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

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

同时,Git 会建立一个属于你自己的本地master 分支,它指向的是你刚刚从remote server传到你本地的副本。随着你不断的改动文件,git add, git commit,master的指向会自动移动,你也可以通过merge(fast 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”的形式为”+:”,冒号前表示local branch的名字,冒号后表示remote repository下 branch的名字。注意,如果你省略了,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 (省略了,等价于“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,删除它。用一个空的去更新它,就相当于删除了)

### 合并Git分支至Master 当准备将功能分支中的更改集成到`master`分支时,可以遵循一系列操作来完成这一过程。确保在执行这些命令之前已经保存了所有的修改。 #### 切换到目标分支 为了安全起见,在合并前先切换回`master`分支,并拉取最新的更新以保持同步: ```bash git checkout master git pull origin master ``` 这一步骤有助于减少冲突的可能性,因为`master`包含了最新的提交记录[^2]。 #### 执行合并操作 一旦处于`master`上,则可以通过如下方式把其他分支(比如名为`feature_branch`的功能开发分支)的内容合入当前分支: ```bash git merge feature_branch ``` 如果选择了这种方式来进行合并,Git会尝试自动解决任何可能存在的差异;如果有无法解析的地方则会产生冲突提示,这时就需要手动编辑文件解决问题后再继续流程。 对于那些已经被成功处理过的变更集,Git具有足够的智能化程度去识别重复项而不会造成数据冗余——即不会创建额外的复制提交对象。相反地,只会添加必要的合并提交来表示两个历史交汇点之间的关系[^1]。 另外一种常见的做法是采用rebase重定基底的方式代替直接merge,这样可以使项目的历史更加线性清晰: ```bash git checkout feature_branch git rebase master git checkout master git merge --ff-only feature_branch ``` 上述方法首先调整了特性分支上的改动使其基于最新版的主干之上,之后再简单快速前进式的合并回去。不过需要注意的是rebasing改变了原有commit id所以应当谨慎对待公共共享过后的分支变动情况。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值