Gitでソースを管理する技術者、というのをやってみたくなった。
簡単にセットアップできそうな気配だったので、Gitea(ギッティー)を使わせていただくことにした。
Gitea - 一杯のお茶を添えた Gitは、とても簡単に起動できた。
そして、Git / Bookを見ながら、Giteaを使って色々と試してみることができる。
一通りやってみると、Gitがなんとなく分かってくるので、自前の環境で学習するのはとってもオススメ。
副次的な効果として、Githubで表示されている様々な情報が何を意味しているのか分かってくる。
一通りやってみたことを記した結果、今回もとても長くなってしまった。
インストール
Giteaのインストールと初期セットアップ
DockerでGiteaを動かす方法が説明されており、簡単に使えそうな気配。
Installation with Docker
Docker hubで最新版が1.17.2だったので、これを利用させていただくことにした。
docker-compose.yml
version: "3"
networks:
gitea:
volumes:
gitea:
mysql:
services:
server:
image: gitea/gitea:1.17.2
container_name: gitea
environment:
- USER_UID=1000
- USER_GID=1000
- GITEA__database__DB_TYPE=mysql
- GITEA__database__HOST=db:3306
- GITEA__database__NAME=gitea
- GITEA__database__USER=gitea
- GITEA__database__PASSWD=gitea
restart: always
networks:
- gitea
volumes:
- gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- 3000:3000
- 222:22
depends_on:
- db
db:
image: mysql:8
container_name: gitea_db
restart: always
environment:
- MYSQL_ROOT_PASSWORD=gitea
- MYSQL_USER=gitea
- MYSQL_PASSWORD=gitea
- MYSQL_DATABASE=gitea
networks:
- gitea
volumes:
- mysql:/var/lib/mysql
これを実行すると、すぐに動作し始める。
$ sudo docker compose up -d
DNSに新しいサイトを登録して、名前解決ができるようにした。
git.hogeserver.hogeddns.jp → 192.168.110.10
サイトにアクセスしてみる。
http://git.hogeserver.hogeddns.jp:3000
初期設定の画面が表示されるので、以下のように設定してみた。
※後からの設定も可能。コンテナの中のテキストファイルを修正する。
| 区分 | 項目 | 設定値 | 備考 |
|---|---|---|---|
| データベース設定 | データベースのタイプ | MySQL | |
| ホスト | db:3306 | ||
| ユーザー名 | gitea | ||
| パスワード | gitea | docker-compose.ymlで複雑なものに変えておくのが良いと思う | |
| データベース名 | gitea | ||
| 文字セット | utf8mb4 | ||
| 基本設定 | サイトタイトル | Gitea: Git with a cup of tea | |
| リポジトリのルートパス | /data/git/repositories | ||
| Git LFSルートパス | /data/bit/lfs | ||
| 実行ユーザー名 | git | ||
| サーバードメイン | git.hogeserver.hogeddns.jp | ||
| SSHサーバーのポート | 22 | ||
| Gitea HTTPポート | 3000 | ||
| GiteaのベースURL | http://git.hogeserver.hogeddns.jp:3000/ | まずは、このURLで動作させる。 | |
| ログの保存先パス | /data/gitea/log | ||
| メール設定 | SMTPホスト | ※未指定 | ホームラボだけで使えるサーバーのため、後で設定。 |
| メール送信者 | ※未指定 | ||
| SMTPユーザー名 | ※未指定 | ||
| SMTPパスワード | ※未指定 | ||
| 登録にはメールによる確認が必要 | チェックなし | ||
| メール通知を有効にする | チェックなし | ||
| サーバーと外部サービスの設定 | ローカルモードを有効にする | チェックなし | 静的ファイルのCDNと、プロフィールのGravatarを無効にする。 |
| Gravatarを無効にする | チェックなし | ||
| フェデレーテッド・アバターを有効にする | チェックあり | ||
| OpenIDを使ったサインインを有効にする | チェックなし | ||
| セルフ登録を無効にする | チェックなし | ||
| 外部サービスを使用した登録のみを許可 | チェックなし | ||
| OpenIDを使ったセルフ登録を有効にする | チェックなし | ||
| 登録時のCAPTCHAを有効にする | チェックなし | インターネットに公開するならきっと必要。 | |
| ページ閲覧にサインインが必要 | チェックなし | ||
| デフォルトでメールアドレスを隠す | チェックあり | インターネットに公開するならきっと必要。 | |
| デフォルトで組織の作成を許可 | チェックなし | デフォルトはチェックあり。運用ポリシーによって決める。 | |
| デフォルトでタイムトラッキング有効 | チェックあり | ||
| メールを隠すときのドメイン | noreply.hogeserver.hogeddns.jp | ||
| パスワードハッシュアルゴリズム | pbkdf2 | pbkdf2、argon2、scrypt、bcryptからの選択。 | |
| 管理者アカウントの設定 | 管理者ユーザー名 | rohhie | このユーザーが最初のユーザー、かつ、管理者になる。 |
| パスワード・パスワード確認 | <password> | ||
| メールアドレス | rohhie@hogeserver.hogeddns.jp |
「Giteaをインストール」をクリックしてちょっと待つと、ログインした状態になる。
ちょっと適当な設定ではじめている。
本格的に運用しようと思ったら、設定の手直しが必要になるが、まず動き出してくれるというのがありがたい。
リバースプロキシの設定
公開するポートを80とか443にする。ROOT_URLの設定が動作上大切なようなので、どちらか一方での公開となる。
ここでは、Apache2を利用している。
HTTP
ホスト側のApacheで設定を用意する。
/etc/apache2/sites-available/myservice.conf
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName git.hogeserver.hogeddns.jp
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/git-error.log
CustomLog ${APACHE_LOG_DIR}/git-access.log combined
ProxyPreserveHost On
AllowEncodedSlashes NoDecode
ProxyPass / http://localhost:3000/ nocanon
</VirtualHost>
※ホスト名は適宜変更。
必要なモジュールを追加し、サイトを有効にして、Apacheに反映する。
$ sudo a2enmod proxy_http $ sudo a2ensite myservice.conf $ sudo systemctl restart apache2
Giteaの設定ファイルにも変更が必要。
viがインストールされていて、以下で設定ファイルを開くことができた。
$ sudo docker exec -it -u git gitea vi /data/gitea/conf/app.ini
[server]
ROOT_URL = http://git.hogeserver.hogeddns.jp:3000/
※ホスト名は適宜変更。
変更結果を保存して、Giteaのコンテナを再起動。
$ sudo docker compose restart
これで、ポート80でサービスを提供できるようになった。
HTTP(サブディレクトリ)
サブディレクトリでサービスを公開することもできる。
設定の変更点だけを記しておく。
/etc/apache2/sites-available/myservice.conf
<VirtualHost *:80>
ServerName hogeserver.hogeddns.jp
ProxyPass /git http://localhost:3000 nocanon
</VirtualHost>
※ProxyPassの宛先の最後の/を取り外している。ログファイルとか気になるところは修正。
$ sudo docker exec -it -u git gitea vi /data/gitea/conf/app.ini
[server] DOMAIN = hogeserver.hogeddns.jp SSH_DOMAIN = hogeserver.hogeddns.jp ROOT_URL = http://hogeserver.hogeddns.jp/git/
※DOMAINとSSH_DOMAINはブラウザでのアクセスに直接影響しないけれど、合わせておいた方が良いと思う。
変更結果を保存して、Giteaのコンテナを再起動。
$ sudo docker compose restart
これで、ポート80でサービスを提供できるようになった。
HTTPS
ホスト側のApacheで設定を用意する。
/etc/apache2/sites-available/myservice.conf
<VirtualHost *:80>
ServerName git.hogeserver.hogeddns.jp
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
RewriteCond %{SERVER_NAME} =git.hogeserver.hogeddns.jp
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
<VirtualHost *:443>
ServerAdmin webmaster@localhost
ServerName git.hogeserver.hogeddns.jp
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/git-error.log
CustomLog ${APACHE_LOG_DIR}/git-access.log combined
SSLProxyEngine On
ProxyPreserveHost On
AllowEncodedSlashes NoDecode
ProxyPass / http://localhost:3000/ nocanon
SSLEngine on
SSLCertificateFile /etc/ssl/certs/wild.hogeserver.crt
SSLCertificateKeyFile /etc/ssl/private/wild.hogeserver.key
</VirtualHost>
※ホスト名は適宜変更。
※SSLでは、ホームラボで利用可能な自己署名証明書・秘密鍵を指定しているが、これも適宜変更。
必要なモジュールを追加し、サイトを有効にして、Apacheに反映する。
$ sudo a2enmod proxy_http rewrite ssl $ sudo a2ensite myservice.conf $ sudo systemctl restart apache2
Giteaの設定ファイルにも変更が必要。
viがインストールされていて、以下で設定ファイルを開くことができた。
$ sudo docker exec -it -u git gitea vi /data/gitea/conf/app.ini
[server] ROOT_URL = https://git.hogeserver.hogeddns.jp:3000/
※ホスト名は適宜変更。
変更結果を保存して、Giteaのコンテナを再起動。
$ sudo docker compose restart
これで、ポート443でサービスを提供できるようになった。
HTTPS(サブディレクトリ)
こちらも設定の変更点だけを記しておく。
/etc/apache2/sites-available/myservice.conf
<VirtualHost *:80>
ServerName hogeserver.hogeddns.jp
RewriteCond %{SERVER_NAME} =hogeserver.hogeddns.jp
</VirtualHost>
<VirtualHost *:443>
ServerName hogeserver.hogeddns.jp
ProxyPass /git http://localhost:3000 nocanon
</VirtualHost>
※ProxyPassの宛先の最後の/を取り外している。ログファイルとか気になるところは修正。
$ sudo docker exec -it -u git gitea vi /data/gitea/conf/app.ini
[server] DOMAIN = hogeserver.hogeddns.jp SSH_DOMAIN = hogeserver.hogeddns.jp ROOT_URL = https://hogeserver.hogeddns.jp/git/
※DOMAINとSSH_DOMAINはブラウザでのアクセスに直接影響しないけれど、合わせておいた方が良いと思う。
メールサーバーの設定
Giteaはポート25を使った単純なメール転送ができない。Go言語が提供するライブラリの制限のように見える表現がされている。
Gitea / Email setup
外に使えるメールサーバーがあるなら、それを設定する。
$ sudo docker exec -it -u git gitea vi /data/gitea/conf/app.ini
[mailer] ENABLED = true HOST = mx.hogeserver.hogeddns.jp:587 FROM = no-reply@hogeserver.hogeddns.jp MAILER_TYPE = smtp IS_TLS_ENABLED = false USER = no-reply PASSWD = p@ssword123
※相手先のメールサーバーにあわせて設定。
ここでは、新たにno-replyというアカウントを作って、それでメールを送信することにした。
GiteaはメールのFROMに付けるメールアドレスを、ここで指定するFROMに統一していないようで、例えば、管理者がイシューにコメントを書いた時、ユーザーに送られるメールのFROMが指定されていないものとみられる。ホームラボでは、Administrator<root@hogeserver.hogeddns.jp>などというメールアドレスからメールが送られるケースがあった。これはあまり気持ちよくないので、no-replyというアカウントを新設することとした。
コンテナを再起動すると、設定が反映される。
さて、ホームラボだけれども…
localhostならばポート25でメール送信できるかもしれないが、Dockerを利用したのでその方法は使えない。Submission、SMTPSを使った通信に限定される。また、ホームラボの中だけでメールを取り扱いたいが、SMTPサーバーが提示するのは自己署名証明書だったりもするので、対策が必要。
DockerでKopanoを動しており、これを少し改変して、Postfixが提示する証明書をSnakeoilから自己署名証明書に変更。
そして、Submissionでメールを送信できるように設定した。
また、Giteaに自己署名証明書を受け入れてもらうために、CA証明書を登録する必要がある。
CA証明書の登録は、コンテナを作り直す度に実行する必要があるので、Dockerファイルを作って処理するとか、どうにかしたいところ。
$ sudo docker cp ca.crt gitea:/usr/local/share/ca-certificates $ sudo docker exec gitea update-ca-certificates WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
警告が出たけれど、登録はされているようだ。
$ sudo docker exec gitea ls -la /etc/ssl/certs | grep "ca\.crt" lrwxrwxrwx 1 root root 39 Sep 18 16:48 ca-cert-ca.pem -> /usr/local/share/ca-certificates/ca.crt
Giteaからメールの送信テストをしたところ、こんなメールが届いた。
Subject: Gitea Test Email!
Date: Sun, 18 Sep 2022 17:18:30 +0900
From: webmaster@hogeserver.hogeddns.jp
To: rohhie@hogeserver.hogeddns.jp
本文:
Gitea Test Email!
どうにかホームラボだけでメールを流通させることができるようになった。
サービスに関する設定
ユーザーに向けたサービス提供の設定を見直す。
ユーザーに関する設定は、[service]セクションに集まっていた。
設定内容をWeb画面で見ることはできるけれど、設定変更はできないので、設定ファイルを開いて変更していく。
$ sudo docker exec -it gitea vi /data/gitea/conf/app.ini
[service] DISABLE_REGISTRATION = false REQUIRE_SIGNIN_VIEW = false REGISTER_EMAIL_CONFIRM = true ENABLE_NOTIFY_MAIL = true ALLOW_ONLY_EXTERNAL_REGISTRATION = false ENABLE_CAPTCHA = false DEFAULT_KEEP_EMAIL_PRIVATE = true DEFAULT_ALLOW_CREATE_ORGANIZATION = false DEFAULT_ENABLE_TIMETRACKING = true NO_REPLY_ADDRESS = noreply.hogeserver.hogeddns.jp
設定を反映。
$ sudo docker compose restart
結果はこうなった。
リポジトリの作成を制限する
インターネットにサーバーを公開することを想像してみた。
- 自分でリポジトリを作って、物凄く長い記事になっているヤツを公開する。
- 訪問者は好きなようにクローンすることができる。
- もし、訪問者がログインしたくなったら、ユーザー登録ができる。イシューを書き込んだりもできる。
- 訪問者がフォークしてソースに手を入れてくれることは歓迎するが、新たにリポジトリを作って欲しいとは思わない。
あくまでもダウンロードを簡単にする目的で公開すると思うのだけれど、コミュニケーションは取ってみたい。
これをどう実現するか色々眺めて試してみたところ、ユーザーが作成できるリポジトリの上限を0にしておくことで実現できることが分かった。
各ユーザーは「リポジトリの上限数」という設定値を持っており、-1が設定されている。
この設定値が-1のとき、デフォルトの制限が適用される、という仕組み。
なるほど！確かにこれなら、後からデフォルト値を変更できる。
デフォルト値は以下で設定する。
$ sudo docker exec -it -u git gitea vi /data/gitea/conf/app.ini
[repository] MAX_CREATION_LIMIT = 0
SSHの接続環境を作る
最初にパススルーなしで接続できるところまで整理し、その後にパススルーするように設定を変更していく。
パススルーまでやると、ポート22でサービスを公開できるようになる。
パススルーなし
Giteaの設定ファイルを変更。
$ sudo docker exec -it -u git gitea vi /data/gitea/conf/app.ini
/data/gitea/conf/app.ini
[server] SSH_DOMAIN = git.hogeserver.hogeddns.jp
※ホスト名は適宜変更。
変更結果を保存して、Giteaのコンテナを再起動。
$ sudo docker compose restart
SSHの公開鍵と秘密鍵を生成する。ファイル名を指定していて、パスフレーズは「なし」としている。
$ ssh-keygen -t ed25519 -C "rohhie@rohhie.net" -f ~/.ssh/id_ed25519_rohhie@rohhie.net Generating public/private ed25519 key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/rohhie/.ssh/id_ed25519_rohhie@rohhie.net Your public key has been saved in /home/rohhie/.ssh/id_ed25519_rohhie@rohhie.net.pub The key fingerprint is: SHA256:7pNuwz9zk6HvnWzqNx8ZWxzvDt05pK5ngILnHN2n5pg rohhie@rohhie.net The key's randomart image is: +--[ED25519 256]--+ | | | | | . | | .o| | . S o o+| | . = o o..ooB| | +.+. .++.*+| | +* *o==++o| | ooE+XO*+oo| +----[SHA256]-----+
できあがった公開鍵をサイトに登録。
接続を試してみる。
$ ssh -p 222 git@git.hogeserver.hogeddns.jp -i ~/.ssh/id_ed25519_rohhie@rohhie.net PTY allocation request failed on channel 0 Hi there, rohhie! You've successfully authenticated with the key named rohhie@rohhie.net, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. Connection to git.hogeserver.hogeddns.jp closed.
こんにちは、rohieさん。rohhie@rohhie.net というキーで認証に成功しましたが、Gitea はシェルアクセスを提供しません。
もしこれが予期せぬことであれば、パスワードでログインし、別のユーザーでGiteaをセットアップしてください。
このやり方でgit cloneできるのかな？と思ったけれども、秘密鍵の指定方法が見つからない。
そこで、この接続を簡単にするssh_configファイルを作成する。
~/.ssh/config
host git.hogeserver.hogeddns.jp
HostName git.hogeserver.hogeddns.jp
User rohhie
Port 222
IdentityFile ~/.ssh/id_ed25519_rohhie@rohhie.net
接続を試してみる。
$ ssh git@git.hogeserver.hogeddns.jp PTY allocation request failed on channel 0 Hi there, rohhie! You've successfully authenticated with the key named rohhie@rohhie.net, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. Connection to git.hogeserver.hogeddns.jp closed.
この状態で、Giteaで表示されるリポジトリのURLをコピーしてきて、クローンしてみる。
$ git clone ssh://git@git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git Cloning into 'Samba-ad-dc-with-docker'... remote: Enumerating objects: 198, done. remote: Counting objects: 100% (198/198), done. remote: Compressing objects: 100% (191/191), done. remote: Total 198 (delta 123), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (198/198), 1.09 MiB | 9.66 MiB/s, done. Resolving deltas: 100% (123/123), done.
とりあえず、これで操作はできるようになった。
パススルー
Giteaのコンテナを動かしているホストに、gitユーザーを作成。パスワードなしにしている。
$ sudo adduser git --disabled-password
Adding user `git' ...
Adding new group `git' (1001) ...
Adding new user `git' (1001) with group `git' ...
Creating home directory `/home/git' ...
Copying files from `/etc/skel' ...
Changing the user information for git
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n]
gitユーザーの公開鍵・秘密鍵を作成する。
$ sudo -u git ssh-keygen -t rsa -b 4096 -C "Gitea Host Key" Generating public/private rsa key pair. Enter file in which to save the key (/home/git/.ssh/id_rsa): 何も入力せずにEnter Created directory '/home/git/.ssh'. Enter passphrase (empty for no passphrase): 何も入力せずにEnter Enter same passphrase again: 何も入力せずにEnter Your identification has been saved in /home/git/.ssh/id_rsa Your public key has been saved in /home/git/.ssh/id_rsa.pub The key fingerprint is: SHA256:uR1s79vqD1u4iaXMKA+TwzQmXbuYWY4ACp8l8kibDNI Gitea Host Key The key's randomart image is: +---[RSA 4096]----+ | | | . | |=.E . . | |**o= . . + | |o++ o = S + | | * X = o . | | @ + . = . | | .+ + = B | | oo =.O+o | +----[SHA256]-----+
公開鍵をauthorized_keysに登録。
$ sudo -u git cat /home/git/.ssh/id_rsa.pub | sudo -u git tee -a /home/git/.ssh/authorized_keys $ sudo -u git chmod 600 /home/git/.ssh/authorized_keys
giteaコマンドを作成。
$ 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
GIDとUIDを確認し、コンテナに渡す環境変数を変更する。
$ id git uid=1001(git) gid=1001(git) groups=1001(git)
docker-compose.yml
…
services:
server:
environment:
- USER_UID=1001
- USER_GID=1001
…
volumes:
- gitea:/data
- /etc/timezone:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
- /home/git/.ssh:/data/git/.ssh
…
ports:
- 3000:3000
- 127.0.0.1:2222:22
…
コンテナを削除し、再度起動する。
$ sudo docker compose down $ sudo docker compose up -d
Giteaでユーザーの鍵を一度削除し、再度登録する。
結果として、以下のようにファイルが編集される。
接続すると、先程作成したgiteaコマンドが呼び出されてパススルーする動きをするようだ。
ssh-rsa AAAAB3NzaC1yc2EAA…RfR5w== Gitea Host Key
# gitea public key
command="/usr/local/bin/gitea --config=/data/gitea/conf/app.ini serv key-5",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-ed25519 AA…I3v rohhie@rohhie.net
作業用の環境から、クローンしてみる。
~/.ssh/config
host git.hogeserver.hogeddns.jp
HostName git.hogeserver.hogeddns.jp
User rohhie
IdentityFile ~/.ssh/id_ed25519_rohhie@rohhie.net
※先程まで設定していたポート222の指定なし。
$ git clone ssh://git@git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git Cloning into 'Samba-ad-dc-with-docker'... remote: Enumerating objects: 198, done. remote: Counting objects: 100% (198/198), done. remote: Compressing objects: 100% (191/191), done. remote: Total 198 (delta 123), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (198/198), 1.09 MiB | 8.62 MiB/s, done. Resolving deltas: 100% (123/123), done.
クローンできた。
設定されているリモートサーバーを確認してみたところ、ちゃんとsshでの接続になっていた。
$ git remote -v origin ssh://git@git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git (fetch) origin ssh://git@git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git (push)
リモートリポジトリのURLを変更
いままでHTTPSでアクセスしていた環境を、SSHに切り替えることにした。
リモートリポジトリは以下で確認ができる。
$ git remote -v origin https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git (fetch) origin https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git (push)
書き換え。一応、書き換えの対象を明確にするため、古いURLも指定している。
$ git remote set-url origin \ ssh://git@git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git \ https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git
ユーザーのSSH接続
GiteaがSSHで接続できるように整備されていれば、この後から使うユーザーは簡単に設定ができる。
SSHの公開鍵と秘密鍵を生成する。ファイル名を指定していて、パスフレーズは「なし」としている。
オプションの-fは、他の鍵がある場合に名前を変えるためのメモとして記載しているだけで、無指定であればid_ed25519で作られる。
$ ssh-keygen -t ed25519 -C "piyo-piyo" -f ~/.ssh/id_ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (/home/HOGEDOMAIN/piyo/.ssh/id_ed25519): Created directory '/home/HOGEDOMAIN/piyo/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/HOGEDOMAIN/piyo/.ssh/id_ed25519 Your public key has been saved in /home/HOGEDOMAIN/piyo/.ssh/id_ed25519.pub The key fingerprint is: SHA256:My1uHoS0kTtBlAUv7P/ahOo52oh3iHteXFO6nkyQJ4I piyo-piyo The key's randomart image is: +--[ED25519 256]--+ | .++. | | o.o | | B . . | | . o O + | | E . X S . | | o X B | | . .o O . | | ..++oO * | | o=++=.*.o | +----[SHA256]-----+
公開鍵を表示させ、Giteaに登録する。
$ cat .ssh/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFH1xHMEQWRKXxVmYB+zi0bdllJkWUZNDCEQHdeHi7Zm piyo-piyo
SSH接続のための設定ファイルを作る。
~/.ssh/config
host git.hogeserver.hogeddns.jp
HostName git.hogeserver.hogeddns.jp
User piyo
IdentityFile ~/.ssh/id_ed25519
ユーザー名と、メールアドレスをglobalに登録する。
$ git config --global user.name "piyo" $ git config --global user.email "piyo@hogeserver.hogeddns.jp"
これで、Giteaに表示されるgitのURLを使って操作ができる。
パスワード認証を廃止
パスワード認証を廃止することもできるようだ。
この場合、ユーザーはSSHで接続しないと更新ができない。
設定は以下の通り。
$ sudo docker exec -it gitea vi /data/gitea/conf/app.ini
[service] ENABLE_BASIC_AUTHENTICATION = false
設定後に、パスワード認証を試してみた。
$ git push Username for 'https://git.hogeserver.hogeddns.jp': piyo Password for 'https://piyo@git.hogeserver.hogeddns.jp': <piyoのパスワード> remote: Unauthorized fatal: Authentication failed for 'https://git.hogeserver.hogeddns.jp/DevGroup/Gitea-with-docker.git/'
パスワード認証が禁止になっていることを教えてくれたりはしないが、確かに機能しなくなった。
CLI tea command
GiteaのCLI(コマンドラインインターフェース)である tea を準備する。
これは、Githubでいうところの、ghなのだろう。
Gitea / tea
インストール
ダウンロードページから適用したい環境用のファイルをダウンロードして使用する。
この日は、0.9.0が提供されていた。
$ wget https://dl.gitea.io/tea/0.9.0/tea-0.9.0-linux-amd64 $ sudo mv tea-0.9.0-linux-amd64 /usr/local/bin/tea $ sudo chmod +x /usr/local/bin/tea $ sudo chown root:root /usr/local/bin/tea
インストールできたので、コマンドを実行してみる。
$ tea tea - command line tool to interact with Gitea version Version: 0.9.0 golang: 1.18.6 go-sdk: v0.15.1-0.20220831004139-a0127ed0e7fe USAGE tea command [subcommand] [command options] [arguments...] …
説明も表示される。
tea is a productivity helper for Gitea. It can be used to manage most entities on one or multiple Gitea instances & provides local helpers like 'tea pr checkout'.
teaはGiteaのための生産性向上ヘルパーです。1つまたは複数のGiteaインスタンスでほとんどのエンティティを管理するために使用でき、'tea pr checkout'のようなローカルヘルパーを提供します。tea tries to make use of context provided by the repository in $PWD if available. tea works best in a upstream/fork workflow, when the local main branch tracks the upstream repo. tea assumes that local git state is published on the remote before doing operations with tea. Configuration is persisted in $XDG_CONFIG_HOME/tea.
DeepL先生の翻訳
tea は、リポジトリから $PWD で提供されるコンテキストがあれば、それを使用しようとします。upstream/fork ワークフローでは、ローカルのメインブランチが上流のリポジトリを追跡しているときに、tea は最適に動作します。tea で操作を行う前に、ローカル git 状態がリモートで公開されていると想定しています。設定は、$XDG_CONFIG_HOME/tea に永続化されます。
teaでログイン
teaコマンドを利用するために、トークンというのが必要になるようだ。
Giteaの設定→アプリケーションでトークンを作成してみる。
一度しか表示されないというトークンをメモしておく。
5b51edc1254aa404627b412d1f6c396900a90fc7
ログインしてみる。
$ tea login add --url git.hogeserver.hogeddns.jp --token 5b51edc1254aa404627b412d1f6c396900a90fc7 Login as rohhie on https://git.hogeserver.hogeddns.jp successful. Added this login as git.hogeserver.hogeddns.jp
画面を更新してみたところ、最終使用日が表示されている。
試しに、もう一度ログインしてみる。
$ tea login add --url git.hogeserver.hogeddns.jp --token 5b51edc1254aa404627b412d1f6c396900a90fc7 Error: token already been used, delete login 'git.hogeserver.hogeddns.jp' first
既に使われている、と。一旦消してみる。
$ tea login delete $ tea login add --url git.hogeserver.hogeddns.jp --token 5b51edc1254aa404627b412d1f6c396900a90fc7 Login as rohhie on https://git.hogeserver.hogeddns.jp successful. Added this login as git.hogeserver.hogeddns.jp $ tea login +----------------------------+------------------------------------+----------------------------+--------+---------+ | NAME | URL | SSHHOST | USER | DEFAULT | +----------------------------+------------------------------------+----------------------------+--------+---------+ | git.hogeserver.hogeddns.jp | https://git.hogeserver.hogeddns.jp | git.hogeserver.hogeddns.jp | rohhie | false | +----------------------------+------------------------------------+----------------------------+--------+---------+
デフォルト？これは、恐らくだけれど、複数のGiteaを操作したい場合に、デフォルトを設定するものだと思われる。
他のユーザーでログインしてみたけれど、当然、このrohhieの情報は使われない。
とりあえず、設定方法だけ整理しておく。
$ tea login default git.hogeserver.hogeddns.jp $ tea login +----------------------------+------------------------------------+----------------------------+--------+---------+ | NAME | URL | SSHHOST | USER | DEFAULT | +----------------------------+------------------------------------+----------------------------+--------+---------+ | git.hogeserver.hogeddns.jp | https://git.hogeserver.hogeddns.jp | git.hogeserver.hogeddns.jp | rohhie | true | +----------------------------+------------------------------------+----------------------------+--------+---------+
リポジトリを見てみる。
$ tea repo NOTE: no gitea login detected, falling back to login 'git.hogeserver.hogeddns.jp' +--------+-------------------------+--------+-------------------------------------------------------------------+ | OWNER | NAME | TYPE | SSH | +--------+-------------------------+--------+-------------------------------------------------------------------+ | rohhie | Samba-ad-dc-with-docker | source | git@git.hogeserver.hogeddns.jp:rohhie/Samba-ad-dc-with-docker.git | +--------+-------------------------+--------+-------------------------------------------------------------------+
no gitea login detected, …というのがよく分からないが、動いている。
設定の保管場所
設定はこちらに保管されていた。このファイルを見ると、sshでも接続できそうな気がする。試していないけど。
~/.config/tea/config.yml
logins:
- name: git.hogeserver.hogeddns.jp
url: https://git.hogeserver.hogeddns.jp
token: 5b51edc1254aa404627b412d1f6c396900a90fc7
default: true
ssh_host: git.hogeserver.hogeddns.jp
ssh_key: ""
insecure: false
ssh_certificate_principal: ""
ssh_agent: false
ssh_key_agent_pub: ""
user: rohhie
created: 1664018169
preferences:
editor: false
flag_defaults:
remote: ""
接続には名前が付いているのだけれど、URLでは長すぎるので、hogeに変更してみた。
- name: hoge
先程の no gitea login detected の表示は、ログイン名を指定すると表示されなくなる。
$ tea repo -l hoge +--------+-------------------------+--------+-------------------------------------------------------------------+ | OWNER | NAME | TYPE | SSH | +--------+-------------------------+--------+-------------------------------------------------------------------+ | rohhie | Samba-ad-dc-with-docker | source | git@git.hogeserver.hogeddns.jp:rohhie/Samba-ad-dc-with-docker.git | +--------+-------------------------+--------+-------------------------------------------------------------------+
あるいは、Giteaからクローンしたディレクトリにいれば表示されない。
$ cd Samba-ad-dc-with-docker/ $ tea repo +--------+-------------------------+--------+-------------------------------------------------------------------+ | OWNER | NAME | TYPE | SSH | +--------+-------------------------+--------+-------------------------------------------------------------------+ | rohhie | Samba-ad-dc-with-docker | source | git@git.hogeserver.hogeddns.jp:rohhie/Samba-ad-dc-with-docker.git | +--------+-------------------------+--------+-------------------------------------------------------------------+
イシューの操作
例えば、イシューを操作しようとしたら、どういう感じになるのか試してみよう。
使えるコマンドを聞いてみる。
$ tea issue --help
NAME:
tea issues - List, create and update issues
USAGE:
tea issues command [command options] [<issue index>]
DESCRIPTION:
Lists issues when called without argument. If issue index is provided, will show it in detail.
COMMANDS:
list, ls List issues of the repository
create, c Create an issue on repository
reopen, open Change state of an issue to 'open'
close Change state of an issue to 'closed'
help, h Shows a list of commands or help for one command
…
早速一覧を表示させてみよう。
$ tea issue ls NOTE: no gitea login detected, falling back to login 'hoge' Remote repository required: Specify ID via --repo or execute from a local git repo.
リポジトリのあるディレクトリにいると、そのリポジトリに対する操作になるようだ。
$ cd Samba-ad-dc-with-docker/ $ tea issue ls +-------+-------------------+-------+--------+-----------+-------------+ | INDEX | TITLE | STATE | AUTHOR | MILESTONE | LABELS | +-------+-------------------+-------+--------+-----------+-------------+ | 6 | ほげほげ | open | rohhie | | help wanted | | 4 | ほげほげ | open | rohhie | | bug | +-------+-------------------+-------+--------+-----------+-------------+ $ tea issue 4 #4 ほげほげ (open) @rohhie created 2022-09-10 11:18 …
イシューを作ってみる。
$ tea issue create ? Target repo: rohhie/Samba-ad-dc-with-docker ? Issue title: ほげほげ3 ? Issue description: [Enter 2 empty lines to finish]teaコマンドを使ってイシューを作ってみる。 問題が発生した時に、サッとメモとして書き込めるのは良い。 ? Issue description: teaコマンドを使ってイシューを作ってみる。 問題が発生した時に、サッとメモとして書き込めるのは良い。 ? Assignees: rohhie ? Milestone: [none] ? Labels: help wanted ? Due date: #7 ほげほげ3 (open) @rohhie created 2022-09-24 19:08 teaコマンドを使ってイシューを作ってみる。 問題が発生した時に、サッとメモとして書き込めるのは良い。 https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker/issues/7
現時点ではコメントの管理や、細かなステータスの変更、タイムトラッカーの開始など、細かな操作はできないように見える。
でも、AssigneesとMilestoneは選択式で、イシューはとても作りやすかった。
将来は実装されるかもしれないし、使えるところはどんどん便利に使っていけばいいと思う。
とにかく使ってみる
Gitのことはよく分かっていないけれども、今すぐに管理をはじめたいファイルがある。
Samba ad dcをDockerで動かすための学習をしており、3つのホストで個別にファイルを管理していたので、題材としてちょうどいい。
早速やってみよう。
リポジトリの作成
リポジトリという言葉自体は色々な場所で聞くけれども、何を指しているのだろうか。
リポジトリについて
リポジトリには、プロジェクトのすべてのファイルと各ファイルの改訂履歴が含まれています。
Github Docs / リポジトリについて
リポジトリ内でプロジェクトの作業について話し合い、管理できます。
Giteaでは、右上の＋から、新しいリポジトリを作成することができる。
試しに、こんな設定でリポジトリを作る。
適用するライセンスは、良く考えて設定する必要がある。
Qiita / GitHubで公開したソースにオープンソースライセンスを適用
| 項目 | 設定値 |
|---|---|
| オーナー | rohhie(最初から設定されている) |
| リポジトリ名 | Samba-ad-dc-with-docker |
| 公開/非公開 | リポジトリをプライベートにする チェックなし |
| 説明 | 簡単な説明文を入力。 |
| テンプレート | 無指定 |
| イシューラベル | 無指定 |
| .gitignore | 無指定(後で必要になって追加している) |
| ライセンス | MIT(まだちゃんと検討していないが、事実上これかなと) |
| README | Default |
| リポジトリの初期設定 | .gitignore、ライセンスファイル、READMEファイルの追加 チェックあり |
| デフォルトブランチ | main(最近はmasterではなくmainらしい) |
| 署名トラストモデル | デフォルトのトラストモデル |
| テンプレートリポジトリにする | チェックなし |
すると、このようなリポジトリができあがった。
リポジトリのファイルを取り出す
ここに説明があって、一通り読んでおくと、色々なことができるようになると思う。
Git / Documentation / Book
読みながら色々とやってみる。
まず、HTTPSで接続するのだけれど、サーバーが自己署名証明書を提示するので、オレオレ認証局をシステムに登録しておく。
$ cat <<EOF | sudo tee /usr/local/share/ca-certificates/ca.crt > /dev/null -----BEGIN CERTIFICATE----- <証明書の中身> -----END CERTIFICATE----- EOF $ sudo update-ca-certificates
とりあえず、Giteaからデーターを取り出す。
言い換えると、リモートリポジトリSamba-ad-dc-with-dockerのクローンをローカルに作る、ということになるのかと思う。
$ git clone https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git
どんな状態になったのか確認してみる。
$ cd Samba-ad-dc-with-docker $ ll total 20 drwxrwxr-x 3 rohhie rohhie 4096 Sep 6 07:32 ./ drwxr-x--- 8 rohhie rohhie 4096 Sep 6 07:32 ../ drwxrwxr-x 8 rohhie rohhie 4096 Sep 6 07:32 .git/ -rw-rw-r-- 1 rohhie rohhie 1078 Sep 6 07:32 LICENSE -rw-rw-r-- 1 rohhie rohhie 74 Sep 6 07:32 README.md $ git branch * main
ファイルをアップロードする
ライセンスファイルを書き換えたので、Giteaにアップロードしよう。
ローカルリポジトリでコミットする。
$ git commit -a -m "ライセンスファイルを更新"
[main 09ad10f] ライセンスファイルを更新
Committer: rohhie <rohhie@party.hogeserver.hogeddns.jp>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly. Run the
following command and follow the instructions in your editor to edit
your configuration file:
git config --global --edit
After doing this, you may fix the identity used for this commit with:
git commit --amend --reset-author
1 file changed, 2 insertions(+), 2 deletions(-)
ユーザー名とホスト名から、名前とメールアドレスが自動的に設定されました。それらが正確であることを確認してください。これらを明示的に設定することで、このメッセージを表示しないようにすることができます。以下のコマンドを実行し、エディタの指示に従って設定ファイルを編集してください。
DeepL先生の翻訳
git config --global --edit
この後、このコミットで使用した ID を次のようにして修正します。
git commit --amend --reset-author
名前とメールアドレスを設定しておく必要があるのか。なるほど。
Qiita / エラー：fatal: Not a git repository (or any of the parent directories): .git 対処方法
Qiita / gitconfig の基本を理解する
$ git config --global user.name "rohhie" $ git config --global user.email "rohhie@rohhie.net"
コマンド実行の結果、以下のファイルが作成された。
~/.gitconfig
[user]
name = rohhie
email = rohhie@rohhie.net
コミッターの表示がおかしいので、一旦ディレクトリごと削除して、もう一度。
$ cd ../ $ rm -rf Samba-ad-dc-with-docker/ $ git clone https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git $ cd Samba-ad-dc-with-docker/
ライセンスファイルを変更してコミットする。
$ git commit -a -m "ライセンスファイルを更新" [main 09ad10f] ライセンスファイルを更新 1 file changed, 1 insertions(+), 1 deletions(-)
コミットをGiteaに伝える。
ローカルリポジトリの変更を、リモートリポジトリにプッシュする。
$ git push origin main Username for 'https://git.hogeserver.hogeddns.jp': rohhie Password for 'https://rohhie@git.hogeserver.hogeddns.jp': <rohhieのパスワード> Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 347 bytes | 392.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 remote: . Processing 1 references remote: Processed 1 references in total To https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git 7930b1e..09ad10f main -> main
Giteaで確認してみると、コミットした際のコメントが表示され、ファイルの内容も更新されていた。
ファイルを追加する
今まで、手作業で管理していたファイルをリポジトリに追加してみる。
具体的には、作業用ディレクトリにsambaというサブディレクトリを作り、そこに関連ファイルをコピーしてきた。
$ git commit -a -m "作業中のファイルを登録"
On branch main
Your branch is up to date with 'origin/main'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
samba/
nothing added to commit but untracked files present (use "git add" to track)
コミットで-aを指定したので、追加したディレクトリやファイルが自動的に登録されると思ったのだが、manで確認してみると、Gitに伝えて管理対象にしておかないと何もしないそうだ。
Gitに追加したディレクトリを知らせる。
$ git add samba/
改めてコミットしてみる。
$ git commit -a -m "作業中のファイルを登録" [main ffb438c] 作業中のファイルを登録 8 files changed, 599 insertions(+) create mode 100644 samba/Dockerfile create mode 100644 samba/baseimage/Dockerfile create mode 100644 samba/docker-compose.yml create mode 100755 samba/packages/backup.sh create mode 100755 samba/packages/config-primary.sh create mode 100755 samba/packages/config-restore.sh create mode 100755 samba/packages/config-secondary.sh create mode 100755 samba/packages/restore.sh
リモートリポジトリにプッシュする。
$ git push origin main
Giteaにファイルが追加された。
ローカルリポジトリの状況を確認する
不足しているファイルがあったので追加し、一部のファイルを修正した。
$ git status
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: samba/docker-compose.yml
Untracked files:
(use "git add <file>..." to include in what will be committed)
samba/docker-compose.yml.primary
samba/docker-compose.yml.restore
samba/docker-compose.yml.secondary
samba/entrypoint.sh
samba/packages/cert/
no changes added to commit (use "git add" and/or "git commit -a")
修正したファイルは、確かに samba/docker-compose.yml で間違いない。
not stagedという状態になっているので、コミット対象になっていない。
追加したファイルがたくさんあるが、これも間違いはない。
Gitに管理対象として伝えていないので、これもコミット対象にならない。
やっているうちにだんだん分かってきたのだけれど、コミットは変更をひとくくりにして登録するもの。
後から、「この変更を入れた時、他に何をしたのか」という見方をすることがあるので、変更したものを一切合切ステージに上げて適当なコメントでコミットすると、困ったことになることがある。だから、◯◯の変更をコミットする、となったら、関係するファイルだけをステージに上げてコミットするのが良いと思う。
今回は、不足しているファイルが見つかったという理由なので、全部一括でステージに上げてコミットする。
$ git add . ← これですべてのファイルが追加される。
$ git status
On branch main
Your branch is up to date with 'origin/main'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: samba/docker-compose.yml
new file: samba/docker-compose.yml.primary
new file: samba/docker-compose.yml.restore
new file: samba/docker-compose.yml.secondary
new file: samba/entrypoint.sh
new file: samba/packages/cert/ca.crl
new file: samba/packages/cert/ca.crt
new file: samba/packages/cert/server.crt
new file: samba/packages/cert/server.key
$ git commit -m "不足しているファイルを"
コミットメッセージを修正する
早速やっちゃいました。コミットするときにメッセージを間違えてしまった。
$ git commit --amend
テキストエディタが起動するので、メッセージを修正して保存。
不足しているファイルを追加
# Please enter the commit message for your changes. Lines starting
…
直前のコミットを取り消す
よくよく考えると、「不足しているファイルを追加」というコミットに、一部修正が紛れ込んでいる。
まだ、Giteaにアップロードしていないので、コミットを取り消してやり直そう。
$ git reset --soft HEAD^
HEAD^という表記が、1つ前という意味になるようだ。
Qiita / 【やっとわかった！】gitのHEAD^とHEAD~の違い
これで、HEADが指し示すコミットが、ファイルを追加する前に戻る。
具体的には、こういうことになっている。
$ git reflog ae009f0 (HEAD -> main, origin/main, origin/HEAD) HEAD@{0}: reset: moving to HEAD^ 52e4e45 HEAD@{1}: commit (amend): 不足しているファイルを追加 2cf58f6 HEAD@{2}: commit: 不足しているファイルを ae009f0 (HEAD -> main, origin/main, origin/HEAD) HEAD@{3}: commit: 作業中のファイルを登録 baedd43 HEAD@{4}: commit: ライセンスファイルを更新 ff5197b HEAD@{5}: clone: from https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git
コミットを取り消すことができた。
特定のファイルをコミットの対象から外す
誤ってコミットに紛れ込んでしまった「変更したファイル」をステージから下ろす。
やり方は、git statusで状況を聞けば、親切に教えてくれる。
$ git restore --staged samba/docker-compose.yml
追加したファイルだけを対象にできたので、コミットする。
$ git commit -m "不足しているファイルを追加"
変更点は変更点で、コメントを付けて追加する。
$ git add samba/docker-compose.yml $ git commit -m "サーバーのIPアドレスを本番用に変更"
修正結果をリモートリポジトリにプッシュする。
$ git push origin main
Giteaで変更結果が登録されていることが確認できた。
変更点を確認する
ステージに上がっていないファイルを、最新のコミットと比較する。
$ git diff
diff --git a/samba/docker-compose.yml b/samba/docker-compose.yml
index ae4efca..df73ee1 100755
--- a/samba/docker-compose.yml
+++ b/samba/docker-compose.yml
@@ -11,7 +11,7 @@ services:
SMB_REALM: HOGESERVER.HOGEDDNS.JP
SMB_DOMAIN: HOGEDOMAIN
SMB_ADMINPASS: p@ssword123
- SMB_HOSTIP: 192.168.110.10
+ SMB_HOSTIP: 192.168.110.12
SMB_RPC_PORTS: 49152-49200
SMB_PURPOSE: "primary"
SMB_USEBIND9: "true"
ステージに上がっているファイルを比較する時は、パラメーターを追加する。
$ git add samba/docker-compose.yml
$ git diff --staged
様々な比較ができるとのこと。
Qiita / 忘れやすい人のための git diff チートシート
特定のファイルを無視する
作業中、Samba ad dcのバックアップをいくつか作成しているが、このファイルを無視したい。
git ignoreを使ってファイルを無視する方法【初心者向け】
無視したいファイルが3つ入っているところ。
$ git status
On branch main
Your branch is up to date with 'origin/main'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
samba/packages/backup-addc-2022-08-28-12-49-38_001.tar.gz
samba/packages/backup-addc-2022-08-28-19-51-26_001.tar.gz
samba/packages/backup-addc-2022-09-04-23-59-15.tar.gz
nothing added to commit but untracked files present (use "git add" to track)
このプロジェクトに.gitignoreファイルを作成し、除外するファイルやディレクトリを定義。
<work dir>/.gitignore
*.gz
他の作業環境でもバックアップが置かれる可能性を考慮して、.gitignoreファイル自体を管理対象にしている。
もし、管理対象にしたくないなら、.gitignoreをファイルの中に書いておけば良い。
$ git add .gitignore $ git commit -m "バックアップファイルを無視するようにした" $ git push origin main
ファイル名の変更
Gitの管理対象になっているファイルの名前を変更する場合、gitコマンドで変更する。
$ git mv hoge.cfg fuga.cfg
でも、実際はmvしても同じ結果が得られる。
Qiita / Git で管理しているファイルのリネームを git mv でなく mv してしまったときにどうなるのか調べてみた
リモートの更新を受け取る
ホスト1でクローンした後、ホスト2でクローン。
ホスト2では、色々と修正点があってGiteaを更新した。
このとき、ホスト1で状態を確認したところ、変更点はないように見えた。
$ git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean
ホスト1としては、最新状態という認識になっている。
この更新をホスト1で受け取るにはどうしたらいいのか。
$ git pull remote: Enumerating objects: 14, done. remote: Counting objects: 100% (14/14), done. remote: Compressing objects: 100% (10/10), done. remote: Total 10 (delta 7), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (10/10), 2.21 KiB | 90.00 KiB/s, done. From http://git.hogeserver.hogeddns.jp:3000/rohhie/Samba-ad-dc-with-docker aa05cc8..0815323 main -> origin/main Updating aa05cc8..0815323 Fast-forward samba/docker-compose.yml.secondary | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ samba/packages/config-secondary.sh | 27 +++++++++++++++++++++++++- 2 files changed, 106 insertions(+), 1 deletion(-) create mode 100644 samba/docker-compose.yml.secondary
この、ファイルを取ってくるとは、ローカルにあるremotes/origin/mainにGiteaのmainをフェッチしてきて、それをmainにマージしているのだそう。
Qiita / 【初心者向け】git fetch、git merge、git pullの違いについて
どういうことなのか確認してみると…
$ git branch -a * main ← (2) ここにremotes/origin/mainの状態がマージされる remotes/origin/HEAD -> origin/main remotes/origin/main ← (1) ここにリモートの状態が取り込まれる $ git remote -v origin https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git (fetch) origin https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker.git (push)
なるほど。だから、git push origin mainなのか。
タグを付ける
Giteaの画面でもチラチラ見えているタグ、ローカルで付けることができる。
Git book / 2.6 Git の基本 - タグ
タグには軽量版と注釈付きがある。
過去のコミットにもタグを付けることができるということなので、過去の状態を見てみる。
$ git log --pretty=oneline 4a220350dd52a84ab27820f9f5654487d7519801 (HEAD -> readme, origin/readme) READMEの拡充 … 945a8643dfd6412bcb2f5b1867065a8fa02d0507 サーバーのIPアドレスを本番用に変更 aa4535b82e195d12eb0b8791a9a8bed39c5cc157 不足しているファイルを追加 … ff5197bba15cd89c09be6238416b119ba49ab4c2 Initial commit
軽量版のタグと、注釈付きのタグを作ってみる。
$ git tag v0.9.0 aa4535b82e195d12eb0b8791a9a8bed39c5cc157 $ git tag v0.9.1 945a8643dfd6412bcb2f5b1867065a8fa02d0507 -a -m "概ね動く状態になったバージョン"
軽量版はこのように見える。
$ git show v0.9.0
commit aa4535b82e195d12eb0b8791a9a8bed39c5cc157 (tag: v0.9.0)
Author: rohhie <rohhie@rohhie.net>
Date: Fri Sep 23 11:15:11 2022 +0000
不足しているファイルを追加
…
注釈付きはこのように見える。
$ git show v0.9.1
tag v0.9.1
Tagger: rohhie <rohhie@rohhie.net>
Date: Sat Sep 24 06:17:14 2022 +0000
概ね動く状態になったバージョン
commit 945a8643dfd6412bcb2f5b1867065a8fa02d0507 (tag: v0.9.1)
Author: rohhie <rohhie@rohhie.net>
Date: Fri Sep 23 12:34:00 2022 +0000
サーバーのIPアドレスを本番用に変更
これをリモートリポジトリにプッシュするには、タグを指定する必要がある。
$ git push origin v0.9.0 v0.9.1
これでGiteaでもタグの情報が見られるようになった。
ファイルの変更履歴を見る
あるファイルの過去の状態を見たくなった。
Tips of Rubbish / [GIT] 特定のファイルの変更履歴や過去のデータ内容を確認する方法
$ git log -p samba/docker-compose.yml.primary
これで、どのコミットでどんな変更をしたのか見ることができた。
過去のファイルを取り出す
ファイルの変更履歴を見て、どのコミットがそれだったか分かった。
このファイルを取り出してみる。
$ git restore --source=633fb133412d11a5dc497861dabc39870f0ca488 samba/docker-compose.yml.primary
これを直前のコミットの状態に戻すこともできる。
$ git restore samba/docker-compose.yml.primary
ローカルからはじめる
ローカルでリポジトリを作って作業し、後からGiteaにそれを登録したくなったらどうするのか調べてみたところ、手順は
- ローカルでリポジトリを作る。
- Giteaに空のリポジトリを作る。
- ローカルのリポジトリをプッシュする。
となった。
ローカルでリポジトリを作る
Giteaでリポジトリを作成するとき、デフォルトブランチがmainになっていた。
よく見るのはmasterというブランチだったので、ちょっと情報を探してみたら、mainにする流れのようではある。
Qiita / git v2.28でデフォルトブランチをmainに変更する
そこで、デフォルトで作られるブランチがmainになるように設定。
$ git config --global init.defaultBranch main
ローカルリポジトリを作る。
$ git init Initialized empty Git repository in /home/rohhie/Ubuntu-docker/.git/ ■先程の指定をしていない場合、変更方法を教えてくれる。 $ git init hint: Using 'master' as the name for the initial branch. This default branch name hint: is subject to change. To configure the initial branch name to use in all hint: of your new repositories, which will suppress this warning, call: hint: hint: git config --global init.defaultBranch <name> hint: hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and hint: 'development'. The just-created branch can be renamed via this command: hint: hint: git branch -m <name>
ローカルのファイルをステージして、コミットする。
$ git add . $ git commit -m "initial commit"
Giteaに空のリポジトリを作る
teaコマンドを使用して、Giteaに空のリポジトリを作る。
$ tea repo create --name Ubuntu-with-docker NOTE: no gitea login detected, falling back to login 'git.hogeserver.hogeddns.jp' rohhie/Ubuntu-with-docker (empty) Issues: 0, Stars: 0, Forks: 0, Size: 76 Kb Updated: 2022-09-17 16:26 (0s ago) ~ Browse: https://git.hogeserver.hogeddns.jp/rohhie/Ubuntu-with-docker ~ Clone: git@git.hogeserver.hogeddns.jp:rohhie/Ubuntu-with-docker.git ~ Permission: admin https://git.hogeserver.hogeddns.jp/rohhie/Ubuntu-with-docker
空のリポジトリが作成されたようだ。
Giteaでそのリポジトリを見てみると、このようにかなり親切に教えてくれている。
ローカルのリポジトリをプッシュする
最初に作ったリポジトリを、Giteaにプッシュする。
$ git remote add origin git@git.hogeserver.hogeddns.jp:rohhie/Ubuntu-with-docker.git $ git push -u origin main Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 2 threads Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 587 bytes | 587.00 KiB/s, done. Total 5 (delta 0), reused 0 (delta 0), pack-reused 0 remote: . Processing 1 references remote: Processed 1 references in total To git.hogeserver.hogeddns.jp:rohhie/Ubuntu-with-docker.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'.
Giteaから確認してみたところ、ファイルが登録されている。
これで、ローカルではじめた作業をそのままGiteaで管理できるようになった。
ブランチ
最初にGiteaでリポジトリを作成するとき、ブランチの名前をmainとしていた。
ブランチについて、こちらで教えてくれている。
Git / 3.1 Git のブランチ機能 - ブランチとは
何か変更を加えるときには、作業用のブランチを作成して作業し、できあがったらマージする。
こうすると、作業中に他の誰かがソースを求めたときに、作業中のファイルを提供せずに済む。
[Master]---+------(1)------+---[Master(merged)]
| |
+---[Working]---*
時間の経過 -->
※ある日作業が発生したら、ブランチWorkを作成。(1)の期間は他の人には変更が影響しない。作業が終わったらWorkingをMasterに統合する。
複数人で作業をするなら、ブランチを使って作業するのは必然なのだろう。
そういえば、ブランチってどんな名前を付けるのが良いのかな、命名規則を探してみようと思って探していたら、フローにたどり着いた。
Github flowがシンプルで、学習する身としてまずはこれかなと。master(main)ブランチが常に安定版。
ブランチには短い説明的な名前を付けることで、作業が一目で分かるようになる、とされている。
色々なところで見かけるプロっぽい厳格なものにgit-flow(日本語訳)と呼ばれるモデルがある。
記事を読んでいくと、Branch naming convention(ブランチの命名規則/日本語訳ではブランチ名の習慣)という形で記載されている。
Gitは自由度が高いので、こういったモデルを参考にして、現場にあったものを考えていくのだろう。
ブランチの作成
最初はmainブランチだけが存在する状態。
[ main ]-@--------------------[main(merged)]
時間の経過 -->
作業を開始する前にブランチを作る。
$ git branch working
[ main ]--@+-------------------[main(merged)] | +---[Working] 時間の経過 -->
そのブランチに移動する。
$ git checkout working Switched to branch 'working'
[ main ]---+-------------------[main(merged)]
|
+-@-[Working]
時間の経過 -->
作成したブランチをリモートリポジトリにプッシュする。
$ git push origin working
Giteaで見てみたところ、ブランチが作られており、切り替えができるようになっていた。
ブランチの統合
ブランチでの作業が完了してコミットした。
$ git commit -a -m "変更内容を説明" $ git push origin working
変更をブランチmainにマージするときには、誰かにレビューをしてもらう訳だけれども。
今は一人で作業しているので、簡単に差分を確認。
$ git diff main working diff --git a/README.md b/README.md index 506f001..967762a 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,5 @@ # Samba-ad-dc-with-docker -Samba-ad-dcをDockerで気軽に利用する。 \ No newline at end of file +Samba-ad-dcをDockerで気軽に利用する。 + +説明を追加。
マージ作業はブランチmainで行うので、そちらに移動する。
$ git checkout main Switched to branch 'main' Your branch is up to date with 'origin/main'.
[ main ]---+-------------@-+---[main(merged)]
|
+---[Working]-
時間の経過 -->
このとき、ブランチworkingで行った変更が元の状態(ブランチmainの状態)に戻った。
もし、コミットしていないファイルがあった場合、それは元の状態に戻ることはなく、ブランチmainで変更されているファイルとして扱われる(ファイルが消失することはなかった)。
さて、ブランチworkingを、ブランチmainにマージする。
$ git merge working Updating 8e40dbc..0ddd9c1 Fast-forward samba/docker-compose.yml | 1 + 1 file changed, 1 insertion(+)
[ main ]---+---------------@---[main(merged)]
| |
+---[Working]---+
時間の経過 -->
Fast-forwardと表示されているが、これは、変更点がworkingで行われたことだけだったので、HEADがworkingのコミットに移動したことを教えてくれている。
Qiita / fast-forwardマージから理解するgit rebase
$ git reflog 0ddd9c1 (HEAD -> main, working) HEAD@{0}: merge working: Fast-forward 8e40dbc HEAD@{1}: checkout: moving from working to main 0ddd9c1 (HEAD -> main, working) HEAD@{2}: commit: コメントを追加 …
もしも、マージする時にブランチmainに変更があると、マージするのにコメント入力が求められる。
※画面遷移を記すのが難しかったので、ここではパラメーターでコメントを指定している。
$ git merge working -m "workingで行われた変更をマージ" Merge made by the 'ort' strategy. samba/Dockerfile | 1 - 1 file changed, 1 deletion(-)
ort戦略でマージされ、新しいコミットが作られた。
$ git reflog
83aeef3 (HEAD -> main) HEAD@{0}: merge working: Merge made by the 'ort' strategy.
c3da65f HEAD@{1}: commit: ブランチmainで行った変更
8d7fd00 HEAD@{2}: checkout: moving from working to main
d593a72 (working) HEAD@{3}: commit: ブランチworkingで行った変更
…
Fast-forwardとort戦略によるマージのどちらだったのか、という点を掘り下げたが、どちらも概念的には「ブランチworkingをブランチmainに統合した」と捉えて良いと思う。
統合が完了したので、ブランチworkingを削除しておく。
$ git branch -d working
[ main ]---+-----------------@-[main(merged)]
|
+---[Working]---*
時間の経過 -->
マージした結果をリモートリポジトリにプッシュする。
$ git push origin main
これで、リモートリポジトリにブランチが統合されたところまでは伝えることができる。
しかし、Giteaでブランチの一覧を見ると、ブランチworkingは残っていて埋没と表示されている。
埋没のところをマウスカーソルをポイントしたところ、デフォルトブランチに含まれているとの表示がされた。
リモートリポジトリのブランチを削除するにはどうすれば良いか。
freeCodeCamp / Git ブランチを削除する方法 (ローカル、リモート)
$ git push origin --delete working
これで、Giteaでもブランチworkingが削除された。
他のブランチのファイルを持ってくる
ブランチを切り替えると、ファイルがきれいに入れ替わる。素晴らしい仕組みだなと思う。
だけど、他のブランチにあるファイルを持ってきたいと思った。
Zenn / git restoreで他のブランチからファイル単位で取り込む
$ git restore --source <branchname> <filename>
以前のコミットのファイルを持ってくることもできる。
1つ前のコミットのREADME.mdを持ってくるのに、このような書き方ができる。
$ git restore --source main^ README.md
過去の状態に戻す
この操作は、ローカルで他に影響を与えない範囲でやっている分には良いが、Giteaにプッシュした履歴に対して行うと、他のユーザーに影響を与えるように思う。
やるなら、何をどの範囲でやっているのかということをよく整理してから…です。
上流のコミットにリベースしたが、リベースする前に戻したくなった(マージを試すため)。
これに限らず、過去の状態に戻そうと思うこともあるかもしれない。
戻したい場所を探すのに、HEADのログを見てみた。
$ git reflog
a06eb93 (HEAD -> main, upstream/main, origin/main, origin/HEAD) HEAD@{0}: rebase (finish): returning to refs/heads/main
a06eb93 (HEAD -> main, upstream/main, origin/main, origin/HEAD) HEAD@{1}: rebase (start): checkout upstream/main
4aaf9dc (origin/smallfixed) HEAD@{2}: checkout: moving from 4aaf9dc7e0bc7d0cb51faddeec4fff4b09184c7d to main
4aaf9dc (origin/smallfixed) HEAD@{3}: checkout: moving from main to origin/main
…
戻したい先のコミットは4aaf9dcだと分かったので、リセットする。
$ git reset --hard 4aaf9dc
※リベースしてみたけれども、その先のコミットを取り込んでしまうので、
これで、ローカルのファイルが元の状態に戻った。
これをGiteaにプッシュする。通常、コミットを失うような更新は拒否されるため、-f(--force)を付けて無理矢理更新している。
$ git push -f origin main
これで、Giteaも元の状態に戻った(というか、元のコミットを指し示す状態になった)。
Giteaの機能
Giteaにはかなり多くの便利な機能が実装されている。よく調べて使いこなしていきたい。
Giteaの機能はGithubに似ているので、理解が進むとGithubに表示されている情報が何を示しているのか、何が行われているのかを理解できるようになるという、副次的な効果もある。
イシュー
Giteaでは、バグ報告や新機能に関する議論、質問などをイシューで行うようだ。
イシューを作成する画面では、ブランチ、ラベル、マイルストーン、プロジェクト、担当者が指定できるようになっている。
ラベルを表示させたところ0件となっていて、定義済みのラベルセットが追加できるようになっていた。
クリック1つで7つのラベルが作成された。
| ラベル名 | 説明 | DeepL先生の翻訳 |
|---|---|---|
| bug | Something is not working | 何かがうまくいかない |
| duplicate | This issue or pull request already exists | この課題またはプルリクエストはすでに存在している |
| enhancement | New feature | 新機能 |
| help wanted | Need some help | 助けが必要 |
| invalid | Something is wrong | 何かがおかしい |
| question | More information is needed | より詳細な情報が必要 |
| wontfix | This won't be fixed | これは修正されない |
このリポジトリに書き込み権限がない場合、イシューを作成できるが、ラベルやマイルストーンを設定することができない。
これらの属性情報は、リポジトリの運営関係者が整理して、運営しやすくするためにあるのだろう。
イシューには、タイムトラッカーという機能が付いている。
イシューの作業を始める時にタイマーを開始し、終えたら終了させる…というのを繰り返していくと、掛かった時間の合計が表示される。
マイルストーン
マイルストーンは、イシューとプルリクエストをひとまとめにして管理するための仕組み。
イシューを作る時、プルリクエストを作る時に、マイルストーンの指定ができる。あるいは、あとからリポジトリの運営関係者が指定する。
マイルストーンを作った直後はオープン・クローズ0件の状態。
- イシューやプルリクエストにマイルストーンを設定すると件数が増える。
- イシューやプルリクエストがクローズすると、進捗率があがる。
作成したいくつかのイシューにマイルストーンを割り付けてみた。
すると、マイルストーンに件数が表示され、クローズすると進捗率が上がるという、実にわかりやすい作りになっていた。
プロジェクト
プロジェクトは、イシューやプルリクエストをカンバン方式で管理するための仕組み。
プロジェクトテンプレートは「基本的なカンバン」と「バグ トリアージ」が用意されていた。
※トリアージというのは、バグの対応優先度を決めることのよう。この手の話は日本語で済ませていたので、ちょっと調べることになった。
テンプレート「基本的なカンバン」で作られるプロジェクトボード
→ 未分類、To Do、In Progress、Done
テンプレート「バグ トリアージ」で作られるプロジェクトボード
→ 未分類、Needs Triage、High Priority、Low Priority、Closed
イシューやプルリクエストを割り付けた時、プロジェクトボードの未分類入る。
プロジェクトボードは、追加・削除・編集ができる。好きなカンバンを作って管理できるが、未分類だけは編集も削除もできない。
作成したイシューにマイルストーンを割り付けてみた。
すると、プロジェクトにカードができて、オープンのものは緑のアイコン、クローズのものは赤のアイコンで表示される。カードは、ドラッグ＆ドロップで表示順序を変えることができて、他のプロジェクトボードに移動させることもできる。
見てすぐに状態が分かるように整理できて、これも実にわかりやすい。
さて、プロジェクトとマイルストーンは似た機能だなと思うのだけれども、どう使い分けるのが良いのか。
StackOverflow / What is the difference / relationship between GitHub Projects and Milestones?
一番多くのいいねを獲得している回答から抜粋。
So the way I see it, is that Projects are a completely separate way to visualize and organize your work on an higher level (think "project management", multiple teams, multiple repository, etc.), while Milestones are a way to organize your deadlines and releases on a more basic level (think "release management", "versions", etc.). With this in mind, it makes sense that an issue only belongs to one Milestone (it's only released or pushed to production once) but can be part of different Projects.
つまり、プロジェクトは、より高いレベルで作業を可視化し整理するための完全に別の方法であり（「プロジェクト管理」、複数のチーム、複数のリポジトリなどを考えてください）、マイルストーンはより基本的なレベルで締切やリリースを整理するための方法です（「リリース管理」、「バージョン」などを考えてみてください）。このことを考えると、1つの課題は1つのマイルストーンにしか属さない（1度だけ本番環境にリリースまたはプッシュされる）が、異なるプロジェクトに属することができるのは理にかなっていると言えます。
DeepL先生の翻訳
2017年に追記されていることは、こんなところかと。
| 機能 | 用途 |
|---|---|
| マイルストーン | スクラム開発のためのツール。 タイムボックスの反復(事前に期間で合意。制限時間に達した時点で達成度を評価することを繰り返す)や、いくつかのイシューをまとめて取り扱うスプリント(チームが一定量の作業を完了させるための短く区切られた期間)での作業に向いている。 |
| プロジェクト | カンバン方式のためのツール。 継続的な配信、安定した業務フローに向いている。 |
管理する作業の規模によって、選択は変わってくるかもしれない。
もちろん両方使ったっていい話だし、管理しやすい方を使いましょ。
個人のレベルでは、時間の区切りなく、目的もコロコロ変わるという、ダラダラしたアジャイルっぽいことをやっているかなと思うので、基本的にはマイルストーンがいいかな。
でも、思いついたテーマがスゴく多い時には、カンバンで管理してイシューを動かしていくというのは、残量が目に見えていいかもしれない。
タグとリリース
ローカルで作ったタグもちゃんとGiteaに表示されていて、タグを選択するとその時点のファイルが表示される。
また、zipやtar.gzでその時点のソースをダウンロードすることもできる。
そして、タグをベースにリリースを作成する。
リリース情報には、タイトル、内容を付け加えることができ、利用者にどのようなバージョンなのかを細かく知らせることができる。
「プレリリース」にチェックを入れておくと、オレンジでプレスリリースの表示がなされ、本番適用には向かないことが分かるようになる。
Giteaでは、リリースを作成するインターフェースが用意されている。
そこで「タグのみ作成」というボタンが用意されており、タグだけを作成することもできる。
Wiki
プロジェクトに配置されているREADME.mdファイルを編集すれば、かなりかっこよく説明文を置いておけるんだけれど、Wikiというのが気になる。
新規にページを作った時、Homeという名前を付けると、それがWikiのホームページになる。
_Sidebarという名前を付けると、どのページでも右ペインに表示されるサイドバーになり、_Footerという名前を付けると、同様にページの最後に必ず表示される。
とりあえず、Home、Usageの2つのページを作ってみた。
サイドバーには、ページを切り替えるためのリンクを貼ってみようかな。
目次 * [ホーム](https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker/wiki/Home) * [使い方](https://git.hogeserver.hogeddns.jp/rohhie/Samba-ad-dc-with-docker/wiki/Usage)
フッターって何を置くのかな？と思ったけれど、とりあえず著作権表示でも置いてみようか、と思った。
マークダウンが使える訳なんだけれども、文字列をセンタリングするにはどうしたらいいのか。
<p align="center">Copyright (c) 2022 rohhie.</p>
※インラインでHTMLが書けるのか。
枠組みができた。あとからゆっくりと充実させていけばいいと思う。
GPGキー
GPGキーでコミット・タグに署名し、そのコミット・タグがその人本人によって行われたことが確認できるようにする仕組み。
調べてみたところ、情報量がかなり大きくなってしまったので、別のページに切り出した。
ここでは、GPGキーを既に持っている場合についてメモしておく。
まず、署名するキーを登録する。
$ git config --global user.signingkey <キーID>
GPGキーのパスワード入力画面を表示させるため、TTYを環境変数に設定する。
毎回必要なので、.bashrcに書いておく。
~/.bashrc
# tty to enter passphrase for GPG key. export GPG_TTY=$(tty)
※最後に追加すればOK。
GPGキーの公開鍵を表示させる。
$ gpg --armor --export <キーID>
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGMxoWQBEADOQTbqqKhB2UA1P+I30dLL/IFf99YKCFDJE0k+UtrOaBn/6Cbx
…
Zagefnv79a1v0kYiQlU0nm4ZQIQRDKNmswBvkK6bBrZm+ESKNbUQWW6wM9e7vsYz
bPqbfIj63sVcTG4FYf0IH9ZQJRqSVDHhrg9QheLW623+CbpolVT45b+6
=f7QF
-----END PGP PUBLIC KEY BLOCK-----
ここで表示された鍵、つまり
-----BEGIN PGP PUBLIC KEY BLOCK-----
から
-----END PGP PUBLIC KEY BLOCK-----
までをコピーしてGiteaに貼り付け、キーを追加する。
これで準備はできた。
コミットする際に-Sを付けて署名する。
Github docs / コミットに署名する
$ git commit -S -m "コミットする際のメッセージ"
タグへの署名の仕方もこちらで教えてくれた。
Github docs / タグに署名する
$ git tag -s 1.0.0
パッケージ(断念)
Giteaの1.17からパッケージレジストリが使えるようになった、と書かれている。
Gitea Docs / Package Registry
アプリケーション開発者には、きっと待望の機能なのだろう。
でも、そもそもGitが分かっていないところからスタートしている身としては、ちょっと学習範囲が広すぎるので、いつかまた。
もしも、当面サービスを提供しないから表示を止めておきたい、という場合は以下の設定を追加しておく。
$ sudo docker exec -it gitea vi /data/gitea/conf/app.ini
[packages] ENABLED = false
複数人で作業をする
1人で使った場合の機能を色々とみてきたが、複数人で作業をする場合に、どのようなことができるのか試してみる。
Ubuntu 22.04でPartyというホストを作り、最近作ったSamba ad dcのドメインに参加させた。
ドメインには3人のユーザーがいて、それぞれこんな役割で共同作業がどういうものなのかを試してみる。
| ユーザー | 役割 |
|---|---|
| rohhie | 自分 |
| hoge | 共同作業者 |
| piyo | リポジトリの外から協力する人 |
ユーザー登録
[hoge]
Chromeでプロファイルを作り、hogeとしてユーザー登録する。
[hoge]
アカウントを登録 ボタンをクリックすると、
「hoge@hogeserver.hogeddns.jp に確認メールを送信しました。 3時間以内に受信トレイを確認し、登録手続きを完了してください。」
というメッセージが表示された。
でも、メールが届かない。
このとき、サーバーのファイアウォールが不具合を起こしていたので、Giteaに問題があったわけではない。
Dockerで立ち上げたSamba ad dcが悪影響している。ufwをreloadして復旧。
[hoge]
登録したユーザーhogeでサインインする。
[hoge]
サインインしたら、アカウントの有効化を求められた。
ボタンを押したところ、メールが届いた。
こんにちは、hoge さん。 Gitea: rohhie.net へのご登録ありがとうございます！
あなたのアカウントを有効化するため、3時間以内に次のリンクをクリックしてください:
https://git.hogeserver.hogeddns.jp/user/activate?code=20220919103100018082ac3656db8e1e3af16940dbcae5e9096ccbcd5c686f6765
開かないですか？ コピーしてブラウザーに貼り付けてみてください。
© Gitea: rohhie.net
[hoge]
メールに書かれたリンクを開いたところ、パスワードを要求された。
パスワードを入力したところ、アカウントがアクティベートされた。
アバターが表示されているが、これは恐らく…Gravatarが自動的に生成してくれたものであろう。架空のメアドですいません…。
[piyo]
Chromeでプロファイルを作り、piyoとしてユーザー登録する。
今度はすぐにアクティベーションメールが送られてきて、アカウントをアクティベートすることができた。
共同作業者との作業
共同作業者(Collaborators)に権限を渡して、一緒に作業を進めていく。
[rohhie]Gitea-with-dockerというリポジトリを作って活動をはじめた。
[hoge]
SSHが使えるように、それも、パススルーの設定がいいんじゃない？と考えた。
早速、イシューでそのことを伝える。
- rohhieに新しいイシューが登録された旨のメールが届く。
- hogeはイシューにラベルを付けることができなかった。
イシューを見て、それは良い考えで、hogeにやって欲しいとコメント。
- rohhieはイシューにラベルを付けることができたので、enhancementとした。
- hogeにイシューへの返信があった旨のメールが届く。
[hoge]
ローカルでブランチを作り、そこで修正作業を開始。
$ git branch issue#1 $ git checkout issue#1[rohhie]
hogeを共同作業者に追加し、書き込みの権限を設定。
書き込み権限は、ファイルに変更を加えることができるかなり大きな権限といえる。
- 共同作業者に与えられる権限は、管理者、書き込み、読み取りの3種類だった。
- 管理者の権限を渡せば、このリポジトリをいかようにもできる。
- 読み取りは、プライベートなリポジトリを運営している時、誰かに見せるためにあるのではないかと想定。
- hogeは書き込み権限を得たことにより、リポジトリでできることが色々と増えた。
- 例えば、先程できなかったタグ付けや、プルリクエストの作成、プロジェクトの作成ができるようになった。
- ブランチを作成し、コミットをプッシュできるようになった。
- プルリクエストでマージコミットを作成することができるようになった。
- hogeに共同作業者に追加された旨のメールが届く。
[hoge]
ファイルを1つ修正し、1つ追加。コミットして、プッシュする。
$ git add . $ git commit -m "SSHパススルー対応" $ git push origin issue#1
[hoge]
Giteaで新しいプルリクエストを作成する。
マージ先:main ← プル元:issue#1 を指定して、新しいプルリクエストボタンを押したところ、メッセージを書き込む枠が表示された。
そこにどのような変更を加えたのか、という説明を書いて、プルリクエストを作成した。
- rohhieにプルリクエストが作成された旨のメールが届く。
- プルリクエストには #2 が付与された。
プルリクエストの 変更されたファイル をクリックし、差分内容を確認して、この対応が完成していると判断した。
会話 をクリックし、変更内容の説明の先にある マージコミットを作成 をクリックした。
表示される入力枠には、確認して完成していると判断したことを記入した。
- マージコミットの他に、リベース後にファストフォワード、リベース後にマージコミット作成、スカッシュコミットを作成、が選択できる。
- マージコミットを作成 をクリックしたとき、コマンドラインからこの操作をする方法が表示されていた。
これをそのままローカルで実行することもできそうだった。 - hogeに#2がマージされた旨のメールが届く。
- Giteaで確認したところ、ブランチmainに変更が反映されていた。
また、ブランチissue#1がマージ済みであることが表示されていた。
イシューにブランチissue#1を指定し、要望が実装されたことを記してクローズした。
- hogeにイシューがクローズされた旨のメールが届く。
- hogeにイシューで要望が実装された旨のメールが届く。
- ブランチissue#1を割り当てたので、クローズするだけでも良いかもしれない。
- コメントを残すなら、先にコメントを投稿してからクローズすると、メールの到着順序が変な感じにならないと想定される。
- hogeのGiteaに通知が表示され、そこからイシューに飛ぶと、通知が消えた。
これをもってリリースを作成した。
- リリースそのものでは、誰にもメールは送られなかった。
- この操作によって、タグとリリースの両方が作成された。
リリースには 安定版 と表記されている。
プルリクエスト
共同作業者でなくてもソースに手を入れることができる。
フォークして変更し、できあがったらプルリクエストを出す。
[piyo]
リポジトリGitea-with-dockerに興味を持ち、このシステムを運用しようと考えた。
だが、一部変更したい点を見つけた。そこで、フォークすることにした。
- フォークしたリポジトリは、先頭のアイコンがフォークのものに変わる。
- どこからフォークしたのかが、リポジトリの名前の下に表示される。
- エクスプローラーでリポジトリの右側にフォークのアイコンが付与される。
- コミット、ブランチ、タグといった情報がそのまま複写されている。
イシュー、ラベル、リリースは複写されない。
- rohhieのリポジトリで、フォークの数字が1増加する。
- フォークボタンは、サインインしていないと押すことができない。
[piyo]
ブランチを作り、そこで修正作業を開始。
$ git branch smallfixed $ git checkout smallfixed
[piyo]
修正結果をプッシュ。
$ git add . $ git commit -m "Small fixed." $ git push origin smallfixed
[piyo]
作ったブランチをmainにマージして、いらなくなったブランチを削除。
$ git checkout main $ git merge smallfixed $ git push origin main $ git branch -d smallfixed
- コミットとブランチがそれぞれ1つ追加されている。
- 修正に使用したブランチは 埋没 と表示される。
なお、元のリポジトリではマージ済みと表示されていた ブランチissue#1 も 埋没 と表示されている。
[piyo]
この修正をフォーク元のプロジェクトに提案するため、この小さな変更についての説明を書いて、プルリクエストを作成した。
マージ先:rohhie/Gitea-with-docker:main ← プル元:piyo/Gitea-with-docker:smallfixed
- piyo/Gitea-with-dockerのブランチsmallfixedの表示が、埋没 からプルリクエストのリンクに変わった。
それ以外にこのことを表示する場所はないように見える。 - rohhie/Gitea-with-dockerにプルリクエストが追加される。
- rohhieにはpiyoからのプルリクエストを知らせるメールが届き、Giteaでも通知が表示される。
- 共同作業者のhogeにはメールも通知も表示されない。
- プルリクエストから、コミットの状態や、変更されたファイルの状態を確認できる。
- ブランチは追加されていない。
修正内容を確認し、組み込むべきだと判断したので、マージコミットを作成した。
マージコミット作成時、ブランチ 'piyo/Gitea-with-docker:smallfixed' の削除にチェックを入れた。
- piyoに#3をmainにマージしたとのメールが届く。
- rohhieは、マージするときにメッセージを入れておいたけれど、それはメールに反映されなかった。
- Giteaでも通知が表示され、マージされたこと、ブランチが削除されたことを見ることができた。
- 実際に、piyo/Gitea-with-dockerのブランチがrohhieによって削除されていた。
- 表示させようとすると、404が表示される。
- ブランチ一覧に復元させるボタンが用意されていて、ボタンを押したら復元することができた。
- rohhie/Gitea-with-dockerのプロジェクトにマージされた。
- コミットが1つ追加された。コミット時に入力したメッセージはここで見ることができた。
- ブランチsmallfixedは削除されていたが、プルリクエストでどんな変更があったのかを確認することができた。
[piyo]
smallfixedのブランチを復元させた。
- rohhie/Gitea-with-dockerにブランチsmallfixedは表示されない。
- piyo/Gitea-with-dockerでは、ブランチが表示されて選択もできるようになった。
piyoの作成したブランチの取り扱いは、どこかでもう一度整理する必要がありそうだが、変更をrohhieに提供することができた。
上流の変更を取り込む
他のユーザーの提案を受け入れて、本家がどんどん良いものになっている。
自分の提案もマージされている本家に、新たに提案したい箇所が見つかった。
という状況を考えると、フォークした他のユーザーが、本家の変更を取り込むシーンもあるだろう。
Githubのドキュメントを見ると、ここでいう本家を上流と表現している。
フォークでどんどん枝分かれできるから、この表現なのかと思われる。
上流の変更を取り込むために、上流をポイントするリモートを作成する。
上流はrohhieのGitea-with-dockerなので、以下のコマンドで追加する。
Github docs / フォークにリモートを設定する
$ git remote add upstream git@git.hogeserver.hogeddns.jp:rohhie/Gitea-with-docker.git $ git remote -v origin git@git.hogeserver.hogeddns.jp:piyo/Gitea-with-docker.git (fetch) origin git@git.hogeserver.hogeddns.jp:piyo/Gitea-with-docker.git (push) upstream git@git.hogeserver.hogeddns.jp:rohhie/Gitea-with-docker.git (fetch) upstream git@git.hogeserver.hogeddns.jp:rohhie/Gitea-with-docker.git (push)
上流をフェッチする。
$ git fetch upstream remote: Enumerating objects: 25, done. remote: Counting objects: 100% (24/24), done. remote: Compressing objects: 100% (19/19), done. remote: Total 19 (delta 8), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (19/19), 3.29 KiB | 373.00 KiB/s, done. From git.hogeserver.hogeddns.jp:rohhie/Gitea-with-docker * [new branch] install -> upstream/install * [new branch] issue#1 -> upstream/issue#1 * [new branch] main -> upstream/main
ここから上流を取り込むが、今思いつく方法は2つ。
リベース
1つはリベース。フォーク直後のように、現在の上流のmainのコミットを指し示す。
$ git rebase upstream/main Successfully rebased and updated refs/heads/main.
これをプッシュしてみる。
$ git push origin main
Giteaで見てみると、狙い通り上流のコミットを指している。
作成したブランチは見えているので、上流とは別の履歴になっているようみ見える。
コマンドで見てみると、HEADが上流のmainのコミットを指していた。
$ git show HEAD commit a06eb9350f6a78f21af49422f1017aa27e8ad178 (HEAD -> main, upstream/main, origin/main, origin/HEAD) Author: rohhie <rohhie@rohhie.net> …
自分のHEADの履歴を見ると、どんなことをしたのかが見えるようになっている。
$ git reflog
a06eb93 (HEAD -> main, upstream/main, origin/main, origin/HEAD) HEAD@{0}: rebase (finish): returning to refs/heads/main
a06eb93 (HEAD -> main, upstream/main, origin/main, origin/HEAD) HEAD@{1}: rebase (start): checkout upstream/main
4aaf9dc (origin/smallfixed) HEAD@{2}: checkout: moving from 4aaf9dc7e0bc7d0cb51faddeec4fff4b09184c7d to main
4aaf9dc (origin/smallfixed) HEAD@{3}: checkout: moving from main to origin/main
…
4aaf9dc (HEAD -> main, origin/smallfixed, origin/main, origin/HEAD) HEAD@{12}: commit: Small fixed.
9c90efb (tag: 1.0.0) HEAD@{13}: checkout: moving from main to smallfixed
9c90efb (tag: 1.0.0) HEAD@{14}: clone: from git.hogeserver.hogeddns.jp:piyo/Gitea-with-docker.git
そのコミットで何をしたのかを、確認することもできた。
StackOverflow / Does git record history of branch heads?
$ git show HEAD@{3}
commit 4aaf9dc7e0bc7d0cb51faddeec4fff4b09184c7d (origin/smallfixed)
Author: piyo <piyo@hogeserver.hogeddns.jp>
…
マージ
上流の変更を取り込むもう1つの方法がマージ。
Qiita / GitHubでフォーク元の差分を取り込む
$ git merge upstream/main Updating 4aaf9dc..a06eb93 Fast-forward gitea/docker-compose.yml | 1 + gitea/edit-app.ini.sh | 2 ++ 2 files changed, 3 insertions(+) create mode 100755 gitea/edit-app.ini.sh
結局、マージした結果が上流と一緒になるので、リベースしたのと同じ結果になった。
何がマージされたのかを見てみる。
$ git log --merges commit 915e1ea3e145935236d2961b6883c4f20acdcb58 Merge: 9c90efb 4aaf9dc Author: rohhie <rohhie@rohhie.net> …
※今回の操作では、2つのコミットがマージされていることが分かった。
プッシュする。
$ git push origin main
これをGiteaで確認してみたところ、ブランチmainが指しているコミットが、上流のブランチmainのコミットになった。
競合
なお、マージする時に上流と差分があったらどうなるのか、気になって確認してみた。
| やったこと | 結果 |
|---|---|
| 空ファイルを1つ追加。 コミットせず。 | Fast-forwardされ、追加されているファイルはUntracked filesとなった。 ファイルが消えるようなことはなく、追加してコミットが可能。 HEADは上流のブランチmainのコミットになった。 |
| 空ファイルを1つ追加。 コミット済み。 | マージのコメントを入力するため、テキストエディタが起動。 Merge remote-tracking branch 'upstream/main' がセットされている。 HEADはpiyoの新しいコミットになった。 |
| 空ファイルを1つ追加。 既存ファイルを変更。 コミット済み。 | マージのコメントを入力するため、テキストエディタが起動。 Merge remote-tracking branch 'upstream/main' がセットされている。 既存ファイルの変更が競合にならなかったので、その変更が有効になった。 HEADはpiyoの新しいコミットになった。 |
| 空ファイルを1つ追加。 既存ファイルを競合するように変更。 コミット済み。 | 競合するファイルを表示し、マージが停止する。 競合を解消してマージを継続すると、解消したファイルが登録されていた。 HEADはpiyoの新しいコミットになった。 |
競合する状態を試してみたところ、マージが停止した。
git statusで競合するファイルが表示される。
当該のファイルを開けてみたら、競合していることが分かるように編集されていた。
上(左？)がローカルの状態、下(右？)が上流の状態を表している。
<<<<<<< HEAD # 競合を試すためのテストコメント ======= # Testing conflict. >>>>>>> upstream/main
競合を直したいように直して結果をステージし、マージを続行する。
$ git add . $ git merge --continue [main d91df6a] Merge remote-tracking branch 'upstream/main'
これで、マージが完了した。
Giteaにプッシュして確認してみたところ、ブランチmainにpiyoの新しいコミットが表示されていた。
リベースで競合が起きていた時にどうなるかというと、やっぱり同じように競合で処理が停止する。
当該のファイルを開けてみたら、競合していることが分かるように編集されていたが、マージのときと表示の順序が逆になった。
<<<<<<< HEAD # Testing conflict. ======= # 競合を試すためのテストコメント >>>>>>> 87611c9 (競合を試すためのコメント追加)
編集結果をステージし、リベースを続行する。
$ git add . $ git rebase --continue Successfully rebased and updated refs/heads/main.
リベースしたが、追加ファイルがあったため、ブランチmainにpiyoの新しいコミットが表示されていた。
リベース or マージ
上流の変更を取り込む時に、リベースするか、マージするか。
できあがった結果を見ると、同じものができあがっているのだけれど、履歴が違っている。
どちらの方法でも、やった作業が消えてしまうことはない。コミットは残っているから。
Git Bookでも、一概にどちらがよいとは言えないと教えてくれている。
Git Book / 3.6 Git のブランチ機能 - リベース
履歴の違いがどうなるのかを意識して、どちらを使うのかを自分で決める、ということのようだ。
組織とチーム
Giteaでは権限には3種類(管理者、書き込み、読み込み)が指定できるが、与えられる権限の粒度が少し荒いように思う。
権限を細かくコントロールしたい場合には、組織とチームを活用する。
チームには以下のような特徴がある。
- 既存のリポジトリに組織やチームを追加することができない。
- オーナーが組織を作り、その組織にオーナーを切り替える。
- あるいは、組織を先に作り、その組織でリポジトリを作る。
- 組織にはチームを作ることができて、同じ権限を持つ人を集める。
- チームがアクセスできるリポジトリを制限することができる。
組織とチームの特徴を掴むために行った操作は以下の通り。
まず、組織DevGroupというのを作ってみた。
チームを見るとOwnersがあり、その名前のところがリンクになっていて、ここから所有者となるユーザーを追加できた。
組織に所属していることは、公開・非公開の設定ができる。
組織に参加していない人に、自分がこの組織に所属していることを見せるかどうか決めることができた。
組織は下部にチームを作成できる。
チームではリポジトリへの7種類のアクセス権を設定できて、それぞれにアクセスなし、読み取り、書き込みの権限を設定できる。
チームにユーザーを追加すれば、その権限で活動してもらうことができる。
組織はリポジトリを持つことができる。組織のオーナーはリポジトリのオーナになり、チームを追加することでユーザーに権限を渡す。
チームの権限が読み取りになっているが、「読み取り」のところにマウスカーソルをポイントすると「チームの権限はチーム設定ページで設定されており、リポジトリごとに変更することはできません」と表示される。便宜上の表示のようだ。
なお、Giteaの管理者はチームがプライベートであっても見ることができて、Ownersのチームに参加することもできることが分かった。
LFとCRLF問題(断念)
一人でやっている分には多分問題ないと思うのだけれど、複数人が色々な環境で作業すると発生しうる問題。
Qiita / 気をつけて！Git for Windowsにおける改行コード
色々と探していたときに見つけた話で、発生するメカニズムと解決をざっくりと整理してみたが、試すのはまた今度。
やったこと
やったことの多くは本編に記載したが、一部、ちょっと外れたものをこちらに。
Giteaのカスタマイズ
ホームページにいくつかメッセージを置きたくなったので、Giteaをカスタマイズしようと考えた。
まずは、Giteaが内蔵しているテンプレートを取り出す。
$ sudo docker exec -it gitea bash --login
# su - git $ gitea embedded extract --destination /data/gitea 'templates/home.tmpl' Extracting to /data/gitea: /data/gitea/templates/home.tmpl $ exit # exit
これを取り出しておく。
$ sudo docker cp gitea:/data/gitea/templates/home.tmpl ./ $ sudo chown git:git home.tmpl
編集を終えたら、ファイルを書き込んで、コンテナを再起動する。
$ sudo docker cp -a home.tmpl gitea:/data/gitea/templates/ $ sudo docker compose restart
参考までに、このような変更を入れると…
home.tmpl
{{template "base/head" .}}
<div class="page-content home">
<div class="ui stackable relaxed page grid" style="padding-left: 10%; padding-right: 10%;">
<div class="sixteen wide center aligned centered column">
<div>
<img class="logo" width="220" height="220" src="{{AssetUrlPrefix}}/img/logo.svg"/>
</div>
<div class="hero">
<h2>{{AppName}}</h2>
<h2><a href="https://rohhie.net">メインページ</a>でご紹介しているコードを掲載</h2>
</div>
</div>
</div>
<div class="ui stackable relaxed page grid" style="padding-left: 10%; padding-right: 10%;">
<div class="eight wide column">
<h1>制限事項</h1>
<ul class="hero ui header">
<li>本サイトの情報を使用したことにより発生するいかなる損害も、本サイトとろっひー、善意の参加者は一切の責任を追わないものとします。
<li>…
<li>…
</ul>
</div>
<div class="eight wide column">
<h1>本サイトの利用について</h1>
<ul class="hero ui header">
<li>HTTPSとSSHでアクセスしていただけます。
<li>…
<li>…
<li>…
</ul>
</div>
</div>
</div>
{{template "base/footer" .}}
このような表示になった。
Gitea CLIのコンパイル
ソースをクローンしてコンパイルする。
$ git clone https://gitea.com/gitea/tea.git $ cd tea $ make Command 'make' not found, but can be installed with: sudo apt install make # version 4.3-4.1build1, or sudo apt install make-guile # version 4.3-4.1build1
おっと。
$ sudo apt install make $ make make: go: No such file or directory go build -buildmode=pie -mod=vendor -tags '' -ldflags '-X "main.Version=0.9.0+2-g6a4ba6a" -X "main.Tags=" -X "main.SDK=" -s -w' -o tea make: go: No such file or directory make: *** [Makefile:112: tea] Error 127
おっとっと。
$ sudo apt install golang-go
※639MB程のインストール。
再度。
$ make
go build -buildmode=pie -mod=vendor -tags '' -ldflags '-X "main.Version=0.9.0+2-g6a4ba6a" -X "main.Tags=" -X "main.SDK=v0.15.1-0.20220831004139-a0127ed0e7fe" -s -w' -o tea
…
To ignore the vendor directory, use -mod=readonly or -mod=mod.
To sync the vendor directory, run:
go mod vendor
make: *** [Makefile:112: tea] Error 1
あらら。
$ go mod vendor $ make
少し時間が掛かり、コンパイルが終了。
$ ll ./tea -rwxrwxr-x 1 rohhie rohhie 22528000 Sep 17 15:54 ./tea* $ ./tea --version Version: 0.9.0+2-g6a4ba6a golang: 1.18.1 go-sdk: v0.15.1-0.20220831004139-a0127ed0e7fe
これは…/usr/local/binにコピーしておけば良さそうだ。
$ sudo cp ./tea /usr/local/bin
なお、できあがったコマンド tea は、他のUbuntuホストに持って行けばそのまま実行できる。
Go言語は、これがいいんだよなー。(Windows版を作りたかったら、確かクロスコンパイルする必要があるとは思うけれど、それもできた記憶)
起きたこと
イシューが編集できない
過去に投稿したイシューを編集しようとしたら、編集領域が表示できない。
この問題を検索すると、問題はあったようだけれども、修正されているようだ。
Github / go-gitea / gitea / Edit issue is not working in 1.17.0 #20767
Github / go-gitea / gitea / Edit form doesn't display when editing issue/comment #20747
書かれているキャッシュの削除も、上手く問題を解消できなかった。
でも、シークレットモードでは上手く表示できるし、他のアカウントに切り替えたら編集ができた。
こういうときは、だいたいブラウザの拡張機能が原因。
ということで、1つ1つ消してはページを再読み込みして…とやってみると、EPUB READERというのを外したところで、上手く表示ができるようになった。
これはきっと、Giteaが悪いとか、プラグインが悪いとかではなく、何かの名前がバッティングしているということなのだろう。
いま、この拡張機能は利用していないので、オフにしてページを読み込みなおしたら問題が解消した。
ページのインデックス
2022/11/04 追記
最近投稿している記事では、長いソースを掲載していることもあり、Giteaでソースをダウンロードできるようにした。
とくに、DynamicDNSのきじでは、Samba ad DCにレコードを登録・更新・削除するスクリプトがあるけれど、あまりに長いのでGiteaだけに掲載している。
ところが、公開直後からGoogleやMicrosoftからのアクセスが凄かった…そして、結果としてGoogle Search Consoleで7万件の未登録URLができてしまった。
クローラーのCPUやストレージを消費し、多大なトラフィックを生んでしまったであろうことは想像に難くない
バージョン18からサイトマップ機能が実装されるようなので、それまでの間はrobots.txtでクローラーを止めておいた方が良さそうだ。
2023/10/08追記
サイトマップが実装されていたので、設定してみた。
robots.txtの作成。
gitea:/data/gitea/robots.txt
User-agent: * Sitemap: https://<url>/sitemap.xml
※<url>の部分を自分のサイトにあわせて変更。
Giteaを再起動すれば、robots.txtがみられるようになる。
これで、robots.txtとサイトマップが提供ができると思うのだけれど、実際にクロールする側に立ったことはないから、どの程度の何を見るようになるのか(変化するのか)はちょっと分からない。
さいごに
Gitの仕組みを使って、今までやってきた様々なファイルを管理しておくべきだった、と物凄く嬉しい後悔をしている。
ローカルリポジトリという考え方を知っているだけでも、だいぶ違ったのではないか。履歴管理はGitに任せられるわけだから。
今回、色々と遊んでいる環境はというと…
| ホスト | 役割 | メモリ実使用量/メモリ容量 | HDD使用量 |
|---|---|---|---|
| classc | ルーター、Samba ad dc、Gitea、Kopano | 2.1GB/4GB | 17GB |
| party | Samba member server(ソースをいじるだけ) | 0.4GB/4GB | 7GB |
この環境を作るまでに色々と時間を掛けたのは確か。でも、利用するリソースってこの程度。
やる気になるか、ならないか、それだけのことだった。
コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他