如何正确的使用github进行项目的协同开发?

近期跟小伙伴们一起做一些小的项目，我们自然是使用github来作为版本控制啦～感觉应该是没找到正确的使用姿势吧总是觉得很难用；每次向master分支提交pull request之前总是需要更新以下本地的仓库，如果不小心忘记更新再加上master分支没有仔细看提交的内容的话就会覆盖掉master分支上的一些文件，最后甚至逼的大家直接在伺服器上改线上代码，面对面的喊 "喂！我正改这个文件呢你们别动！", 很是逗逼 -.-

谢邀。

首先你们要学会git的正确的基础的用法，先把progit的前4章理解完先。其次，忘记更新的情况下，是不可能覆盖掉的，除非你们选择了 --force，那只能是nozuonodie。正确理解merge/rebase先。总之，看书吧。

怎样使用 GitHub？ - 天猪(刘勇) 的回答

使用git丢代码的情况，一般来说就是还没有学会git的正确使用方法，这个时候讲流程什么的都是扯淡的。

先建立起良好的git的工作习惯，再来讨论是github的PR模式好用，还是传统的基于master进行开发方便，或者至少分一个master/develop的模式更好，更进一步的或者git flow比较方便。

对于git初学者，在认真学习pro git的前提下，我有以下建议：

1. 永远保持你的工作区干净，也就是说无论做什么操作之前，只要工作区不干净，就先提交，然后再考虑自己要做什么。我建议初学者用commit而不是通常大家推荐的stash，因为commit可以在log里面一目了然。

2. 使用自己不熟悉的操作，或者不知道后果的操作，或者有些担心的操作之前，先创建一个备份的branch。虽然reflog也能够在操作失败后把提交找回来，但这个对初学者其实是很有难度的操作，与其在代码丢掉后不知所措，不如在一开始就做好备份，git的branch功能这么廉价，创建一个备份不会超过3s。你每熟悉一个命令，每真正掌握一个命令，就可以省略掉一次备份的操作，如此循序渐进。

3. 永远不要push -f，如果有需要cancel的修改，用reverse反冲后重新建立新的提交。再强调一遍，永远不要覆盖已经push的历史，永远！

4. 永远不要merge远程的同名分支，同名分支在同步的时候一定是rebase，merge是用来合并不同的逻辑分支的，同一个逻辑分支必须rebase。如果对rebase心存疑虑，参考2，在rebase之前，先创建备份分支。

上班途中简答

&> 每次向master分支提交pull request之前总是需要更新以下本地的仓库

push 之前要先 pull 这种常识就不用说了吧，当然为了避免冲突可以先 fetch 再手动 merge 或 rebase

&> 如果不小心忘记更新再加上master分支没有仔细看提交的内容的话就会覆盖掉master分支上的一些文件

如果你们是采用 pr 的方式向 master 提交修改，可以引入 code review 机制，即提交 pr 的人不应该有权力 merge 这个 pr 到 master。此外可以用 git 的 local hook，确保 push 之前先跑一遍 pull。想偷懒的话可以直接设个

alias gpush = "git pull git push origin master"

&> 最后甚至逼的大家直接在伺服器上改线上代码

没事，小项目大家都这么干过。不过如果你想更好的利用 git 和 github 的话，最好还是避免直接修改线上代码，否则线上代码和 code base 不一样才是后患无穷。建议你们写好编译部署的代码，确保 master 中的代码随时可以用于生产环境，这样代码的改动可以随时应用于线上，就不会想著去改线上代码了。

刚好今天研究了github协同开发问题。常见的办法有两种：
1.通过邀请的方式，共同开发。适合小团队
2.通过fork方式。可以用纯命令行或者github页面操作方式进行。

对于您这种情况，建议可以使用邀请共同开发的方式进行。

详细操作步骤和命令截图可以参考这里：

github协同工作

GitHub ,一个拥有数十亿行代码的网站，聚集数百万个级别程序大神共同研究开源软体中的问题的网站。作为一只纯正的程序猿，又怎么可以不知道GitHub 这一巨大的宝藏，并如饥似渴的进行挖掘利用其中的宝藏呢！

? 什么是Git和GitHub？

（科普篇）

Git 是由Linux 之父Linus Tovalds 为了更好的管理Linux的内核而开发创立的分散式版本控制、软体配置管理软体！用人话解释一遍，就是，Git是管理你的代码记录的工具！然而,这么简单的功能不是用office 就可以轻而易举的实现了呢？所以Git的过人之处并不仅仅在于简单的保存，它甚至可以保存你的每次修改记录，这就是Git育种与众不同的特质！也正是因为这个特质，让Git拥有了很多过人的用处！但这一切局限於单机操作！从而，GitHub的衍生完美地解决了Git的这个出厂bug，打开官网页面，赫然的就是：

GitHub lets you version your code, collaborate with others, and share what you』ve built with the world. We』re excited to see what you make.

显而易见，GitHub可以随时、随地、随心地上传(push) ,下载（push) 各种文本、代码文件到在线GitHub ，更像是一个超大的远程仓库，可以供你存储，交流各种文件信息，毫无疑问，作为一个超级云盘，在平台上可以随时上传，创造属于自己的开源代码并和全世界的朋友分享自己的成果！ GitHub就这样成为了一个各大资深程序猿钟爱的聚集地！

正因为以上两个独一无二的特质，Git的修改记录存储以及GitHub为多机交互提供的完美适配，让Git 和Github 成为了协同工作的首选。团队成员可以独立创建分支，隔离工作，最后又共同提交到主代码库，各个分支合并到在主枝形成了一棵枝繁叶茂的大树，众人合力共同栽种出一棵枝繁叶茂的大树，为团队协作提供了完美的交互平台。此外，GitHub贴心的为大家设计了简易平台，可以供使用者 Pull Request 以及修改内容的讨论区域，极大程度的优化了使用者的满发分体验。

当然，如果有敌方队友对你的代码进行了一番修改，你同样可以通过（Roll back to the Commit）回到自己的初始上传状态来应对敌方向你发动的代码修改攻击！倘若你和敌方队友达成共识，你同样可以通过（Git pull）选项将云端上的最新修改同步更新到本地！

? 论正确的打开姿势？

（Simon老师亲自全程展示，重点五颗星）

Step1：在本地安装Git

选择合适的版本进行安装，当然这个软体虽然不是很大，但下载还是有丝丝费力！

Step2：创建和处理本地仓库（repository）

新建一个文件夹，右击Git Bash Here. 通过Git init这个命令将新建的文件夹升级成为Git可以直接管理的仓库。此时本地创建的仓库和Git已经完美连接，此后涵盖于此新建文件夹所有的本地修改，删除等等动作均可以被Git探测并且同步记录。(遗憾的是，视频和照片这些二进位的文件目前仍无法做到跟踪文件的详细变化)

如果有敌方队友不满意你的操作，对你的代码进行了一番骚操作，你同样可以通过（Roll back to the Commit）回到自己的初始上传状态来应对敌方向你发动的代码修改攻击！然而很意外，你和敌方队友达成共识，你同样可以通过（Git pull）选项将云端上的最新修改同步更新到本地！

Step3：创造属于远程项目仓库

SSH公钥认证可实现SSH免密码登陆，所以GitHub上仓库与本地仓库的连接，也是通过使用了SSH的公开密钥进行认证的。

同时在GitHub 上注册帐户，创建远程仓库（ Create New Repo），系统自动生成一个仓库地址，与本地的新建文件夹运行命令进行关联（git remote add origins https://github.com/......）然后，本地和远程的仓库就已经完成了所有的连接，初始适配完成！至此，可以开启一段奇妙的GitHub之旅。之后，只要经过简单的命令（git push origin master）, 或是通过（commit to master）实现将本地的分支推送到远程仓库，让更多的程序爱好者看到你的最新著创作！在云端上一砖一瓦搭建的项目仓库通过(open the file in Github Deskpot)可以分分钟搬运到你的本地文档，实现实时同步更新，可以说是酷炫到爆炸！