Git on 七三的小站

使用 Docker Compose 安装 Gitea

Fri, 21 Mar 2025 00:00:00 +0800

Gitea 是一个轻量级的 DevOps 平台软件。从开发计划到产品成型的整个软件生命周期，他都能够高效而轻松的帮助团队和开发者。包括 Git 托管、代码审查、团队协作、软件包注册和 CI/CD。

项目网址：https://github.com/go-gitea/gitea
官方文档： https://docs.gitea.com/zh-cn/

1. 镜像选择

Gitea 提供的镜像包括 标准 和 rootless 。

rootless 镜像使用 Gitea 内部 SSH 功能来提供 Git 协议，不支持 OpenSSH，不需要 root 权限。

项目	标准镜像	rootless 镜像
执行用户	root	非 root
ssh 端口	22	2222
git 用户与组	任意（由配置文件中指定）	1000:1000
openssh	支持	不支持
AppPath	/usr/local/bin/gitea	/usr/local/bin/gitea
WorkPath	/data/gitea	/var/lib/gitea
CustomPath	/data/gitea	/var/lib/gitea/custom
ConfigFile	/data/gitea/conf/app.ini	/etc/gitea/app.ini

2. 安装部署

2.1. 使用 `rootless` 镜像

2.1.1. 创建工作目录

docker 自动创建的目录是root 权限，因此需要手动创建目录，以确保权限一致。

rootless 镜像内的git 用户与组的id是1000:1000 ，所以建议主机也使用1000:1000 。

当然了，不一致也没关系，但需要通过user: xxxx:xxxx 指定具体值。

mkdir data config
sudo chown 1000:1000 data config

2.1.2. 创建配置文件

特别注意：data config 文件夹应由user: xxxx:xxxx指定的用户所有，以确保主机能够正常访问这两个文件夹。

services:
  server:
    image: gitea/gitea:1.21-rootless
    container_name: gitea
    hostname: gitea
    restart: always
    user: 1000:1000
    volumes:
      - ./data:/var/lib/gitea
      - ./config:/etc/gitea
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "0.0.0.0:3000:3000"
      - "0.0.0.0:2222:2222"

2.1.3. 启动运行

注意：如果在 HTTP 上使用的是非 3000 端口，请将 app.ini 更改为匹配 LOCAL_ROOT_URL = http://localhost:3000/。

docker compose up -d
docker compose logs -f

2.2. 使用 `标准` 镜像

2.2.1. 创建工作目录

docker 自动创建的目录是root 权限，因此要手动创建目录。

与 rootless 镜像不同，标准镜像内的 git 用户id可以通过环境变量指定，自由度更高。

mkdir data
chown 1000:1000 data

2.2.2. 创建配置文件

注意事项：

data 文件夹应由 environment 指定的用户所有。
只需挂载一个路径 /data ，相比rootless 更简单
支持 openssh 标准 22 端口
特别注意：生成的 ssh 文件夹是 root 权限的，因此主机要有 root 权限。

services:
  server:
    image: gitea/gitea:latest
    container_name: gitea
    hostname: gitea
    restart: always
    environment:
    # - GITEA___server__PROTOCOL=http
    # - GITEA___server__DOMAIN=code.wangyan.cloud/
    # - GITEA___server__ROOT_URL=https://code.wangyan.cloud/
    # - GITEA___server__HTTP_ADDR=0.0.0.0
    # - GITEA___server__HTTP_PORT=3000
    # - GITEA___server__SSH_DOMAIN=wangyan.cloud/
    # - GITEA___server__SSH_PORT=22
    # - GITEA___server__LFS_START_SERVER=true
    # - GITEA__database__DB_TYPE=mysql
    # - GITEA__database__HOST=127.0.0.1:3306
    # - GITEA__database__NAME=gitea
    # - GITEA__database__USER=gitea
    # - GITEA__database__PASSWD=123456
    # - GITEA__mailer__ENABLED=true
    # - GITEA__mailer__PROTOCOL=smtp+starttls
    # - GITEA__mailer__SMTP_ADDR=smtp-mail.outlook.com
    # - GITEA__mailer__SMTP_PORT=587
    # - GITEA__mailer__FROM="No-Reply" <no-reply@outlook.com>
    # - GITEA__mailer__USER=no-reply@outlook.com
    # - GITEA__mailer__PASSWD=123456
      - USER_UID=1000
      - USER_GID=1000
    volumes:
      - ./data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "0.0.0.0:3000:3000"
      - "0.0.0.0:2222:22"

2.2.3. 启动运行

docker compose up -d
docker compose logs -f

3. SSH 容器直通

由于 SSH 在容器内运行，如果需要 SSH 支持，则需要将 SSH 从主机传递到容器。

3.1. 创建 `git` 用户

这里的git 用户用于ssh 容器透传。如果不需要 git clone git@host:username 功能，可以忽略。

# uid 和 gid 也可以随机不指定。
sudo groupadd -g 1100 git && \
sudo useradd -c "Git Version Control" -m -d /home/git -s /bin/bash -u 1100 -g 1100 git

# 将用户添加到docker用户组
sudo usermod -aG docker git

3.2. 方法一：使用 AuthorizedKeysCommand

该方法最大优点是：通过 AuthorizedKeysCommand 进入容器获取git用户的 authorized_keys，不需要挂载主机的 .ssh 目录到容器。

客户端执行 git clone 命令后，会进入容器执行 gitea keys 命令，返回用户的 authorized_keys 公钥信息完成认证，该信息是带有 command="/usr/local/bin/gitea 路径的，与容器上 Gitea 二进制文件的位置匹配。
通过验证后，主机 SSH 服务器为git用户建立会话，并使用主机git用户的 shell 执行后续命令。

3.2.1. Docker 获取 authorized_keys（推荐）

主机使用 docker exec 方式进入容器获取 authorized_keys。

# gitea 是容器名称，请根据实际修改。
# 标准镜像需要加 "-u git" 指定用户，root 身份运行 docker exec 会报错。
cat <<"EOF" | sudo tee -a /etc/ssh/sshd_config
Match User git
  AuthorizedKeysCommandUser git
  AuthorizedKeysCommand /usr/bin/docker exec -i -u git gitea /usr/local/bin/gitea keys -e git -u %u -t %t -k %k
EOF

sudo systemctl restart sshd

3.2.2. SSH 获取 authorized_keys（二选一）

与docker shell 基本一样，不同地方在于没有使用 docker exec 进入容器，而是通过 ssh git@127.0.0.1 进入容器。

此方法需要将容器的 22 端口映射到主机，比如映射为 2222，并且主机git用户要创建一个密钥对，并提前将公钥添加到容器的 /data/git/.ssh/authorized_keys 目录。

cat <<"EOF" | sudo tee -a /etc/ssh/sshd_config
Match User git
  AuthorizedKeysCommandUser git
  AuthorizedKeysCommand /usr/bin/ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 /usr/local/bin/gitea keys -e git -u %u -t %t -k %k
EOF

sudo systemctl restart sshd

3.3. 方法二：共享 authorized_keys

此方法是通过与容器共享 authorized_keys文件的方式来进行用于认证，用于带有 openssh 的标准镜像。

为了使转发正常工作，需要将容器的 SSH 端口（22）映射到主机端口 2222。

#docker-compose.yml
ports:
  - "127.0.0.1:2222:22"

接下来要使容器git用户的uid 和 gid 与主机上的git用户一致。

#docker-compose.yml
environment:
  - USER_UID=1000
  - USER_GID=1000

然后，创建主机与容器互联的密钥。

# 生成 authorized_keys 文件
sudo -u git mkdir /home/git/.ssh/
sudo -u git ssh-keygen -f "/home/git/.ssh/idrsa" -t rsa -b 4096 -C "Gitea Host Key"
sudo -u git echo "$(cat /home/git/.ssh/idrsa.pub)" >> /home/git/.ssh/authorized_keys
sudo -u git chmod 600 /home/git/.ssh/authorized_keys

接下来将主机/home/git/.ssh挂载到容器中。这可确保authorized_keys文件在主机用户和容器之间共享。

volumes:
  - /home/git/.ssh/:/data/git/.ssh

通过 Gitea 界面添加的所有用户公钥都将有前缀 command="/usr [...]。

/home/git/.ssh/authorized_keys内容如下：

# SSH pubkey from git user
ssh-rsa <Gitea Host Key>

# other keys from users
command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-1"...

因此，当客户端执行 git clone 命令时会执行 /usr/local/bin/gitea 文件。

3.4. 转发主机命令到容器

3.4.1. 方法1：shell 方式（推荐）

为了能够在容器内执行命令，我们还需要修改git 用户的默认shell

# gitea 是容器名称，请根据实际修改。
cat <<"EOF" | sudo tee /home/git/docker-shell
#!/bin/sh
/usr/bin/docker exec -i -u git --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh "$@"
EOF

sudo chmod +x /home/git/docker-shell
sudo usermod -s /home/git/docker-shell git

当然，也可以使用下面SSH方式执行。（二选一）

cat <<"EOF" | sudo tee /home/git/ssh-shell
#!/bin/sh
ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $@"
EOF

sudo chmod +x /home/git/ssh-shell
sudo usermod -s /home/git/ssh-shell git

3.4.2. 方法2：Shim 方式

在主机创建虚假gitea可执行文件，该文件将把命令从主机转发到容器。

# gitea 是容器名称，请根据实际修改。
# 与 shell 相比多了 $0
cat <<'EOF' | sudo tee /usr/local/bin/gitea
#!/bin/sh
/usr/bin/docker exec -i -u git --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh $0 "$@"
EOF
sudo chmod +x /usr/local/bin/gitea

当然，也可以使用下面SSH方式执行。（二选一）

cat <<"EOF" | sudo tee /usr/local/bin/gitea
#!/bin/sh
ssh -p 2222 -o StrictHostKeyChecking=no git@127.0.0.1 "SSH_ORIGINAL_COMMAND=\"$SSH_ORIGINAL_COMMAND\" $0 $@"
EOF
sudo chmod +x /usr/local/bin/gitea

4. Gitea Actions

4.1. Act Runner

4.1.1. 使用二进制文件

# 下载
wget https://gitea.com/gitea/act_runner/releases/download/v0.2.7/act_runner-0.2.7-linux-amd64
mv act_runner-0.2.7-linux-amd64 gitea-runner
chmod +x gitea-runner
./gitea-runner --version

# 导出默认配置文件
./gitea-runner generate-config > config.yaml

# 注册
# ./gitea-runner --config config.yaml register
./gitea-runner register \
 --no-interactive \
 --instance https://codes.wangyan.cloud/ \
 --token xx \
 --name gitea-runner

4.1.2. 使用 Docker 镜像

导出配置文件

sudo docker pull gitea/act_runner:latest
sudo docker run --entrypoint="" --rm -it gitea/act_runner:latest act_runner generate-config > config.yaml

配置 Cache

#vim config.yaml
cache:
enabled: true
dir: ""
# 使用步骤 1. 获取的 LAN IP
host: "192.168.8.17"
# 使用步骤 2. 获取的端口号
port: 3030

运行

#vim docker-compose.yml
version: "3.8"
  services:
    runner:
    image: gitea/act_runner:nightly
    environment:
    CONFIG_FILE: /config.yaml
    GITEA_INSTANCE_URL: "http://119.29.17.197:3000"
    GITEA_RUNNER_REGISTRATION_TOKEN: "xx"
    GITEA_RUNNER_NAME: "gitea-runner"
    volumes:
    - ./config.yaml:/config.yaml
    - ./data:/data
    - /var/run/docker.sock:/var/run/docker.sock
    ports:
    - "3030:3030"

4.2. Actions Demo

vim .gitea/workflows/demo.yaml

name: Gitea Actions Demo
run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀
on: [push]
  
jobs:
 Explore-Gitea-Actions:
 runs-on: ubuntu-latest
 steps:
 - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event."
 - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!"
 - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
 - name: Check out repository code
 uses: actions/checkout@v3
 - run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner."
 - run: echo "🖥️ The workflow is now ready to test your code on the runner."
 - name: List files in the repository
 run: |
 ls ${{ gitea.workspace }}
 - run: echo "🍏 This job's status is ${{ job.status }}."

参考文档：

Git 分布式工作流程

Tue, 20 Mar 2012 00:00:00 +0800

一、概述

1.1、集中式工作流

一个存放代码仓库的中心服务器，接受所有开发者提交的代码，而后提交者，必须先下载合并服务器上的数据，解决冲突之后才能推送数据到共享服务器上。

SVN和GIT都可以使用该工作流，优点是简单高效，只需给每个人推送数据的权限，就可以开展工作了。

图5-1：集中式工作流

1.2、集成管理员工作流

这是 GitHub 上最常见工作流，首先克隆（Fork）某个项目，成为自己的公共仓库，然后按照自己的节奏开发，最后用Pull 工具告知管理员接纳你的贡献。

贡献者从官方项目仓库（blessed repository），克隆出各自的私有仓库（developer private）。
贡献者修改代码后，推送数据到自己的公共仓库（developer public）。
贡献者给维护者发送邮件，请求拉取自己的最新修订。
维护者在自己本地仓库（integration manger）中，将贡献者的仓库加为远程仓库，合并更新并做测试。
维护者将合并后的更新推送到主仓库（blessed repository）。

图5-2：集成管理员工作流

1.3、司令官与副官工作流

与集成管理员工作流类似，区别是多了一个副官（lieutenant）的角色，他们负责集成项目中的特定部分。这种多级别管理方式一般适用于大项目，如linux项目。

图5-3：司令官与副官工作流

二、为项目作贡献

2.1、提交指南

#请不要在更新中提交多余的白字符（whitespace）
git diff --check，

#请将每次提交限定于完成一次逻辑功能。
git　add --patch

#请谨记撰写友好的提交说明。
#首行简明扼要，另起空行后，再进一步补充说明。
git commit

2.2 私有的小型团队

私有，是指源代码不公开，他人无法访问项目仓库，但你和其他开发者则都具有推送数据到仓库的权限。

私有的小型团队，一般采用集中式工作流

1、A和B分别克隆了远程仓库并提交了更新

git clone jessica@githost:simplegit.git
git commit -am 'xxxx'

2、A推送了项目至远程仓库

git push origin master

3、B不能直接推送了，首先需要fetch，然后合并到本地，最后再推送。

git fetch origin　#首先下载了A推送到服务器的最近更新
git merge origin/master #然后将提交历史合并到本地
git push origin master #最后B也推送到远程

2.3、私有团队间协作

成员：John Jessica Josie 分工：John负责featureA、Josie负责featureB、Jessica参与A和B。

#Jessica
$ git clone (url) #从服务器克隆仓库
$ git checkout -b featureA #在本地开发A分支
$ vim lib/simplegit.rb
$ git commit -am 'xxxx' #图6-1(3309)
$ git push origin featureA #推送A分支到服务器A分支(Jessica无权推到主分支)

Jessica 发邮件给John(在github中使用Pull 工具)，在等待他的反馈之前，Jessica 决定和Josie一起开发featureB

#Jessica
$ git fetch origin #更新，包括远程featureB分支。
$ git checkout -b featureB origin/master　#从远程主分支创建一个本地跟踪分支featureB
$ vim lib/simplegit.rb
$ git commit -am 'add ls-files' ##图6-1(85127)

图6-1：Jessica 的更新历史

Jessica正准备将featureB分支推的服务器，但是Josie已抢先推送了featureBee，所以应先更新、合并，然后再推送本地featureB到远程featureBee

#Jessica
$ git fetch origin #图6-2(fba9a)
$ git merge origin/featureBee  #图6-2(cd685)
$ git push origin featureB:featureBee #图6-2(cd685)

收到了John的邮件，他对远程featureA分支已做修改，请过目。

#Jessica
$ git fetch origin #下载最新数据
$ git log origin/featureA ^featureA #查看更新了哪些内容
$ git checkout featureA  #切换到本地featureA分支
$ git merge origin/featureA #图6-2(aad88)，把John的修改合并到自己的featureA分支中：
$ git commit -am 'small tweak' #图6-2(774b3)
$ git push origin featureA #推送到远程featureA分支

图6-2：Jessica 的更新历史

最后通知集成管理员将featureA 及featureBee分支并入主线。#图6-3(5399e)

图6-3：管理员合并A、B分支后的历史

2.4、公开的小型项目

与私有项目不同，公开项目没有直接更新主仓库分支的权限。

$ git clone (url) #克隆原始仓库
$ cd project
$ git checkout -b featureA #创建特性分支开展工作
$ (work)
$ git commit

首先，点击"Fork"按钮，创建一个自己可写的公共仓库。然后，将此仓库添加为本地的第二个远端仓库，命名为myfork 接着，再把featureA 整个分支推到myfork仓库。最后，直接用GitHub提供的pull request工具通知项目管理员。

$ git remote add myfork (url)
$ git push myfork featureA

附：手工发送请求通知

#参数一：是原始分支
#参数二：是请求对方来抓取的Git仓库。
$ git request-pull origin/master myfork

建议：随时保持自己的master 分支和官方origin/master 同步，并将自己的工作限制在特性分支上，好处是既方便又灵活，采纳和丢弃都轻而易举。

比如现在要开始第二项特性的开发

$ git checkout -b featureB origin/master
$ (work)
$ git commit
$ git push myfork featureB
$ (email maintainer)
$ git fetch origin

图7-1：featureB 以后的提交历史

假设一：因为代码基准不一致，管理员无法采纳你提交的第一个分支。方案一：首先要衍合最新origin/master，解决相关冲突，然后重新提交你的修改

$ git checkout featureA
$ git rebase origin/master
$ git push -f myfork featureA #必须使用-f强制推送

图7-2：featureA 重新衍合后的提交历史

假设二：管理员有意采纳第二个分支后，但还需要做些修改。方案二：首先以origin/master为基准，新建特性分支featureBv2，然后合并featureB分支，最后修改提交。

$ git checkout -b featureBv2 origin/master
# --squash 选项将目标分支上的所有更改全拿来应用到当前分支上
# --nocommit 选项告诉Git 此时无需自动生成和记录（合并）提交
$ git merge --no-commit --squash featureB
$ (change implementation)
$ git commit
$ git push myfork featureBv2

图7-3：featureBv2 之后的提交历史

2.5、公开的大型项目

工作流程与上面类似，区别在于提交补丁不需要创建自己可写的公共仓库，只需将每次提交的差异内容以电子邮件的方式依次发送到邮件列表中即可。

# format-patch 命令依次创建补丁文件，并输出文件名
# -M 选项允许Git 检查是否有对文件重命名的提交。
$ git format-patch -M origin/master

编辑 ~/.gitconfig 文件，配置imap选项

[imap]
folder = "[Gmail]/Drafts"
host = imaps://imap.gmail.com
user = user@gmail.com
pass = p4ssw0rd
port = 993
sslverify = false

$ git send-email *.patch　#发送补丁到邮件列表

Git 使用指南

Sun, 19 Feb 2012 00:00:00 +0800

Git 是一个分布式版本控制系统，可以记录文件变化，以便在需要时退回过去某个时间点的状态，它与SVN最大不同在于，GIT是直接快照，而非比较差异，因此它拥有许多令人兴奋的特性，如简便的分支管理、高效率的分布式控制等等。

本文是《Pro Git》阅读笔记整理，重点介绍 Git基础使用、Git分支管理、Git分布式工作流程。

一、Git 基础要点

1.1、直接快照非比较差异

Git 只关心文件数据的整体是否发生变化，而SVN关心的是文件内容具体差异。

1.2、三种文件状态

已提交（committed ），已修改（modified ）和已暂存（ staged ）。

1.3、典型工作流程

新文件–已暂存–已提交–已修改–已暂存–已提交 …

二、Git 安装与初始化

2.1、安装方法

apt-get -y install git-core git-gui
yum -y install git git-gui

Mac: http://code.google.com/p/git-osx-installer
Windowns: http://code.google.com/p/msysgit

2.2、git 中文本地化

#获取中文本地化文件
curl -L https://github.com/gotgit/git-po-zh_CN/raw/maint-zh-cn/po/zh_CN.po > zh_CN.po

#将zh_CN.po文件复制到Git源码的po目录
cp zh_CN.po path/to/git/po/

#编译及安装 git，然后就可以让Git说中文了。
cd path/to/git/
make all && sudo make install

2.3、全局配置

/etc/gitconfig ：系统中对所有用户都适用的配置文件，使用–system选项。
~/.gitconfig ：用户目录下的配置文件只适用于该用户，使用–global选项。
.git/config ：当前项目的.git目录中的配置文件，仅针对当前项目有效。

git config --global user.name "WangYan"
git config --global user.email "WangYan@example.com"
git config --global core.editor vim
git config --global merge.tool vimdiff

2.4、密钥配置

首先生成密钥对，然后上传.pub后缀的公钥，到github这类托管平台。

mkdir ~/.ssh && cd ~/.ssh
ssh-keygen -t rsa -C "WangYan@example.com" -N '' #生成密钥对

测试密钥是否有效，并提示密钥所属用户ID或所属版本库ID

ssh -T git@github.com

2.5、自动完成

#wget http://www.wangyan.cloud/download/conf/.git-completion.bash
cp contrib/completion/git-completion.bash ~/.git-completion.bash
cat >>~/.bashrc<<EOF
source ~/.git-completion.bash
EOF

2.6、命令别名

git config --global alias.ci commit #实例1：ci 提交
git config --global alias.last 'log -1 HEAD' #实例2：查询最新版本
git config --global alias.visual "!gitk" #实例3：运行外部命令

三、Git 基础使用

3.1、常规操作

3.1.1、创建Git项目

git init #从当前目录初始化
git clone git://gist.github.com/xx.git #从现有仓库克隆

3.1.2、检查当前文件状态

git status

Untracked files：表示未跟踪文件。（新文件）
Changes to be committed：表示已暂存，但未提交。（已git add，但未提交）
Changed but not updated：已修改，但未暂存（文件已修改，未git add暂存）

3.1.3、跟踪新文件

git add file1.txt（文件或目录的路径，目录则递归处理）
git add .（跟踪所在目录下的所有文件及子目录）

3.1.4、忽略某些文件不跟踪

cat >.gitignore<<-EOF
# 忽略注释
*.a 忽略所有.a 结尾的文件
*.[oa] 忽略所有以.o 或.a 结尾的文件
!lib.a 忽略除lib.a 外的文件
/TODO 忽略根目录下的TODO 文件
build/ 忽略build/ 目录下的所有文件
doc/*.txt 忽略doc/notes.txt
EOF

3.1.5、暂存已修改文件

注：git add 既可以跟踪新文件，也可以暂存已修改文件。

git add .

3.1.6、查看已暂存和未暂存差异

git diff：查看未暂存和已暂存文件间的差异。
git diff --cached 查看已暂存和上次提交时的差异

3.1.7、删除/移动已跟踪文件

git rm file.txt
git rm -f file.txt 强制删除，适用于已修改且已暂存。
git rm --cached file.txt 从跟踪清单中删除，但不实际删除文件。
git rm *~ 删除当前目录下所有~结尾的文件。
git rm \*~ 递归删除当前目录及子目录下所有~结尾的文件。

git mv file1 file2 #移动文件

3.1.8、提交更新

git commit
git commit -m "Story 1: Fix some bugs"

跳过暂存直接提交

git commit -a -m "Story 2: Fix some bugs"

3.1.9、查看提交历史

git log 按提交时间列出所有的更新，最近的更新排在最上面。

-p 展开显示每次提交的内容差异。-n 仅显示最近的n 条提交。--stat 仅显示简要的增改行数统计。--author 仅显示指定作者相关的提交。--committer 仅显示指定提交者相关的提交。--grep 搜索提交说明中的关键字。--all-match 同时满足指定的选项。

git log --since=2.weeks
git log --since="2008-10-01" --before="2008-11-01"

--since, --after 仅显示指定时间之后的提交。--until, --before 仅显示指定时间之前的提交。

3.1.10、查看版本细节

git show xx 查看项目特定版本更新细节
git show HEAD 显示当前分支的最新版本的更新细节

git show HEAD^ 查看HEAD 的父版本更新细节
git show HEAD^^ 查看HEAD 的祖父版本更新细节
git show HEAD~4 查看HEAD 的祖父之祖父的版本更新细节

3.2、撤销操作

3.2.1、修改最后一次提交

git commit --amend

注：若文件状态没变化，则修改提交说明，否则修正并覆盖上次提交。

3.2.2、取消已经暂存的文件

git reset HEAD filename

3.2.3、取消对文件的修改

git checkout -- filename

3.3、远程仓库的使用

3.3.1、查看项目的远程库

git remote -v （-v 选项显示对应远程库地址）
实例：origin git://github.com/schacon/ticgit.git

3.3.2、添加远程仓库

git remote add [shortname] [url]
实例：git remote add pb git://github.com/paulboone/ticgit.git

3.3.3、从远程仓库抓取数据

从指定远程仓库中拉取所有本地仓库没有的数据。

git fetch [remote-name]

注意事项：

如果是克隆了一个仓库，此命令会自动将远程仓库归于 origin 名下。
fetch 命令只拉取数据，不会自动合并到当前工作分支。
git clone 本质是创建本地 master 分支，并用于跟踪远程仓库中的 master 分支。

3.3.4、推送数据到远程仓库

git push [remote-name] [branch-name]
实例：git push origin master

注：克隆操作会自动使用默认的master仓库和origin分支名称

3.3.5、查看远程仓库信息

git remote show [remote-name]

1）New remote branches 哪些远端分支还没有同步到本地

2）Local branch pushed with ‘git push’ 运行git push 时缺省推送的分支

3）Stale tracking branches 已同步到本地的远端分支在远端服务器上已被删除。

3.3.6、远程仓库的删除和重命名

git remote rename [remote-name] [new-remote-name] #重命名
git remote rm [remote-name] #删除

3.4、本地标签管理

3.4.1、显示已有的标签

git tag #按字母顺序显示
git tag -l 'v1.4.2.*' #显示特定标签

3.4.2、新建标签

git tag v1.4  #轻量级的标签 
git tag -a v1.4 -m 'my version 1.4' #含附注的标签

3.4.3、后期加注标签

git tag -a v1.2 9fceb02

3.4.4、签署验证标签

git  -s v1.5 -m 'my signed 1.5 tag'　#签署标签
git tag -v [tag-name] #验证标签
git show [tag-name] #查看相应标签的版本信息

3.4.5、推送标签至远程仓库

git push origin [tagname] #推送某个标签
git push origin --tags #推送所有标签

3.4.6、删除标签

git tag -d v1.0.0 #删除本地标签
git push origin :refs/tags/v1.0.0 #删除远程标签

四、GIt 分支管理

4.1、新建本地分支

git branch testing #创建testing分支
git checkout testing #切换至testing分支
git checkout -b iss53 #创建并切换至iss53分支。

4.2、合并本地分支

git checkout master  #首先切换到主分支
git merge hotfix #测试完毕后，合并hotfix分支
git branch -d hotfix #删除已合并的hotfix分支

4.3、解决合并冲突

git status #合并失败的文件以"unmerged"标出
git add . #标记冲突已解决，并暂存文件
git mergetool #Git默认图形化冲突解决工具

4.4、合并远程分支

origin/master #格式：远程仓库/分支名
git merge origin/serverfix #合并远程分支serverfix到当前分支

4.5、删除远程分支

#git push [远程仓库名] :[远程分支]
#注意区别：git push [远程名] [本地分支]:[远程分支]
git push origin :serverfix　#删除远程分支

4.6、创建跟踪分支

方法一：

git checkout -b [分支名] [远程名]/[分支名]
git checkout -b serverfix origin/serverfix

方法二：（适用1.6.2以上版本Git）

git checkout --track [远程名]/[分支名] 
git checkout --track origin/serverfix

4.7、查看分支

git branch #列出所有分支，星号"*"表示当前所在分支。
git branch -v #查看各分支最后一次提交信息

#查看已和当前分支合并的分支
#可用git branch -d 删掉未标星号的分支，因为已经合并了。
git branch --merged 

#查看未和当前分支合并的分支
#强制删除未合并的分支git branch -D
git branch --no-merged

4.8、衍合所在分支

git checkout experiment #切换到需要衍合的分支
git rebase master #衍合experiment分支到主分支

图解Git的分支管理

Sun, 19 Feb 2012 00:00:00 +0800

一、Git 分支本质

1.1、首次提交后，各对象间关系

生成blob类型对象，它存储着当前文件状态的快照。（暂存操作）
生成tree对象，该对象中的每个文件，包含着指向blob对象的索引。（提交）
创建commit对象，它包含指向tree对象的索引和其他元数据。（提交操作）

图1-1：Git仓库各对象间关系

1.2、多次提交后，提交对象间关系

修改后再次提交，那么这次的提交对象会包含一个指向上次提交对象的指针。

图1-2：多次提交后，提交对象间的关系

1.3、本地master主分支

Git分支本质：是一个指向commit 对象的可变指针，例如master为默认分支名称。

图1-3：指向提交历史的master分支

1.4、创建新分支

创建新分支本质：是创建一个指向当前commit对象的指针。

git branch testing #创建testing分支

图1-4：指向同一提交历史的多个分支(master、testing)

1.5、当前分支

HEAD 指针指向当前分支，默认指向 master 分支。

图1-5：HEAD 指向当前所在的分支

1.6、切换分支

checkout 切换至 testing 分支，于是 HEAD 指针也指向了testing分支。（图1-6-1）

git checkout testing #切换至testing分支

图1-6-1：HEAD 指向了testing分支

修改后再提交，HEAD 依然随着testing分支一起向前移动（图1-6-2）

vim test.rb
git commit -a -m 'made a change'

图1-6-2：每次提交后HEAD 随着分支一起向前移动

返回原来的master主分支继续工作。（图1-6-3）

git checkout master

图1-6-3：返回原来的master主分支

当在主分支中修改提交后，分叉出"87ab2"的提交对象，但不会干扰到testing分支。（图1-6-4）

vim test.rb
git commit -a -m 'made other changes'

图1-6-4：分叉了的分支历史

二、分支工作流程

开发某个项目 (master主分支，生产服务器)
为该项目增加某个新需求 (iss53分支)
已上线项目需要修补，于是为本次修补建立新分支(hotfix分支)
合并补丁（hotfix分支）到master分支，完成已上线项目Bug修补
继续开发新需求（iss53分支），并且纳入已发布的补丁

2.1、开发某个项目（master分支）

首先，我们正在开发某个项目，并推送到了生产服务器。

图2-1：一个简单的提交历史

2.2、为该项目增加某个新需求 (iss53分支)

创建并切换至iss53分支，注意要加"-b"参数。

git checkout -b iss53

图2-2-1：创建一个新的分支(iss53)

修改后再次提交。

vim index.html 
git commit -a-m 'addedanewfooter [issue53]'

图2-2-2：iss53 分支随工作进展向前推进

2.3、修补上线项目Bug（hotfix分支）

已上线项目需要修补，于是为本次修补建立新分支(hotfix分支)

git checkout master #首先切换到主分支
git checkout -b 'hotfix' #然后创建hotfix分支

图2-3：hotfix分支是从master(c2位置)分出

2.4、合并补丁（hotfix分支）到master分支

补丁（hotfix分支）测试完毕，于是合并到master分支，完成Bug修补。

git checkout master  #首先切换到主分支
git merge hotfix #测试完毕后，合并hotfix分支
git branch -d hotfix #删除已合并的hotfix分支

合并时会出现“Fast forward”（快进）提示，表示无分歧需要解决，直接向前移动指针。

图2-4：合并hotfix分支后指针位置

2.5、继续开发新需求，并纳入已发布的补丁

git checkout master #切换至master 
git merge iss53 #合并iss53到master

注意：这次与之前hotfix合并不同，由于当前master分支直接祖先是C2，iss53分支直接祖先是C3，所以Git需要和它们的共同祖先C2进行一次简单的三方合并计算。

图2-5-1：合并iss53分支后指针位置

解决合并冲突

git status #合并失败的文件以"unmerged"标出
git add . #标记冲突已解决，并暂存文件
#git mergetool Git默认图形化冲突解决工具

图2-5-2：Git 自动创建了包含合并结果的对象(C6)

三、远程分支

远程分支（remote branch）是对远程仓库状态的索引，格式如下：

格式：远程仓库名/分支名
默认：origin/master

3.1、克隆远程分支

Git clone 会克隆远程origin/master分支，并建立一个相同位置的本地master分支。

图3-1-1：Git clone 建立本地master和远程origin/master分支

正在本地master分支工作，与此同时，其他人向远程仓库推送了内容，从f42c5更新到了190a3，但是本地origin/master指针依然会停留在f42c5位置。

图3-1-2：远程仓库更新，但本地origin/master指针不改变

3.2、更新本地分支

git fetch 从远程仓库更新你本地还没有的数据。（新增了31b8e,190a3）

图3-1-3：运行 git fetch origin 同步远程仓库至本地

注意：在fetch操作抓来新远程分支XX之后，本地不会新增XX分支，有的只是一个你无法移动的origin/XX指针。

如果要把远程分支合并到当前分支，可以运行：

git merge [远程仓库名]/[分支名]
git merge origin/serverfix。

3.3、跟踪分支

从远程分支检出的本地分支，称为跟踪分支(tracking branch)。在跟踪分支里git push可推送本地分支到相应的远程仓库，反过来可直接运行git pull，可获取远程分支所有更新，并且合并到当前本地分支。

注：克隆操作会自动创建一个master分支来跟踪origin/master。

如果想要在远程分支的基础上分化出一个新分支，可以运行：

方法一：

git checkout -b [分支名] [远程名]/[分支名]
git checkout -b serverfix origin/serverfix

方法二：（适用1.6.2以上版本Git）

git checkout --track [远程名]/[分支名] 
git checkout --track origin/serverfix

3.4、推送本地分支

方法一：

语法：git push (远程仓库名) (本地分支名)
实例：git push origin serverfix

方法二：（可自定义远程分支名）

语法：git push (远程仓库名) (本地分支名):(远程分支名)
实例：git push origin serverfix:serferfix

四、衍合

把一个分支整合到另一个分支的办法有两种：merge（合并）和rebase（衍合），两者得到的结果一样，但衍合能产生一个更为整洁的提交历史。

4.1、合并与衍合区别

合并(merge)：通过C2-C3-C4三方合并计算生成C5。

图4-1-1：合并(merge)分支后的提交历史

衍合(rebase)：把在C3 里产生的变化补丁重新在C4 的基础上打一遍。

衍合原理：从两个分支共同祖先(C2)开始，提取你所在分支(experiment)每次提交时产生的差异（diff），然后回到需要衍合入的分支(master)，按顺序施用每一个差异补丁文件。

git checkout experiment
git rebase master

图4-1-2：把C3 里产生的改变衍合到C4 中

最后回到master分支进行一次快进合并，结果同三方合并例子中的C5内容一模一样，但衍合能产生一个更为整洁的提交历。

图4-1-3：master 分支的快进。

4.2、衍合(rebase)风险

注释事项：永远不要衍合那些已经推送到公共仓库的更新。

常见用法：一般把衍合当成一种在推送之前清理提交历史的手段，而且仅仅衍合那些永远不会公开的commit

五、小结

5.1、新建本地分支

git branch testing #创建testing分支
git checkout testing #切换至testing分支
git checkout -b iss53 #创建并切换至iss53分支。

5.2、合并本地分支

git checkout master  #首先切换到主分支
git merge hotfix #测试完毕后，合并hotfix分支
git branch -d hotfix #删除已合并的hotfix分支

5.3、解决合并冲突

git status #合并失败的文件以"unmerged"标出
git add . #标记冲突已解决，并暂存文件
git mergetool #Git默认图形化冲突解决工具

5.4、合并远程分支

origin/master #格式：远程仓库/分支名
git merge origin/serverfix #合并远程分支serverfix到当前分支

5.5、删除远程分支

#git push [远程仓库名] :[远程分支]
#注意区别：git push [远程名] [本地分支]:[远程分支]
git push origin :serverfix　#删除远程分支

5.6、创建跟踪分支

方法一：

git checkout -b [分支名] [远程名]/[分支名]
git checkout -b serverfix origin/serverfix

方法二：（适用1.6.2以上版本Git）

git checkout --track [远程名]/[分支名] 
git checkout --track origin/serverfix

5.7、查看分支

git branch #列出所有分支，星号"*"表示当前所在分支。
git branch -v #查看各分支最后一次提交信息

#查看已和当前分支合并的分支
#可用git branch -d 删掉未标星号的分支，因为已经合并了。
git branch --merged 

#查看未和当前分支合并的分支
#强制删除未合并的分支git branch -D
git branch --no-merged

5.8、衍合所在分支

git checkout experiment #切换到需要衍合的分支
git rebase master #衍合experiment分支到主分支

Git on 七三的小站

使用 Docker Compose 安装 Gitea

目录

1. 镜像选择

2. 安装部署

2.1. 使用 rootless 镜像

2.1.1. 创建工作目录

2.1.2. 创建配置文件

2.1.3. 启动运行

2.2. 使用 标准 镜像

2.2.1. 创建工作目录

2.2.2. 创建配置文件

2.2.3. 启动运行

3. SSH 容器直通

3.1. 创建 git 用户

3.2. 方法一：使用 AuthorizedKeysCommand

3.2.1. Docker 获取 authorized_keys（推荐）

3.2.2. SSH 获取 authorized_keys（二选一）

3.3. 方法二：共享 authorized_keys

3.4. 转发主机命令到容器

3.4.1. 方法1：shell 方式（推荐）

3.4.2. 方法2：Shim 方式

4. Gitea Actions

4.1. Act Runner

4.1.1. 使用二进制文件

4.1.2. 使用 Docker 镜像

4.2. Actions Demo

Git 分布式工作流程

目录

一、概述

1.1、集中式工作流

1.2、集成管理员工作流

1.3、司令官与副官工作流

二、为项目作贡献

2.1、提交指南

2.2 私有的小型团队

2.3、私有团队间协作

2.4、公开的小型项目

2.5、公开的大型项目

Git 使用指南

目录

一、Git 基础要点

1.1、直接快照非比较差异

1.2、三种文件状态

1.3、典型工作流程

二、Git 安装与初始化

2.1、安装方法

2.2、git 中文本地化

2.3、全局配置

2.4、密钥配置

2.5、自动完成

2.6、命令别名

三、Git 基础使用

3.1、常规操作

3.1.1、创建Git项目

3.1.2、检查当前文件状态

3.1.3、跟踪新文件

3.1.4、忽略某些文件不跟踪

3.1.5、暂存已修改文件

3.1.6、查看已暂存和未暂存差异

3.1.7、删除/移动已跟踪文件

3.1.8、提交更新

3.1.9、查看提交历史

3.1.10、查看版本细节

3.2、撤销操作

3.2.1、修改最后一次提交

3.2.2、取消已经暂存的文件

3.2.3、取消对文件的修改

3.3、远程仓库的使用

3.3.1、查看项目的远程库

3.3.2、添加远程仓库

3.3.3、从远程仓库抓取数据

3.3.4、推送数据到远程仓库

3.3.5、查看远程仓库信息

3.3.6、远程仓库的删除和重命名

3.4、本地标签管理

3.4.1、显示已有的标签

3.4.2、新建标签

3.4.3、后期加注标签

3.4.4、签署验证标签

2.1. 使用 `rootless` 镜像

2.2. 使用 `标准` 镜像

3.1. 创建 `git` 用户