基本概念 了解工作区,暂存区和版本库的区别和联系有助于我们更好理解 git 的工作流程,了解命令的操作意图. git 和其他版本控制系统如 svn 的不同之处就是有暂存区的概念. 基本概念 工作区 | Working Directory 正常情况下能看到的目录(不包括隐藏文件),也就是用户主动创建的目录 暂存区 | Stage 工作区下的隐藏.git目录下的.index文件,因此也称为索引. 版本库 | Repository 工作区下的隐藏目录.git目录 通过前几节我们知道,将文件纳入版本控制…

git 入门教程之协同开发 前面我们已经介绍过远程仓库的相关概念,不过那时并没有深入探讨,只是讲解了如何创建远程仓库以及推送最新工作成果到远程仓库,实际上远程仓库对于团队协同开发很重要,不仅仅是团队协同开发的基础,也是代码备份的保障手段,现在我们先简单回忆下相关概念,以便为接下来的协同开发做好铺垫! 远程仓库和远程分支 远程仓库 远程仓库其实并不复杂,实际上只是本地电脑上的本地仓库在另一台远程电脑的备份而已. 相对本地仓库来说远程电脑上的版本库自然就是远程仓库,远程仓库使得我们的版本库更加安全,…

廖雪峰Git入门教程  2018-05-24 23:05:11     0     0     0 https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000…

远程仓库 如果说本地仓库已经足够个人进行版本控制了,那么远程仓库则使多人合作开发成为可能. 如果你只是打算自己使用git,你的工作内容不需要发布给其他人看,那就用不到远程仓库的概念. git 是分布式版本控制系统,分布式意味着同一个git 仓库 可以部署在不同的机器上,正如"鸡生蛋蛋生鸡"问题一样,不论如何,先要有一个原始仓库,然后才能分布到其他机器上去. 充当原始仓库的机器要有一个特点那就是24h 开机且大家都能访问到,这个概念类似于"中央服务器".这样一来大家都…

版本控制 我们知道 git 是分布式版本控制系统,所以称被控制对象是版本本身没错,但是从git 命令中发现,并没有版本这个名词,有的只是commit,所以前几节我一直称其为提交. 为了避免后续教程引发歧义,特意说明,无论是版本也好,提交也罢,都是中文翻译而已,不必太过较真,直接原汁原味称commit也可以啊! 假设你已掌握暂存区的相关概念,简单来说,暂存区就是更改文件的缓存集合,等待一次性全部提交到版本库,正因如此,方便我们批量操作相关性文件,打包提交到版本库,这正是暂存区的独特魅力. 我们反复…

大家好,欢迎来到周一git专题. git clone 在上一篇文章当中我们聊了怎么在github当中创建一个属于自己的项目(repository),简称repo.除了建立自己的repo之外,我们更多的情况是拷贝别人的repo,这样才可以获得别人整理好的代码资料什么的,也更符合开源(白嫖)精神嘛. 这也不是什么难题,相信很多人都知道,当我们想要获取其他人的repo的时候,可以通过git clone命令进行拉取.比如你想要获取我们这个教程的repo,可以通过下面这个命令. git clone git…

参考文献: 1. Pro Git 2. Git教程 3. Git教程 4. 图解Git…

声明:由于本人对于Git的学习还处于摸索阶段,对有些概念的理解或许只是我断章取义,有曲解误导的地方还请见谅指正! 一.分支 1.1分支的概念. 对于的分支的理解,我们可以用模块化这个词来解释:在日常工作中,一个项目的开发模式往往是模块化,团队协作式的开发.这样我们项目的进度可以称得上多核并发式的开发了.这种模块化的开发要求我们尽可能的高内聚低耦合以免造成一只胳膊没了整个人都废了的局面.因此在所有的版本控制器对代码进行管理的时候都引入了分支这个概念.那么分支是什么呢? 分支是相对于主干来说的,或者…

一,安装Git: 1.1Linux上安装命令: sudo apt-get install git 1.2在Windows上安装Git: 使用Windows版的msysgit,官方下载地址:http://msysgit.github.io/,点击进入官网,如果官网无法正常下载我这里有当前的最新版,已经上传到CSDN上,下载地址为:http://download.csdn.net/detail/huangyabin001/7564005,点击进入下载 1.3安装完成进行配置: $ git confi…

"春风得意马蹄疾,一日看尽长安花",对于项目也是如此,最值得期待的恐怕就要数新版本发布的时刻了吧?每当发布新版本时要么是版本号命名(比如v0.0.1)或者代号命名(比如Chelsea),不管怎么说这种里程碑阶段总是要留下些许纪念意义. 既然想要纪念这种特殊的历史时刻,自然是希望它能够固定下来,不要发生随意移动,产生不可预期后果. 这种需求其实和我们前面说的分支概念很相似,均是源于特殊的版本号,逐渐收集起一系列版本,最终形成一条相对独立的历史线,但分支并不是实现里程碑概念的最佳选择,为什…

本地仓库和远程仓库在本质上没有太大区别,只不过一个是本地电脑,一个是远程电脑. 远程仓库不一定非得是 github 那种专门的"中央服务器",甚至局域网的另外一台电脑也可以充当"中央服务器"的角色,因为它存在的最初目的只是方便大家交换彼此的提交记录而已! 所以本地仓库和远程仓库的基本行为应该是一致的,约定俗成的规定是远程仓库一般不直接参与日常开发工作,主要作为项目托管中心. 某些自动化持续集成环境中也可能会直接操作远程仓库,这时远程仓库就真的和本地仓库没什么区别了!…

前面我们已经介绍过远程仓库的相关概念,不过那时并没有深入探讨,只是讲解了如何创建远程仓库以及推送最新工作成果到远程仓库,实际上远程仓库对于团队协同开发很重要,不仅仅是团队协同开发的基础,也是代码备份的保障手段,现在我们先简单回忆下相关概念,以便为接下来的协同开发做好铺垫! 远程仓库和远程分支 远程仓库 远程仓库其实并不复杂,实际上只是本地电脑上的本地仓库在另一台远程电脑的备份而已. 相对本地仓库来说远程电脑上的版本库自然就是远程仓库,远程仓库使得我们的版本库更加安全,毕竟远程电脑可不是一般的电脑…

背景 什么是分支?简单地说,分支就是两个相对独立的时间线,正常情况下,独立的时间线永远不会有交集,彼此不知道对方的存在,只有特定情况下,两条时间线才会相遇,因为相遇,所以相知,因为相知,所以改变! 正如分支对于科幻电影来说是一个很好的卖点,关于分支的话题完全可以开启新的题材,对于这点相信不少科幻迷都深有体会,不必赘述. 回归正题,分支对于版本控制系统又意味着什么呢?实际工作中,我们大多作为一个团队一起合作开发项目,如果是独立开发者,只有一个人的话,其实用不到分支的概念,甚至远程仓库也用不到.所以…

撤销更改 相信你已经了解了 git 的基本概念,也清楚了工作区,暂存区和版本库的关系,现在让我们用所学的知识继解决实际问题吧! 背景 正常看得见的目录是我们最为熟悉的工作区,在工作中不可能总是100%的精力,难免会犯错,尤其是下午犯困,晚上加班更是如此.下面列举了常见的一些场景 场景一: 工作区出现意外更改且尚未添加到暂存区 北京时间现在是晚上10点钟,你正在赶制一份工作报告,尽管心中一万个不愿意,还是不得不做. 开始模拟意外更改前,先查看一下 test.txt 文件相关信息: # 列出当前目录…

实战 git git 是一款分布式版本控制系统,可以简单概括: 不要把鸡蛋放在一个篮子里,你的一举一动都在监视中. 实战场景 你作为某项目的其中一员或者负责人,和小伙伴们一起开发,大家既有着各自分工互不干扰,也有着相互合作,最终每个人的劳动成果汇聚成最后的项目,愉快完成项目! 要求 理解 git 的工作流程,懂得实际工作中如何交流合作 掌握 git 常用操作,工具为我所有,进而提高工作效率 独当一面,最好能够独自解决使用git 过程中遇到的问题 主动分享经验,能够教会别人如何使用 git 更上一…

人生不如意之事十之八九,合并分支往往也不是一帆风顺的. 准备新的feature1分支,继续我们的新分支开发: $ git checkout -b feature1 Switched to a new branch 'feature1' 修改readme.txt最后一行,改为: Creating a new branch is quick AND simple. 在feature1分支上提交: $ git add readme.txt $ git commit -m "AND simple&quo…

在版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支.截止到目前,只有一条时间线,在Git里,这个分支叫主分支,即master分支.HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支. 一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点: 每次提交,master分支都会向前移动一步,这样,随着你不断提交,m…

分支就是一条独立的时间线,既有分支,必有主干,正如一棵树谈到树枝,必有树干一样的道理.我们先前对git 的全部操作默认都是在主干上进行的,这个主干也是一种特殊的分支,名为 master 分支. 无论是穿越历史还是撤销更改,我们都或多或少接触过时间线,git 管理的版本串在一起就组成了这个时间线,其中master 分支是当前分支,HEAD 指向master ,因此HEAD 相当于指向了最新的版本. 基于分支上的操作,每一次 commit 都会提交一个新版本,并且新的 commit 指向原来的 co…

删除文件 回忆一下文件的常见操作,新增文件,修改文件,删除文件等,新增和修改文件都单独讨论过,现在我们来研究一下如何删除文件. 你可能会说删除文件还不简单啊,直接 rm -rf <file> 即可,但是这仅仅是本地文件被删除了,对于 git 来说,文件并没有被删除. 还记得我们开篇介绍git 时就说过,一切操作皆版本 ,对于新增是一个版本,修改也是一个版本,就连删除都是一个版本. 下面让我们看一下 git 中如何删除文件吧! 背景 # 查看当前文件列表 $ ls file1.txt file2…

备忘录[译] 创建 | Create 克隆一个已存在的仓库 | Clone an existing repository git clone git@github.com:snowdreams1006/snowdreams1006.github.io.git 创建一个新的本地仓库 | Create a new local repository git init 本地更改 | Local Changes 工作目录中已更改文件 | Changed files in your working dire…

知识速查 创建版本库 初始化项目 git init 从零开始创建项目 示例 git init 克隆项目 git clone 将已有项目拷贝到本地 示例 git clone git@github.com:snowdreams1006/snowdreams1006.github.io.git 添加文件 git add 将新文件或已修改文件添加到缓存区 示例 git add README.md 查看状态 git status 查看当前文件是否和上次提交内容是否有修改 示例 git status REA…

忽略文件 "并不是所有的牛奶都叫特仑苏",在版本控制系统中也有相似的表达,那就是"并不是所有的文件都需要提交". 有的是因为没必要提交,比如日志文件,系统缓存文件等,有的是因为不能提交,比如个人隐私文件,付费文档等. 正常来说,这些文件都是不应该被提交到版本库,倘若一不留神提交到版本库,要么泄露机密信息,要是造成经济损失,要么对团队其他人工作造成不便. 有鉴于此,我们应该寻求一种机制来规避事故的发生,在 git 版本控制系统中一般有三种不同的解决方案. 最常用也是最…

前情概要 初识 git 时,我们就已经接触过 git 的基本配置,使用 git config 命令配置用户名和邮箱: # 配置当前项目(`local`)的用户名(`snowdreams1006`) git config --local user.name "snowdreams1006" # 配置当前项目(`local`)的邮箱(`snowdreams1006@163.com`) git config --local user.email "snowdreams1006@16…

git 鼓励大量使用分支---"早建分支!多用分支!",这是因为即便创建再多的分支也不会造成存储或内存开销,并且分支的作用有助于我们分解逻辑工作,这样一样其实比维护单一臃肿分支要简单得多! 正因如此,每个新功能会创建合并分支,修复 bug 会创建合并分支等等,一段时间后再次回顾整个版本库的提交历史就会发现分支错综复杂,难以理清! 虽然"条条大路通罗马",但错综复杂的道路容易让人迷失方向,如果不使用分支,当然就不存在"分叉问题",所以在某些情况下我…

和往常一样,每个人团队开发者都在自己的本地分支上进行日常工作,相互独立又相互联系,一直以来相安无事,可是某天下午,上级领导突然急冲冲的打电话告诉你线上出bug了,需要你紧急修复,下班之前必须解决! 我们天生就是创造 bug 的特殊群体,每天都在和各种各样的 bug 打交道,早已经习惯了这样的工作节奏,再也没有当初刚刚遇到紧急问题的手足无措,先喝杯茶,冷静一下,然后汇报领导说:放心吧!保证30min 内解决问题! 背景 学习了分支操作的相关知识,团队内部就基本的开发流程达成一致: 假设线上是主干…

默认情况下合并分支常常直接使用 git merge 命令,是最方便快速的合并方法.其实这种情况下 git 采用的是 fast forward 模式,特点是删除分支后,会丢失分支信息,好像从来没存在该分支一样,而我们推荐的是recursive 模式,能够保留分支的版本记录. 递归模式(recursive) 创建并切换 dev 分支,提交版本后切换回 master 分支,然后再合并 dev 分支,这不过这一次不再使用 git merge dev 命令: # 创建并切换 dev 分支 $ git ch…

如果足够幸运的话,团队成员互不影响,彼此相安无事,大家各自基于 master 分支的某个 commit 创建自己的分支,平时在分支上独立工作,等到一段时间后再合并 merge 到 master 分支,这样一样 master 作为各个功能的集大成者,最终完成项目. 然而事情总不是一帆风顺的,团队协作时由于意见不同,遇到冲突简直是家常便饭,既然无法回避冲突,当冲突发生时如何应该呢? 背景 基于 master 分支上的某个 commit ,新功能由此继续开发: echo "git commit c1&…

回到过去 背景 现在你已经掌握git的基本操作了,文件发生更改首先使用 git add 添加更改,然后 git commit 提交全部更改,当本地文件再次发生更改时,仍然需要git add 和 git commit 两步操作,中途如何想查看文件是否发生更改,使用git status 查看版本库状态,git diff 命令帮助我们查看更改详情. 像这样重复的操作其实每次都会产生一个快照,用于保存文件状态,只不过这个快照不是完整的文件,被称为提交或者版本commit .一旦发生意外,假如文件修改乱了…

版本管理 背景 在上一节中我们已经成功创建版本库并且已经添加test.txt等文件,这一节我们继续讲解如何进行版本控制. 首先我们先查看test.txt 文件有什么内容吧! # 查看文件内容 $ cat test.txt git test git init git diff $ 接下来模拟正常工作,接着输入一下内容: # 追加新内容到 test.txt 文件 echo "understand how git control version" >> test.txt # 查看…

本地仓库 背景 创建工作目录 平时工作时我们习惯对文档分门别类进行管理,.doc .txt 等文本类型的文件习惯存在 doc文件下,开发java js 等源代码文件存在在 src 目录下,这一点很好理解,那么讲解 git的项目我们也要创建一个文件夹,姑且新建一个demo的文件夹吧! # 在工作空间创建指定目录 mkdir demo # 切换至工作目录 cd demo 创建本地仓库 既然已经创建了工作文件夹,那么我们自然是希望该文件下的所有文件都能被 git 管理,也就是说在当前文件下的创建新文件…