ESAGE GITLAB 部署与使用

git bash安装使用：

第一步：

去github上下载git for window ，url : http://msysgit.github.io/，然后按默认选项安装即可
我这边只安装了git shell。
如果是linux系统请直接yum

第二步：

然后将git的bin/cmd目录设置到path环境变量中。我的是“G:\Git\cmd”。

第三步：

Git的配置主要包括用户名，邮箱的设置，以及生成SSH密钥公钥等。
首先运行一下的命令设置git提交代码时你自己的用户信息。

$ git config --global user.name "mengt_niu"
$ git config --global user.email "niumt@esage.cn"

第四部：

生成SSH key
找到“Git Bash”，运行之，并执行以下命令：

  //ssh-keygen -t rsa
  $ ssh-keygen -t rsa -C "niumt@esage.cn"
  

程序会提示您输入密钥的文件名，比如输入oschina，按回车即可。然后会要求你输入一个密码，将来在使用密钥的时候需要提供这个密码。可以输入，也可以不输入直接回车（无论输入还是不输入，都会要求你确认一次）。我们不输入密码
确认完毕后，程序将生成一对密钥存放在以下文件夹：

  //C:\Users\lenovo\.ssh
  C:\Users\Administrator[这里替换成你的用户名]\.ssh
  

密钥分成两个文件，一个私钥（github_rsa）、一个公钥（github_rsa.pub）。
私钥保存在您的电脑上，公钥交项目负责人添加到服务器上。用户必须拥有与服务器公钥所配对的私钥，才能访问服务器上的代码库。
key添加成功之后会有邮件提醒，如果报500错误，请重启服务器

第五步:测试

ssh加-T选项测试目标服务是否可用:

  $ ssh -T git@"git.esage.cn"
  

第一次连接时，会询问是否信任主机，确认后输入yes。如果看到Welcome to GitLab, Rusher!就算配置成功了，接下来就可以通过ssh来提交代码了

第六步:实际操作

  //Git global setup:
  $ git config --global user.name "mengt_niu"
  $ git config --global user.email "niumt@esage.cn"

如果自己有一个单独的库，独自测试：

  //=========Create Repository
  $ mkdir myunicenter
  $ cd myunicenter
  $ git init
  $ touch README
  $ git add README 
  //如果没有这个add 会error[src refspec master does not match any]
  //引起该错误的原因是，目录中没有文件，空目录是不能提交上去的
  $ git commit -m 'first commit'
  $ git remote add origin git@git.esage.cn:mengt_niu/myunicenter.git
  //如果报error[fatal: remote origin already exists.]
  //那么请输入以下命令 
  //$ git remote rm origin
  //然后在输入之前的命令
  //git remote add origin git@git.esage.cn:mengt_niu/myunicenter.git
  $ git push -u origin master

  //=========Existing Git Repo?
  $ cd existing_git_repo
  $ vi README
  $ git diff README
  $ git add README
  $ git rm --cached   //使用这条命令可以撤销 add
  $ git add README
  $ git commit -m 'first commit'
  $ git remote add origin git@git.esage.cn:mengt_niu/myunicenter.git
  $ git push -u origin master
  $ git reset --hard  //可以用这条来回撤commit
    $ git push origin HEAD --force //提交回撤请求
  

Git的一些常用的撤销提交版本的的命令：

      $ git revert HEAD                  
      //撤销前一次 commit
      $ git revert HEAD^              
      //撤销前前一次 commit
      $ git revert commit 
      //（比如：fa042ce57ebbe5bb9c8db709f719cec2c58ee7ff）撤销指定的版本，撤销也会作为一次提交进行保存。 
      // revert 后要submmit ~
      $ git push

分组共同项目：主要说这点:

  //=======clone
  $ git clone git@git.esage.cn:mengt_niu/myunicenter.git
  $ cd myunicenter
  $ git checkout -b nmtReturn 
  //创建分支
  //=======edit
  $ vim new.html  
  //添加文件
  $ git add new.html 
   //添加到git缓存区
  $ git commit -m "most code implementation"  
  //设置提交描述
  $ git push -u origin nmtReturn          
  //提交
  $ vi README   
  //修改文件
  $ git diff README 
  // 对比修改内容
  //git status -s 也可以对比。和diff有什么不同，可以自己尝试一下
    diff --git a/README b/README
    index e69de29..316b3b1 100644
    --- a/README
    +++ b/README
    @@ -0,0 +1 @@
    +this is esage 2014-11-13 ,this is version not centos7 node!
  $  git add README 
  //添加到git缓存区
  $  git commit -m "vi readme"  
  //设置提交描述
    [master 8b52dcc] vi readme  
    1 files changed, 1 insertions(+), 0 deletions(-)
  $  git push -u origin nmtReturn   
  //提交
  $  git push -u origin nmtReturn:master  
  //分支nmtReturn想直接将推送到受保护的分支上。没人有权限将报错
    Counting objects: 5, done.
    Compressing objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 315 bytes, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To git@git.esage.cn:mengt_niu/myunicenter.git
    5c4d769..8b52dcc master -> master
    Branch master set up to track remote branch master from origin.

第七步：合并请求

分组共同项目：主要说这点:
nmtReturn在Commit页面上浏览分支nmtReturn,然后向项目领导创建一个合并请求。
这个合并请求除了领导可以登录gitlab上看到之外，还可以通过邮件方式看到。领导即使没有登录gitlab，只要他的邮箱支持手机邮箱等方式， 手机邮箱可以通过短信的方式通知领导，领导可以实时看到合并要求。

  //管理员对要求合并的分支代码进行审核。 
  //在你的目录分支后面有当前分支的名字 
  //管理员从服务器上获取nmt提交的分支。
  $ git clone git@git.esage.cn:mengt_niu/myunicenter.git
  $ cd myunicenter
  $ git fetch
  

然后nmt推送的远程新分支被管理员拉拽到本地，但是不是以本地分支存在， 而是保存在 .git/refs/heads 之外（.git/refs/remotes/origin/之中）的远程分支。 管理员可以如下方法对nmt的分支进行审核。
执行

  $ git log master..origin/nmtReturn //可以看到nmt推送了几个提交。 
 

管理员可以合并nmt的分支：

 
  $ git merge origin/nmtReturn 
   

管理员可以逐一对nmt的提交审核。如果发现有问题，管理员可以本地回滚。

 
  $ git reset --hard HEAD^ // 或 master@{1} 
   

几个反复后，当nmt的分支审核无误，管理员将合并后的本地 master 分支推送到远程服务器：

 
  $ git push # 缺省 remote 为 origin 
  

注意:
协同开发时，我们从远程服务器上pull下代码的时候，出现以下提示信息：

 
  [
  Auto-merging name
  CONFLICT (content): Merge conflict in name
  Automatic merge failed; fix conflicts and then commit the result.
  ]
  

从git status的结果可以发现：其中xxxx这个文件存在合并冲突

  $ git status
   

我们需要手动去解决冲突，在进行合并。

第八步：继续开发

nmt看到请求已经接受。

  $ git fetch
   

执行 git fetch 会获取到更新的 master 分支。然后

  $ git checkout master 
  $ git merge --ff origin/master 
   

nmtReturn分支完成使命，删掉吧：

  $ git branch -D nmtReturn 
   

然后创建新的分支，进行新的功能开发

以下是一个常用的git命令：

----------------remote-------------
   git remote add [shortname] [url] //添加远程仓库
   git remote -v //列出远程仓库
   git remote show [remote-name] //列出远程仓库详细信息
   git remote rename old-name new-name //远程仓库重命名
   git remote rm [remote-name] //删除远程仓库
   rm -rf [name] //删除本地仓库
----------------fetch----------------
   git fetch [remote-name] //将远端的数据拉到本地仓库，并不自动合并到当前分支，仍需手工合并。
-----------------tag-----------------
   git tag v1 //建立标签
   git tag -a v1 -m '建立标签'
   git show v1 //查看标签版本信息 
---------------reset-----------------
   根据–soft –mixed –hard，会对working tree和index和HEAD进行重置:
   git reset –mixed：此为默认方式，不带任何参数的git reset，即时这种方式，它回退到某个版本，只保留源码，回退commit和index信息
   git reset –soft：回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可
   git reset –hard：彻底回退到某个版本，本地的源码也会变为上一个版本的内容
   HEAD 最近一个提交
   HEAD^ 上一次
    每次commit的SHA1值. 可以用git log 看到,也可以在页面上commit标签页里找到

冲突的产生:

很多命令都可能出现冲突，但从根本上来讲，都是merge 和 patch（应用补丁）时产生冲突。 而rebase就是重新设置基准，然后应用补丁的过程，所以也会冲突。 git pull会自动merge，repo sync会自动rebase，所以git pull和repo sync也会产生冲突。当然git rebase就更不用说了。 冲突的类型

逻辑冲突:

git自动处理（合并/应用补丁）成功，但是逻辑上是有问题的。
比如另外一个人修改了文件名，但我还使用老的文件名，这种情况下自动处理是能成功的，但实际上是有问题的。
又比如，函数返回值含义变化，但我还使用老的含义，这种情况自动处理成功，但可能隐藏着重大BUG。这种问题，主要通过自动化测试来保障。所以最好是能够写出比较完备的自动化测试用例。
这种冲突的解决，就是做一次BUG修正。不是真正解决git报告的冲突。

内容冲突

两个用户修改了同一个文件的同一块区域，git会报告内容冲突。我们常见的都是这种，后面的解决办法也主要针对这种冲突。

树冲突

文件名修改造成的冲突，称为树冲突。
比如，a用户把文件改名为a.c，b用户把同一个文件改名为b.c，那么b将这两个commit合并时，会产生冲突。

  $ git status
      added by us:    b.c
      both deleted:   origin-name.c
      added by them:  a.c

如果最终确定用b.c，那么解决办法如下：

  $ git rm a.c
  $ git rm origin-name.c
  $ git add b.c
  $ git commit

执行前面两个git rm时，会告警“file-name : needs merge”，可以不必理会。
树冲突也可以用git mergetool来解决，但整个解决过程是在交互式问答中完成的，用d 删除不要的文件，用c保留需要的文件。
最后执行git commit提交即可。

内容冲突的解决办法:

发现冲突
一般来讲，出现冲突时都会有“CONFLICT”字样：

  $ git pull
    Auto-merging test.txt
    CONFLICT (content): Merge conflict in test.txt
    Automatic merge failed; fix conflicts and then commit the result.
 

但是，也有例外，repo sync的报错，可能并不是直接提示冲突，而是下面这样：
error: project mini/sample
注：无论是否存在冲突，只要本地修改不是基于服务器最新的，它都可能报告这个错误，解决方法都是一样。
这个时候，需要进入报错的项目（git库）目录，然后执行git rebase解决：

  $ git rebase remote-branch-name
  

冲突解决的一般过程
merge/patch的冲突解决
先编辑冲突，然后git commit提交。
注：对于git来讲，编辑冲突跟平时的修改代码没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。
rebase的冲突解决
rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。
解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也就是把修改内容加入缓存）：

  $ git add -u
  

注：-u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件。
然后执行下面命令继续rebase：

  $ git rebase --continue
  

有冲突继续解决，重复这这些步骤，直到rebase完成。
如果中间遇到某个补丁不需要应用，可以用下面命令忽略：

  $ git rebase --skip
  

如果想回到rebase执行之前的状态，可以执行：

  $ git rebase --abort
  

注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。

编辑冲突的方法

直接编辑冲突文件
冲突产生后，文件系统中冲突了的文件（这里是test.txt）里面的内容会显示为类似下面这样：

  $ vi test.txt
    a123
    <<<<<<< HEAD
    b789
    =======
    b45678910
    >>>>>>> 6853e5ff961e684d3a6c02d4d06183b5ff330dcc
    c

其中：冲突标记<<<<<<< （7个<）与=======之间的内容是我的修改，=======与>>>>>>>之间的内容是别人的修改。
此时，还没有任何其它垃圾文件产生。
最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。