虚机ubuntu下局网搭建gitlab服务器

部署过程:

  • 坑一:当安装了postfix后,发现需要重新配置成internet,使用命令

sudo apt-get install gitlab-ce

然后就是参考过程:

https://blog.csdn.net/discoverer100/article/details/51814171

  • 坑二:本人禁用了先前安装的nginx,把external_url改成了“http://192.168.23.128:8010”,才顺利OK。否则看到的界面有问题,是CSS等资源不完整的显示。此时虽然能有改密码的界面,但不会成功的。如果是想和即有的nginx配合,请参考:https://jingyan.baidu.com/article/6525d4b1b5d89dac7c2e944a.html
  • 坑三:腾讯云把gitlab做起生意了,如果想在上面搞,域名和证书都要理顺,而且会对外界资源有排斥。

用户数据设计:

以下基于本人环境,不用参考。

root下面有codera,coderb,coderc

codera下面建立一个标准项目:bgsvc4hbw

grp4task1下面指定codera是owner(负责人),由root创建组,再邀请codera

此后,codera又建立了一个仓库flowshow用于研究git工作流。

进阶应用:

管理员密码重置

https://blog.csdn.net/weixin_30687051/article/details/97273880

工作流学习链接:

https://blog.csdn.net/qq_32452623/article/details/78905181?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1.control

小结一下,gitflow的心得:

1)feature都是起止于develop分支(回归develop时使用:git merge –no-ff)

2)hotfixs是起于master,止于同时推给master(打tag且尾号加1)和develop(回归方式cherry-pick)

3)realse是起于develop,和hotfixs永远不发生关系,止于性质与hotfixs相同,但区别tag是前一位版本号加1。同样不使用merge来回归develop

4)对于master外的发布,可以根据环境灵活建立分支,比如一平台一分支。

5)tag一般不会隐式推送到远端,所以,可以只选择大版本来显示手工命令推送。

https://blog.csdn.net/github_27263697/article/details/79563949

备份和迁移

https://blog.csdn.net/qq_40907977/article/details/106756999

云上git服务器

使用gitosis用户管理

→安装

首先,切换python2来安装
yum install -y python-setuptools 
git clone git://github.com/res0nat0r/gitosis.git 
cd gitosis 
python setup.py install 
然后,修改/user/local/bin/gitosis-三个文件的第一行,python后面加2.7
经过上面的修改,大环境中python版本仍为3.6,而gitosis会自行应用2.7

→环境搭建

本地公钥生成,做为管理的初始公钥
生成公钥命令:ssh-keygen -t rsa
注意生成后把
.pub的结尾,把@后面数字开头或者有_的都去掉,本人直接改成@localhost.
为此,我还去改造了命令提示符,但生成的公钥匙结果依然依赖hostname
https://www.cnblogs.com/xiaofeiIDO/p/8037331.html
并使用

  1. su - gitfarmer
  2. gitosis-init<~/new.pub
上面这条命令2,后台会执行一系列操作,比如生成一个gitosis-admin的仓库,把new.pub中的内容移至仓库的keydir目录中,同时公钥文件名称与仓库中的gitosis.conf里的memebers名一致。 最后,由于公钥匙是gitfarmer用户下生成的,所以,另建立了manage_instance目录,在里面
  1. git clone gitfarmer@127.0.0.1:repositories/gitosis-admin.git
此时,管理已经具备功能而且是在服务端本地来管理,安全分离。

客户端应用

→生成应用者的公钥

https://www.jianshu.com/p/ba6efe6bf60d 一般客户端为window且安装了git bash。下面就是在git bash中生成自己公钥匙的过程。 把id2cvm.pub上传到keydir中,然后,修改gitosis.conf增加你要管理的代码仓库。 然后,git commit. 事实上发现,通过命令行建立的好像并不被git bash接受,最后,还是用了git gui中的工具,生成了默认的id_rsa.pub才有效果。 ssh -Tv gitfarmer@hostname是很好的工具,但有时你发现没有反应这是因为你的服务端并未设置欢迎语录而已,需要看日志中是否22端口已经登录成功。并且要看最后的返回值是否为0来证明测试成功。

→在服务端建立裸仓库来对应客户端

原以为gitosis会代劳这个动作,实践发现需要自己来,有些帖子说的不对。

→客户建立仓库关联,推送代码

本人在git bash中操作系列命令:
mkdir BL_main

cd BL_main

git init

vim readme.md

git add .

git commit -m "first import"

git remote add origin gitfarmer@182.XXX.181.XXX:repositories/BL_YTF_prj.git

git push origin master
最后一条会跳出让你输入服务端登录ssh密码,并且此前在服务端~/respositories/已经建立了相应的裸仓库。

→在客户端多个公钥匙对应多个仓库的管理

在windows下,git bash会找到用户目录下.ssh/config文件来判断,如果你配置了分支,就会根据你请求的@后面值来查找config中的HostName来匹配
$ cat ~/.ssh/config 
HOST mycvm
HostName 182.XXX.181.XXX
User gitfarmerXXX
Port 22
#PreferredAuthentications publickey
IdentityFile C:\Users\user\.ssh\id_rsa

HOST github
HostName github.com
PreferredAuthentications publickey
IdentityFile C:\Users\user\.ssh\id2cvm
上面的mycvm就是你命令中要给出的
ssh -Tv gitfarmer@mycvm
 
如果测试成功,就说明分支判断了,支持多公钥管理

附录

https://blog.csdn.net/harry_haiwei/article/details/77714651 https://www.cnblogs.com/yshyee/p/4288465.html https://www.webyang.net/Html/web/article_257.html 原理指导
把用户gitfarmer加入到sudo组中: https://blog.csdn.net/qq_39290007/article/details/81125750 同一主机多个git ssh公钥配置: https://blog.csdn.net/yigehui12/article/details/89333264

git局网实战

介绍个轻量级方案,让局网下使用git方便,抛砖引玉了。

第一步,首先在A机上,把代码的目录变成仓库。
用git init或者用GUI操作,这没啥新鲜的。
第二步,在A机某个共享文件夹中建立个裸仓库(基于第一步的仓库)
即使用命令:在第一步的目录中,而share则是本机的共享目录。
git clone –bare . /c/Users/Administrator/Downloads/share/bare-cad.git
但,此时,第一步的仓库并没有把第二步刚建立的仓库当成远程仓库。所以,还要手工建立联系。
git remote add origin /c/Users/Administrator/Downloads/share/bare-cad.git
再加上一个
git push –set-upstream origin master
可保万全,它设置了第一步仓库的上游或者说远端源是第二步仓库了。不信,你用git branch -a或git push来测试。
到此,A机内循环通道完毕。
第三步,在局网的其它机器B上,映射驱动器为A机的那个共享目录。
Y:/bare-cad.git就是那个第二步建立的仓库。
并同时克隆一个仓库在自己喜欢的目录下。
git clone /Y/bare-cad.git
上游或远程关系自动建立好,git pull/push都没问题了。
第四步,开始协同开发,推拉自如。好像装箱和开箱,而这个中转箱,则为bare-cad.git.

git学习笔记

基础概念:
合并(merge):一般在分支到主线
     快进:另一分支并没有更改过。
     合并:两分支各自变化了,需要解决冲突
比如,如果要将开发中的分支(develop),合并到稳定分支(master),
  首先切换的master分支:git checkout master。
  然后执行合并操作:git merge develop。
  如果有冲突,会提示你,调用git status查看冲突文件。
  解决冲突,然后调用git add或git rm将解决后的文件暂存。
  所有冲突解决后,git commit 提交更改。
分支衍合(rebase):一般在主线到分支
     最好的场景是把主线的修复推向需要的支线。
分支衍合和分支合并的差别在于,分支衍合不会保留合并的日志,不留痕迹,而 分支合并则会保留合并的日志。
  要将开发中的分支(develop),衍合到稳定分支(master)。
  首先切换的master分支:git checkout master。
  然后执行衍和操作:git rebase develop。
  如果有冲突,会提示你,调用git status查看冲突文件。
  解决冲突,然后调用git add或git rm将解决后的文件暂存。
  所有冲突解决后,git rebase –continue 提交更改
     一个对象名,是根据内容sha出来的40字符串。
     二个目录:git目录,工作目录
     三个:
          index,staging area,未入仓库的,由仓库管理的,暂存区
     四种对象:每个对象都包括三部分:类型,大小和内容。
          blob,git show
          tree,git ls-tree
          commit,git show -s –pretty=raw ,一个commit只指向一个tree,它用来标记某一个特定时间点的状态。包括时间戳,提交者,(parent)指向上次提交对象的指针,(tree)。
          tag,git cat-file tag v1.5.0 用来标识某个提交的方法,包括对象名,对象类型,标签名,,标签创建者名字。
以下转来的思路清楚的后台逻辑:
————————————-

设想你现在位于 alpha/ 目录下,这里有一个文本文件 number.txt,里面的内容只有一个词:“first”。

现在执行 git init 将这个 alpha 文件夹初始化为 Git 仓库。

执行 git add number.txt 会将 number.txt 添加到 Git 的索引(index)中。这个索引记录了所有 Git 保持追踪的文件,现在它有了一个映射记录 number.txt -> first,同时 add 命令还会把一个包含了 first 字符串的二进制对象加入 Git 的对象数据库里。

现在执行 git commit -m first。这条命令会做三件事情。首先在对象数据库内创建一个树对象,用以记录 alpha 目录下的文件列表,这个对象有一个指针指向前面 git add 命令创建的 first 二进制对象;第二,这条命令还会创建一个 commit 对象用以代表刚刚提交的版本,它包含一个指针指向刚刚的树对象;第三,master 分支也会指向这个新创建的 commit 对象。

现在执行 git clone . ../beta。它会创建一个新目录 beta 并将其初始化为 Git 仓库,然后把 alpha 仓库的对象数据库中所有对象拷贝给 beta 的对象数据库,将 beta 的 master 分支像 alpha 的 master 一样指向相应的对象。它还根据 first提交的内容配置索引,并根据索引更新目录下的文件——也就是 number.txt

现在切换到 beta 目录,修改 number.txt 的内容为“second”,执行 git add number.txt 和 git commit -m second,新创建的提交对象 second(译注:姑且称之为 second)会有一个指向父提交(first)的指针,表示 second 继承自 first,而 master 分支则指向 second 提交。

回到 alpha 目录,执行 git remote add beta ../beta,将 beta 仓库设为远程仓库。然后执行 git pull beta master

在这条命令背后,它其实会执行 git fetch beta master,从 beta 仓库中找到 second 提交的相关对象拷贝到 alpha 仓库;把 alpha 中关于 beta 的 master 分支记录指向这个 second 提交;更新 FETCH_HEAD 指向刚刚从 beta 仓库拉取的 master 分支,还是这个 second 提交。

此外,pull 命令还会执行 git merge FETCH_HEAD。从 FETCH_HEAD 得知最近拉取的分支是 beta 仓库的 master 分支,据此拿到相应的对象,也就是 second 提交对象。此时 alpha 的 master 分支指着 first 提交,正好是 second 的祖先提交,于是对于 merge 命令来说只需要将 master 分支指向 second 提交即可。接下来 merge 命令还会更新索引以匹配 second 提交的内容,并且相应更新工作目录中的文件。

现在执行 git branch red,创建一个名为“red”、指向 second 提交的新分支。

然后执行 git checkout red。在 checkout 之前,HEAD 指向 master 分支,执行命令之后它就指向了 red 分支,使得 red 成为当前分支。

接下来把 number.txt 的内容修改为 “third”,执行 git add numbers.txt 和 run git commit -m third

之后再执行 git push beta red,这条命令会把 alpha 仓库内跟 third 提交相关的对象拷贝至 beta 仓库,并且将(alpha 仓库内记录的)beta 仓库 red 分支指向 third 提交。就酱。

—————————-

事实上只有理解后台的动作,才能在命令中游刃有余。下面个人总结的,请大家抛砖。

后台的勤劳者
git clone
—后台把新仓库的同名分支和旧仓库的远程分支(相对于新仓库)做“自动追踪”映射了。
手工改的命令是:
git branch –set-upstream master origin/next
–set-upstream-to=origin/next master
在push后加下面的效果一致(关联阅读):注远程没有next也会生推过去,并设置了跟踪关系。
-u origin next
git pull <远程主机或仓库默认origin> <远程分支>:<本地分支>
—后台的动作包括fetch FETCH_HEAD(默认是远程的master并设置,在不加参数情况下,它也会全取来远程下面的所有分支)
—后台还有merge动作。前提是当前分支与远程分支存在追踪关系了。
git push<远程主机或仓库默认origin> <本地分支>:<远程分支>
—注意这是危险的,要先pull才好。它在后台只接受“快进”,并且要注意冒号前的分支所属
rebase
—后台有个删除动作的,为了让树看起来漂亮,他会像橡皮一样擦除本分支内的commit对象,然后做好搬运合并。所以,这一般都在非主分支上。
附个技巧:有点像“月光宝盒”哟
#保留你当前状态,包括未跟踪的垃圾文件,并最后再搞回来
git stash
git checkout fe9c4
#看代码等操作
git checkout master
git stash pop
注意pop是会删除stash对象的,而apply不会,要有多个stash时,用stash@{num}来指代。

git工作流设计

对于源码管理和产品线管理为了避免混乱,应该有个大致的管理方案:
项目名假如为:tj_dj
则产品管理线:(主机)
主分支–master
开发分支–develop-tj_dj
发布分支–release-tj_dj
特性分支(短生命线分支)–f-[特性名]-tj_dj
修复分支–hotfix-tj_dj

轻量级开发情况:(AB机间没有网络)
在各自本机建立环境,本地建立好bare仓库和本地开发仓库。
总体上要求,bare仓库是同名的,但在自己的本地开发仓库中把远程仓库命名个性化。Dell为例:
dell-前缀。
技巧:
bare仓库用来fetch和push的“箱子”,为远程仓库。
使用拷贝方式来和其它机共享bare仓库。
各机器为主工作时,则要使用很多分支技术来merge其它机的进度代码。

多人联合开发情况:
这里就仁者见仁,智者见智了。但是最典型的就是gitflow了。但不是起对了几个分支名就行了。要得其要领。
原则:
master和develop分支是稳定分支,一直存在。
master只允许release和hotfix分支来的merge
develop日常开发
feature上开发功能,功能成熟后合并到develop上
release是从develop上分出来,bug修复后,打上tag后,要同时合并回develop和master
很小的bug修复会则会在hotfix上进行。
1). 首先将远程代码拉取到本地
  git clone xxx
  git checkout -b develop origin/develop
2).新建feature分支
  git checkout -b feature
3).多人在feature上开发,如果中途需要将develop的变更合入feature,所有人需要将本地的代码变更提交到远程
  git fetch origin
  git rebase origin/feature
  git push origin feature
然后由feature负责人rebase develop分支,删除原来feature分支,重新新建feature分支;
  git fetch origin
  git rebase origin/feature
  git rebase develop
  git push origin :feature
  git push origin feature
这样可以保证feature保持线性变更;
4).feature开发完成后,所有人需要将本地的代码变更提交到远程
  git fetch origin
  git rebase origin/feature
  git push origin feature
然后由feature负责人rebase develop分支,然后将feature分支合入develop,删除feature;
  git fetch origin
  git rebase origin/feature
  git rebase develop
  git checkout develop
  git merge feature
  git push origin :feature
这样可以保证develop保持线性变更,各feature的变更完整可追溯;
5).合入feature后拉出对应的release/feature分支,后续bug修复在release/feature上
  git checkout develop
  git checkout -b release/feature
release/feature分支的同步合并与feature分支相同
6).release/feature分支bug修复完成后,拉取对应的tag推送远程进行发布
  git tag -a v1.0 -m ‘feature发布’
  git push origin v1.0
之后将release/feature合入develop分支,然后删除
  git rebase develop
  git checkout develop
  git merge release/feature
  git push origin :release/feature
7).发布完成后将release合入master分支,保证master为最新稳定版本(实际操作为发起merge request)