git学习总结
总算有机会使用git了，ubuntu 上搭了个 gitlab 服务，为避免后人踩坑，分享下：
对于Linux小白来说，安装 ubuntu 桌面版，比命令行直观。先熟悉后，视情况再安装 ubuntu 服务版。
安装docker版的gitlab，集成了 redis，posgresql 等依赖组件。
docker版的gitlab安装很简单，真的仅一句话，丝毫不折腾：
sudo docker run --detach \
--hostname gitlab.linux.com \
--publish 443:443 --publish 80:80 --publish 22:22 \
--name gitlab-ce \
--restart always \
--volume /media/administrator/GitLabData/gitlab/config:/etc/gitlab \
--volume /media/administrator/GitLabData/gitlab/logs:/var/log/gitlab \
--volume /media/administrator/GitLabData/gitlab/data:/var/opt/gitlab \
gitlab/gitlab-ce
我安装的是gitlab 10.1.4 版本
其中域名 gitlab.linux.com 在hosts里解析
administrator 是我的Linux用户名
GitLabData 是我另挂载的一个磁盘，用于存储仓库数据
sudo dockers ps
有 (health) 字样说明服务正式启动了
如果服务未成功运行，执行： sudo docker start gitlab-ce //启动docker sudo docker exec -it gitlab-ce bash //进入docker gitlab-ctl restart //启动gitlab
sudo dockers ps //查看docker服务
exit //退出docker
git学习总结
一个文件会有很多版本，一个文件夹也会有多个版本，本地电脑当前文件夹下保存的是最新版本，每次编辑器保存后，文件实时覆盖。
如果要记录一个历史版本，就进行一次commit，git会保留下当前文件的快照，生成一个版本号，作为历史版本，以便查询，比较，还原。
我们当前开发工作的叫develop分支。实际工作中，我们会遇到历史版本的文件需要修改的情况。
比如已发布的程序发现了bug，需要立即修正，我们就要获取历史版本，修正bug后立即发布，这就另生成了一个版本分支。
因为修改的基础代码不是最新的develop版本，在最新的develop源码下，这个bug依旧存在，尚未修复。
为了直观，我们预先建立一个发布分支叫master分支，master分支是develop分支中里程碑版本的集合。
当有发布的程序需要修正bug，就获取master分支的最新版本，修改后提交master分支，同时也应把这部分修改内容提交到develop分支。
至此，git作为个人的版本管理工具已经功能完备了。
但，git作为团队协作工具，还需要管理不同人的不同版本的文件，以免文件互相覆盖。
我们把一个文件共享在团队服务器上，团队成员将此文件各自复制到本地电脑上，同一个文件在不同的个人电脑上会有多个副本。
如果此文件被不同的人各自修改，再次上传到服务器上，此文件不应被互相覆盖。
这时git服务端就会在接收文件时，智能判断会不会覆盖别人的修改内容，如果有此可能，会提示文件有冲突，阻止上传。
上传失败，通常的做法是，再次从服务器上获取最新版本的文件，在本地重新修改合并后，再次尝试推送到服务器上。
git判断你本次修改的文件基础版本跟服务器上该文件最新版本号是否一致，如果一致，才允许上传并覆盖共享的文件。
为了减少此类冲突情况的发生，我们应不定期地频繁获取服务器上的最新版本，修改后及时推送。
这样团队成员修改本地文件时，就是在修改最新版本的文件，而不是被别人修改过的过期版本的文件。
一次获取文件(pull+rebase)的过程可分离为3个步骤:获取服务端文件(fetch)，与本地工作区文件合并(merge)，重置本地为最新的版本号(rebase)
另外，git作为一个分布式版本管理工具，还有一个功能，可以支持不同的团队，创建自己的代码库。
从官方代码库中，可以fork出一个分支到团队git服务器上，作为团队开发的独立代码库，而不会影响到官方的代码库。
需要贡献代码时，向官方发送合并请求，并非主动推送代码到官方代码库。
官方维护人员收到合并请求后，视情况获取贡献者的代码，再合并到官方代码库。
这个示意图是个人初步理解，非权威仅供参考
