02-Git远程仓库Github

1、Git远程仓库

　　（Gitgub网站作为远程代码仓库时的操作和本地代码仓库一样的，只是仓库位置不同而已）

需要准备的东西：

　　1、准备Git源代码仓库https://github.com/

　　2、准备李顺涛的文件F:/gitTest/lishuntao/

　　3、准备经理的文件F:/gitTest/manager/

创建远程仓库

　　1、登录注册Github

　　2、创建仓库入口

3、编辑仓库信息

4、仓库创建完成

5、查看仓库地址

　　远程仓库地址：https://github.com/lishuntao123/test1.git

2、配置SSH

　　如果某台电脑需要与Github上的仓库交互，那么就要把这台电脑的SSH公钥添加到这个Github账户上。

1、配置SSH公钥入口

2、修改电脑git配置

　　配置Github注册邮箱和用户名

 vi .git/config

 [user]

      email = 1259553287@qq.com   #github注册邮箱

      name = lishuntao123  #github注册用户名

3、生成SSH公钥

 ssh-keygen -t rsa -C "1259553287@qq.com"

备注：删除旧密钥

删除~/.ssh目录，这里存储了旧密钥

rm -r .ssh

3、克隆项目

　　准备项目经理的文件F:/gitTest/manager/

　　准备我的的文件F:/gitTest/lishuntao

经理的工作：

　　建立项目：克隆远程仓库+配置身份信息+创建项目+推送项目到远程仓库

1、克隆远程仓库的命令

cd F:

cd gitTest

cd manager

git clone git@github.com:lishuntao123/test1.git

2、解决可能出现的密钥错误

提示错误信息：

sign_and_send_pubkey: signing failed: agent refused operation

错误原因：在ssh账户中没有加入新生成的密钥

解决：将密码加入ssh账户

eval "$(ssh-agent -s)"

ssh-add

3、克隆到本地

4、查看经理文件

5、配置经理信息

cd manager

cd test1

git config user.name "经理"

git config user.email "manager@qq.com"

6、创建项目

7、推送项目到远程仓库

#工作区添加到暂存区

git add .

#暂存区提交到仓库区

git commit -m "建立项目"

#推送到远程仓库

git push

我的工作：

　　获取项目：克隆项目到本地、配置身份信息

1、克隆项目到本地

cd lishuntao

git clone git@github.com:lishuntao123/test1.git

2、配置我的身份信息

  cd test1

  git config user.name '李顺涛'

  git config user.email '1259553287@qq.com'

我的信息配置成功后，可以和项目经理协同开发同一个项目。

4、多人协同开发

　　1、代码编辑界面介绍：linux使用gedit做演示

　　2、模拟本人先编辑login.py文件代码

3、模拟经理编辑login.py文件代码

4、模拟自己同步服务器代码

　　本次可以把count=2同步到自己的本地服务器

接下来重复上面的代码，实现基本的协同开发

6、总结：

要使用git命令操作仓库，需要进入到仓库内部

要同步服务器代码到本地代码就执行：git pull

本地仓库记录版本就执行：git commit -am '版本描述'

推送代码到服务器就执行：git push

编辑代码前要先pull，编辑完再commit，最后推送是push

5、代码冲突

　　多个人协同开发的时候，避免不了会出现代码冲突的情况。因为多个人同时修改了同一个文件，危害会影响正常的开发进度。一旦出现了代码冲突，必须先解决在做后续开发，否则做苦力。

　　冲突的由来：共同编辑文件，一个推送到远程仓库，所在行已经被占位。所以后提交的会提示要先git pull才能够同步到本地仓库才可以进行编辑，

解决冲突：

　　原则：谁冲突谁解决，并且一定要协商解决

　　方案：保留所有代码或者保留一人代码

　　解决完冲突后，仍需要add、commit、push

补充：

容易冲突的操作方式
- 多个人同时操作了同一个文件
- 一个人一直写不提交
- 修改之前不更新最新代码
- 提交之前不更新最新代码
- 擅自修改同事代码
减少冲突的操作方式
- 养成良好的操作习惯,先pull在修改,修改完立即commit和push
- 一定要确保自己正在修改的文件是最新版本的
- 各自开发各自的模块
- 如果要修改公共文件,一定要先确认有没有人正在修改
- 下班前一定要提交代码,上班第一件事拉取最新代码
- 一定不要擅自修改同事的代码

6、标签

　　当一个大版本完成之后，需要打一个标签。标签的作用就是记录大版本，备份大版本代码。

模拟项目经理打标签：

1、进入到经理的本地仓库test1

2、项目经理在本地打标签

 git tag -a 标签名 -m '标签描述'

例子： git tag -a v1.0 -m 'version 1.0'

3、经理推送标签到远程仓库

 git push origin 标签名

例子： git push origin v1.0

4、查看打标签结果

备注：删除本地和远程标签

  # 删除本地标签

  git tag -d 标签名

  # 删除远程仓库标签

  git push origin --delete tag 标签名

7、分支

作用：
- 研究新的功能或者攻关难题
- 解决线上bug
特点：
- 分支使每个员工开发期的代码互不干扰
- 项目开发中公用分支包括master、dev
- 分支master是默认分支，用于发布，当需要发布时将dev分支合并到master分支
- 分支dev是用于开发的分支，开发完阶段性的代码后，需要合并到master分支
- 项目中每个项目成员都可以单独建立分支用于的代码开发，实现不交叉

模拟项目经理分支操作

1、查看当前分支

没有创建其他的分支，因此只有master分支

2、项目经理创建并切换到dev分支

 git checkout -b dev

3、项目经理在dev分支编辑代码

5、管理dev分支源代码：add、commit、push

5、dev分支合并到master分支

  git checkout master

#1、先切换到master分支    只有当dev分支合并到master分支成功，别人才能获取到num3

 git merge dev

#2 dev分支合并到master分支

git push

# 经理推送合并分支操作到远程仓库

6、别人同步经理合并后的num3（只有代码同步成功，分支合算才算成功）

BUG分支：重中之重

有时当我们正在开发新功能时，出现了线上BUG。此时，必须暂停正在开发的功能，新建临时分支先解决线上BUG。

以下代码为模拟张三解决线上BUG：v1.0版本出错

1.张三切换到dev分支
2.张三在dev分支上编辑代码
3.线上v1.0版本突然发现bug
- 张三暂停手中的工作，解决线上v1.0版本bug
- 记录未提交的修改：保留现场
```
  git stash #记录未提交的数据 也就是刚暂停手中的工作
```
4.张三解决线上v1.0版本bug
- 4.1 张三切换到master分支
- 4.2 新建fixbug分支，并下载v1.0版本的代码到fixbug分支
```
  git checkout -b fixbug v1.0
```
- 4.3 修复线上v1.0版本bug
- 4.4 管理fixbug分支代码
```
add、commit、push
```
- 4.5 合并fixbug分支到master分支，并推送到远程仓库
```
  # 切换到master分支

  git checkout master

  # 合并fixbug分支到master分支

  git merge fixbug

  # 推送合并到远程仓库

  git push
```
- 4.6 经理打标签v1.1，发布v1.1版本
```
 git tag -a v1.1 -m 'version 1.1'

 git push origin v1.1
```
- 4.7 张三恢复dev分支未提交的修改（切换到dev分支）
  - 恢复到发现线上bug的那个节点
  - v2.0开发中...
```
git stash list

git stash pop
```
- 4.8 张三将fixbug分支合并到dev分支
  - 当把未提交的修改提交后，即可将fixbug合并到dev
  - 保证张三现在开发的版本不会有v1.0版本遗留问题
```
  # 切换到dev分支

  git checkout dev

  # 合并fixbug分支到dev分支

  git merge fixbug

  # 推送

  git push
```
- 4.9 张三将dev分支合并到master分支，并推送
- 到目前为止：v1.0版本bug解决了，v2.0也开发完成了

合并分支禁用`Fast Forward`模式

在合并分支时，默认采用Fast Forward模式
该模式没有分支合并的版本记录
如果需要在合并分支时记录版本需要禁用Fast Forward模式
```
  git merge --no-ff -m '合并描述' 分支名
```
```
　　
```