今さら聞けないGit　

GitHub Actions リリースノートを自動生成する


## 概要

GitHubのリリースを自動生成するGitHub Actionsを紹介します。

### GitHub リリースって使ってる？

https://docs.github.com/ja/repositories/releasing-projects-on-github/about-releases

https://docs.github.com/ja/repositories/releasing-projects-on-github/managing-releases-in-a-repository

OSSなど公に公開しているソフトウェアではGitHubリリースはもちろんよく使われますが、クローズドなリポジトリでは周りに聞いた感じではあまり活用されていないように感じます。

GitHubリリースをしっかり書いているとどの

【Grep】ripgrep / git grep を使用した文字列検索

# はじめに
影響範囲調査時などで活躍するため、備忘録として記載します。

# Todo
Git管理されているリポジトリにおいて、対象の文字列が使われているファイルのパス・内容を出力する

## 検索ワード例
例）AccessTokenモデルが使用されていそうなワードを予測
– `AccessToken`
– `access_token`
– `at.`

## 出力したい内容

– ファイルパス
– 特定のワードが使用されている行の内容
– 行番号の表示も行う
– 下記ファイルは検索対象から除外したい
– `***_spec.rb`
– `schema.rb`

# ripgrep

:::note
事前にインストールしておく
“`terminal
brew install ripgrep
“`
:::

### テンプレート

“`rb:テンプレ1
rg ‘検索ワード1|検索ワード2’ -g ‘!検索から除外したいファイル名’ -n –sort-files
“`

“`rb:テンプレ2（ファイルパスがメイン）
rg ‘検索ワード1|検索ワード2’ -g ‘!

スパースチェックアウトのやり方

“`bat
REM .gitディレクトリのみがcloneされる
git clone –sparse –filter=blob:none –no-checkout [リポジトリURL]

REM さらにシャローコピーも（最速clone）
git clone –depth=1 –sparse –filter=blob:none –no-checkout [リポジトリURL]

REM チェックアウト対象のセット（それまでの内容を破棄して上書き）
git sparse-checkout set [ディレクトリ名]

REM チェックアウト対象の追加（それまでの内容を残して追加）
git sparse-checkout add [ディレクトリ名]

REM チェックアウト対象の確認
git sparse-checkout list
“`

git add ~ push するとき用のバッチファイル

初回プッシュのときにしか必要ないコマンドも含まれてるけどもう最初で毎回手間取るのがめんどくさいので全部ひっくるめてやった。
あまり人間をなめるなよ。

“`batch:push.bat
@echo off
cd %~dp0

git add -A
git commit -m %1

git config pull.rebase false
git pull –allow-unrelated-histories origin main
git push -u origin main
“`

使い方：
引数にcommit message（ダブルクオーテーションで囲む） を書いて実行

例：
“`batch
./push.bat [コミットメッセージ]
“`

【Git】Organization アカウントのリポジトリにメンバーを招待し参加するまでの手順

## ■ はじめに

### 説明
Organizationアカウントから招待されて、メンバー（外部コラボレータ）として参加した事はあるが、その逆（招待をする側）はなかった。先日社外のエンジニアと業務委託契約を締結して自社の開発に外部コラボレータとして招待する必要があったため、手順などを調べて今後の為にドキュメント化した。

– Organizationアカウントから招待されて、メンバー（外部コラボレータ）として参加したい場合
– Organizationアカウントからメンバーを招待したい場合

などの操作を解説。
本ページの構成としては下記。

1. 最低限リモートリポジトリないと話が進まない為作成。飛ばしても問題ない
2. 招待側の操作
3. 招待され受け入れる側の操作

ちなみに Organizationアカウントとは組織で様々な人が同時に使える共有アカウントみたいなもの。
詳細は GitHub Docs を参照。

https://docs.github.com/ja/get-started/learning-about-github/types-of-github-accou

gitで勝手に認証されてしまった場合 Your name and email address were configured automatically based on your username and hostname.

# 初めに
gitで勝手に認証されてしまった場合の対処方法を説明します

# エラー文
“`
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:

git config –global user.name “Your Name”
git config –global user.email you@example.com

“`
# 解決策
名前とメールアドレスの情報を書き換えていく
まずは名前
“`
git config –global user.name “名前”
“`
名前の部分はgitのユーザーネーム
次にメールアドレス
“`
git config –global user.email ~
“`
~はgitで登録しているメ

fatal: detected dubious ownership in repository at ‘ディレクトリ名’ ~

# 初めに
gitを使っていて遭遇したエラーの解決方法を紹介します。

# エラー文

“`
fatal: detected dubious ownership in repository at ‘ディレクトリのパス’
To add an exception for this directory, call:
“`
# 解決方法
“`
git config –global –add safe.directory ~
“`
で解決できる

~はディレクトリのパス

個人開発でのgit flow 運用方法

# 初めに
チームで開発していく中でgitの運用をしっかりすることが大事だと考えているので、個人でできる範囲でgitを上手に運用する方法をまとめました。

# git flow

# 1.mainとdevelopを作る
mainブランチとdevelopブランチは必須で残しておくようにしてました。mainブランチは本番環境でブラウザに表示させる用のブランチです。このブランチでは開発をしません。developブランチでは本番環境でブラウザに表示させる前のテストをするブランチです。このブランチでも開発はしません。最後に本番環境にプルする時にdevelopブランチをmainブランチにマージしてました。

# 2.featureとhotfixを作る
featureブランチはdevelopブランチから派生します。僕は作りたい機能ごとにこのブランチを作ってました。たとえばajax処理に更新を加えたい時
“`
feature-ajax-update
“`
のような感じです。
gitのコマンドの流れはこれです。
“`
ブランチを作ってチェックアウト
git checkout -b

リモートリポジ

GitHub Actions リリースプルリクエストを自動生成する


## 目的

今回は `develop` → `main` のリリースプルリクエストを自動で作成します。

Gitブランチのマージの流れの図です。

“`
H——–I feat-2
/ \
F—G feat-1 \
/ \ \
C——-D——–E develop
/ \ ★ リリースプルリクエスト
A——————–B main
“`

各開発者が `feature` ブランチで開発し、`develop` ブランチへマージされていきます。

リリースしたいタイミングで `develop` → `main` へ向け

automuteusのセルフホスト環境構築　2024/4更新

# automuteusのセルフホスト環境構築
## 目次
1.始めに
2.Docker設定用のファイルをダウンロード
3.Dockerダウンロード
4.ディスコードボット作成
5.Docker構築
6.終わりに
## 1.始めに
automuteusのセルフホスト導入の時に自分が目に入ったブログは全部今の環境ではできない方法をとっていたので改めて導入する方法を残した方がいいかなと思い書いてます。有識者の方から見ると若干おかしいところがあると思いますがそこは目を瞑ってください。またチャプターはじめのうんちくはなんでこんな面倒なことをしているのかを知りたい方向けのものなので興味のない方は読み飛ばしていただいて結構です。

## 2.Docker設定用のファイルをダウンロード
Dockerとはwindowsのソフトがmacで動かないようにプログラ厶はその人の環境にかなり依存します。それをコンテナという別環境をPCの中に作り出すことで動作の安定化や環境への依存をなくすことができる画期的なソフトウェアです。Dockerのセットアップには設計書を作成し、それをDockerに構築してもらう必要があ

Github Actions超入門

# はじめに

なんとなくgithubを使っていると、リポジトリの上の方にいるこいつ。

いつも目につくけど、一体なんなんだろう？

そう思いながら放置してきた方に向けたGithub Actionsの入門です。

## GitHub Actionsとは
GitHub Actionsは、Githubが提供しているワークフロー自動化ツールです。Githubのユーザーであればすぐに利用できます。

詳細はこちら…

https://docs.github.com/ja/actions/learn-github-actions/understanding-github-actions

色々書いてありますが、要はテストとかを自動でできちゃいます！という便利なものです。
なんだか難しそうですが…実は簡単に使えてしまうわけです。

## 前

DBに関するブランチは別で作成しろ

複数人でDBのスキーマファイルを書いていたが、DB専用のブランチを作らずに作っていたため、他ブランチでスキーマファイルをA君がエラー修正のために更新しても、B君は以前のメインブランチにあファイルから編集しているので、マージしたときはA君のエラー修正が反映されていない状態だった。

DBはDBでブランチを分けて作ろう。

apacheにgitをいれてcloneしたものを表示する

# 初めに
git cloneしたプロジェクトをapacheで表示させてみたのでその解説をします。

# 環境情報
macOS Sonoma 14.4.1
CentoOS Stream X_86_64
Apache/2.4.57
composer version 2.7.2
Laravel Installer 5.7.1
git version 2.43.0

# 解説する

## サーバ側でやること
rootユーザーでログインする
gitをインストール
“`
dnf install git-all
“`
git でコマンド紹介が出ればオッケー

.sshに移動
“`
cd .ssh
“`
githubと連携するための公開鍵と秘密鍵をおいておくディレクトリを作る
“`
mkdir git_hub
“`
git_hubに移動
“`
cd git_hub
“`
そのディレクトリに鍵のペアを作る
“`
ssh-keygen -t ed25519 -C “gitのメールアドレス” -f キー名
“`
パスフレーズはメモしておく

ssh-agentへのsshキーの追加
パス

git@github.com: Permission denied (publickey). の解消について（漠然）

## 背景

・Gitの概要が分かったので自力で作業環境を以下の通り整えようとした。
1. githubでリポジトリを新規作成
2. `git init`で管理したいフォルダーを設定
3. 既にバージョン管理したいファイルがあったのでREAME.mdは生成せずQuicksetup通りにコマンド実行
＞ しかし`push`時にエラー

“`:実行した作業（Quick setup通り）
git init
git add .
git commit -m “first commit”
git branch -M main
git remote add origin https://github.com/〇〇〇〇/〇〇〇〇.git
git push -u origin main ←ここでエラー
“`
“`:エラー内容
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access

Git Rebaseの活用法

**Git rebase** は、Git の強力なツールの一つで、コミット履歴を整理するのに役立ちます。特に、プロジェクトでクリーンなコミット履歴を維持することが重要な場合に便利です。この記事では、Git rebase の基本的な使い方と、実際のワークフローでの活用方法を説明します。

### Git Rebaseの基本

Git rebase は、ブランチのベースを移動または「リベース」することで、マージよりもクリーンな履歴を作成します。具体的には、指定したブランチのコミットを一時的に取り除き、現在のブランチの先頭に再適用します。

### 活用例1: フィーチャーブランチの更新

開発中にメインブランチ（例えば **`main`**）が更新された場合、自分のフィーチャーブランチ（例えば **`feature`**）に最新の変更を取り入れたいことがあります。この場合、rebase を使用して **`feature`** ブランチを最新の **`main`** ブランチに再ベースすることが推奨されます。

“`bash
bashCopy code
# main ブランチに切り替え
g

git addからgit pushまでのコマンド面倒じゃない？

zshを利用している方向け。

# 何が面倒なのか？
日々の開発で、ファイルを変更したら以下のコマンドでpushするのが一般的です。
“`sh
git add
git commit -m “message”
git push origin
“`

ただ変更をコミットするのに`git …`と打ったり、**3回もコマンドを実行するのは面倒！**

# どうやる？
## oh-my-zshのgit pluginによるalias
[ohmyzsh](https://github.com/ohmyzsh/ohmyzsh)の[git plugin](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/git)に組み込まれているaliasを利用することでここまで短縮可能です。

“`sh
ga # 全てのファイルの場合は gaa というaliasが存在
gcmsg “message”
gp origin
“`

### さらに短く
[git-con

VSCode + Git Graph で Git をもうちょっと快適に操作する

:::note warn
ここで紹介するのは GUI 操作になります。キーショートカットガチ勢からすると全く快適にならないので注意。
:::

## Git Graph とは

VSCode の拡張の一つ。


Git リポジトリのツリーをグラフィカルに表示してくれます。


行をクリックすれば、そのコミットでの変更の詳細が出ます。

![git-graph-commit-detail.png](https://qiita-image-store.s

【git】コンフリクトをマージせずに解決する方法 “リベース”

## はじめに
コンフリクトが起きた時、プルリクを作り直してmergeしていたところ、メンターさんに「リベースで解決できるといいね」とアドバイスをいただきました。リベースってなんだ、と思い使ってみたところとても便利なコマンドだったのでメモしたいと思います。

## リベースとは
以下の図のようにmasterブランチから複数のブランチが切られているとします。（図はgit graphを用いています）

図のように片方（feature/1）が先にmergeしたとします。
![スクリーンショット 2024-04-13 22.51.33.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2984024/864804d3-c363

Gitでなるべくストレージ容量を節約したい

# Gitでストレージをなるべく節約する。
## shallow clone、partial cloneの活用
## git clone –depth 1で取得したレポジトリには制約がある。
“`sh
git clone –depth 1
“`
### 複数のブランチとタグ情報をclone[^3]
“`sh
git clone –depth 1 –no-single-branch
“`
[^3]: https://zenn.dev/tetsu_koba/articles/77347ef2c283ac
### 過去履歴がほしいとき。
“`sh
git fetch –depth 100
“`
#### partial cloneの活用
“`sh
git fetch –filter=tree:0 –no-recurse-submodules –unshallow
“`

#### shallow clone解除（全履歴）
全履歴取得なので、ストレージの負担は大きい。
“`sh
git fetch –unshallow
“`

#

gitにて複数のコミットを圧縮する方法

gitでローカルにて「〇〇日の終わり」「一旦コミット」や「チェックアウトするから一旦コミット」（←stashを使うべき）等で変なタイミング、細かすぎるタイミングでコミットしてしまった場合にプルリク等を出すのに問題がある場合、
**git rebase**で複数のコミットを一つにまとめられる。

例としてLaravelのルーティングファイルで下記のように3世代の変更があったとする。
**web.php**
“`