Git+Github使用全流程

git

分布式的版本控制

• 便于进行版本的回滚操作
• 结合在线代码托管，可以进行协作和异地处理

1. 本地的版本控制

必须的步骤

1. 进入要管理的目录

2. 对该目录进行初始化

   git init
   

3. 检测当前目录中所有文件的状态

   查询文件状态：

   git status
   

   状态分为3种：

   • 未经过管理的文件（新文件 or 更改过的文件）：红色 ：处于工作区

   • 已经经过管理的文件：绿色 ：处于缓存区

   • 已经进行版本控制，生成一个版本 ：git status 查询不到：已在版本库

4. 红色–>绿色： 即：文件由工作区–>缓存区

   git add 文件名     // 使该文件被管理
   git .             // 使所有的文件被管理
   

5. 绿色–>生成版本： 即：文件由缓存区–>版本库

   git commit -m '描述信息'
   

更改文件后需要再次提交并生成版本

2. 回滚操作

git reset --hard 版本号

回滚后，如果使用git log 查询不到回滚之前的版本

需要使用

git reflog
git reset --hard 版本号

再次进行回滚即可

3.分支

git中分支可以提供多个环境，意味着可以把工作从开发主线上隔离开，避免影响主线的稳定性

常见命令

1. 查看分支

   git branch
   

2. 创建分支

   git branch 分支名
   

3. 删除分支

   git branch -d
   

4. 切换分支

   git checkout 分支名
   

   随着分支的切换，文件的内容也会发生对应的变化

5. 分支合并

   git merge 要合并的分支
   

   注：合并分支需要先切换分支

常见工作流

不在稳定的master分支中修改开发，而是将dev分支中的版本合并到master分支中

4.github托管的版本控制

代码托管的仓库

步骤

• 注册账号

• 创建仓库

• 本地推送

为本地的文件在github中起别名

git remote add origin 仓库地址

origin为项目的别名，可以更改

a. 提交代码

git push -u origin 分支名称
# 可能由于本地项目中可能有多个分支，需要多次提交

b. 代码克隆

git clone 仓库地址
# 克隆的项目中已经存在所有的分支

c.代码在本地与异地的更新

git checkout 分支名
git pull origin 分支名
# 上述分支均为有新内容的分支

其中，

git pull origin 分支名

可以分为以下两个步骤：

git fetch origin 分支名
git merge origin/分支名

注意

在push代码时，出现问题：

1. 10054问题

   出现10054问题时，需要解除ssl验证

5.偶然事件处理

异地忘记提交代码

情景：在异地忘记提交文件1，而在本地又在文件1中开发了新的功能，上传到github中。则，当异地重新拉取代码时，会产生冲突

需要手动解决。

6.rebase

目的：使提交记录变得简洁

可分为以下经典场景：

1.合并操作过程中提交的无用版本

具体操作过程：

1. 指定合并的所有版本

   git rebase -i 版本号
   可合并 指定版本-->HEAD 的版本信息
   或
   git rebase -i HEAD~3
   可合并HEAD至先前3个版本的信息
   

2. 使用s 命令把新版本依次合并到旧版本中

上图即表示：把V4合并至V3中,把V3合并到V2中去

一些命令如下：

3. 编辑新的提交信息，保存得到结果
   

注意：

建议不要合并已经push的版本

2.异地不同功能代码合并时，避免出现分叉

可能分叉出现的情景：

在异地忘记提交文件1，而在本地又在文件2中开发了新的功能代码，上传到云端中。（暂不考虑出现冲突的场景）

则，当异地重新在云端拉取代码时，两文件合并会产生分叉

解决方案

在进行功能的合并时，使用以下代码

git fetch origin dev(异地所处的分支名)
git rebase origin/dev

3.rebase过程中出现冲突

当使用rebase过程中出现冲突时，需要手动解决冲突

而后，继续rebase的过程

过程处理代码：

解决冲突之后
git add 文件名
git rebase --continue

即可！

更多内容，请访问我的博客！
万物生长xy