1、Git本地密钥生成
在初次使用git的时候需要做的一件事,之后使用过程中不需要这么做了.可以把这个过程认为是一个认证过程.
GitHub密钥生成官方文档
- 1、 生成秘钥.公钥
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
Enter a file in which to save the key (/Users/you/.ssh/id_rsa)[Press enter]
Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]
- 2、绑定到 代码托管中心服务器中 .在个人页面 -> 用户设置 ->管SSH密钥-> 增加密钥 将生成的id_rsa.pub(这个文件所在的目录是C:/users/XXX/.ssh/id_sra.pub) 拷贝到 密钥内容部分.
在以后的使用中,你的每一次提交,每一次clone,每一次push,每一pull,都是这个账号的。
2、建立远端仓库和本地仓库的关联
我们首先通过浏览器在服务器上建立一个仓库；
在本地的工作目录下执行如下命令来建立本地和远端的连接
cd dir
git remote add origin http://192.168.9.14:3001/XXX/XXX.git
git init // 使用init命令将当前目录初始化为Git仓库
3、上传代码
第一步：添加所有要上传的文件到暂存区中
git add index.html // 需要上传的文件
git add . // 监控工作区的状态树，使用它会把工作时的所有变化提交到暂存区
git add -u //他仅监控已经被add的文件（即tracked file），
//会将被修改的文件提交到暂 存区。add -u 不会提交新文件（untracked file）
git add -A ：是上面两个功能的合集（git add --all的缩写）
第二步：添加本次上传的说明
git commit -m '本次上传的说明'
第三步：将本地仓库推到远端仓库的master分支中
git push -u origin master // 后续一般要输入邮箱账号密码等
4、版本回退
$ git reset --hard head^
在Git中，HEAD表示当前版本，就是最新提交的版本，即使用git log打印出来的位于第一位的版本，上一个版本就是HEAD，上上个版本就是HEAD^，
当前向上100个可以写成HEAD~100。当然，还有一种方式就是直接使用commit id来代替HEAD^，比如版本号是
cadab353589f3eef075817b890dafe8b722d802b，
那么就可以直接使用命令：
$ git reset --hard cadab353589f
使用前几位表示即可，git会自动查找
注：版本回退以后，使用git log打印的历史记录都是回退版本之前的数据，之后的都没有了，不过放心，git总有后悔药可以吃哒~
1.如果命令行窗口没有关闭，直接去前面找commit id即可；
2.如果命令行窗口关闭了，或者第二天后悔了，可以进入到该目录下，使用git reflog命令来查看以前的每一次命令，可以获得每次提交的commit id，
就可以版本回退了。
$ git reflog // 可以查看命令历史，包含提交的commit id
5、查看分支
git branch -a
上面显示的是本地分支，绿色字体和”*”表示的是当前所在的分支，
下面红色部分显示的是远程仓库的分支。
显示如下：
* master
remotes/origin/HEAD -> origin/master HEAD-远程仓库的当前分支是主分支
remotes/origin/dev dev分支(所有操作都会合并到该分支)
remotes/origin/master master分支-主分支
创建本地仓库的dev分支
git checkout -b dev
将远程仓库的dev分支代码复制到本地dev分支
git pull origin dev
创建自己的本地分支
git checkout -b mybranch // 创建自己的分支
git checkout mybranch // 切换到自己的分支
git merge dev // 将本地dev的分支合并到自己的分支上
... 可能存在冲突，进行解决
git checkout dev
git merge mybranch // 更新dev分支
git push origin dev // 推送到远端服务器上
6、解决merge冲突
一般有三种冲突：
- 逻辑冲突
git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。
比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。
又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。
这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。
- 内容冲突
两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种，后面的解决办法也主要针对这种冲突。
- 树冲突
文件名修改造成的冲突，称为树冲突。
比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。
- 1、先本地直接提交代码：git push origin master
- 2、如果别人在自己之前提交了修改，git会提示push失败，需要先pull远程代码：git pull origin/master （拉取远程仓库进行自动合并）
- 如果能自动合并，git会提示auto merge成功，这时可以直接git push origin master
- 如果不能自动merge，git会提示auto merge失败，需要手动解决冲突：
- git pull --rebase origin remote
if there is conflict, change it and execute the following command - git add .
- git rebase --continue
if all be done - git push origin remote
- git pull --rebase origin remote
每次都用这种方式，就不会有错了。
其他常用Git命令
1、
git status
#查看当前未提交的改动
# 显示提交的状态：已经添加，等待提交事务的文件(绿色字体表示)；
# 已经改变但是没有添加(not staged)的文件(红色字体表示)；
2、
git log
Commit xxx commit id 版本号
Author:xxx<xxx@xxx.com> 提交人和邮箱
Date：xxx 提交的时间
XXXXXXXXXXXXXX 提交的信息
好的项目管理习惯
每天临走之前,git push 一下今天的代码, 第二天来了继续工作之前,git pull 一下,把远端的最新的代码, 同步到本地.
每次完成 了重大的部分或者一个单独的单元的时候, git push 一下.
