Git学习笔记 - 1

本文深入探讨了Git中的远程分支管理、fetch与pull的区别、push的灵活使用及rebase的应用技巧等高级主题,帮助读者掌握更高效的版本控制实践。

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

 

ProGit这本书讲的挺不错。循序渐进。有几个命令书中语焉不详,卡住了挺长时间。记录一下。

remote branch

每一个remote branch都会在本地表现为一个不可改变的静态branch。使用git branch -a可以看到。红色的就是remote branch。不能够对这些branch进行改动,但是可以创建一个这些remote branch的tracking branch:

git checkout -b b1 origin/b1
# or
git checkout --tracking origin/b1

这时候,创建出来的local branch就会被git看作是对应的remote branch的tracking branch。在执行git push的时候,local branch的内容就会自动被push到它的tracking branch。

缺省的master就是origin/master的tracking branch。

本地的branch只能够通过向remote branch推送(push)数据的方式来和remote branch交互。如果想创建一个remote branch,就需要创建一个branch,然后

git branch b2
git push origin b2

这两条命令创建一个本地branch b2,然后将它增加到remote branch。这时候运行 git branch -a,能看到有了一个新的remote branch。

 

git fetch

git fetch [remote_repo] :这个是将remote repo所有的数据:包括更新的文件,新增/减的分支,tag,等等,全部下载到本地的local repo。但是,不会做merge。也就是说,master分支数据可能是旧的,但是origin/master上的数据已经是新的了。可以进一步运行

git checkout master
git merge origin/master

来将两个分支进行merge。或者更好使用git push来进行merge(前提是master确实是origin/master的tracking branch)

git pull

git pull [remote_repo branch_name]:这个命令直接从指定remote_repo的指定branch拉取相应的数据。并将远程branch的更新和本地的tracking branch做merge。

注意。这时候,并不会把这个branch之外的数据拉下来。比如,如果远程的另一个branch有更新,或者增加了一个新的branch,这个命令并不会把这些数据拉下来。

如果直接执行git pull [remote_repo],则会将所有数据拉下来,包括其它分支的更新,包括新增的分支。同时还会将当前branch与它tracking的branch做merge。

git push

git push [remote_repo local branch:remote branch]。缺省情况下,将当前branch的改动push到缺省repo中它track的branch。也可以加repo和branch,将当前分支的数据push到任何一个repo的任何一个branch

删除远程分支

如果需要删除一个远程分支,则需要git push origin :b1根据 git push的定义,就是把空push到远程的b1 branch。也就是删除了。

但是,如果别人已经在b1删除之前执行了fetch或者pull,在本地有了b1这个branch,再次执行fetch或者pull并不会删除这个branch。运行git branch -a也不能看出这个branch被删除了。这时候需要运行

$ git remote show origin
* remote origin
  Fetch URL: git@github.com:xxx/xxx.git
  Push  URL: git@github.com:xxx/xxx.git
  HEAD branch: master
  Remote branches:
    master                 tracked
    refs/remotes/origin/b1 stale (use 'git remote prune' to remove)
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

这时候能够看到b1是stale的,可以使用git remote prune origin将它从本地repo也去掉。

 

Rebase

rebase就是re-base。git每个commit都有一个parent指针指向当前提交的parent,即base。rebase则是改变commit的parent,这样的好处是可以减少版本树的分支和复杂度,坏处是用不好的话会给别人带来很多麻烦。

假设有一个master:7,branch f1是从master:7上cut出来的一个branch。f1是一个local的branch,用来开发一个feature。

在开发feature的时候,有人将一些修改commit到了master上。

在feature做了一个阶段之后,master已经有了版本10。f1有了版本5。这时候想把f1上的修改合并到master上。首先执行git pull把master上的更新都拉到本地来。然后可以使用rebase命令将f1上的改动都rebase(gitpro上翻译为衍合,我觉得拟合也挺好,至少是个现有的词)到master上,然后进行提交。

git checkout f1
git rebase master
#or
git rebase master f1

这时候,git会先找到f1和master的交点,也就是cut f1的时候的版本(master:7),从这个版本开始,git将f1每次的提交作为一个diff文件保存起来。然后checkout master,将这些diff一个个应用到master上。

看起来很像是merge,不过merge会产生一个新的提交,而rebase是re-base,也就是改变f1的每个提交:改变每个提交的parent,改变每个提交指向的文件快照。让整个过程看起来好像就没有f1一样,所有的改动都是直接在master上来的。Rebase过之后,如果feature已经做完,f1可以直接被删掉。

merge则会产生一个新的提交,不改变已有的提交。好处是比较安全,历史不会被改动。不好之处就是版本树会比较乱。

rebase很好很清爽。需要注意的一点是“永远不要rebase那些已经推送到远程repo的更新(commit)”

rebase会改变commits的内容,也就是改变历史,对于没有push到server上的commits无所谓,反正只有本地一个人在用。这时候使用rebase将commits rebase到公共branch(master),可以让本地的历史更清爽。

对于一个已经push到remote repo的commits。比如f1如果已经在remote repo上了,而且,f1:1到f1:3已经push到repo上了。这时候如果再将f1:1到f1:5 rebase到master上,然后强制push到repo上,结果就是f1这个branch的历史被改动。当然,如果这个remote branch只有一个人用,也还无所谓。如果有人在f1:3的时候cut出来一个branch,这时候那个人就悲剧了。再次pull的时候,将会收到rebase后改动的commits,以及原来就有的commits,情况会变的异常糟糕。

如果是push到master上,影响将更大。

总之,remote repo上的commit永远不要改动。也就是说,永远不要将已经push出去的commit再rebase一下。rebase也无所谓,切不要push出去也不会对别人造成影响。如果push出去了,这样改变了history,改变了server上的版本树,情况就糟糕了。

具体图和例子请参照Git Pro

http://progit.org/book/zh/ch3-6.html

转载于:https://www.cnblogs.com/deepnighttwo/archive/2011/06/18/2084438.html

<think>好的,用户想要寻找关于Git的学习资料,特别是搭建相关的教程或指南。首先,我需要回顾用户提供的引用内容。 引用[1]提到了Git教程,推荐了Gitee和GitLab,适合国内用户使用,因为GitHub可能有访问速度问题。用户可能需要基础教程和替代平台的信息。引用[2]详细说明了如何在本地搭建Git服务器,包括初始化仓库和客户端上传步骤。用户对搭建自己的Git服务器感兴趣,比如公司内部使用GitLab的情况。 接下来,我需要整理这些信息,分步骤回答。首先,推荐基础学习资料,包括官方文档和中文教程。然后,介绍搭建私有仓库的教程,包括GitLab和Gitea。用户可能还需要了解自建服务器的步骤,比如使用git init --bare创建裸仓库,以及客户端如何连接。此外,可能还需要推荐书籍和视频教程,帮助用户深入学习。 用户的问题可能还涉及如何选择适合自己团队的解决方案,比如GitLab适合企业,而Gitea适合轻量级需求。需要解释不同工具的优缺点。另外,基础操作和进阶资源也需要覆盖,确保用户从入门到进阶都有资料参考。 检查是否有遗漏点,比如权限管理、分支策略等高级主题,是否需要提及?根据引用内容,用户主要关注搭建教程,但可能也需要一些进阶资源。因此,在推荐资料时,应包括基础和进阶内容,满足不同层次的需求。 最后,生成相关问题,帮助用户深入探索Git的搭建和使用。例如,如何选择自建Git服务,或者Git仓库的权限管理方法。这些问题能引导用户进一步学习,解决实际操作中可能遇到的问题。</think>以下是关于Git学习资料及搭建教程的整理和推荐,结合引用内容和实际需求: --- ### 一、Git基础学习资料 1. **官方文档** Git官方提供完整的英文文档,涵盖所有基础命令和原理:[Git Book](https://git-scm.com/book/en/v2) *适合系统性学习,但需要一定英语基础。* 2. **中文快速入门教程** - 廖雪峰Git教程:[Git教程](https://www.liaoxuefeng.com/wiki/896043488029600) *从安装到分支管理,内容通俗易懂,适合新手。* - 菜鸟教程Git篇:[Git简明指南](https://www.runoob.com/git/git-tutorial.html) *提供命令速查和基础操作演示。* --- ### 二、Git私有仓库搭建教程 #### 1. **自建Git服务器** - **引用[2]的方法**: 在服务器上执行 `sudo git init --bare sample.git` 创建裸仓库,客户端通过SSH或HTTP协议连接上传代码[^2]。 *适用于小型团队或个人项目,无需复杂配置。* - **详细步骤**: ```bash # 服务器端 mkdir /opt/git && cd /opt/git sudo git init --bare myproject.git chown -R git:git myproject.git # 设置权限 # 客户端 git remote add origin user@server:/opt/git/myproject.git git push origin master ``` #### 2. **企业级解决方案** - **GitLab搭建** - 官方文档:[GitLab Omnibus安装指南](https://docs.gitlab.com/ee/install/) *提供Docker、Linux等多种安装方式,适合企业级代码管理。* - 国内优化方案: *替换Gem源为阿里云镜像以加速安装,解决依赖问题。* - **轻量级替代:Gitea** - 官网教程:[Gitea快速部署](https://docs.gitea.io/en-us/) *单二进制文件部署,资源占用低,适合中小团队[^1]。* #### 3. **国内代码托管平台** - **Gitee(码云)** - 官方教程:[Gitee帮助中心](https://gitee.com/help) *提供Git基础操作、仓库管理及CI/CD集成,访问速度快。* --- ### 三、进阶学习资源 1. **分支策略与协作** - 《Pro Git》第5章:[分布式Git工作流](https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows) *深入讲解Git Flow、GitHub Flow等协作模型。* 2. **权限管理** - GitLab权限配置:[Project Members权限说明](https://docs.gitlab.com/ee/user/permissions.html) *细化开发者、维护者角色权限,保障代码安全。* 3. **书籍推荐** -Git权威指南》:全面覆盖Git底层原理和高级技巧。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值