今さら聞けないGit　

GithubにSSH接続できているのに、名前解決エラーによりGit操作ができないとき

**`ssh -T git@github.com`を実行した際に，`You’ve successfully authenticated`と表示されているのが前提です**
# 原因
~/.gitconfigに[user]項目以外の項目（[url “github:”]）が含まれていた
# 解決策
~/.gitconfigから[url “github:”]や[url “git@github.com:”]の項目を削除する（全体を削除しなくても.insteadofの項目を除くだけでも良いと思います）

AWS SessionManager の SSH接続を使いやすくする

## 前置き

– SessionManagerを用いたSSH接続が利用できる環境
– AWSアカウント複数持ちで、プロファイル毎に管理している場合
– InstanceIDが動的で、いちいち調べるのが面倒な場合
– とりあえず、同ネームタグのどのサーバーでもいいから接続したい場合

InstanceIDを調べずに、サーバー接続できるスクリプトのご紹介です。
このスクリプトを設定したら以下のコマンドだけでssm接続できます。

“`bash
> ssh ssm.[プロファイル名].[ネームタグ名]
“`

## 設定方法

**（Git For Windows の GitBashで検証しました。クライアント環境に合わせて調整してください）**

### ■ 1. ファイルを配置する

`[ユーザー]/bin/` フォルダに以下のコードをファイルとして配置する。
※パスの通ったフォルダであればどこでも大丈夫です。

“`bash:ファイル名：aws-ssm.sh
#!/bin/bash

# AWS-SSM ProxyCommand
# Configure to ssh_confi

Oh My Zshでlessのようなページャーが出てしまう

## 概要
最近、Oh My Zshを使用し始めたのですが、git branchコマンドを実行すると、lessのようなページャーが使われ、スクロールして確認できるようになっています。これは、ブランチが多い場合に便利ですが、毎回 q を押して終了するのが面倒だと感じます。
その解決法についてまとめたいと思います。

## 解決法
### git branch
もし元の git branch の挙動、つまり一度に全てのブランチを表示して終了したい場合、ページャーを無効にする設定ができます。以下のコマンドで git branch でページャーを無効にできます。

“`sh
git config –global pager.branch false
“`

これで、ブランチの一覧がページャーなしで一度に表示されるようになります。

### git stash list
git stash list でも同じようにページャーが表示される場合、これもページャーを無効にできます。git stash コマンドに対してもページャーの設定を変更しましょう。

以下のコマンドを実行して、stash コ

Gitをコマンドをメモする

# 概要
勉強のためにGitをインストールしたけど
使ってないとすぐコマンドを忘れそうなのでメモすることにした。

# ユーザ名・メールアドレスの設定

Gitをインストールした後にすぐユーザ名・メールアドレスを設定。

ユーザ名の設定
“`gitコマンド
git config –global user.name <ユーザ名>
“`

ユーザ名の確認
“`gitコマンド
git config –global user.name
“`

メールアドレスの設定
“`gitコマンド
git config –global user.email <メールアドレス>
“`

メールアドレスの確認
“`
git config –global user.email
“`

# リポジトリの初期化
下記のコマンドを実行することにより
リポジトリの初期化を行い、隠しディレクトリで「.git」が作成される。
“`
git init
“`

ステータスの確認
下記のコマンドでファイルの変更状況やステージングエリアの状態を確認できる。
“`
git status
“`

#

Gitのリモートブランチとかリモートリポジトリとかをまとめる

リモートリポジトリとかリモートブランチ周りがイマイチ理解しきれていない気がするので調べた範囲でまとめてみる。

## リモートリポジトリの登録
リモートリポジトリを指定する際、URLをいちいち指定するのは面倒なのでリモートリポジトリに任意の名前をつけて登録することができ、リモートリポジトリの指定の際にその名前を使うことができる。

リモートリポジトリの登録は`git remote add `で行い、
現在登録されているリモートリポジトリは`git remote -v`で確認できる。
“`
//originという名前でリモートリポジトリを登録
> git remote add origin git@github.com:user/TestRepository.git

//登録されているリモートリポジトリの確認
> git remote -v
origin git@github.com:user/TestRepository.git (fetch)
origin git@github.com:user/TestReposito

GITでのブランチ差分確認方法

Gitでは、ブランチ間の差分を確認することがよくあります。コードのレビューや変更の把握に便利なこの操作は、git diff コマンドを使ってシンプルに行えます。

### 基本的なgit diffの使い方

– コマンドの基本構文

“`bash
git diff
“`

“`bash
git diff ..
“`

このコマンドは、`branch1` と `branch2` の間の **差分（変更内容）** を表示します。

### コミット単位での差分確認（–statオプション）
`–stat` オプションを使うと、ファイルごとの変更数を簡潔に表示します。

“`bash
git diff –stat main feature-branch
“`

“`diff
src/main.go | 12 ++++++++—-
README.md | 2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
“`

Git Comment サンプル

# git コメントのサンプル

feat: 新機能
fix: バグ修正
docs: ドキュメントのみの変更
style: コードの意味に影響を与えない変更（空白、フォーマット、セミコロンの欠落など）
refactor: バグを修正せず、機能を追加しないコード変更
perf: パフォーマンスを改善するコード変更
test: 不足しているテストの追加または既存のテストの修正
chore: ビルドプロセスや補助ツール、ライブラリの変更（ドキュメント生成など）

下記から拝借しました。
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type

【Jenkins】java.io.IOException: CreateProcess error=2, 指定されたファイルが見つかりません。

# 原因
`Cannot run program “nohup”`がエラーにあれば、`C:\Program Files\Git\usr\bin`がWindowsのPathに追加されていないため

# 対応方法
`C:\Program Files\Git\usr\bin`をシステム環境変数`Path`に追加する。

# 参考
https://teratail.com/questions/186520

【DAY36】チーム開発におけるGit

## はじめに
私は個人開発ではGit、Githubを使っていますが、チーム開発ではGit、Githubを使ったことがほとんどなく、コンフリクトに遭遇したこともありません。Gitの知識はチーム開発をする上では必須の知識であるため、もっと学びたいと考え、サポーターズ主催の勉強会「チーム開発でコンフリクトしないためのGit・GitHubの使い方」に参加させていただきました。そこでの学びをここに記します。

## Gitとは
バージョン管理システムの一つです。
分散型のシステムで、個人のPCで完結し、他の人に影響を及ぼさずに変更ができます。

## Gitのブランチ
ブランチとは、プロジェクト内で並行して作業を進めるための分岐点であり、他の作業に影響を与えず作業することができます。
「メインブランチ」と「作業ブランチ」があり、メインブランチにはmasterやmainというブランチ名が使われます。
作業ブランチには好きな名前をつけられますが、同じ名前のブランチは同時に一つしかつくれません。
作業ブランチで作業したものはメインブランチにマージされるように開発をするのが一般的です。

## Git

Gitにファイルをコミットする手順[超初心者用]

# はじめに
この記事は、Gitにファイルをコミットするための手順について説明しています。

# 1.コミット(commit)とは
コミットとは、一言でいうと「**追加や変更を行ったファイルをGitのリポジトリに保存するためのコマンド**」です。
コミットを利用すると、自分の作業履歴を記録して保持することができます。

次の章で、具体的なコミットの手順について説明していきます。
# 2.コミットの手順

ここから具体的なコミットの手順について説明していきます。

### 2-1.ローカルの作業ディレクトリに移動する
ターミナルを開き、以下のコマンドを入力する。
“`
$ cd [作業ディレクトリパス]
“`
例 `$ cd ~/~/sample_app`

### 2-2.新しい Git リポジトリを作成するためのコマンドを入力する
このコマンドを実行すると、そのプロジェクトディレクトリが Git によって管理され、コードの変更履歴を追跡したり、以前の状態に戻したりすることができるようになります。

“`
$ git init
“`
このコマンドは、新しいプロジェクトを始めると

git log のMerge pull requestコミットメッセージからPR番号のみ抽出して一覧化するコマンド

## mainとdevelopmentの差分のPR番号一覧を取得

“`shell-session
$ git log –merges –oneline origin/main…origin/development | grep “Merge pull request” | sed -E ‘s/.*#([0-9]+).*/\1/’
“`

## 補足

### git log –merges –oneline

`–merges`: マージコミットのみを表示するオプション
Gitリポジトリには、通常のコミット（単純な変更を記録するコミット）と、ブランチの統合を行った際に生成されるマージコミットがあります。
`–merges` オプションを使うと、マージコミットだけがフィルタリングされ、表示されます。これにより、他の通常のコミットは表示されません。

`–oneline`: 各コミットを1行で簡潔に表示するオプションです。
通常、`git log` はコミットIDや日時、作成者、コミットメッセージなどを複数行にわたって表示しますが、`–oneline` オプション

#5 gitでタグを削除する方法（ローカル、リモート）

# はじめに

リリース作業後、誤ってタグを作成してしまったので、削除しました。
削除する方法を調べてメモしておきます。

## ローカルのタグを削除する

“`
git tag -d
“`

## リモートのタグを削除する

“`
git push origin -d
“`

以上です。

Git pushでエラーで色々試しているとファイルが削除された話

# Terrafromのリソースファイルをgitで管理しようとしたら変更したファイルが全て削除された！

## 結論
以下のコマンドを実行したから

“` bash
$ git reset –hard HEAD #この二つのコマンドは同じ意味では無い、実行結果は異なる

$ git reset –hard ‘HEAD^’
“`
pushのエラーはgitで管理する必要の無い、大きいファイルもpushしようとしたから容量を超えてエラーになった。.gitignoreで不要なファイルを除外する事でpushできた。
[参考にした記事](https://qiita.com/kojiro513/items/a96bc443a8c00fa1990b#gitignore-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E6%9B%B4%E6%96%B0)

## 状況

terraformの学習で作ったファイルをまとめてpushしたところ、ファイルサイズの上限を超過してエラーになり、解決するために色々試した中の一つで、コミット履歴を取り消さない

【Git】ブランチ操作 まとめ

備忘録です。

■ブランチの切り方
ブランチを切りたい親ブランチに移動する
“`$ git branch [branch_name]“`

プッシュする
“`$ git push origin [branch_name]“`
※origin:リモートリポジトリ名のデフォルト設定

■ブランチの削除
リモートリポジトリのブランチ削除
“`$ git push origin –delete [branch_name] “`

ローカルリポジトリのブランチ削除
“`$ git branch -d [branch_name]“`

■直前のコミット取り消し
“`$ git reset –soft HEAD^“`

■addの取り消し（特定ファイル）
“`git rm –cached -r [file_name]“`
※「r」はリモート追跡ブランチ一覧表示

■コミットを結合させる
“`$ git rebase -i HEAD~~~“`
または
“`$ git rebase -i HEAD~3“`
※コミット頭から統合させたい分「~」をつける
※「i」はin

ローカルからリモートの作業ディレクトリにgitで自動更新かける方法

AWS EC2のLinuxにファイル編集を行う際、VScodeのremote-sshを使用していたのですが、
このremote-sshがリソースをバカバカ食ってサーバーを落とすことが多々ありました。

そこで別の方法を模索した際に、ローカルのVScodeで編集してリモートのgitにpushする方法となりました。その際問題点などがあったので、備忘録として記載していく。

前提条件
・ローカルPCからリモートに対してssh接続できる
・ローカル/リモートにgit環境を構築している
・webapplicationの作成で/var/www/test配下を使用
#
①リモート環境にベアリポジトリを作成

:::note info
ベアリポジトリ(bare repository):
gitの変更記録を保持するリポジトリ。基本的にpushするリポジトリはベアリポジトリである必要がある。対するノンベアリポジトリと違い作業ディレクトリがない。
:::
“`
$ cd ~/var/www/test/repo/remote.git　※フォルダなかったのでmkdirで作成
$ git init –bare

#3. 意外と便利なGitコマンドたち

# はじめに
皆さんこんにちはnayaaaaです。
今回はGitのコマンドについていろいろと調べて試してみたので個人的に便利だなと思ったものをまとめてみました。

皆さんがGitで日常的に使用するコマンドはgit (add、commit、pull、push）あたりかなぁと思います。あと初回のセットアップ時にgit (config、init、clone)とか？
しかし、Gitのコマンドは意外にも多く実装されており、中には覚えておくと便利なものも複数あります。
特に、Gitをあまり触ったことがないという方は是非参考にしていただければと思います。

# Gitコマンド

– #### git log
`git log` コマンドは現在までのコミット情報をを表示してくれます。

“`
$ git log
commit d34787267422c56976421bb6510948b5ccab188b (HEAD -> main, origin/main, origin/HEAD)
Author: ユーザー名 <メールアドレス>
Date: Sat Oct 19 21:03:49 202

【大掃除】汚くなったPRをきれいにしてからレビューをしてもらおう！！

## 1. TL;DR
ソフトウェア開発では、試行錯誤の結果も重要な作業の一部です。
しかし、失敗したコードや不要な変更をProductionのcommitに残す必要はありません。

そこで、一時的なPRを作成し、履歴を残しつつもコードベースには影響を与えない方法があります。
この記事では、不要なPRを効率よく整理し、きれいな状態でレビューしてもらうための手順を紹介します。

“`shell
# ただ、以下のコマンドを使ったことがある人は読まなくても問題ない記事だと思います。
git reset –soft main
“`

## 2. よくある状況

1. 実装方針が固まる前に、試行錯誤しながら改修を進める。
1. 作業時間や試行ごとにgitのcommit履歴を積み重ねる。
1. その過程で、不要となった試行や変更がいくつか発生する。
1. そのままPRを出すと、無駄な変更が多く含まれ、レビューの負担が増えてしまう。

## 3. 対応方針

上記の状態に対して対応方針は２つ程度あるかと思います。

### 3.1. 方法1: 新規変更履歴はそのままに、`tig`で行単位の

WSL上のUbuntu再インストール後のセットアップ手順（備忘録）

この記事では、WSL上でUbuntuを再インストールする際に、私が最低限行っているセットアップ手順（Git設定、Dockerインストールなど）をまとめました。忘れがちな手順を効率よく再現するための備忘録です。

## WSL上のUbuntuをアンインストール

まず、既存のUbuntuインスタンスを削除します。

“`powershell
wsl -l -v
wsl –unregister Ubuntu-24.04
“`

※ ここではUbuntu 24.04を例にしています。ご使用のバージョンに応じて適宜変更してください。

## WSL上にUbuntuを再インストール

次に、WSLで利用可能なUbuntuをインストールします。まずはオンラインで利用できるディストリビューションのリストを確認し、WSL自体を最新にアップデートしてからインストールします。

“`powershell
wsl –list –online
wsl –update
wsl –install -d Ubuntu-24.04
“`

## 基本セットアップ

### 1. Ubuntuのミラー

3種類のgit reset（soft, mixed, hard）

# はじめに
`git reset`には3のオプションがあり、どれを使用するかは状況や目的により大きく異なります。この記事では、状況に応じてどのオプションを選択すべきかを解説します。

# git reset とは
変更をある地点まで戻すコマンドです。「ある地点」とはコミット地点のことであり、コミットのHASH値を指定することで、任意の場所まで戻すことができます。

“`
$ git reset [オプション] 戻したい地点のコミット番号
“`

無くしたコミットの差分がどうなるかはオプションで指定することができます。

| オプション | 差分の削除有無 | 差分の状態 |
|:-:|:-:|:-:|
|–soft|残る|ステージング状態になる|
|–mixed|残る|ステージング状態にならない|
|–hard|削除される:scream:|-|

# 3種類のオプションと使いどころ
ということで、三種類のオプションをどんな状況で使うべきか見ていきましょう。

## 1. –soft
`–soft`を指定すると、無くしたコミットに含まれていた修正は全て保持されます。また

フォークしたリポジトリとオリジナルリポジトリの同期

## フォークしたリポジトリとオリジナルリポジトリの変更を同期し、マージする手順書

この記事では、フォークしたリポジトリをオリジナルリポジトリと同期させ、その後マージを行う手順を詳しく説明します。以下の手順に従って、フォーク先とローカルリポジトリを最新の状態に保ち、スムーズに開発を進めましょう。

### 前提条件
– GitHubアカウントを持っていること
– フォークしたリポジトリをローカルにクローンしていること
– Gitがインストールされていること

### 手順1: フォークしたリポジトリをオリジナルと同期する

#### 1. GitHubのウェブUIで「Sync fork」ボタンを使用する

1. **GitHubにログイン**し、フォークしたリポジトリのページに移動します。
2. リポジトリのトップページにある「**Sync fork**」ボタンをクリックします。
– このボタンはリポジトリの上部に表示されています。
3. 「Sync fork」をクリックすると、フォーク先のリポジトリがオリジナルリポジトリ（upstream）の最新の変更と自動的に同期されます。