文章目录

git操作篇1. 项目克隆2. 项目的提交3. 项目的推送4. 分支和gitflow流5. 项目还原到历史版本6.合并之rebase和merge7. 冲突解决

gitlab操作篇1.gitlab项目新建2.sshkey设置3.代码上传

git操作篇

1. 项目克隆

<code>git clone git@gitlab.test.cn:pro/project1.git

2. 项目的提交

注：如果要查看文件的状态可以用git status命令：

如上图所示，文件已经修改了。

3. 项目的推送

<code>git push origin feature/test01

注：如果要查看远程的项目源地址可以如下命令：

git remote -v

4. 分支和gitflow流

master分支

master分支是最终版本的分支，是正式发布使用的，是受保护的分支，在master分支上不能随意修改

---

develop分支

develop分支从master分支拉取出来，作为功能分支的集成分支，这样也方便master分支上的所有提交分配一个版本号；如图所示：

<code>1.如果在远程服务器上没有develop这个分支，那么在本地新建一个并上传

git branch develop

git push -u origin develop

2.如果远程已经存在，那么在本地直接远程check下来即可

git checkout -b develop origin/develop

3.如果功能分支需要合并进来

git pull origin //在合并进来之前最好先拉取一下，以免有冲突

git merge feature/feature-lisi

---

feature分支

feature分支也叫功能分支，就是对一个项目组按人员划分来建立分支比如张三，就是feature/feature-zhangsan,李四，就是feature/feature-lisi。功能分支不是从master中去fork分支(切记)，而是将develop分支作为父分支。当功能开发完成后合并回develop分支。

这样子做的目的是每个人开发都相对独立，相互不受影响。其结构图所示：

<code>如果是新的feature分支，在远程不存在的，那么从develop中创建出功能分支

git checkout -b feature/feature-lisi develop

将本地的feature分支提交到远程服务器上

git push origin feature/feature-lisi

如果远程featrue分支已经存在

git checkout -b feature/lisi origin feature/lisi

---

release分支

到了发布的时候，专门为发布准备了一个分支就是release分支，它从develop中fork出来，这么做的目的是一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下一个版本。

并且这个版本只做上线前的bug修复用(即测试测出来的bug修改)，不能新增功能，一旦合并到master分支后，也同时要将所做的修改合并到develop分支中去。其结构图所示：

<code>1. 从develop中fork一个分支

git checkout -b release-0.1 develop

2. 发布时的操作

git checkout master

git merge release-0.1

git push

3. 一定要合并回develop

git checkout develop

git merge release-0.1

git push

4. 删除发布分支

git branch -d release-0.1

---

hotfix分支

hotfix分支也叫维护分支或者热修复分支，用于快速给生产线上的产品打补丁用(比如客户在生产线上发现了紧急bug需要马上修复)，这是唯一从master分支中去fork出来的分支，修复完成后，将修改的要合并到develop分支，master分支应该用新的版本号打好tag。

这样做的目的是，让团队快速解决掉问题，而不用打断其他工作或等待下一个发布。可以理解成在master分支上处理的临时发布。结构图如图所示：

<code>1. 从master中fork出一个分支

git checkout -b hotfix-001 master

2. 修改完bug，进行合并提交

git checkout master

git merge hotfix-001

git push

3. 切换到develop分支进行合并提交

git checkout develop

git merge hotfix-001

git push

4. 删除热修复分支

git branch -d hotfix-001

注：在切换到某个分支的时候，必须需要对这个分支做一个拉取，以免出现冲突

git pull origin [分支名]

5. 项目还原到历史版本

如果我们开发时候，发现错了想还原到具体某一个版本，git也很方便。

先通过查找日志查找版本号

git log [文件名]

每次，修改提交都有一个记录编号

还原到某个版本

可以从日志中找到某个日志编号进行还原,比我我要还原成2月份的一个版本

git查看版本树

<code>git log --oneline --graph --decorate --all

git reset --hard e957e52aa922b7b95b4d6bc85159fa41d466acd3

注：如果还原到上一个版本或者上上个版本

git reset --hard HEAD^ //还原到上一个版本

git reset --hard HEAD^^ //还原到上上个版本

6.合并之rebase和merge

rebase

git checkout develop

git rebase -i[分支A]

rebase操作时，是从两个分支共同的commit节点开始，将当前的分支develop的commit都提取出

来，追加到分支A上，有冲突就解决冲突，合并完成后会将develop原来提交的commit记录号删除掉，在最后重新生成新的commit记录号，

所以rebase不会产生多个commit，可以节省资源，但同时比较坑的是，如果多次commit有冲突，需要解决多次冲突

merge

git checkout develop

git merge [分支A]

merge操作时，两个分支共同的节点号，以及他们最新提交的节点，一起合并生成一个最新的节点。冲突只要解决一次就行，但同时也会产生多个commit。从公司多人协作项目考虑，建议用merge.

总结

我们在使用合并代码时，默认是使用fast-forword模式，这种模式不会保存commit记录，在合并和删除分支时会将分支信息删除掉。

git rebase --onto develop

提示:

First,rewinding head to replay your work on top of it...

Fast-forwarded master to develop.

git merge develop

提示:

Updating 5a8b732..85a33e2Fast-forward

2.txt |1 -

1 file changed, 1 deletion(-)

在使用git pull时其实是拉取远程文件 和 合并的一个组合

git pull= git fetch + git merge

git pull-r= git fetch + git rebase

7. 冲突解决

比如有文件2.txt初始内容如下:

develop分支添加2.txt文件

develop分支合并了内容

3333333

111111

现在有两个分支masert，develop都不小心修改了同样的内容:

develop：

develop分支添加2.txt文件

develop分支合并了内容

develop分支修改了内容

master：

develop分支添加2.txt文件:

develop分支合并了内容，

master分支修改了内容

这个时候，在master分支下，将develop合并进去

git checkout master

git merge develop

提示:

Auto-merging 2.txt

CONFLICT(content):Merge conflict in 2.txtAutomatic merge failed;

fix conflicts and then commit the result.

提示在合并2.txt文件时发生冲突如图所示:

<<<<< HEAD 和 ===== 之间的表示当前分支下所修改的内容，

=======和 >>>>> develop之间的表示develop分支的内容。

接下来就来解决冲突,选择其中一行的内容，也可以两行都保留，很简单只需要<<<<<HEAD,======,>>>>>>> develop去掉，在这个例子以develop分支修改的为主，然后再提交。

<code>develop分支添加2.txt文件

develop分支合并了内容

develop分支修改了内容

git add 2.txt

git commit -m"2.txt冲突解决'

提示:

[master 5a8b732]2.txt冲突解决

gitlab操作篇

gitlab master分支第一次push代码的时候只有主程序员才能推送，其他角色推送不了会报错

1.gitlab项目新建

1.1 进项目首页

1.2 创建空白项目(比较常用)

1.3 通过模板来进行创建（选择了模板之后，会自动生成框架，直接使用就行）

1.4 还可以通过从其他git源导入进来

2.sshkey设置

2.1 在本机生成sshkey，下面以mac下面为例进行演示，windows平台下的网上自己搜索。

<code>1. 进入.ssh目录

cd ~/.ssh

2. 生成SSH密钥

默认名称：

ssh-keygen -t rsa -C "你的个人邮箱"

自定义名称：

ssh-keygen -t rsa -f "密钥名称" -C "你的个人邮箱"

例子：

ssh-keygen -t rsa -f "id_rsa_xinhui" -C "hjc_042043@sina.cn"

接下来直接回车下去，不用输入passphrase内容，不然每次操作都要输入passphrase

3. 获取SSH公钥信息

这时在.ssh目录下会生成两个文件，私钥id_rsa和公钥id_rsa.pub两个密钥文件。

2.2 在gitlab平台添加sshkey

可以将id_rsa.pub文件内容复制出来，然后黏贴到gitlab平台

添加成功之后看如图所示：

2.3 如果有多个git源仓库，怎么办?

如果有多个git源库，比如既有gitlab，又有github版本库的时候，那么SSHkey需要做区分,需要在~/.ssh目录中添加一个config文件，以及known_hosts文件，config文件主要是来管理git源，known_host是来管理私钥内容，内容如下：

<code># gitlab

Host 192.168..0.103

HostName 192.168..0.103

User allen.huang

IdentityFile ~/.ssh/id_rsa

# github

Host github.com

HostName github.com

User hjc1985

IdentityFile ~/.ssh/id_rsa_github

# golivecc

Host 192.168.0.102

HostName 192.168.0.102

User hjc

IdentityFile ~/.ssh/id_rsa_golivecc

# 对Host进行测试：

$ ssh -T git@192.168.0.102

Welcome to GitLab, 黄锦潮! #如果输出如下结果表示成功

参考：

https://segmentfault.com/a/1190000002994742

http://blog.csdn.net/baidu_35738377/article/details/54580156

3.代码上传

Git用户名和邮箱的配置

注：如果有多个git源,不能用 git config --global

git config user.name "你注册的用户名"

git config user.email "你注册的邮箱"

创建新版本库

git clone git@192.168.0.102:git-test/demo.git

cd phptest

touch README.md

git add README.md

git commit -m "add README"

git push -u origin master

设置gitignore

在.gitignore文件中例如可以把缓存，日志类的文件忽略掉把.DS_Store (mac下有，windows下没有)，thumbs.db, data/logs, data/caches等

如果已存在的文件夹

<code>cd existing_folder

# 初始化git仓库

git init

# 将远程git库和当前的库进行绑定

git remote add origin git@192.168.0.102:git-test/demo.git

git add .

git commit -m "Initial commit"

git push -u origin master

如果已存在的 Git 版本库

cd existing_repo

git remote rename origin old-origin

git remote add origin git@192.168.0.102:git-test/demo.git

git push -u origin --all

git push -u origin --tags

git利用nginx进行域名的反向代理

#PROXY-START/

location ~* \.(php|jsp|cgi|asp|aspx)$

{

proxy_pass http://localhost:8099;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header REMOTE-HOST $remote_addr;

}

location /

{

proxy_pass http://localhost:8099;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header REMOTE-HOST $remote_addr;

add_header X-Cache $upstream_cache_status;

#Set Nginx Cache

add_header Cache-Control no-cache;

expires 12h;

}

server

{

listen 80;

server_name git.programlife.tech;

index index.php index.html index.htm default.php default.htm default.html;

root /www/wwwroot/git.programlife.tech;

#SSL-START SSL相关配置，请勿删除或修改下一行带注释的404规则

#error_page 404/404.html;

#SSL-END

#ERROR-PAGE-START 错误页配置，可以注释、删除或修改

#error_page 404 /404.html;

#error_page 502 /502.html;

#ERROR-PAGE-END

#PHP-INFO-START PHP引用配置，可以注释或修改

#清理缓存规则

location ~ /purge(/.*) {

proxy_cache_purge cache_one $host$1$is_args$args;

#access_log /www/wwwlogs/git.programlife.tech_purge_cache.log;

}

#引用反向代理规则，注释后配置的反向代理将无效

include /www/server/panel/vhost/nginx/proxy/git.programlife.tech/*.conf;

include enable-php-00.conf;

#PHP-INFO-END

#REWRITE-START URL重写规则引用,修改后将导致面板设置的伪静态规则失效

include /www/server/panel/vhost/rewrite/git.programlife.tech.conf;

#REWRITE-END

#禁止访问的文件或目录

location ~ ^/(\.user.ini|\.htaccess|\.git|\.svn|\.project|LICENSE|README.md)

{

return 404;

}

#一键申请SSL证书验证目录相关设置

location ~ \.well-known{

allow all;

}

access_log /www/wwwlogs/git.programlife.tech.log;

error_log /www/wwwlogs/git.programlife.tech.error.log;

}