git 入门到入土

git 入门到入土

常用命令（本地）

命令建议粗略过一遍配合概念食用

• add

  将文件添加到暂存区

• commit -m <提交描述信息>

  提交文件到 git 仓库

对于一个 git 仓库中的文件按照存在位置，主要分为三个

工作区：开发者实际操作的文件夹

暂存区：从工作区提交到 git 仓库中间过程，文件暂时存放的地方，对应 .git 文件夹下的 index 文件

git 仓库：git 实际进行版本控制的地方，对应 .git 文件夹下的 objects 文件夹，只有提交后对应文件才归 git 进行版本控制

暂存区有什么作用？

一下看过去暂存区好像并没有什么作用，但是在实际流程中暂存区有不可替代的作用。

git 仓库中并不会存储真正的文件，而是按照每一次提交的文件快照串联成一棵树，而暂存区所在的 index 文件保存着文件对应的索引，提交后可以转化为 git 仓库上的树节点。

如果你想对一系列复杂的业务代码进行提交，如果没有缓存区可能会多次提交。但是加上缓存区后可以避免多次提交。

• status

  查看文件状态

  git 中文件存在几种状态

• untracked：未跟踪，即这个文件不由 git 进行管理

• unmodified：未修改，由 git 管理，但是与上一次的快照一样即未被更新

• modified：修改，与上一次快照不一样文件已经被修改过

• staged：已经被放入暂存区的

• branch

  分支相关操作

  git branch <branchName> #创建分支
  

• checkout

  切换分支

  git checkout <branchName> #切换到指定分支
  git checkout -b <branchName> #创建并切换到指定分支
  

• merge

  分支合并

  git merge <branchName> #将当前分支与指定分支合并
  

• rebase

  转基

  git base <branchName> #将指定分支作为当前分支的基础
  

• log

  查看提交记录

• reflog

  查看提交记录

• reset

  返回之前的某一步操作

概念

• 在 git 中实际上是按照每一次提交的文件快照串联成一个树结构例如

  

• 每一次提交（commit）就会在对应分支上添加一个新的节点
  

• 但是显而易见一棵树不能仅有一条主干（main），例如一个项目初始化后需要三个程序员（a，b，c）相互合作那么就需要为三个程序员每人建立一个分支 git branch <branchName>，使他们可以在自己的分支上工作
  

• 如果到了某一天需要进行项目上线，那么肯定需要将三个人的工作成果合并到主分支上

• 使用merge 将三个分支合并到 main分支上，依次合并 a，b，c
  

• 使用 rebase 将三个分支合并，依次合并 a，b，c
  
  merge 是直接将两个分支的头节点合并到一块，

  rebase 是将操作的分支作为当前以公共祖先节点开始将操作的节点作为当前节点的根基

  实际工作中应根据业务具体选择合并方案。

• 如果在操作中我突然反悔了，想回到之前的某一步怎么办？

  git reset <commitId> 可以根据之前提交的 id 返回到你想返回的任意一步，例如上图中的 c1，c2… 实际工作中 commitId 会是一串随机字符串

  可以通过 git log 查看之前提交版本的所有 commitIds
  
  git reset c1
  

• 但是我突然又感觉 c3 版本好一点，如上所述，git log 可以查看当前 commitId 之前的所有 commitIds ，但是无法查看它之后的 commitId ，此时通过 git reflog 进行查看

本地仓库实践

1. 从新建一个 git 仓库说起

   本地初始化一个仓库 git init ，
   
   生成 .git 文件夹

   代表此时 myRepository 文件夹归 git 管理，

2. 添加文件 vim hello
   

3. 将文件添加到暂存区 git add hello

4. 提交文件 git commit -m <提交的描述信息>
   

5. 假设此时有两个工作者 a b ，创建两个分支 branch-a，branch-b
   

6. a 工作者将 hello 中的内容修改为 a
   
   

7. 提交 a 的工作并将分支 branch-a 与主分支 master 合并
   

8. b 工作者将 branch-b 中的 hello 修改为 b，并且与主分支合并
   
   

9. 合并 branch-b 时可以看到 Automatic merge failed ：自动合并失败

   查看 hello 中的内容

   <<<<<<< HEAD
   a
   =======
   b
   >>>>>>> branch-b
   

   此时产生了合并冲突，所以 git 不能自动合并，需要手动就行合并选择保存的内容然后重新提交。

远程仓库实践

1. 创建远程仓库（使用 gitee 码云）
   

2. 本地 clone 远程仓库
   

3. 尝试推送文件，如果之前未录入账号密码需要录入 gitee 账号密码
   

4. 截止目前为止远程仓库的创建和本地仓库的推送都为同一账号，该账号为仓库的所有者，但是在团队开发中如果有其他的程序员需要共同操作这个仓库该怎么办？

5. 模拟其他开发者

   1. 如果是在一台机器上操作，需要将计算机上保存的 git 账号删除，修改为其他开发者的账号：win 10 左下角搜索凭证=>进入凭证管理器=>删除 gitee 相关凭证

   2. git clone 仓库

   3. 创建新文件并且尝试推送到远程仓库

      

   4. 查看到没有 push 的权限，这是因为仓库的所有者没有对当前开发者开放权限

   5. gitee 登录仓库所有者账号邀请开发者
      
      

   6. 开发者复制链接地址，将地址输入到浏览器地址栏即可加入仓库成为开发者

   7. 开发者重新尝试提交新文件到远程仓库
      

   8. 但是此时会产生新的问题，仓库所有者的本地仓库只能看到 hello 文件而看不到 newFile 文件。

      使用 git pull 进行下载远程仓库文件并且合并到本地仓库分支

      git pull 相当于 git fetch （下载远程库文件）git merge （合并）的结合

   9. 团队协作可能会产生例如上述合并冲突的问题，采用同样的方法解决即可

整合 idea

1. idea 关于 git 的配置
   
   

2. clone 远程仓库
   
   

3. 添加新文件测试提交到远程仓库
   
   

4. idea 解决合并冲突

   1. 仓库所有者修改 hello 文件提交并推送

   2. 开发者使用 idea 也修改并推送

   3. 此时爆有冲突需要先合并远程分支，点 Merge

      

   4. 解决冲突的三种策略，此时选择 Merge

      

   5. 见下图
      

   6. 重新 push 即可

扩展

.ignore 文件

在有些场合下我们不需要将本地工作区的所有文件全部归 git 管理可以在 .ignore 文件中进行忽略

1. 工作目录下新建文件 .gitignore

2. 通配符

   • #：注释
   • *：零个或多个任意字符
   • ?：匹配一个任意字符
   • [abc]：匹配 a b c 中任意一个
   • [0-9]：匹配所有 0-9 之间的数组
   • !：取反，忽略指定模式之外的文件/目录
   • /：匹配文件夹

3. 实例

   *.log #忽略所有 log 结尾日志
   !main.log #但 main.log 除外
   dependencies/ #忽略 dependencies 文件夹下的所有文件
   

reset 的三个参数

采用 hard 修改所有即可

–hard：不保留变更

–soft：保留变更且变更内容处于 Staged

–mixed：保留变更且变更内容处于 Modified

参考资料

• https://learngitbranching.js.org/?locale=zh_CN 可视化进行 git 操作，观察 git 每一条命令具体发生了什么
• https://gitee.com/progit/ Pro Git 官方手册