.git
目录。yum install git-core
apt install git
安装后需要配置Git工作环境,更新后沿用配置,也可以随时使用同样命令更改配置。
git config
配置级别 | Windows配置文件 | Linux配置文件 | Git选项 | 作用范围 |
---|---|---|---|---|
系统 | 安装目录/etc/gitconfig |
/etc/gitconfig |
--system |
所有用户 |
全局 | $HOME ,即用户根目录,一般来说C:\Users\your-user-name\.gitconfig |
~/.gitconfig |
--global |
当前用户 |
本地 | .git/config |
.git/config |
--local |
本地仓库 |
git config --global user.name "your-name"
git config --global user.email "your-email"
--global use global config file
--system use system config file
--local use repository config file
--worktree use per-worktree config file
--list
,直接编辑配置文件--edit
。git help
git --help
man git-
最基本最常用的Git命令。
git init
cp [your-file] ./
git add *
git commit -m "initial projet version"
git clone [url] [local-repo-name]
忽略某些文件:无需进行版本管理的文件,将其列入.gitignore
中,将不会再进行跟踪,git status
时将不再显示其未跟踪状态。一般情况下我们可以选择将项目生成的二进制文件,临时文件,自己本地特有但不需要进行版本管理的文件加入忽略列表。
*.[oa]
*~
.gitignore
格式规范:
#
号开头的行被忽略。/
说明要忽略目录。!
取反。glob模式是指Shell使用的简化的正则表达式。规则:
*
号匹配零个或者多个任意字符。不包括表示目录的/
或者\
(Windows中)。**
则可以匹配任意字符,包括目录。[abc]
匹配任意一个方括号中的字符,[0-9]
匹配0到9的任意一个字符。?
匹配一个任意字符。例子:
# 忽略所有.a文件,除了lib.a
*.a
!lib.a
# 忽略TODO文件和bulid文件夹
/TODO
/bulid/
# 忽略doc/目录下的所有txt文件和忽略doc/以及其子目录下所有txt文件
doc/*.txt
doc/**/*.txt
Git仓库中的文件状态:
Git的版本管理操作:
检查当前Git仓库文件状态:Git status
。
添加文件到暂存区:git add
。这个命令用于跟踪未跟踪文件,暂存已修改文件。
比较工作区相对暂存区差异:git diff
。即是修改后还没有暂存起来的内容。
比较已经暂存的内容相较上次提交(版本库内最新内容)之间的差异:git diff --cached
或者git diff --staged
。
提交更新:git commit
,Git会进入默认编辑器提示你输入提交信息。编辑器一般是vim,有由git config core.editor
指定。编辑时注释中会包含此次提交改动的文件信息。加入-v
选项则文件的具体差异都会显示在提示中,帮助你更好的编写提交信息,提交时注释会被丢弃。加入-m
选项则直接在其后添加提交信息参数,用""
包含,则不会进入编辑。得到的提示信息如下:
[master 60dcae0] update ignore list & hello.c
2 files changed, 9 insertions(+)
提交时跳过使用暂存区域:git commit -a -m "commit message"
,跳过git add
步骤。
从Git中移除文件:git rm
,从跟踪清单(确切地说从暂存区域)移除,同时从本地删除,这样提交时就会从将文件从版本库删除了。仅删除本地文件的话不会从暂存区域移除。
如果只想从版本库移除,而不想从本地删除,则使用git rm --cached [file]
,保留本地文件,移除暂存区文件(不再跟踪),下次提交时即可生效。使用git rm
也可以使用文件模式匹配规则。并且git在Shell之上也有自己的扩展模式匹配规则(不展开说)。
移动文件:git mv [file_from] [file_to]
,仓库中的元数据并不会体现出这是一次改名操作。不过Git会推断出发生了什么。其实运行git mv readme.md readme.txt
就相当于(必须先rm
再add
):
mv readme.md readme.txt
git rm readme.md
git add readme.txt
分开操作git也会意识到这是一次改名操作,怎么做到的?思考。
查看提交记录命令:git log
。每次提交记录中都会显示:SHA-1校验和,作者和邮箱,提交时间,提交说明。
添加选项-p
显示提交文件差异。
-2
只显示最近两次更新。
--stat
仅显示简要的增改行数统计
另外--pretty
提供了不同的参数:oneline
,short
,full
,fuller
可以显示不同风格的记参数还可以是format
用于自己定制要显示的记录格式,这样的输出方便后期编程提取(哇,细节太多。常用格式占位和说明:
%H 提交对象(commit)的完整哈希字串
%h 提交对象的简短哈希字串
%T 树对象(tree)的完整哈希字串
%t 树对象的简短哈希字串
%P 父对象(parent)的完整哈希字串
%p 父对象的简短哈希字串
%an 作者(author)的名字
%ae 作者的电子邮件地址
%ad 作者修订日期(可以用 -date= 选项定制格式)
%ar 作者修订日期,按多久以前的方式显示
%cn 提交者(committer)的名字
%ce 提交者的电子邮件地址
%cd 提交日期
%cr 提交日期,按多久以前的方式显示
%s 提交说明
用法:git log --pretty=format:"%h - %an , %ar : %s"
。还要细心注意作者和提交者的区不得不说细节真的到位,也是真的多。
--graph
选项:可以显示ASCII图形表示的分支合并历史。
常用选项和含义:
选项 说明
-p 按补丁格式显示每个更新之间的差异。
--word-diff 按 word diff 格式显示差异。
--stat 显示每次更新的文件修改统计信息。
--shortstat 只显示 --stat 中最后的行数修改添加移除统计。
--name-only 仅在提交信息后显示已修改的文件清单。
--name-status 显示新增、修改、删除的文件清单。
--abbrev-commit 仅显示 SHA-1 的前几个字符,而非所有的 40 个字符。
--relative-date 使用较短的相对时间显示(比如,“2 weeks ago”)。
--graph 显示 ASCII 图形表示的分支合并历史。
--pretty 使用其他格式显示历史提交信息。可用的选项包括 oneline,short,full,fuller 和 format(后跟指定格式)。
--oneline --pretty=oneline --abbrev-commit 的简化用法。
-
限制显示提交次数。--since
,--until
给定时间限制。--author
搜索指定作者,--grep
按关键字搜索。选项 说明
-(n) 仅显示最近的 n 条提交
--since, --after 仅显示指定时间之后的提交。
--until, --before 仅显示指定时间之前的提交。
--author 仅显示指定作者相关的提交。
--committer 仅显示指定提交者相关的提交。
不得不说,使用命令行去显示,查看和搜索记录就不是那么的方便,显得有点繁琐且选项众多,增大了记忆负担。使用图形化的界面查看提交历史可能看起来会更清晰简单一些。使用gitk
或者git-gui
也可以清晰的使用图形界面查看提交信息。这两个好像还不是一个东西,值得研究一下,后续再展开。
git commit --amend
git restore --staged
。执行git status
是有已暂存的文件时提示中便会显示这个命令。或者git reset head
。我的提示前者,可能老版本会提示后者,都能用。git restore
,或者git checkout --
。所以同一个功能为什么有不同命令,版本更新追加的吗?如果放弃本地所有文件修改git checkout .
。git remote
。克隆一个项目后,默认远程仓库名是origin
。如果本地通过git init
创建,则没有远程仓库。
origin
。-v
可以全部列出。git remote add [remote-name] [url]
。此时就可以用这个[remote-name]
指代远程仓库了。git fetch [remote-name]
。将远程仓库所有数据抓取到本地仓库,完成后可在本地访问仓库所有分支。git pull
将会自动抓取远程分支合并到本地仓库中当前分支。完成命令git pull [remote-name] [branch-name]
。git clone
就是自动创建本地master
分支用于追踪远程master
分支。克隆会自动使用master
分支和远程仓库origin
名称。(关于分支,暂时不清楚,后续详细了解。)git push [remote-name] [branch-anme]
。git remote show [remote-name]
。git remote rename [old-remote] [new-remote]
。git remote rm/remove [remote-name]
。打标签:对某一个时间节点上的版本打上标签,比如发布版本时(如V1.0等)。
git tag [-a | -s | -u ] [-f] [-m | -F ] [-e] [ |
。git tag
。或者git tag -l
。git tag -a [tag-name] -m "message"
。轻量标签的话直接使用:git tag [tag-name]
。给特定版本指定标签则最后一个参数指定为该版本(用校验和代表)。git show [tag-name]
。轻量级标签则只会显示打上标签的那个版本的信息,含附注的标签则会显示附注信息。git tag -l
。git tag -d [tag-name]
。git push [remote-name] [branch-name] [tag-name]
推送单个标签,使用--tags
推送所有新增标签。拉取时会将标签拉下来。-d
删除,直接push --tags
没有用。自动补全,安装后应该就有了,Windows上安装Git Bash和Linux安装Git应该是直接就可以使用的。如果需要自定义:看这里。
Git命令别名:
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.unstage 'reset HEAD --'
git config --global alias.last 'log -1 HEAD'
git config --global alias.visual '!gitk' // 外部命令需要加一个!
使用分支可以从主线开发流程中独立出一个开发流程来,然后在不影响主线的同时并行开发。在其他版本控制系统(VCS)中,通常需要创建一个源代码工作目录的完整副本。
但将Git的分支模型称为必杀技也是因为这点将Git和其他VCS家族区分了出来,Git的分支难以置信的轻量。创建可以快速完成,在不同分支间切换也同样可以快速完成。
Git鼓励在工作流程中频繁使用分支与合并,理解分支并熟练运用,将真正改变你开发的方式。(如是说,我很期待)
在了解什么是分支前,先必须回顾Git如何保存数据:Git不保存差异,而是保存一系列文件快照。Git中提交时,会保存一个提交对象,该对象包含一个指向暂存区域快照的指针,并且包含本次提交作者等附属信息,0个或者多个改提交对象的父对象指针:首次提交无祖先,普通提交一个祖先,两个或多个分支合并产生的提交则有多个祖先。
暂存操作会对每一个文件计算SHA-1校验和,然后把当前版本文件快照保存到Git仓库(使用Blob类型对象存储这些快照。是一个文件一个Blob对象吗?),将校验和加入暂存区域。
然后使用git commit
新建一个提交对象前,Git会先计算每一个子目录的校验和,然后将这些目录存储为Git仓库中的树(tree)对象。然后创建的提交对象,除了包含相关提交信息之外,还包含指向这个树对象(这个树对象可能不是根目录吗?如果只更改了一个子目录中的内容。)的指针。有了树对象,就可以重现快照的内容了。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QBeyAsmZ-1661954423289)(https://cdn.jsdelivr.net/gh/HR-1270/ImgHosting/SpringCloud/202208312159057.png)]
做一些修改后再次提交,本地提交对象会包含一个指向上次提交的指针。
现在来看什么是分支(branch),分支本质上就是指向某个提交对象的可变指针。
那么创建分支其实就是创建一个新的指向当前提交对象的指针。也就是说创建一个分支只需要写入一个40字节的SHA-1校验和的成本。这就和其他新建分支需要备份所有项目文件到特定目录的VCS区别开来。
git branch [branch-name] [commit]
。那么Git如何知道当前在那个分支上工作呢?答案是HEAD指针,HEAD指针是指向当前正在工作的本地分支的指针。git branch
只会创建新分支,但并不会自动切换到新分支,
git checkout [branch-name]
。分支操作:
git branch [new-branch-name] [commit]
。git checkout [branch-name]
。git checkout -b [new-branch]
。git merge [branch-name]
。合并时如果当前HEAD指向的版本是要合并的版本的祖先的话,那么就代表要合并的分支是直接在当前版本上做的修改,中间未进行过其他修改,直接将当前分支的指针移动到要合并的提交对象即可,不会有冲突。但如果当前分支有提交,并且有冲突(比如两条线中都修改了同一个文件的同一个位置),逻辑上来说冲突只能由人来解决。Git做了合并,但没有提交,会停下来等待你来解决冲突,此时文件状态是unmerged/未合并。可以使用git mergetool [file]
来编辑文件处理冲突,默认合并工具是vimdiff
(暂时不会用)。
管理分支:
git branch
-d
:删除分支。删除还未合并的分支时会提示错误。-D
则会忽略这个直接删除。--merged
和 --no-merged
筛选已经与当前分支合并的分支与未合并的分支。使用Git可以管理各种工作流程:
长期分支:在master分支只保留最稳定的代码,而在develop平行分支(也可以是多个分不同层次稳定性的分支)中管理后续的开发。等到经过充分测试确保代码稳定之后再逐步合并到master分支上来。
特性分支:在任何规模的项目中都可以使用,指一个短期的用来实现某个单一特性或与其相关工作的分支。比如修复一个紧急问题,添加一个新功能等。等到开发全部完成经过测试之后再将所有提交合并到主干/master上来。
当然目前所述都是本地分支,完全不涉及和服务器的交互。
远程分支(remote branch)就是对远程仓库的分支的索引。他们是一些无法移动的本地分支,在Git进行网络交互时更新。用remote-repo-name/branch-name
这种形式表示远程分支。
一个本地仓库可以有多个远程仓库,一个远程从仓库也可以有多个分支,所有当然可以有多个远程分支。当执行git fetch
时远程分支就会被获取到本地。
git push origin [local-branch-name]:[remote-branch-name]
。master
分支用来跟踪origin/master
,所以git push
和git pull
一开始就可以正常工作。git checkout --track origin/[remote-branch]
git checkout -b [local-branch] origin/[remote-branch]
,本地分支名称不同于要跟踪的远程分支。git push origin :[remote-branch]
,仅仅是把本地分支推送到远程时将本地分支的位置留空。把一个分支的修改整合到另一个分支有两种方法,merge
合并和rebase
衍合(好像也称作变基)。
前面提到过,如果要合并的两个分支沿共同祖先产生了分叉,那么合并时就会产生一个新的提交对象。如果没有分叉,那么就只是单纯的分支指针移动。
还有一种选择就是rebase
,效果就是把C3(要合并的分支experiment
的所有提交对象)的变化在C4(当前master
分支的最后一个提交对象)中打一个补丁(patch),生成一个新的合并提交对象C3’(每一个分支的提交对象打一次补丁在master
生成一个对应提交对象),然后改写expriment
的提交历史,使之成为master
的直接下游。
git rebase master
。执行效果是将当前分支衍合到master
分支的上去。此时再执行合并直接移动master
指针即可完成。衍合操作得到了一个整洁的提交历史,看起来所有修改都是在一条线上顺序进行的,但同样将分支中的提交历史提到了master
中。rebase
之后master
和其他分支的提交历史是完全一致的,分支也就没有了存在的必要。从这个角度来看,这个操作可以在要删除分支的前提下保留提交历史。
一种应用场景:本地分支开发后rebase
到origin/master
再提交,维护者就不需要做任何整合工作。
一看衍合这种操作就能理解这肯定是具有风险的,因为分支的历史被修改了。
在进行衍合的时候,实际上抛弃了一些现存的提交对象而创造了一些类似但不同的新的提交对象。如果你把原来分支中的提交对象发布出去,并且其他人更新下载后在其基础上开展工作,而稍后你又用 git rebase
抛弃这些提交对象,把新的重演后的提交对象发布出去的话,你的合作者就不得不重新合并他们的工作,这样当你再次从他们那里获取内容时,提交历史就会变得一团糟。所以rebase
原则上只应该在本地分支上做,做完之后即删掉本地分支。
如果把衍合当成一种在推送之前清理提交历史的手段,而且仅仅衍合那些尚未公开的提交对象,就没问题。如果衍合那些已经公开的提交对象,并且已经有人基于这些提交对象开展了后续开发工作的话,就会出现叫人沮丧的麻烦。
总结:
rebase
操作把当前分支衍合到目标分支上。也就是说仅修改被衍合分支的提交对象。rebase
仅修改被衍合的分支指针和该分支的提交对象,不修改衍合到的分支的任何对象。多人开发时为了方便,就需要在服务器上创建一个远程的仓库共享给所有人用以拉取和推送自己的工作内容。通常称这个共享的仓库为Git服务器。当然技术上是可以从个人仓库里拉取和推送修改内容,但是这样很容易和本地工作混淆,当然也可以在本地创建仓库作为远程仓库,然后克隆一次之后就不会了。
这一节主要内容是如何架设Git服务器。当然不想自己架设维护服务器的话,选择Github或者Gitee这种代码托管也是完全可以达到同样目的的。
远程仓库通常是一个裸仓库(bare repository),即没有工作目录的仓库,因为我们不需要在这个仓库上直接修改提交。简单来说,就是只包含.git
子目录的内容。
Git可以使用的四种传输协议:本地传输、SSH协议、Git协议、HTTP协议。
本地协议: 远程仓库就在硬盘的另一个目录,需要团队每一个成员都拥有对共享文件系统拥有访问权。
使用方法:
# 克隆一个仓库下来
git clone /git/project.git # 直接复制
git clone file:///git/project.git # 网络传输
# 对现有仓库添加远程仓库
git remote add origin /git/project.git
优点:方便简单,也方便同时获取其他人工作内容。
缺点:难以控制不同位置的访问权限,通过NFS(网络文件系统)不一定是最快的。
SSH协议:唯一一个同时支持读写操作的网络协议(HTTP和Git都是只读的),同时也需要验证授权。
使用:
git clone ssh://user@server/project.git
git clone user@server:project.git
优点:如果要对网络仓库有写权限,ssh协议基本是必须的。架设简单,管理方便。访问安全,所有数据传输都是经过授权和加密的。高效,传输时会压缩数据。
缺点:不能实现匿名访问,所以ssh不利于开源。如果是公司团队开发,ssh已经足够,如果需要开源,那么除了为自己架设ssh协议外,还需要提供匿名访问。
Git协议:这是一个包含在Git软件包里的特殊协议,它会监听一个提供类似于ssh服务的特定端口(9418),而且无需任何授权。如果你的仓库打算支持Git协议,需要先创建 git-daemon-export-ok
文件 — 它是协议进程提供仓库服务的必要条件 — 但除此之外该服务没有任何安全措施。要么所有人都可以克隆Git仓库,要么谁也不能。要开发推送也是可以的,不过没有授权,所以能访问的人都有同样的权限。
优点:现存最快的传输协议,它使用与 SSH 协议相同的数据传输机制,但省去了加密和授权的开销。
缺点:缺少授权,所以不能作为访问Git仓库的唯一方法。一般的做法是,同时提供ssh接口,让开发者拥有推送权限。需要单独的守护进程与端口开放(大型企业级防火墙通常会封锁这个少见的端口)。
HTTP/HTTPS协议:架设便捷,基本上,只需要把 Git 的裸仓库文件放在 HTTP 的根目录下,配置一个特定的 post-update 挂钩(hook)就可以搞定。每个能访问 Git 仓库所在服务器上 web 服务的人都可以进行克隆操作。
搭建:
cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
然后克隆仓库:
git clone http://example.com/gitproject.git
经过HTTP进行推送也是可以实现的,不过不常见太复杂略过。
优点:易于架设,HTTP占用服务器资源少,一般只用静态HTTP服务提供所有数据。HTTP如此常见,以至于企业级防火墙都允许通信。
缺点:客户端效率低,HTTP协议传输体积和网络开销大。
架设之前肯定要导出现有仓库为裸仓库(使用-bare
选项,不包含工作目录),目录名通常以.git
结尾。
git clone --bare my_project my_project.git
其实clone操作相当于git init
+ git fetch
。当然如果从头开始还没有本地仓库的话,直接git init --bare
即可。整体的效果的话大致相当于.git
目录的拷贝:
cp -Rf my_project/.git my_project.git
将裸仓库移动到服务器上:
假设已经有了一个git.example.com的服务器,当然没有解析域名只有IP(局域网或者公网IP)也是可以的,架设服务器的教程网络上汗牛充栋,不赘述;并可以通过ssh访问:
scp -r my_project.git [email protected]:/opt/git # scp是linux下跨机器复制文件的常用命令
简单来说传输到服务器器即可,不一定需要如此传输。现在有了ssh访问权限之后,即可以克隆远程仓库到本地:
git clone [email protected]:/opt/git/my_project.git
如果ssh用户对目录有写权限,那么他现在就可以推送本地的修改了。如果仅有几个人在一个不公开的项目上工作,那么一个ssh服务器与裸仓库便足够了。
权限控制:如果想一部分人只读,一部分人可写,那么使用服务器操作系统的本地文件访问控制机制即可(关于这点,还不是很清楚,Linux也没有那么深入,需要深入了解ssh协议和命令,TODO。)
建立访问权方法:其一,每个人建立一个账户,设定密码。其二,主机上建立一个git账户,每个写权限的人发送一个SSH公钥,然后将其加入git账户的~/.ssh/authorized_keys
文件。这并不会影响提交的数据:访问主机用的身份(git账户)不会影响提交对象的提交者信息(git config user.name/user.email
)。另外,使用其他的SSH授权机制也可以达到相同效果。
大多数 Git 服务器都会选择使用 SSH 公钥来进行授权。系统中的每个用户都必须提供一个公钥用于授权,没有的话就要生成一个。生成公钥的过程在所有操作系统上都差不多。 首先先确认一下是否已经有一个公钥了。SSH 公钥默认储存在账户的主目录下的~/.ssh
目录下的id_rsa.pub
或者id_dsa.pub
文件。有.pub
后缀的是公钥,另一个同名文件是密钥/私钥。
如果还没有或者甚至还没有.ssh
目录,那么可以使用ssh-keygen
命令生成,生成过程中会提示输入密码,如果输入了,则使用这个ssh key推送到远程仓库是需要输入密码,也就是生成过程中指定的那个。否则的话不需要,用户名则是不需要输入。
注册了Github之后,将这个SSH key配置到Github上(Setting -> SSH and GPG keys)之后就可以本地推送到github了。
假设你已经有了一台服务器,还没有的话那就去腾讯云或者阿里云百元一年左右的价格就可以购买一台入门级的VPS,这时候会得到一个公网IP。一般选择Linux操作系统,如Ubuntu/CentOS等,和本地虚拟机、实体机上的装的Linux系统、WSL等操作起来并没有区别。使用XShell,Putty等远程连接工具即可连接使用。当然在做下面所有事情之前你需要确保已经安装git
与openssh-server
。
首先创建名为git
的用户,也就是ssh路径里@
符号前的那个用户名。创建.ssh
目录。
sudo adduser git
su git
cd ~
mkdir .ssh
把要授权的开发者的公钥添加到git
用户的~/.ssh/authorized_keys
文件。公钥看起来是这样的(就是本地用ssh-keygen
生成的id_rsa.pub
文件内容):
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair
逐个添加到文件尾部即可。
创建裸仓库之后本地克隆下来或者添加远程仓库就可以推送修改了。远程:
cd /opt/git # 当然可以在任何有权限可以读写的目录创建
mkdir project.git
cd project.git
git --bare init
本地:(用gitserver
替代主机,实际使用时替换为你的服务器IP)
git clone git@gitserver:/opt/git/project.git
cd myproject
touch Readme.md
git commit -am 'first commit : add Readme.md'
git push origin master
再登录到服务器上git log
即可看到提交记录了。
至此就搭建完毕了,非常快捷与简单。然后再做一些权限配置,使用git
自带的git-shell
工具限制git
用户的活动范围。只要把它设置为git
用户的登录shell,那么该用户就无法使用普通的bash或者其他shell程序。编辑/etc/passwd
文件:
sudo vim /etc/passwd
找到文件末尾类似git:x:1000:1000::/home/git:/bin/sh
这样的行,将其中的bin/sh
改为usr/bin/git-shell
。
现在git
用户只能通过SSH连接来推送和获取Git仓库,而不能直接使用主机Shell。如果ssh git@gitserver
直接进行普通SSH登录则会报错。这样的话就只能通过其他用户远程连接,连接后也不能切换到git
用户来创建仓库。
配置好了ssh协议访问,如果是开源项目,可能还需要你匿名的读取访问。或许对小型的配置来说最简单的方法是运行一个静态Web服务(任何Web服务都可以达到同样的效果:Apache, Nginx, etc.)。将根目录设定为Git仓库所在位置,使用前面提到的post-update
钩子。
首先开启钩子,就是重命名post-update
的样本文件。
cd project.git/hooks
mv post-update.sample post-update
chmod a+x ./post-update
该文件核心内容如下:
exec git-update-server-info
意思是当通过 SSH 向服务器推送时,Git 将运行这个 git-update-server-info
命令来更新匿名 HTTP 访问获取数据时所需要的文件。
把文档根目录设为 Git 项目所在的根目录。然后假定DNS服务已经配置好后,会把.gitserver
请求发送到这台主机。另外需要将仓库所在目录的Unix用户组设置为www-data
,这样web服务才可以读取仓库。
chgrp -R www-data /opt/git
接下来就可以在本地匿名使用HTTP协议访问仓库了:
git clone http://git.gitserver/project.git # http://gitserver/git/project.git 这样可以吗?
当然这需要配置服务器设置。这里省略了,根据具体使用的Web服务器配置方法不同。
另一个提供非授权访问的简单方法是开启一个 Git 守护进程,也就是使用Git协议来匿名访问。
现在已经可以读写或者匿名只读访问了,如果能有一个简单的Web界面访问的话就更好了。
Git自带了一个命令可以做到,使用类似lighttpd
或者webrick
这样轻量级的服务器启动一个临时进程,,可以到项目目录中键入git instaweb
来启动。
如果要用 lighttpd
以外的程序来启动 git instaweb
,可以通过 --httpd
选项指定:
git instaweb -httpd=webrick # 这会在1234端口开一个HTTPD服务
git instaweb -httpd=webrick --stop # 关闭服务时添加--stop选项即可
把用户公钥保存在authorized_keys
中,对团队人数不多时,是比较有效的,当团队达到一定规模,管理起来可能就会非常痛苦。并且这种情况所有用户都会拥有对Git仓库的读写权限,无法更为有效精细的管理。
这时候就需要使用Gitosis了,有趣的是权限的修改并非通过网页设置,而是通过管理一个特殊的Git仓库来实现。
安装Gitosis:
# 依赖
apt install python-setuptools
# 从 Gitosis 项目主页克隆并安装
git clone https://github.com/tv42/gitosis.git
cd gitosis
sudo python setup.py install
# 待补全,暂时没有需求,属于具体应用,需要修改现有的authorized_keys
TODO:后续的Gitolite和Git守护进程(使用Git协议提供匿名访问)暂不涉及。
托管服务列表
当然最广闻人知的必然是世界上最大的程序员交友网站Github。
当然使用就不必多说了,添加SSH Key,创建仓库,克隆或者添加远程仓库,提交。和Git服务器并无二致,也不需要操心去配置Git服务器。
前面已经有了基本的本地工作流程。但是作为项目贡献者时,怎样做才能方便维护者采纳更新,作为项目维护者,又怎么样有效管理大量贡献者的提交呢?
Git与传统的集中式版本控制系统(CVCS)不同,因为是分布式的,所以开发者可以互相分享自己的代码,流程多样灵活。
集中常见的工作流程:
集中式工作流:单点协作模型,一个存放代码仓库的中心服务器,可以接受所有开发者提交代码。所有开发者都是普通节点,作为仓库的消费者,平时工作就是和中心仓库同步数据。
那么当两个人同时修改了同一个地方,就有可能产生冲突,第二个提交的人就需要在推送之前先拉取数据解决冲突。团队不大的话完全可以采用这种工作流程,使用也非常广泛。
集成管理员工作流:由于Git允许使用多个远程仓库,开发者可以建立自己的公共仓库,将数据共享给其他人。这种情况通常有一个代表官方发布的项目仓库(blessed repository),开发者由此仓库克隆自己的公共仓库(developer public),推送自己的提交。维护者有自己本地的克隆仓库,将所有公共仓库作为远程仓库添加进来,测试无误后合并到主干,再推送到官方仓库。
GitHub网站上多采用这种工作流,要贡献代码时先fork项目到自己的列表,成为自己的公共仓库,然后更新提交之后,然后提起Pull Request,等待维护者接受你的贡献。这种工作方式下你可以按照你自己的节奏工作,不必等待维护者处理你的更新,维护者也可以按照自己的节奏,任何时候都可以来处理别人贡献的代码。
司令官与副官工作流:一般超大型项目才会采用,比如Linux内核。各个集成管理员分别负责集中项目中的特定部分,称为副官(lieutenant)。这些集成管理员上方还有负责统筹的总集成管理员,成为司令官(dictator),维护仓库以提供所有协作者拉取最新集成的项目代码。
这种分而治之的项目管理职责也清晰,不易出错,项目极为庞杂或者需要多级别管理时才会体现出优势。
除了这些工作流,实际工作中为了满足各式各样的需求,会需要各种不同的工作方式。
那作为项目贡献者,又有那些常见的工作模式呢?
Git如此灵活,人们的协作方式也可以各种各样,没有固定不变的范式可循。具体到个人,项目所选的工作流程,参与者规模,提交权限等都会影响具体操作的细节。
比如说影响较大的团队规模,如果几百个人工作的仓库,每天可能有几十上百个提交,那么你的提交可能会由于其他人的更新而变得过时甚至无法运行偏离原有逻辑。那么如何确保代码最新,且每次提交后逻辑正确无误呢?几个人的小团队就不需要为这种问题烦恼。
提交指南:代码提交需要规范以方便管理,项目管理时应该需要制定提交规范,不一而足。列举一些常见的点:
可以看一看Git本身的项目提交:git log --no-merges
。
是时候把Git克隆下来了:git clone git://git.kernel.org/pub/scm/git/git.git
,仓库共140MB左右,没有我想象中那么大。TODO:后续有时间回滚并读一下源码。
私有小型团队:仅在一台服务器上提交的话其实与使用SVN等CVCS工作流并无太大差别。但还是有一些区别,比如如果你当前版本不是最新,那么需要先git fetch origin
之后合并到本地(git merge origin/master
)之后再提交,而SVN提交后会自动在服务器进行合并。有冲突的的话需要先解决再提交。最后的本地的仓库历史类似于:
当然也可以rebase
,那就成一条直线了。
最简单的协作方式之一:在自己的特性分支中工作一段时间,完成后合并到自己的master
分支,或者直接在master
中修改提交,拉取并合并origin/master
的更新,再推向远程服务。最后的提交一般都是分叉的而不是线性的(不同于SVN上在同一个分支上提交时完全线性的提交历史)。
私有团队间协作:几个小组分别负责若干特性开发和集成时,每个特性签出一个分支,项目组成员在分支上工作,并把工作推送到服务器,然后项目组管理员负责在项目完成后集成到master
分支并提交到远程。看起来是很清晰的,只是如果同时在多个项目间工作时,因为都在一个本地,千万要记住自己当前工作的分支,不要提交错了。
推送本地分支提交到追踪的远程分支:git push origin [local-branch]:[remote-branch]
。
公开项目:如果不是项目的直接维护者,只是想贡献一些代码,没有直接推送到主仓库的权限,那么就需要把工作成果提交给项目维护人。当然在Github中使用 fork + PR 的方式解决这个问题。另外也可以通过电子邮件发送补丁完成提交。
具体流程:
git push myfork featureA
。这样如果项目维护者未采纳贡献,也不需要回退自己的master
,因为你的提交还在远程分支上。master
与origin/master
同步,签出新分支继续开始工作。这样的做法方便又灵活,采纳和丢弃都轻而易举。多个特性的开发修改互不干扰,不用担心特性代码交叉混杂。
如果开发期间管理员接受了其他人的提交,导致合并无法正确干净地完成,那么你需要将特性分支衍合到最新的origin/master
,解决冲突后,重新提交发起PR。或者在PR前都选择先衍合到最新的origin/master
?
也可以将git request-pull origin/master myfork
的结果发送给管理员以通知采纳。
公开的大型项目:许多大型项目都会立有一套自己的接受补丁流程,你应该注意下其中细节。但多数项目都允许通过开发者邮件列表接受补丁。
工作流程类似于:为每个补丁创建独立的特性分支,而不同之处在于如何提交这些补丁。不需要创建自己可写的公共仓库,也不用将自己的更新推送到自己的服务器,你只需将每次提交的差异内容以电子邮件的方式依次发送到邮件列表中即可。
git format-patch
生成mbox格式的文件作为附件发送给管理员。git send-email
来发送补丁。这些内容具体现在并无太大作用,具体贡献时按照项目约定的流程来即可。不了解也没有做过,不展开说,总结要点:
git apply
或者git am
采纳别人的补丁。master
稳定分支确保发布代码的稳定与develop
开发分支来接受其他人代码。