我们都知道在工作时，代码繁多冗乱真的是很让程序猿头痛的事情。

今天上课时老师教我们使用Github记录和存放代码文件，以下分步骤总结：

第一步：注册github→https://github.com/的账号

第二步：创建一个新的项目 new repository 就是创建仓库的意思

之后就可以安装git客户端开始配置。

http://git-scm.com/download/ ←git下载地址

安装好以后在开始程序中就可以找到git的三个程序，打开Git bash 就可以弹出窗口了。

第三步：首先输入ssh-keygen -t rsa -C “邮箱账号” 注意空格！

回车之后是输入一个保存秘钥的地方，括号里是默认的位置，可以不用输入，直接回车就可以了。

然后回到默认的位置（C:\Users\Administrator\.ssh）找到id_rsa.pub 文件复制粘贴里面的内容

转到网页端github上面找到setting 也就是设置，然后点击左侧的SSH Keys。之后再点击Add SSH Key，这样会出现添加SSH Key 的界面，在Title 这一栏填一个名字，之后将复制的内容粘贴到key这一栏，点击Add Key 按钮完成操作。

第三步就是验证是否成功，点开git端：

1.输入命令：ssh -T git@github.com 。如果你是第一次就会让你输入yes/no 这时输入yes 就可以了。

2.配置用户名和邮箱  ： 

                                   git config--global user.name “用户名”

                                    git config--global user.email “邮箱”

3.如果你想更改下本地存放的地址输入cd /更改的盘名/文件夹名字 记住！cd后面有空格！

到现在为止，就算把git 和gitHub 配置完。然后才开始项目的上传与下载以及如何更新修改！

1) git init 初始化

2)  git remote add origin git@github.com:账户名/仓库名.git (本地与云端的连接)

3) 从gitHub 端同步到本地代码git pull git@github.com:naraqin/naraqin.git（前面是用户名后面是仓库名）

4) 把本地代码同步到github 端

A. git add . 是提交所有本地文件，git add是单独的文件输入命令比如 git add demo.txt 提交的文件是自己创建的文件

B.git commit -m “写下你本次提交代码的提示信息”（这个是规则必须要写 注意-m之前 有空格）

C.提交提示信息之后，我们将它推送到远程仓库上去，命令如下：git push git@github.com:账户名/仓库名.git  [注意push]

基本上到这步就可以使用了，总结一下。如果有新的文件或者修改文件我们必须要先add 然后commit 最后push 

必须先add 然后commit 最后 push期间我们可以穿插 git status

这是git端的基本使用记录。

以下是我对廖雪峰分支管理的自学理解：

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

这段话最够让我知道分支的大概含义，就是分身。通俗来说也许就是创建了一个可以有管理自己代码的东西，不影响自己其余的工作，也不会丢失管理的数据。

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支

在git内是只有一条时间线的，并且就是主分支就是master分支。也就是我们每次提交的新的文件或者修改都是只有一条线。

master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长

而分支合并就是把master分支指向当前分支的提交点，就可以合并分支了。

解决冲突：

当master分支和创建的新分支各自都分别有新的提交，

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突

Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们必须进行人为的修改才可以解决冲突

当我们把master与新分支连接，就可以解决冲突了。

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

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

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

分支管理策略：

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

为了防止丢失，我们就要管理分支。

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

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

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

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

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

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

BUG分支

每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

Git提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支。

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

多人协作

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

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

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

查看远程库信息，使用git remote -v；
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。