GIT学习-基本知识及命令记录

GIT学习-基本知识及命令记录

什么是git

• 分布式管理版本控制系统
• 如果有一个软件，不但能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动，只需要在软件里瞄一眼就可以
• 分布式和集中式区别
  • 集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。
  • 那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

创建版本库

• 在本地创建文件夹并进入，即repository 仓库
• 初始化一个Git仓库，使用git init命令。
• 添加文件到Git仓库，分两步：

1. 使用命令git add ，注意，可反复多次使用，添加多个文件；
2. 使用命令git commit -m ，完成。

修改版本库的一些操作

• 1.查看状态、查看不同
  • 要随时掌握工作区的状态，使用git status命令。
  • 如果git status告诉你有文件被修改过，用git diff可以查看修改内容。
• 2.版本回退(廖雪峰比作时光穿梭)
  • HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。（上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100, 直接用id号也可，id号只写前几位就行。）
  • 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
  • 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
• 3.暂存区
  • 工作区：就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区
  • 版本库：工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
  • Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
  • git add和git commit的操作可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
• 4.管理修改
  • Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。
  • 每次修改，如果不用git add到暂存区，那就不会加入到commit中。
• 5.撤销修改

  • 场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。

  • 场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。

  • 场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

• 6.删除文件
  • 命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
  • 确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit,现在，文件就从版本库中被删除了。
  • 删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：git checkout --
  • git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
  • 注意:从来没有被添加到版本库就被删除的文件，是无法恢复的！

远程仓库

管理远程库

• 要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

• 关联后，使用命令git push -u origin master第一次推送master分支的所有内容；

• 此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

  • 此处注意：要填账号密码，结果出错了，改正如下
    • 在git命令行中输入
      git config --system --unset credential.helper
  • 然后你进行提交操作时会出现询问你码云用户名的命令行
    
  • 输入用户名以后会弹出填写密码的弹窗
    
  • 填写完密码后就可以进行提交了

当然，现在是每次执行clone、pull、push操作时都是需要填写账号密码的，为了不那么麻烦，只需在项目目录下执行以下指令：
git config --global credential.helper store
此时，会在你本地生成一个文本，用于记录你的账号和密码。
再操作一次git pull（clone 或 push）操作后，它会提示你输入账号密码，这一次输入成功后，就不需要再次输入密码了。

• 分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，而SVN在没有联网的时候是拒绝干活的！当有网络的时候，再把本地提交推送一下就完成了同步.

分支管理

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。
现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

创建于合并分支

查看分支：git branch

创建分支：git branch

切换分支：git checkout 或者git switch

创建+切换分支：git checkout -b 或者git switch -c

合并某分支到当前分支：git merge

删除分支：git branch -d

解决冲突

• 当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

• 解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

• 用git log --graph命令可以看到分支合并图。

分支管理策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

• 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

• 那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

• 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

• 所以，团队合作的分支看起来就像这样：
  

Bug分支

• 修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

• 当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

• 在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

features分支

• 开发一个新feature，最好新建一个分支；

• 如果要丢弃一个没有被合并过的分支，可以通过git branch -D 强行删除。

后续暂时用不着，不进行学习

参考廖雪峰git教程
https://www.liaoxuefeng.com/wiki/896043488029600