git常规基础操作有哪些？

jingzmmi

5、Git的协作模式（一）

1、分布式工作流程

与传统的集中式版本控制系统（CVCS）相反，Git 的分布式特性，使开发者间的协作变得更加灵活多样。
在集中式版本控制系统中，每个开发者就像是连接在集线器上的节点，彼此的工作方式大体相像。 而在 Git 中，每个开发者同时扮演着节点和集线器的角色。也就是说， 每个开发者既可以将自己的代码贡献到其他的仓库中，同时也能维护自己的公开仓库， 让其他人可以在其基础上工作并贡献代码。
由此，Git 的分布式协作可以为你的项目和团队，衍生出种种不同的工作流程， 接下来会介绍几种常见Git工作流程。
你可以选择使用其中的某一种，或者将它们的特性混合搭配使用。
2、集中式工作流

Git为了便于客户机之间的协同工作，Git版本控制系统一般会设置一个中央版本库服务器，目的是让所有客户机都从该主机更新版本，提交最新版本，该工作模式下的客户机地位都平等。
集中式工作流像SVN一样，以中央仓库作为项目所有修改的单点实体，所有修改都提交到 Master分支上。这种方式与 SVN 的主要区别就是开发人员有本地库，但是Git 很多特性并没有用到。
如下图：

上图说明：

• 一个远程仓库，
  
• 一个主分支master，
  
• 团队每个成员都有一个本地仓库，在本地仓库中进行代码的编辑、暂存和提交工作。
  

集中式工作流总结：

• 适用人群：小型开发小团队，习惯使用SVN工具的小团队。
  
• 工作方式：
  
  
  
  • 团队组长创建远程仓库，创建一个master分支，组员可读可写。
    
  • 每个开发人员都git clone远程仓库到本地仓库，在master分支上开发。
    
  • 每次开发都要git pull更新远程仓库的master分支版本到本地。
    
  • 每次开发完成就git commit到本地仓库， 接着git push到远程仓库。
    
  
  
• 缺点：
  
  
  
  • 忘了git push，一直会提交到本地仓库，没有推送到远程仓库。
    
  • 忘了git pull，导致本地仓库与中央仓库不一致，发生文件冲突。
    
  • 大量操作git pull，导致增加Git分支合并次数，增加了Git变基次数，降低了Git的性能。
    
  
  

3、分支工作流

功能分支工作流在集中式工作流的基础上，为各个新功能分配一个专门的分支来开发，即在master主分支外在创建一个分支，程序员开发的新功能全部push到此分支上，等到功能成熟的时候，再把此分支合并到主分支master上。
如下图：

分支工作流总结：

• 适用人群：小型开发团队，熟悉Git分支的团队。
  
• 工作方式：
  
  
  
  • 团队组长创建远程仓库，创建一个master分支，组员可读不可写。
    
  • 每个开发人员都git clone远程仓库到本地仓库。
    
  • 每个开发人员创建自己的feature分支，在feature分支上开发。（记住，feature分支是基于master分支）
    
  • 每个开发人员每次开发完成就git commit到本地仓库中自己的feature分支， 接着git push到远程仓库。
    
  • 通过pull request提醒团队组长，浏览组员提交feature分支。
    
  • 组长把feature分支拉下来，然后合并到自己本地仓库的master分支上测试。
    
  • 组长测试feature分支通过之后，由组长负责把feature分支合并到远程仓库的master分支上。
    
  • 组长在远程仓库把合并过的feature分支删除。
    
  • 组员在本地仓库把合并过的feature分支删除。
    
  • 组员将本地仓库分支切换为master分支，然后git pull将本地仓库的master分支更新到远程仓库的master分支版本。
    
  
  
• 缺点：
  
  
  
  • 增加团队组长的工作量。
    
  • 增加团队组员提交步骤。
    
  
  

  PS：Pull Request作用是可以让其他组员或组长可以查看你的代码，并可以提出代码修改意见或者讨论。
4、GitFlow 工作流(最流行)

Gitflow工作流没有用超出上面功能分支工作流的概念和命令，而是为不同的分支，分配一个很明确的角色，并定义分支之间如何交互，和什么时候进行交互。

• 除了有master主分支（用于存储正式发布的历史版本）外，还有一个作为功能集成分支的develop分支。
  当初始化完成后，某个程序员想要开发一个功能，并不是直接从master分支上拉出新分支，而是使用develop分支作为父分支来拉出新分支。
  当新功能完成后，再合并回父分支，新功能的提交并不与master分支直接交互。
  
• 一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。
  新建的发布分支用于开始发布循环，所以从这个时间点开始之后新的功能，不能再加到这个分支上，该分支只应该做Bug修复、文档生成和其它面向发布任务。
  一旦对外发布的工作都完成了，发布分支合并到master分支，并分配一个版本号打好Tag。
  另外，这些从新建发布分支以来的做的修改，要合并回develop分支上。
  
• 维护分支或说是热修复（hotfix）分支用于，快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。
  修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。
  为Bug修复使用专门分支，让团队可以快速处理掉问题，而不用打断其它工作或是等待下一个发布循环。
  你可以把维护分支想成是一个直接在master分支上处理的临时发布。
  

总结就是：Gitflow 工作流通过为功能开发、发布准备和维护设立了独立的分支，让发布迭代过程更流畅，充分的利用了分支的特点。严格的分支模型也为大型项目提供了一些非常必要的结构。
下图是完整的Gitflow 工作流开发方式图，但实际开发工作环境可能会精简：

Gitflow工作流总结：

• 适用人群：任何开发团队，熟悉Git分支的团队。
  
• 工作方式：
  
  
  
  • 项目维护者创建项目维护者的远程仓库，创建master分支与develop分支，贡献者可读不可写。
    
  • 每个贡献者git clone远程仓库中的develop分支到本地仓库。（记住，develop分支相当于master的分支，包括功能开发，修改，测试。master分支相当于最终分支）
    
  • 每个贡献者在本地仓库创建自己的feature分支，在feature分支上开发。
    
  • 在feature分支又可以创建多个feature分支，继续开发项目。
    
  • 每个贡献者每次开发完成就git commit到本地仓库中自己的feature分支， 接着git push到远程仓库。
    
  • 通过pull request提醒项目维护者，浏览贡献者提交feature分支。
    
  • 项目维护者把feature分支拉下来，然后合并到自己本地仓库的develop分支上测试。
    
  • 组长测试feature分支通过之后，由组长负责把feature分支合并到远程仓库的develop分支上。
    
  • 项目维护者会release分支上git tag打上版本号。
    
  • 项目维护者可以从develop分支创建release分支，接着把release分支合并到master分支上，同时master分支同步到develop分支。
    
  • 项目维护者在远程仓库把合并过的feature分支删除。
    
  • 每个贡献者在本地仓库把合并过的feature分支删除。
    
  • 每个贡献者将本地仓库分支切换为develop分支，然后git pull将本地仓库的master分支更新到远程仓库的develop分支版本。
    
  
  

  PS：Gitflow工作流是Vincent Driessen工程师提出的多分支工作流。

5、Forking 工作流(偶尔使用)

分叉(Forking)工作流也可以叫做分布式工作流，是在 GitFlow工作流的基础上的衍生，充分利用了Git在分支和克隆上的优势，再加上pull request 的功能，以达到代码审核的目的。既可以管理大团队的开发者（developer）的提交，也可以接受不信任贡献者（contributor）的提交。
这种工作流使得每个开发者都有一个服务端仓库（此仓库只有自己可以push推送，但是所有人都可以pull拉取修改），每个程序员都push代码到自己的服务端仓库，但不能push到正式仓库，只有项目维护者才能push到正式仓库，这样项目维护者可以接受任何开发者的提交，但无需给他正式代码库的写权限。
这种工作流适合开源社区的开源项目，大家统一对项目做贡献，但是有一个人或一个团队作为开发者来管理项目，所有的贡献者的代码由开发者审核，其功能完善之后再由开发者push到正式仓库中。
总结：

• 分叉(Forking)工作流更适合安全可靠地管理大团队的开发者，而且能接受不信任贡献者的提交。
  
• 在实际工作中，如果偶尔有需要团队外的成员帮我们解决问题时，可能会用到。
  
• 这种工作流程并不常用，只有当项目极为庞杂，或者需要多级别管理时，才会体现出优势。 利用这种方式，项目总负责人（即主管）可以把大量分散的集成工作，委托给不同的小组负责人分别处理，然后在不同时刻将大块的代码子集统筹起来，用于之后的整合。
  

  提示：

• 每个成员都可以从中央版本库中拉取代码。
  
• 每级成员都只能向上一级提交代码。
  
• 上一级合并代码之后继续向上级提交代码。
  
• 最后只有独裁者才能向中央版本库提交代码。
  分叉工作流（分布式仓库工作流）总结：
  
• 适用人群：大型开发团队，熟悉Git分支的团队。
  
• 工作方式：
  
  
  
  • 主项目维护者创建远程仓库，创建一个master分支，从项目维护者可读不可写。
    
  • 从项目维护者通过fork主项目维护者的远程仓库的副本，到自己的远程仓库，包括master分支。（记住，从项目维护者的远程仓库独立于主项目维护者的远程仓库）
    
  • 从项目维护者git clone主项目维护者的远程仓库的副本到本地仓库。
    
  • 从项目维护者创建自己的feature分支，在feature分支上开发。
    
  • 从项目维护者每次开发完成就git commit到本地仓库中自己的feature分支， 接着git push到远程仓库。
    
  • 通过pull request命令，从项目维护者合并自己feature分支，到从项目维护者的远程仓库的master分支上。
    
  • 从项目维护者在远程仓库把合并过的feature分支删除。
    
  • 从项目维护者在本地仓库把合并过的feature分支删除。
    
  • 从项目维护者在远程仓库通过pull request向主项目维护者的远程仓库的推送。
    
  • 主项目维护者通过pull request获取从项目维护者的远程仓库的推送。
    
  • 主项目维护者进行从项目维护者的远程仓库代码审查，测试。
    
  • 主项目维护者确认无误后，可以直接合并到主项目维护者的远程仓库。
    
  
  

6、总结

上面介绍了在Git分布式系统中经常使用的工作流程，但是在实际的开发中，你会遇到许多可能适合你的特定工作流程的变种，你可以按照实际的情况，灵活的进行组合和拓展。
6、Git操作流程

1、Git的基本操作流程

• 初始化一个本地版本库，每个版本库仅需要执行一次。
  
• 将中央版本库内容克隆到本地版本库，每个客户机仅需要执行一次。
  
• 添加指定文件到版本控制管理（这一步只是添加到Git暂存区）。
  
• 将添加、修改等操作，提交到本地版本库（将暂存区的内容提交到本地版本库）。
  如果远程仓库的内容被别人修改了，需要先同步远程的内容，直接git pull就可以更新本地的文件，然后再提交。再这过程中可能需要解决冲突。
  在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。
  
• 将本地版本库中的修改内容“推送”到中央版本库，客户机需要在一阶段性工作完成之后，或在某些时间点（下班，周五），将修改过的内容备份到中央版本库，方便他人更新到最新的代码。
  
• 将中央版本库中的变化内容“拉取”本地版本库，客户机需要不定时的更新才可以获取最新的内容。
  

  提示：实际工作中的很多功能和操作都在第3、4步中。

如下图：

说明：
上面内容涉及到Git中的几个区域：

• workspace：工作区。
  
• staging area：暂存区/缓存区。
  
• local repository：版本库或本地仓库。
  
• remote repository：远程仓库。
  

2、工作区、暂存区、版本库的区别

我们先来理解下Git 工作区、暂存区和版本库概念，这对以后我们学习Git命令会有非常大的帮助。
（1）工作区
就是你在电脑里能看到的目录。
一般我们执行git init命令，就能把一个目录初始化成Git本地版本库。
而这个目录就是该Git本地版本库的工作区。
如下图：git-demo1目录就是一个本地仓库。

具体结构如下图：

（2）版本库
版本库：工作区（项目根目录）有一个隐藏目录.git，这个目录就是版本库，而该目录不算工作区。

具体结构如下图：

（3）暂存区
暂存区：

• 暂存区从字面上去理解就是用来暂时保存文件的地方，实际上它的作用和它的名字是一致的，暂存区可以起到过渡的作用，当我们写代码修改了一些文件的时候，可以把修改的代码提交到暂存区保存，然后接着写代码，接着再提交到暂存区保存，写完某些代码觉得没什么可以修改的时候，可以将暂存区里面的文件一次性提交到版本库。
  
• 暂存区英文叫stage, 或index。
  
• 暂存区是包含在版本库中的，一般存放在.git目录下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
  

暂存区位置如下图：

具体结构如下图：

说明：
版本库又存在两个很重要的区域：暂存区与分支区。
分支区：该区域中可以包含很多分支，而每个分支都可以记录当前工作区中文件状态的快照。
如下图：

即：分支区就相当于本地版本库。
（4）通过新增文件理解三个区的关系
1）工作区新加文件 index.html

2）将index.html提交到暂存区

3）将暂存区内的内容提交到版本库

4）将本地版本推送到Github上

（5）说明
我们只要知道Git的整体操作流程即可，脑子中有一个宏观的概括就可以。关于每一步是如何操作的，和具体使用的命令，我们以后会一步一步的进行详解。
7.设置Git Bash默认路径

如果您不熟悉Git命令，推荐使用Windows TortoiseGit客户端的可视化操作界面，如果您熟悉常用的Git命令，Git Bash将会是您Windows上更加简洁、高效的客户端。（其中运行的是Linux命令）
1、Git Bash默认路径

在windows系统上操作Git的客户端是Git Bash。
安装完Git Bash之后，双击打开，如下图：

使用pwd命令查看当前路径：

每次打开Git Bash都进入默认的目录中。

• win7系统就是Git安装目录的根目录。
  
• win10系统在系统盘的用户目录中，例如：C:\Users\L。
  

2、如何查看Git Bash终端默认路径

右键Git Bash图标，点击属性。

起始位置就是Git Bash打开时默认所在的位置，和Git安装目录的位置是一样的。

提示：
windows10系统，Git版本：2.25.0 ，Git Bash终端默认路径是在系统盘的个人用户目录中。

在Git Bash终端中查看默认路径

3、如何修改Git Bash终端的默认路径

日常工作中，如果你需要管理过个Git本地版本库时，修改Git Bash终端的默认路径，就不需要每次切换目录了。
在Git Bash终端图标上，右键 —> 属性，下面图片的”起始位置:”直接输入你需要Git Bash终端的默认路径即可。如下：

然后重启Git Bash终端，就可以查看到默认路径发生改变了。

提示：
windows10系统，Git版本：2.25.0 ，修改和win7系统不同。
去掉”目标”中的 --cd-to-home，将“起始位置”的内容改为你需要的Git Bash终端的默认路径。

重启Git Bash终端，查看就可以了

4、拓展：指定目录进入Git Bash终端

在我们电脑中的任何目录下，右键 —> Git Bash Here，例如在桌面：

通过这种方式进入到Git Bash终端，我们可以看到下图，进入终端的目录，就是你右键点击Git Bash Here的目录。

这样的方式进入指定的目录也很方便。
5、注意事项

• 版本控制文件类型：对于版本控制系统，无论是CVS、SVN、GIT都只能控制文本文件，对二进行制文件是无法控制。不幸的是，微软的office文件都属于二进行制文件，不能使用版本系统进行控制。
  
• 字符编码与记事本：建议使用UTF-8编码。（windows系统中记事本编码默认不是UTF-8编码，可以使用Notepad++等记事本工具修改）。
  

9、初始化本地版本库

1、Git版本库介绍

每个Git版本控制系统的主机中，都可以包含若干个本地版本库，一般情况下一个本地版本库对应一个项目，用于对某个特定项目中的本地文件进行版本管理。其实，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除等操作Git都能跟踪到，以便任何时刻都可以追踪历史，或者在将来某个时刻可以进行“还原”。
Git中版本库又名仓库，英文名Repository，使用命令git init来创建并初始化一个本地版本库。
初始化后，在当前目录下会出现一个名为.git的目录，所有Git需要的数据和资源都存放在这个目录中。包括暂存区文件，版本记录文件，配置文件等。换句话说，如果你想从项目中删除Git的版本控制，但又要保留项目原文件，那么只需要将这个.git目录删除即可。这样话，这个项目就与Git没有任何关系。
2、创建本地版本库

在日常工作当中，创建Git本地版本库的场景有两种。
场景一：创建一个空的本地版本库
介绍：
这种情况是项目还没有代码，需要先创建一个Git本地版本库的时候。
在你专门存放Git版本库的文件夹中，执行git init your_project（项目名），这个时候Git会在当前路径下，创建一个和项目名称同名的文件夹，这个文件夹就是一个Git的裸仓库，里面的会有一个隐藏的.git文件夹。
要进行开发的时候，只要进入到这个文件夹里面就可以了。
步骤：
直接用Git管理新建的项目

• 进入到Git本地版本库管理目录git-repository。
  
• 查看目录内容。
  
• 执行$ git init your_project，创建Git本地版本库。
  
• 查看Git本地版本库是否创建。
  
• 进入到刚刚创建的Git本地版本库。
  
• 查看Git本地版本库中的内容。
  
• 进入.git目录，进行查看。
  

演示：

说明
当我们执行完$ git init first_git_repo命令之后，会出现下面一行提示。
Initialized empty Git repository in J:/git-repository/first_git_repo/.git/
意思是：初始化一个空的Git仓库，然后是仓库的路径。

.git目录：这个文件夹是Git的核心内容，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。这个文件夹以后我们会详细的讲解。

  提示：
我们也可以在git-repository目录中，先通过mkdir first_git_repo，创建一个仓库目录，然后在进入这个目录中，执行git init命令，和上边是一样的，这里就不演示了。
如果你使用Windows系统，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）不包含中文。

场景二：项目中以存在文件时创建该项目的本地版本库
介绍：
这种情况就是在创建仓库之前，项目中已经有一些代码文件了。换种方式说，在本地创建Git仓库，把代码纳入到Git管理中，提交到 GitHub。
针对这种情况，我们只需要进入到已有的项目代码所在的文件夹，然后执行git init命令就可以了。
步骤：
把已有的项目文件的目录纳入Git管理

• second_git_repo目录是一个已有文件的项目目录。
  
• 进入second_git_repo目录，查看内容。
  
• 执行git init命令，把该目录纳入Git管理。
  
• 该目录纳入Git管理后，查看目录以有.git目录。
  
• 进入.git目录，进行查看。
  

演示：

以上就是Git在本地创建版本库常用的两种情况。
场景三：在 GitHub 网站上进行仓库创建，克隆到本地。
1、进入GitHub网站，点击右上角的加号，选择穿件仓库。

2、进入到创建Git仓库页面

Public：公有的，就是大家谁都能看得到的仓库，也能下载你仓库中的代码。
Private：私有的，你可以选择让谁看到，需要花钱
其他的不用管直接点击创建（Create repository）。
3、查看创建的仓库，选择认证方式

会有一个仓库列表，点击你刚刚创建的仓库。

https和ssh验证方式的区别https基于用户名密码的验证方式。Ssh基于公钥私钥的验证方式（sshkey的方式），之前讲过。4、克隆仓库到本地

• 进入到你想克隆的位置的文件夹中
  

• 执行git clone + 选择认证方式-图4中的clone路径
  

• 查看git-repository-temp目录中，已经clone出GitHub上创建的仓库了。
  

• 进入clone到本地的项目TestNG中查看
  

里边也有.git文件夹，说明也被Git管理。
  以上就是三种创建Git的形式。
10.创建Git仓库--补充

版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。
一、创建一个版本库

第一步：选择一个合适的地方，创建一个空目录：
$ mkdir learngit$ cd learngit$ pwd/Users/michael/learngit
pwd命令用于显示当前目录位置。
  如果你使用Windows系统，为了避免遇到各种莫名其妙的问题，请确保目录名（包括父目录）不包含中文。
第二步：通过git init命令把这个目录变成Git可以管理的仓库：
$ git initInitialized empty Git repository in /Users/michael/learngit/.git/
瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），细心的读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。
如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -al命令就可以看见。
   

  二、把文件添加到版本库

1、首先这里再明确一下

• 所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。
  
• 而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
  
• 不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
  
• 因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。
  

2、使用Windows的童鞋要特别注意：

• 千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。
  
• 建议你下载Notepad++代替记事本，不但功能强大，而且免费！记得把Notepad++的默认编码设置为UTF-8 without BOM即可：
  

Notepad++设置编码
3、把文件添加到版本库
编写一个readme.txt文件，一定要放到learngit目录下（子目录也行），因为learngit目录是上边刚刚用git init命令创建的一个Git仓库，放到其他地方Git再厉害也找不到这个文件。
和把大象放到冰箱需要3步相比，把一个文件放到Git仓库只需要两步。

• 第一步，用命令git add告诉Git，把文件添加到仓库：
  

$ git add readme.txt
执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。

• 第二步，用命令git commit告诉Git，把文件提交到仓库：
  

$ git commit -m "wrote a readme file"[master (root-commit) eaadf4e] wrote a readme file 1 file changed, 2 insertions(+) create mode 100644 readme.txt

• 简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。
  
• git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；2 insertions：插入了两行内容（readme.txt有两行内容）。
  

为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：
$ git add file1.txt$ git add file2.txt file3.txt$ git commit -m "add 3 files."
三、总结：

• 1、初始化一个Git仓库，使用git init命令。
  
• 2、添加文件到Git仓库
  

分两步：使用命令git add <file>，注意，可反复多次使用，添加多个文件；使用命令git commit -m <message>，完成。

• 3、文用到的Git命令
  

序号Git命令说明1git init把一个目录变成Git可以管理的仓库2git add可以将跟踪到的更新放到暂存区（更新包括新增、修改、删除等操作）3git commit -m 'add Test_text'提交更新到仓库重点：配套学习资料和视频教学

那么在这里我也精心准备了上述大纲的详细资料在下方链接如下

请_摘星星给我

git init 初始化代码仓库

• git init 生成.git文件夹
  
• tree -a 查看文件目录树
  

• watch -n .5 tree -a  每0.5秒刷新一次当前目录的树状列表
  
• rm -rf .git/hooks/*.sample 移除目录.git/hooks/下所有以.sample结尾的文件
  

config 代码仓库配置文件（本地）

• cat .git/config 查看本地配置
  

• cat ~/.gitconfig 查看全局配置
  

​git add 将文件从工作区添加至索引区（未提交）

• git cat-file -t xxxxxx 查看对象的类型
  
• git cat-file -p xxxxxx 查看对象的内容
  
  
  
  • 相同内容的不同文件不会导致objects中内容的变化（只存储文件内容+类型）
    
  • 那么文件名存在哪里？
    
    
    
    • 因为git是可以区分文件是还在工作区还是已经在object中，所以一定有地方存储了文件名
      
    
    
  
  

浅谈git中的Hash算法

• 我们看到的git的版本号其实就是一段哈希值
  
• Hash算法可以把任意长度的输入通过散列算法变换为固定长度，并且不可逆
  
• Hash算法主要有
  
  
  
  • MD5 128bit
    
  • SHA1 160bit
    
  • SHA256 256bit
    
  • SHA512 512bit
    
  
  
• ls -lh 查看文件长度
  
• echo "文件类型 文件长度\0文件内容" | shasum计算该文件的hash值
  

• cd .git/objects/6bxxxx ls -lh 查看生成文件的大小（git会做压缩）
  

工作区和索引区

• git ls-files -s 查看索引区文件
  
• untracked files 位于工作区，还未添加到索引区的文件
  

​

原晓山

本地git项目使用

git的初始化

git init
创建文件以后的操作

git add filenamegit commit -m "commit_txt"

可以一次性添加多个文件随后一次性的进行commit操作

如果文件被修改了，想查看出现了什么情况

git status # 查看当前被修改文件的状态的操作git log # 查看日志
修改错了，想要返回上一个版本

git reset --hard HEAD^

其中HEAD表示的是当前版本，一个^表示回退一个版本，两个回退两个版本，以此类推，当然可以使用HEAD-x，x也是版本信息。 回退多了怎么办？找到之前的hash值（前几位即可），键入下述code

git reset --hard 3667b  # 其中3667b是操作记录hash值的前五位

找不到commit id，键入下述命令，又回来了

git reflog
暂存区概念

git add是将文件移动到暂存区，然后commit才是将暂存区的文件放到真正的版本管理区域

写错了，或者删错了，如何丢弃存储区的修改？

git checkout -- filename
丢弃掉暂存区的修改,此时已经被add过了

git reset HEAD filenamegit checkout -- filename
删除文件

rm filenamegit rm filename
远程git连接使用

本地同步到远程连接第一步

配置好ssh，做法就是下述代码  

ssh-keygen -t rsa -C "email@xx.com"

然后将.ssh/id_rsa.pub的信息复制到github上面的ssh的key中去，另外，在config信息中添加下述信息。

Host github.comHostname ssh.github.comPort 443User git

这样就可以实现远程连接的初步配置

关联远程的库

要关联一个远程库，使用命令

git remote add origin git@server-name:path/repo-name.git；# 其中server-name就是github.com类似的

其中，关联一个远程库时必须给远程库指定一个名字，origin是默认习惯命名； 关联后，使用下述命令

git push -u origin master # 第一次git push origin master # 以后
远程拷到本地

git clone *.git

很常见

创建新的分支并实现切换

分两步进行，dev表示的是新建分支的名字

git branch dev # 创建分支git checkout dev # 切换分支

一步到位

git checkout -b dev
分支的合并操作，快速合并

git checkout mastergit merge devgit branch -d dev

先切换，再合并，最后再删除

git switch

git switch -c dev # 创建并切换新的分支
冲突了？

由于如果项目的两个进度发生了冲突，那么就需要手动合并，采用下述代码可以查看当前的分支合并情况

git log --graph --pretty=oneline --abbrev-commit

而具体的操作的代码如下

git merge devgit status# 修改冲突的文件git add filenamegit commit -m "xxx"
正常的合并

git merge --no-ff -m "xx" dev

其中dev是需要合并的分支，xx是需要附加上去的消息

工作到一半就要去干其他的事情

当手头工作没有完成时，先把工作现场存储一下，然后去修复bug，修复后，再回到工作现场，命令如下；

git stash  # 暂时存储git stash list # 查看当前的存储的情况git stash pop # 或者使用git stash apply stash@{x}

在master分支上修复的bug，想要合并到当前dev分支，可以用下述命令，把bug提交的修改“复制”到当前分支，避免重复劳动，但是注意此时需要status是空的

git cherry-pick <commit>
多人协作

谨记远程发生了冲突的话，先拉取到本地，再合并后再发送到远端

标签

git tag <tag_name> <commit_id> # <>中是可以选择的信息git show <tag_name>  # 查看当前标签的信息git tag -a <tag_name> -m "xxx" <commit_id>git tag -d <tag_name>  # 删除

远程传递

git push origin <tag_name>git push origin --tags # 全部传送上去git push origin :refs/tags/v0.9

哭泣的天使LA

创建新分支：
git checkout -b xxx
删除分支：
git branch -D xxx 【不理会是否有未提交的修改内容】git branch -d xxx [会检测未提交的修改内容]
拉取分支内容：
git pull origin xxx
推送分支内容：
git push origin xxx
本地添加要提交的文件：
提交指定文件：  git add filename 提交所有文件：  git add .
本地提交文件：
方法一：git add .git commit -m '日志内容'方法二：git commit -am '日志内容'
放弃本地修改：
git reset --hard
放弃本地修改，强制使用线上版本：
git fetch --all && git reset --hard origin/xxx && git pull
如何强推到线上:
git pull origin  xxx  --force
缓存修改的内容：
git stash  缓存修改的内容git stash apply 应用不删除记录git stash pop  应用删除记录
版本更换命令：
git reset --hard HEAD^ 版本更换为上个版本git reset --hard XXX   设置为指定版本git log  穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。git reflog 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
自己常用的命令整理，如有错误或优化，请一定要留言，进行修改。

742958554A_

git日常使用指南

常用指令

常用命令
  

• cd ：改变目录；
  
• cd . .  ：回退到上一个目录，直接cd进入默认目录；
  
• pwd：显示当前所处目录路径；
  
• ls：显示当前目录下所有文件，ls（ll）显示内容更加详细；
  
• touch : 新建一个文件 如 touch index.js 就会在当前目录下新建一个index.js文件；
  
• rm:  删除一个文件, rm index.js 就会把index.js文件删除；
  
• mkdir:  新建一个目录,就是新建一个文件夹；
  
• rm -r :  删除一个文件夹, rm -r src 删除src目录
  

rm -rf /  # 不要再Linux环境下轻易使用，否者会删除所有文件，也就是传说中的删库跑路，要想好！！！

• mv 移动文件, mv index.html src index.html 是我们要移动的文件, src 是目标文件夹,当然, 这样写,必须保证文件和目标文件夹在同一目录下;
  
• reset: 重新初始化终端/清屏;
  
• clear:清屏；
  
• history ：查看命令历史；
  
• help：帮助；
  
• exit ：退出；
  
• “#” ： 注释；
  

git config - l # 参看配置信息

git 配置文件
   

• Git\etc\gitconfig  ：Git 安装目录下的 gitconfig   --system 系统级
  
• C:\Users\Administrator\ .gitconfig   只适用于当前登录用户的配置  --global 全局
  

设置用户名邮箱
   ```bash
当你安装Git后首先要做的事情是设置你的用户名称和e-mail地址。这是非常重要的，因为每次Git提交都会使用该信息。它被永远的嵌入到了你的提交中。
git config --global user.name "stephensong" #设置用户名 git config --global user.email ****@http://qq.com #设置邮箱 git config --glbal --list # 查看当前有哪些用户信息； ```



git基本理论

三个区域
Git本地有三个工作区域：工作目录（Working Directory）、暂存区(Stage/Index)、资源库(Repository或Git Directory)。如果在加上远程的git仓库(Remote Directory)就可以分为四个工作区域。文件在这四个区域之间的转换关系如下：

• Workspace：工作区，就是你平时存放项目代码的地方；
  
• Index / Stage：暂存区，用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息；
  
• Repository：仓库区（或本地仓库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本；
  
• Remote：远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换
  

bash   git add . -> git commit ->git push # 这一套命令完成本地到远程仓库的提交；

创建仓库

仓库创建两种方式

• bash  git init # 在当前目录新建一个代码库；
  

bash  git clone [url] # 从远程clone一个远程仓库；

文件的状态

版本控制就是对文件的版本控制，要对文件进行修改、提交等操作，首先要知道文件当前在什么状态，不然可能会提交了现在还不想提交的文件，或者要提交的文件没提交上。
  

• Untracked: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 状态变为Staged;
  
• Unmodify: 文件已经入库, 未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified. 如果使用git rm移出版本库, 则成为Untracked文件;
  
• Modified: 文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过, 返回到unmodify状态, 这个git checkout即从库中取出文件, 覆盖当前修改 !
  
• Staged: 暂存状态. 执行git commit则将修改同步到库中, 这时库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存, 文件状态为Modified;
  

查看文件状态
bash git status # 查看所有文件的状态； git status [filename] # 查看指定文件的状态； git add. # 添加所有文件进入暂存区； git commit -m "消息内容" # 提交暂存区的内容到本地仓库；
忽略文件
有些时候我们不想把某些文件纳入版本控制中，比如数据库文件，临时文件，设计文件等
在主目录下建立".gitignore"文件，此文件有如下规则：

• 忽略文件中的空行或以井号（#）开始的行将会被忽略；
  
• 可以使用Linux通配符。例如：星号（*）代表任意多个字符，问号（？）代表一个字符，方括号（[abc]）代表可选字符范围，大括号（{string1,string2,...}）代表可选的字符串等；
  
• 如果名称的最前面有一个感叹号（!），表示例外规则，将不被忽略；
  
• 如果名称的最前面是一个路径分隔符（/），表示要忽略的文件在此目录下，而子目录中的文件不忽略；
  
• 如果名称的最后面是一个路径分隔符（/），表示要忽略的是此目录下该名称的子目录，而非文件（默认文件或目录都忽略）；
  
• bash   *.txt # 忽略所有.txt结尾的文件，这样上传就不会被选中；   ！lib.txt # 但lib.txt除外；   /temp # 仅忽略项目根目录下的TODO文件，不包括其他目录temp；   build/ # 忽略build/下的所有文件；   doc/*.txt # 会忽略doc/notes.txt，但不会忽略doc/servers/arch.txt
  

git日常报错问题解决

Git报错解决：OpenSSL SSL_read: Connection was reset, errno 10054 错误解决

• 第一种方式开代理，但不一定成功！
  
• 第二种方式：
  

bash   git config --global http.sslVerify "FALSE"