github的基础操作之多人协作

管理员先在远程仓库创建好仓库，并建立好相关分支，比如master分支，dev分支

建A,B两个文件夹，代表另个程序员进行克隆

要查看远程库的信息，用 git remote

用 git remote -v 显示更详细的信息  

当团队成员从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

git push -u origin master //向远程仓库origin 的master 分支提交代码

git pull origin master //拉取远程仓库origin 的master 分支的代码  

要查看远程库的信息，用 git remote 用 git remote -v 显示更详细的信息

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支和远程仓库的分支连接起来：

git checkout -b dev origin/dev

//等同于一下多个命令合并使用 创建一个dev分支并切换到dev分支下，同时和远程仓库的dev关联起来

git branch dev //新建分支

git checkout dev //切换分支

//没有把本地的dev分支与远程的dev分支关联起来，此时是没有拉去数据的

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

在dev分支新建一个index.html.，添加 提交

多人协作时，大家都会往master和dev分支上推送各自的修改。但是一般master是稳定的只是用来发布新版本分支，工作干活的分支是dev分支，一般团队成员只会提交dev分支。

2、推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

 git push origin master

如果要推送其他分支，比如dev，就改成：

git push origin dev  

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

• master分支是主分支，因此要时刻与远程同步；

  • dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：

b同学也来进行提交，出现冲突

解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

git pull origin dev

git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push

dev分支有内容：

main分支下什么也没有，因为没有合并：

 

使用github解决远程仓库合并：

 

 

 

 

 git branch --set-upstream-to=origin/dev dev

因此，多人协作的工作模式通常是这样：  

1. 从远程克隆仓库到本地

2. 拉取建立本地开发dev分支并常规开发

3. 用git push origin <branch-name>推送自己的修改；

4. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

5. 如果合并有冲突，则解决冲突，并在本地提交；

6. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

7. 如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

3、添加成员

邀请方界面：

 

 

 

被邀请者：

点击邀请者发送的链接

 

此时被邀请者可以看到一个正常的仓库界面

接下来点击仓库的远程地址

（如果不想配置秘钥，可直接使用https的链接地址

git clone https的地址，就可以完成克隆了

剩下的就是正常的推送）