今さら聞けないGit　

【21歳/大学生】 AIでコミットメッセージの自動生成とコードのリファクタリングが行えるCLIツールを公開してみた

## 何を作ったか

生成AIでソフトウェア開発のさまざまな作業をサポートするCLIツールを作成しました。
現在はコミットの自動生成とリファクタリングをAIが行う機能をサポートしています。

### パッケージ名：[code-agent](https://pypi.org/project/code-agent/ “PyPIのページ”)

Pythonが入っている環境なら`pip3 install code-agent`でインストールできます。
システム全体にインストールする場合、新しいバージョンのpipでは素直にインストールさせてくれないので`–break-system-packages`オプションを付ける必要があります。

### コマンド名：`codex`

サブコマンドでどの機能を利用するか指定できます。
– `codex gen-commit`: ローカルのGitリポジトリからHEADとインデックスの差分をもとに、コミットメッセージを作成する。
– `codex refactor`: 引数に与えられたファイルを読み取り、リファクタリングが行える箇所のコードの表示と新しいコー

【Git・VSCode】VSCodeのソース管理が機能しなくなった時の対処

VSCodeで開発中に「そろそろコミットしとこうかー」とソース管理からコミットしようと確認したところ、変更あるはずなのにいつの間にか更新の認識がされていないことに気がつきました。こちらの復旧方法をいろいろ調べて対処したのでまとめておきます。

　　　　　　　　　　
　　　　　　　　　　*保存してるのにコードの選択肢が出てこない*

## 結論: 別でリモートリポジトリをクローンして.gitファイルをcpする

調べた結果これが一番手っ取り早そうでした。

## 作業

任意の場所に新たにリモートリポジトリからクローンをする

“`bash
git clone
“`

新たにクローンしたリポジトリから.gitファイルを元のリポジトリへコピーする
私の場合はssh先に元リポジトリがあるので scpコマンドで以下

【Git】最新のコミットからの変更があるか確認する方法

## ステージング前の変更あるか確認する

ステージング前の変更があるか確認するには以下のコマンドを実行します。

“`terminal
git diff –quiet HEAD
“`

変更がある場合に異常終了します。

未追跡のファイルは無視されます。

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt-emgitdiffemltoptionsgt–ltpathgt82308203

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt—quiet

## ステージング後の変更があるか確認する

ステージング後の変更があるか確認するには以下のコマンドを実行します。

“`terminal
git diff –cached –quiet
“`

変更がある場合には異常終了します。

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt-emgitdiffeml

【GitHub】プルリクエストのコメントにつけるラベルバッジを返信テンプレートに登録しよう【PullRequest】

ワイ「PullRequest立てたやで！」

開発者A「この部分、こうしたいよね」

開発者B「この部分、こうだな……」

ワイ「👀」

ワイ（Aさんが修正案きてて、Bさんが感想書いてくれてるみたいだ）

——

数時間後…

ワイ｢よっしゃ！直したやで！！！｣

開発者A「いや、その作業はこのPRでやらなくていいです。」
開発者B「ワイのはこのPRで対応してほしいやで。」

ワイ「」

ということにならないように、ラベルがついてると便利だよね！
@iganin san による記事：

https://qiita.com/iganin/items/aee297eade84849cc9cd

## Q. でも毎回手入力してない？

A. [Text Blazeのブラウザ拡張](https://blaze.today/)使えばいいじゃん？
→ この記事は終了です。ありがとうございました😭

——

今回紹介したいものは「[返信テンプレート](https://docs.github.com/ja/get-started/writing-on-github/working-wi

Git の “user.name” と “user.email” を構成していることを確認してください。

最近 VSCode を更新したところ、commit, push 時に表題のエラーが出るようになった。
もちろん、git config user.name と user.email は設定済み。
とりえあえず、リポジトリ内の .git/config ファイルを開いて
“`
[user]
name = name
email = email@example.com
“`
のように手動で設定を追加したらとりあえずは直ったけど、なんだったんだろうか。
![SnapCrab_NoName_2024-3-6_17-23-19_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/131196/49cb

dockerfileでgitのインストール(ターミナルに色つける)

# dockerfile上でgitのインストール & 設定を終わらせたい！
毎回コンテナ起動後に`apt install git-all`やって、
`git config –global user.name “XXX”`やってメールもやって～って面倒くさいよね。
けど、dockerfileに`RUN apt-get install git-all -y`って書くとタイムゾーンで止まりますよね。
そんなときは、
“`dockerfile
ENV TZ=Asia/Tokyo
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
“`
ってタイムゾーンを指定しよう。
その後はgitの初期設定もベタ打ちして終わり。**(共有するときは消す)**
# ～彩りを加える～
素やとターミナルが白でなんかテンションが上がらない。
“`dockerfile
ENV TERM xterm-256color
“`
これで色がついて華やかな開発ライフ！

Gitの警告 [ You have divergent branches and need to specify how to reconcile them]

git pull -aすると、下記のようなエラーが怒られてしまう。

“`sh
service]$ git branch
* develop
service]$ git pull -a
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint: git config pull.rebase false # merge
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
hint:
hint: You can replace “git config” with “git config –global” to se

Gitを安心して使うために知っておきたいGitコマンドの動き　git branch編

# はじめに
私がGitについて勉強し始めてすぐの頃、Gitのコマンドを間違えてしまい研修で作ったプログラムがすべて消えてしまったことがあります。それからGitを使うのがとても怖かったです。もしもGitコマンドの動きを正確に知っていればこのようなミスはしなかったと思います。
この記事ではGit初心者向けに、`git branch`コマンドに焦点を当てて実行されたときの動きをまとめています。

# 具体例と実行コマンド
### 自分で作成した既存のブランチを一覧表示する
“`
git branch
“`
本記事で出てくるコマンドの基本となる`git branch`ですが、こちらは**リモート追跡ブランチ**以外のローカルブランチを一覧表示します。
これだけではローカルブランチをすべて表示することはできません。

#### ローカルブランチ
自分のパソコンの中にあるブランチです。
「オフラインで操作可能なブランチ」のようなイメージであり、本来は下記の**リモート追跡ブランチ**もローカルブランチに含まれます。
しかし、一般的にローカルブランチと呼ばれるものは上記コマンド`git bra

Git ブランチ戦略 – feature/cool-featureをdevに統合するフロー

## はじめに

Gitの典型的なブランチ戦略における、feature/cool-featureブランチからdevブランチへの変更統合プロセスを説明します

## 1. feature/cool-feature ブランチの作成と作業
mainから新しい機能ブランチfeature/cool-featureを作成し、そこで開発作業を行います。

“`text
[main]
|
|—[feature/cool-feature] ← ここで新機能に関する作業を行う
|
|—[dev]
“`
“`shell
git checkout main
git pull origin main
git checkout -b feature/cool-feature
# feature/cool-featureで作業し、コミットを行う
“`

## 2. devブランチの更新

作業が完了したら、devブランチを最新の状態に更新します

“`text
[main]
|
|—[feature/cool-feature] ← 作業完了
|

fatal: detected dubious ownership in repository at

# 事象 : safe.directoryに設定してあるWSL2上のディレクトリをSourceTreeで見たらエラーになった
– 環境
– Windows11 Pro バージョン23H2
– SourceTree Version 3.4.15
– git version 2.42.0.windows.2
– WSL2にあるディレクトリにリポジトリをクローンしている

WSL2のUbuntuにあるディレクトリをSourceTreeで開いたらエラーになりました。
しかし、このディレクトリは`safe.directory`に設定してあります。
なので、VS Codeのターミナル上ではエラーなくコマンド操作できています。

“`
—————————
エラーが発生しました
—————————
‘git log’ がコード 128 で終了しました: fatal: detected dubious ownership in repository at ‘//wsl.localhost/Ubunt

Gitを基本からまとめてみた【便利なコマンド】

## commit –amend

commit –amendを利用することで、直前のコミットを書き換えることができる。
変更を追加したり、コミットメッセージを書き換える事ができる。

#### （1）現在の変更を直前のコミットに統合する

“`
git status
// 現在のコミット履歴のログの確認
git log –oneline

//現在の変更をaddして、commitコマンドを –amendオプションをつけて実行する
git add .
git commit –amend
//コミットメッセージを書き換えられるエディタが開く。必要があればここでコミットメッセージを書き換える。

git status
// 現在のコミット履歴のログの確認
git log –oneline
git show (指定番号)
“`

#### (2) 直前のコミットメッセージを修正する

“`
git status
git log –oneline
git commit –amend

ログメッセージを追加

git log –oneline
“`
## git reb

MarkDown&Gitの社内利用を普及するには（考察）

## 0.はじめに
MarkDownやGitの社内利用をもっと増やしたいなと思ってはいるが、社内利用では特定のメンバーのみ利用していたりするため、MarkDownやGitが少しでも身近にするためには、どうしたらよいかと考えてまとめた記事になります。
ちなみに、私自身は決してマークダウンが得意という分けではありません。

:::note warn
ここでいうGitとはGitHub以外のGit系のバージョン管理製品を含みます
:::

以降に、メリット、デメリットと考察をまとめてみました。
あくまで、個人的な見解です(;^_^A）

—-
### 1.　:sunny:メリット
– テキストエディタで編集可能
専用ソフトがなくても、編集できる。ツールを利用するとしたらMarkDownを利用した補助ツールがあると便利なぐらい。エディタはいろいろあるが、無料で揃えることが可能。
– 中身はテキストなので、ファイル自体が軽い
ファイルが軽いと何が良いかというと、読み込みに時間がかからないのと、受け渡しもしやすい。
– PDFやHTMLへの変換も可能
他のツールを利用する必要はあるが、PD

VSCodeにおけるgitGUI操作方法

Gitに関連する概念

## Gitとは
`Gitとはソースコードや変更履歴を管理するために使われる、代表的な分散型バージョン管理システム
–Wiki`
## 基本概念
### リポジトリとは
ソースコードと変更履歴を格納する倉庫

### gitにおけるローカルとリモートリポジトリの役割の違い
gitは複数人のプロジェクトのソースコードを管理するものなので、
リモートリポジトリの役割：共有倉庫
ローカルリポジトリの役割：個人倉庫

共有倉庫の特徴：
* 個人倉庫のすべてのソースコードと変更履歴に含むこと
* ランチ名に`origin/`がつくこと

個人倉庫の特徴：
* ソースコードと変更履歴が共有倉庫の**一部**あるいは**全部**と**必ず一致**すること

#

Git でファイル名の大文字小文字の変更が検出されない

表題の件、年に1回あるかないかくらいのペースで毎回ハマって調べているので自分でも記事にまとめて知識の定着化を狙います。

## 起こった現象

git で管理しているファイル名を次のような大文字/小文字のみの変更を行った場合に、git ではファイル名の変化が検知できませんでした。

例）Kit**k**at.cs => Kit**K**at.cs （太字部分が、小文字の`k`から大文字の`K`に変更されています。）

これは `core.ignorecase` が `true` のときに発生します。

https://git-scm.com/docs/git-config/2.14.6#Documentation/git-config.txt-coreignoreCase

> If true, this option enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like FAT. For example, if a direct

SVNプロジェクトのGit移行

# はじめに
SVNプロジェクトをGitに移行したときのメモです。

## 手順１：Git for Windows のバージョン変更
バージョン「2.33.0.0.2」の では git svn コマンドを実行するとエラーが発生。
エラーが発生しなかった「2.28.0-rc2」にダウングレードする必要がありました。
https://github.com/git-for-windows/git/releases/tag/v2.28.0-rc2.windows.1

## 手順２：GitLabにプロジェクト作成

## 手順３：GitLabへの移行
“`bash
mkdir temp
cd temp
git svn init –no-metadata https://XXX.XXX.XXX.XXX:XXXX/svn/server/SalesForceAutomation
git svn fetch
git clone . ../salesforce-automation
cd ../salesforce-automation

## オリジンの確認：ローカルになっている
git remo

git pushできなかったとき

## 問題
ブランチを新規作成してコードを書いた後、git commitをした後にgit push origin mainをしたら、「Everythin up-to-date」と表示されてpushできなかった。

## 原因
新規作成したブランチがリモートブランチに公開されていない

## 対処法
“`
git push –set-upstream origin ブランチ名
“`

これでpushすることができました。

ちなみに、自動的に以下を有効化すると自動的にリモートブランチを設定してくれました。
“`
git config –global –add –bool push.autoSetupRemote true
“`

Git branch 操作術

git branchコマンドを最低限の理解する

## 表示
### git branch
ローカルブランチの一覧を表示する。

### git branch -r
-r、もしくは、–remotesオプション。
リモートブランチの一覧を表示する。

### git branch -a
-a、もしくは–allオプション。
リモートブランチを含んだブランチの一覧を表示する。

### git branch -v
-v、もしくは–verboseオプション。
詳細情報を付与した状態で、ブランチの一覧を表示する。
各ブランチの先頭のコミットのIDとメッセージを表示する。
-vvオプションを使用することで、追跡しているリモートブランチの名前を表示する。

## 操作
### git checkout -b
新しいブランチの作成、またはリモート上のoriginブランチをローカルに作成
同時にブランチの切り替えを行う。

### git branch -d
-d、もしくは、–deleteオプション。
指定したローカルブランチを削除する。

gitでfetchとpushを別リポジトリに設定

### 背景
外部ツールの更新をfetchしつつ、カスタマイズした内容を自分のリポジトリにpushしたかった（手軽に）

### ローカルリポジトリを作成
任意のリポジトリを作成、またはclone
“`sh
git clone https://github.com/hoge/fuga
“`
もし`shallow clone`している場合は以下で全体を取得
“`sh
git fetch –unshallow
“`

### リモートリポジトリを確認
“`sh
git remote -v
“`
“`sh
>>> origin https://github.com/hoge/fuga (fetch)
>>> origin https://github.com/hoge/fuga (push)
“`
この段階ではfetchとpushで同一のurlが設定されているため、push先を別urlに設定する

### push先を別リポジトリに設定
“`sh
git remote set-url –push origin https://github.com/piyo
“`

Gitのstashとrestoreの違い

Gitの`stash`コマンドは、現在の作業中の変更を一時的に保管し、作業ディレクトリを最後のコミットの状態に戻します。これは、異なるタスクに切り替える必要があるが、現在の変更をまだコミットしたくない場合に便利です。

一方で、`git restore`コマンドは、特定のファイルの作業ディレクトリやステージングされた変更を元に戻すために使用されます。誤って変更した内容を修正したい時や、ステージングした内容を取り消したい場合に役立ちます。

どちらも作業中の変更を扱うためのツールですが、使用目的と機能には大きな違いがあります。

### git stash

`git stash`コマンドは、作業中の変更（ステージングされていない変更とステージングされた変更の両方）を一時的に保存し、作業ディレクトリをクリーンな状態（最後のコミットの状態）に戻すために使用されます。このコマンドは、別のブランチに切り替える必要があるが、現在のブランチにコミットしたくない変更がある場合に特に便利です。

使用例
– 変更を一時保存する: `git stash push -m “メッセージ”`
– スタッシュ

GitHub上で心霊現象に巻き込まれました・・・。

# 呪われたリポジトリ

こちらです・・・。

https://github.com/matoruru/haunted-repo

「**haunted-repo**」

不吉な名前です。

お化け屋敷ならぬ「**お化けリポジトリ**」ということでしょうか・・・。

# コミット履歴を見てみよう

https://github.com/matoruru/haunted-repo/commits/main/

# おわかりいただけただろうか



# 呪われているッ！！

なんと今回、ghost（幽霊）にコミ