今さら聞けないGit　

Git Stashの復元: 誤って削除されたスタッシュの復元方法

## はじめに

Git stashは、開発者が未完成の作業を一時的に保管し、後で戻ってくることができる便利なツールです。しかし、うっかりStashを削除してしまった場合はどうすれば良いでしょうか？この初心者向けのチュートリアルでは、削除されたGit stashを回復する手順を説明し、貴重な作業が失われないようにします。

## 必要条件

始める前に、使用しているオペレーティングシステムに関わらず、Gitがインストールされていることを確認してください。さらに、Gitリポジトリがセットアップされ、準備が整っていることを確認してください。

## 削除されたStashの回復

ご存知かもしれませんが、Git Stashを削除する際、確認のプロンプトや警告が表示されないことがあります。Stashを削除してしまった場合は、以下の手順に従って回復します。

1. **Stashのコミットハッシュの取得:**
– `git stash pop` を使用した場合は、出力メッセージからstashのコミットハッシュを見つけます。
![Screenshot 2024-01-10 at 8.19.2

Git ブランチ名を Bash プロンプトに表示する方法とカラーコーディング

BashのコマンドプロンプトにGitのブランチ名を表示させることで、現在作業しているブランチを一目で確認できます。さらに、色を変更することで、プロンプトを見やすくカスタマイズすることが可能です。ここでは、Gitブランチ名の表示方法と色の設定方法を詳しく説明します。

#### Git ブランチ名を表示

1. **.bashrc ファイルを編集**:
ターミナルで `.bashrc`または`.bash_profile` ファイルを開きます。
“`bash
vi ~/.bashrc # または vi ~/.bash_profile
“`

3. **カラーコードを使用したプロンプト設定**:
次のコードを追加または修正してください。
“`bash
# Git branch in prompt.
parse_git_branch() {
git branch 2> /dev/null | sed -e ‘/^[^*]/d’ -e ‘s/* \(.*\)/ (\1)/’
}

export PS1=”\[\03

過去のcommitを修正するいくつかの方法について

# はじめに
この記事を読んでいるということは、止むに止まれぬ理由で過去のcommitを修正したいと考えているのでしょう。
私も様々な理由で毎週のように修正しているので、その気持ちはよくわかります…。

ただ修正するにしても方法がいくつかあり、どれを選ぶべきか迷ってしまいませんか？
そこでこの記事では過去のcommitを修正する方法と、使用するのに適した場面を合わせて解説します。

:::note warn
原則として過去のcommitの修正は、
`リモートリポジトリにプッシュする前のcommit`や、`メインブランチにマージ前のcommit`、
`個人的に使用しているリポジトリ`など他の作業者に影響が発生しないcommitに限定してください。
:::

# 1.commitに記録される内容について
そもそもcommitに何が記録されているか、そしてgit logでどのような情報が出力されるのか把握していますか？
これは決して馬鹿にしているわけではなく、標準的なオプ

[VSCode / Git] 最終 commit 以降の変更箇所を目立たせる機能が、オフになった時の対策

# 何を言ってるの？

以下は VSCode の画面の一部を移した画像です。赤枠と赤色の矢印で示した箇所に、縦の青いラインが見えますよね？|･`ω･´)


これは、実は、「最終コミット以降に変更された行」に引かれるラインであり、自分の修正箇所を一目で区別できる便利な機能なのですが、、、

私は、この機能が突如動かなくなる、という現象に遭遇しました(´∩ω∩`\*)

この解決方法を調べたので記載しました。

# 対処方法

VSCode の `settings.json` に以下の行を追加したら、元通り、上記画像のように青色のラインが引かれる状態に戻りました！

“`json:settings.json
{
“scm.diffDecorations”: “gutter”,
}
“`

コミット履歴の確認とコミットを元に戻す方法

# 1.コミット履歴の確認
“`
git reflog
“`
↑を入力
# 2.コミットを戻す方法
“`
git reset –hard リセットしたいコミットID
“`
例えば・・・
“`
git reset –hard HEAD@{1}
“`
「git reset」はコミット履歴には残らないため、リモートリポジトリに「git push」して既に公開しているものに対して行うと、存在するはずのコミットがなくなって不整合が生じ他のメンバーなどがコミットできなくなってしまいます。

そのため、できるだけ「git push」前のローカル側にある時に使うようにします。
# 3.コミットを戻すもう一つの方法
“`
git revert リセットしたいコミットID
“`
gitに履歴が残るため「git push」した後でも使えます。

引用：https://kuku81kuku81.hatenablog.com/entry/2022/10/03_git_how_to_reset_commit#%EF%BC%91%E3%82%B3%E3%83%9F%E3%83%83%E3%83

VSCodeでGitのコミットログをGUIベースでまとめる

## はじめに

Gitを使っていると、**コミットをまとめたい** ときがあります。

例えば、「Greeter（挨拶）クラス」に「goodbye（別れを告げる）メソッド」を実装した場合に、以下のようにコミットが行われたとします。

「Greeterクラス」の「goodbyeメソッド」は新しく実装されたため、**実装〜リファクタリング** までのコミットは **goodbyeメソッドの実装コミット** としてまとめるべきです。

**⬇ こうしたい ⬇**

【Spring Boot】コミットすべきでないファイルやディレクトリなど

# はじめに
　チーム開発においてGitやSVN等でソースコードの管理をする際、プロジェクトフォルダ内にはリモートリポジトリにコミットすべきではない(コミットが非推奨)のファイルやディレクトリが存在するので、まとめました。

　また、内容はJavaのSpring Bootでの開発を前提としていることをご了承ください。

### 開発環境

|項目 |バージョン|
|:-:|:-:|
| 言語 |Java 21 |
|フレームワーク |Spring Boot |
| ビルドツール　| Maven |
| IDE | IntelliJ IDEA 2024.1 (Community Edition) |
| git | version 2.33.0.windows.2 |

# コミットすべきでないファイル

#### 1.ユーザー名やパスワードなどの秘密情報が入力されるファイル

* application.propeties　(DBのユーザー名、パスワード)
* dataSources.ids(IntelliJ IDEA 13以前)　(DBのパスワード)
* dat

コードレビューを1年やってきて、知ってよかったGitコマンド集＋α

# はじめに

最近、コードレビューを実施して承認する立場に変わりました。
開発しているときには使っていなかったコマンドやオプションを使うことで、コードレビューがスムーズになったので、記事にまとめます。

## コードレビューの仕方

私のコードレビューのやり方が特殊かもしれないので、先にコードレビューのやり方を記載します。

コードレビューは、CodeCommitのプルリクエストを使用しています。
検索をしながら確認作業をしたいことが多いので、ローカルにチェックアウトしてきてVSCodeを使って差分を確認しています。
コードレビュー用のワークスペースを作成しています。

コードレビューは大きく以下の流れで進めています。（`feature`ブランチを`master`ブランチにマージするプルリクエストの場合）

0. `master`ブランチの最新を取得する
0. `feature`ブランチをスカッシュマージする
* 競合がでないかも確認する
* ビルドエラーや単体テストエラー（カバレッジ確認も含む）がないかも確認する
0. 差分を確認する
* ス

Gitコマンド一覧

ユーザーネーム・ユーザーメール 設定
“`
git config –global user.name “Test”
git config –global user.email “test@gmail.com”
“`

ユーザーネーム・ユーザーメール 確認

“`
git config –global user.name
git config –global user.email
“`

リポジトリを新規に作成

“`
git init
“`

現在のディレクトリとサブディレクトリ内の新規ファイルと変更をステージング

“`
git add .
“`

リポジトリの現在の状態を表示

“`
git status
“`

変更をコメント付きでコミットする

“`
git commit -m “test”
“`

GitHubとGitを関連付ける

“`
git remote add origin
“`

変更をGitHubリポジトリにプッシュ

“`
git p

【Git】マージ／リベースはどう指定して何が起きるのか、プルのマージ型／リベース型とは

## はじめに
対象読者は以下の通りです。
* マージとリベースは何となく分かるけど、どういう風にコマンド実行して何が起きるのかパッと出てこない方
* プルはフェッチ＋マージって聞いたんだけど、これってマージしてるの？と感じた方

私自身、

「マージする方とされる方、結局どっちにチェックアウトして実行するんだっけ？」
「プルの時にも実行されてるらしいけど、何となく腑に落ちない…」

といった疑問を抱くことがあり、本記事としてまとめることにしました。

## 結論
#### Ｑ．結局どっちにチェックアウトして実行する？
⇒マージ／リベースともに、する方です。（される方ではなく）

どちらも、「あいつ（ブランチ）の力（コミット）を取り込んで、そこまで肩を並べてやる…あわよくば追い抜いてくれるわ！」という意思があります。意味が分からないと思いますが、詳しくは下で。

要するに、変更を取り込む側のブランチが、取り込むまれる側のブランチを指定して実行するということです。これはマージもリベースも共通です。

#### Ｑ．プルの時にも実行されてる？
⇒されてます。

ただ、以下のように若干毛色が

Windows上にGiteaでソース管理環境を構築する

## はじめに
### やりたいこと
Giteaを使い、Windows上にGitHubライクなソース管理環境を構築します。個人やチームでお手軽にソース管理をする場合に適しています。

### Giteaとは
Giteaとは、自己ホスト型のオールインワン ソフトウェア開発プラットフォームです。つまり、GitHubに似たことが社内などのプライベートネットワーク上でできます。

Giteaには以下の特徴があります。
– MITライセンスに基づくOSSなので誰でも利用可能
– 軽量・高速のため、リソースに制約のある環境でもパフォーマンスが良好
– Linux, Windowsなど多くのプラットフォームに対応
– 大規模な開発者コミュニティによって構築・維持されている

### なぜWindows環境なのか
– セキュリティ上、GitHubなどのクラウドサービスは使えない
– 既に使い慣れているWindowsサーバーがある
– Linuxを使えるメンバ

git 作業(クローン編)

# はじめに
以前の記事(以下url)で、gitの使用法について簡単にさらっていったが、今回PCを新調したので、git hub上のデータをクローンしてきて、作業を継続できるようにする。
今回も超初心者の備忘録となっている
https://qiita.com/kushikushi/items/0162288ed71dc2a9a5aa

# 実行
まず、cdコマンドで、クローンしたいディレクトリに移動しておく

“`
cd [移動したいディレクトリパス]
“`

その後、git cloneコマンドを使用する
“`
git clone [リポジトリパス]
“`

今回は、git hubからクローンしたため、以下のようなurlを指定した
“`
https://github.com/[ユーザー名]/[リポジトリ名].git
“`

以上で終了。とても簡単だった。

コマンド1回でgit cloneの実行とvscodeのワークスペースの設定をする

# 概要

`git clone` してから vscode でフォルダを開くまでが面倒だったので、 `clone` コマンドを作って workspace の設定ファイルが生成されるようにした。

alfred で workspace の設定ファイルを検索できるようにしているので、`clone` 後に直ちにローカルリポジトリを開けるようになった。

## 前提条件・制約

– alfred を使う場合は、workspaceファイルを1つのディレクトリ以下に集めておくことになる
– clone されるディレクトリは1つのディレクトリ以下に集まることになる

## `clone` コマンドになるスクリプト
下記をaliasに設定する

“`~/Development/commands/create-workspace/main.zsh
#!/bin/zsh

# 自分のPCのディレクトリに応じて編集する
CONFIG_REPOS_DIRECTORY=$HOME/Development/repositories
CONFIG_WOR

【Git】 個人的よく使うやつまとめ

メモ用。都度追加する。

## バージョン確認
“`
$ git –version
“`

## 今いるブランチを確認
“`
$ git branch
“`

## ファイルごとの差分を見たい時
“`bash
git diff ファイルのパス
“`

## addした内容を消したい時
“`bash
git checkout ファイルのパス
“`

## 現在のブランチとリモートブランチの差分を確認する（どのコミットがpushされるか確認する）
“`bash
git log origin/<ブランチ名>..HEAD
“`

## PR出したあとにコミットを取り消したい時
“`bash
git reset {戻りたいコミット番号}
“`

※「変更があるよ。」と怒られたら
“`bash
git checkout — .
“`
リモートにpush　（だいたい「最新じゃないよ」と怒られるので、-f で 強制push）
“`bash
git push -f origin ブランチ名
“`

## 短縮コマンドを作成する

“`terminal
$ git

Git/Githubの個人的覚書

個人的にGit/Githubで四苦八苦したことを備忘録メモとして継ぎ足していきます。

# Authentication Error
`push`や`ssh -T git@github.com`を実行しても、認証エラーでIDやパスワードすら打たせてもらえない。
ネットで検索しても解決しないので、GithubサイトにてSSH keysに登録していた公開鍵が古かったのが原因だった。
削除したらすんなりうまくいった。

なお、SSH keysまでは以下の手順で進む：
1. アイコン
1. Settings
1. SSH and GPG Keys

# WindowsのPowershellでGitを使うと文字化け
大人しく、Git Bashを使おう。

同じPCで複数のGithubのアカウントを利用する方法

# 同じ PC で複数の Github のアカウントを利用する方法

– 一台のコンピューターで複数の GitHub アカウントを使用する場面があります。新しいアカウントを作成し、元のアカウントには適さないものを投稿することもあるかもしれません。私だけでしょうか…？ このたび、私の毀損のアカウントにあるリポジトリを新しいアカウントに移行する過程で、私のコンピューターでの設定が完了しましたが、このような場合にどう対応すればよいかについてまとめてみました。

## 目次

1. [SSH キーの生成](#1-ssh-キーの生成)
2. [GitHub に新しい公開キーを追加する](#2-github-に新しい公開キーを追加する)
3. [SSH 設定を行い SSH 接続テストをする](#3-ssh-設定を行い-ssh-接続テストをする)
4. [SSH を通じてリポジトリに接続する](#4-ssh-を通じてリポジトリに接続する)
5. [まとめ](#5-まとめ)
6. [参考資料](#6-参考資料)

## 1. SSH キーの生成

1. Git Bash を起動します。
2. SSH

VScodeで.gitディレクトリを表示する

VScodeで.gitディレクトリの中身が見たいのに見つからない！
どうやら、デフォルトでは.gitは非表示になっているよう。
なので.gitが表示されるようにしてみた。

# 手順

「ファイル」→「ユーザー設定」→「設定」の順に選択


「ユーザー」・「リモート（WSL:ubuntu）」・「ワークスペース」のどの範囲で有効な設定を編集するか選択。
左のナビゲーションウインドウを「テキストエディタ」→「ファイル」の順に選択
Excludeの**/.git の×をクリックして削除

![スクリーンショット 2024-04-28 221541.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3780466/f982dad2

GitHubに最初のプッシュをしようとしたときのエラー🙌

GitHubに最初のプッシュをしようとしたときにいくつかのエラーが出たため、こちらで整理します！🙌
今回の肝は、`$ git pull –rebase origin main`です。

後ほど再喝しますが、以下の記事が今回のgitコマンドを理解するのに非常に参考になりました。

git pull と git pull –rebase の違いって？図を交えて説明します！

## 対象
– 未来の自分
– 以下の前提に合致する方

## 前提
– GitHubで、リモートリポジトリを作成済み
– リモートリポジトリにREAD.MEファイルが生成されている
– 初めてのプッシュを行う

## 本題
私が入力した、はじめのコマンドです。
“`bash
# GitHubとGitを紐付け
$ git remote add origin https://github.com/ユーザー名/リポジトリ名.git
“`
ここでは、エラーが出たためプッシュは失敗しています。
“`bash
# 新規ファイルなどをGitHubにプッシュ
$ git push -u origin main
error: src refs

【GitHub】ローカルファイルを新規リモートリポジトリにアップロードする方法

GitHubで管理する予定なくプログラムを書いていたが、気が変わってGitHubにアップロードし、バージョン管理したいことがあると思います。

そんなときのために、ローカルに置いてあるプログラム（ネット上に保存していないプログラム）をGitHubで管理する方法を紹介します。

## 前提

– ローカルにプログラム（ソースコード）があり、リモートにはリポジトリがない

– PCにGitがインストール済み

– GitHubのSSH接続設定済み（まだの人は下記参照）

https://qiita.com/aki4000/items/4c81bc2747bbd5e96d85

Windows 11での説明ですが、Macでも似たような手順だと思います。

## 方法

### 作業フォルダに移動

エクスプローラーでプログラムが置いてあるフォルダまで移動しましょう。

必要であれば、GitHubアップロード用のフォルダを別で作り、用途ごとにフォルダを分けプログラムを置いておくと管理しやすいです。

今回はCドライブ直下にGitHubフォルダを作り、その中にtestフォルダを作って作業フ

gitでpush後のコミットメッセージの変更方法

## はじめに
gitでpush後のコミットメッセージの変更の仕方を記載します。
調べればすぐにわかることですがメモります。

## 対応方法について
以下で記載する対応方法について、先に感想を記載させていただきます。
一人作業の時は何の問題もありません。
ただ、コミットメッセージを変えたい場合は、マージされる前のコミットメッセージまでです。
共同作業の場合、履歴にこだわる場合は、マージされたコミット名称は変えない方が無難です。

また、SourceTreeのようなGUIツールでもリベースやamendといった操作は可能ですが、操作手順や実行中の詳細がコマンドラインに比べて把握しにくいことが多く、特にエラー発生時の対処が複雑になることがありため、コマンドでの対応をお勧めします。予期せぬ結果が発生しかねません。

## 対応方法
Gitで既にpushした後のコミットメッセージを変更するには、以下の手順で行えますが、リポジトリを共有している他の人に影響を与える可能性があるため、注意が必要です。

1. **最新のコミットのメッセージを変更する場合:**
– ローカルでコミットメッセージ