今さら聞けないGit　2023年08月09日

Git Pull Requestの概要　vol.4

Pull Request（プルリクエスト）は、ソフトウェア開発において、コードの変更や追加を管理し、コードベースに統合するための手法の1つです。

以下にPull Requestの基本的な流れと概念を説明します。

ブランチの作成: プロジェクトのコードベースは通常、メインブランチ（例：master、main）と呼ばれるブランチで管理されています。新しい機能や修正を行う際には、このメインブランチから新しいブランチを作成します。このブランチには変更を加えていくことになります。

コードの変更: 作成した新しいブランチで、コードの変更や追加を行います。バグ修正、新機能の実装、ドキュメントの更新などが含まれます。

コミットとプッシュ: 変更が必要な範囲でコミットを行い、変更内容をローカルリポジトリに記録します。その後、変更内容をリモートリポジトリにプッシュして共有します。

Pull Requestの作成: プルリクエストを作成するために、変更が行われたブランチをリモートリポジトリにプッシュします。プルリクエストは、他の開発者に変更内容を確認してもらい、メインブランチへの統合を依頼する手段

Git 権限777のファイルなのに755で登録される

# 概要

– Git管理されいているファイルの権限を任意の権限から777に変更した。差分を確認すると「644 →　755」に変更された旨の内容が出た。どうして777のファイルが755で扱われているのか気になって調べてみた。

# Gitはファイルの権限情報を基本は保持しない

– 当たり前と言ったら当たり前なのだがGitはファイルの中身の差分しか基本的に保持しない。
– ただし例外的に`core.filemode`という設定が`true`になっているときだけ権限情報を保持する。
– `core.filemode`の設定値はローカルリポジトリで`$ git config -l`を実行した出力内容の中に記載されている。
– しかし`core.filemode`が`true`になっていようともGitが管理する権限はファイル所有者の権限が「読み書き実行（7）」かどうかのみ保持する。

# そもそもファイルの権限とは

– Linuxのファイルの権限は下記の3種類である。
– 読み
– 書き
– 実行
– その権限にはそれぞれ整数が振られている。
– 読

READMEにGif動画を埋め込む方法

# 1.はじめに
READMEにGif動画を埋め込んでみたので、忘れないために本記事を書きました。
無料のGitHubプランではアップロードの上限が10MBまでとなっているらしく変換が必要とのこと。

# 2.事前準備
QuickTimeで画面収録を行っている。

# 3. 実装
### 1.ffmpegをインストール
– 以下コマンドでホームディレクトリにffmpegをインストールしてください。
“`
brew install ffmpeg
“`

# 2.movをgifに変換
動画を保存しているディレクトリへ移動し以下コマンドを実行してください。
“`
ffmpeg -i sample.mov -vf scale=720:-1 -r 10 sample.gif
“`

# 3.issueにアップロード
Githubにて新規issueを作成し、上記で作成したgifファイル（sample.gif）をドロップしてください。
そうすると、URLが表示されるのでそのままREAMEにコピー。
READMEを確認し動画が表示されていれば成功です。

Git リモートリポジトリへの送信　リモートリポジトリからの取得　

Githubでリポジトリを新規作成

## git remote add リモートリポジトリを登録
この部分をコピペ
“`
git remote add origin https://github.com/okuyama-code/git-tutorial.git

“`
git remote addを実行すると、以後originという名前（識別子）で、git remote add origin https://github.com/okuyama-code/git-tutorial.git　のリモ

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

作業ディレクトリから追跡されていないファイルやディレクトリを削除する時
※ -fオプションは、強制的に削除する時に使用する

“`
git clean -f
“`
カレントブランチをリモートの同名ブランチにプッシュする時
“`
git push origin HEAD
“`
GitHub CLI（gh コマンド）を使用して、GitHub リポジトリでプルリクエストを作成する時
“`
gh pr create -full -a
“`
作業ディレクトリに変更がある場合に、リベースが失敗する可能性を回避する時

“`
git rebase –autostash
“`
ファイルを編集していた場合に、コミットせずに保存する時
“`
git stash
“`
リモートリポジトリから最新の変更を取得する時

“`
pull –rebase origin main –autostash
“`
不要なリモートブランチを削除

“`
git fetch –prune
“`

## 参考サイト
[地味だけど便利なgitコマンド使い方](https://www.yout

Git コミットを変更する操作　 vol.3

# git reset –歴史を戻る
## 歴史操作を覚えるために、歴史を戻って、fix-Bというトピックブランチを作る

### 1. feature-Aブランチを分岐する前に戻る
リポジトリのHEAD、ステージ、現在のワーキングツリーを指定した状態まで戻すには、**git reset –hard**コマンドを利用します。このコマンドに戻りたい場所のハッシュを与える。

ハッシュはgit logで調べる
各コミットの先頭に表示されている16進数の文字列が、各コミットのハッシュの一部です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3490027/0db0fd12-dd73-9bcc-b

【Git】git push rejected

# はじめに
### 「rejected」とは
* rejected…「却下、拒否」
* リモートリポジトリとローカルリポジトリの間で競合が起き拒否される状態
# 原因
* リモートとローカルの最新情報が異なっているからプッシュするとrejected(拒否)される
# 解決策
* リポジトリを最新状態にする
“`
git pull origin <ブランチ名>

git push origin <ブランチ名>
“`
# おわり
* とりあえずエラーあったら`git pull`で最新状態にする
> 参考文献
> 1. [git pushがrejectされたときの解決方法URLまとめ](https://qiita.com/kaw/items/767deb773223fe013ada)
> 2. [【git】git pushがrejectedされた時の解決方法](https://hachimaki37.hatenablog.com/entry/2020/08/19/183445)

git コマンド [ブランチの操作]　vol.2

ブランチは、別々の作業を並行して行うために利用する。

### git branch — ブランチを一覧表示
ブランチ名の一覧を表示するとともに、現在のブランチを確認するためのコマンド。
“`
$ git branch
* master　//*が現在のブランチ
“`

## git checkout -b — ブランチを作成し、切り替える
### feature-Aブランチに切り替えコミットする
1. feature-Aという名前のブランチを作成
“`
$ git checkout -b feature-A
Switched to a new branch ‘feature-A’
“`
これは、
“`
git branch feature-A
git checkout feature-A
“`
を順番に実行した結果と同じ動きをします。
feature-Aブランチを作成し移動している。
確認
“`
$ git branch
* feature-A
master
“`
![image.png](https://qiita-image-store.s3.ap-no

[memo] git for windows (git bash) のバージョンアップ

## はじめに

git for windows (git bash) のバージョンアップをする機会があったので、将来の自分のためにメモします。

## git for windows のバージョン確認

git for windows のバージョン確認は、普通に git 本体のバージョンを確認すれば良いみたい。
具体的には git bash 上で以下のコマンドを実行すれば OK。

“`
git version
“`

## git for windows のバージョンアップ

git bash 上で、以下を実行すれば OK。

“`
git update-git-for-windows
“`

実体のコマンドは `git-update-git-for-windows` というシェルスクリプトで、先頭が `git-` で始まっていると git のサブコマンド化がされるため、`git update-git-for-windows` で実行が可能なようです。

“`:git bash 上での実行結果
$ which git-update-git-for-windows
/min

git コマンド　基本的な操作　vol.1

## サンプル
“`
# 新しいディレクトリを作成して移動します
mkdir git-tutorial
cd git-tutorial

# Git リポジトリを初期化します
git init

# 新しいファイルを作成し、内容を追加します
echo “Hello, Git!” > hello.txt

# Git にファイルの変更を追跡させます（ステージング）
git add hello.txt

# 変更の状態を確認します
git status

# 変更をコミットし、メッセージを残します
git commit -m “Initial commit: added hello.txt”

# 新しいブランチを作成して切り替えます
git checkout -b feature-branch

# ファイルを編集し、変更を追加します
echo “Modified content” >> hello.txt
git add hello.txt

# 変更の状態を確認します
git status

# 変更をコミットします
git commit -m “Modified hello.

「Git 基本の使い方33」 – “Git言語”が完全に理解できた

WEBアプリケーション開発のためGit・Sourcetreeを学んだのですが、非常に便利なツールだということが分かったので主な有用性と使い方・一見難解な”Git言語”について簡潔に学習してみました。

# Gitの利点
Gitの利点は、誰がいつ、どのファイルを変更したかを管理できるようになることです。またバージョン管理をすることで「ファイルを消しちゃった！」というケアレスミスを予防できます。
Gitを用いればファイルを管理する集中型管理システム・分散型管理システムを簡単に導入することのも利点です。

– 集中型管理システム→システムを必ず中央システムにつなぐ
– 分散型管理システム→ローカルなリポジトリーを作成する。オフラインでも作業できる他、ファイルを共有することでリモートリポジトリーの復旧が容易になる

# Git機能の有効活用

複数PCにリモートリポジトリーのクローンを作り、複数人でのマルチタスクや個人での仕事場・リモコンワークでの平行作業に活用できます。リモートリポジトリ－を提供しているサービスとしては **Bitbucket・GitHub** 等がある。外部には出せない社内

【Git】エラー : src refspec master does not match any

# はじめに
### 「src refspec master does not match any」とは
* 翻訳すると「`src refspec master が一致しません`」
# 原因
* ブランチ名が一致しない場合(最新のバージョンではデフォルトブランチが`main`)
* コミットが存在しない場合
ローカルリポジトリにコミットがない状態で、空のリポジトリをプッシュしようとした時に出る(私はこれが原因だったと思います)
# 解決策
* ブランチ名が一致しない場合
`git push origin master` → `git push origin main`に変更するのを試す

* コミットが存在しない場合
`git add .`
`git commit -m “コミットメッセージ”`
上記のコマンドを実行する
# おわり
> * 参考文献 : [git push時のerror: src refspec master does not match anyについて](https://blog.deepblue-ts.co.jp/git/git-push-error/)

【Git】On branch master Initial commit nothing to commit (create/copy files and use “git add” to track)

# 「On branch master Initial commit nothing to commit」とは
* 直訳すると「`ブランチ master 初回コミット コミット対象の変更はありません（ファイルを作成またはコピーし、’git add’ を使用して追跡対象としてください）`」
* 新しいGitリポジトリを初期化した後に表示される
* まだリポジトリ内にコミット対象の変更が存在しないことを示す
# 原因
* 私の場合新しく作成したリポジトリに、変更対象が存在しない状態で`追加`と`コミット`を実行しようとしたため起きた
# 解決策
ファイルに変更を加えてから`git add`、`git commit`を実行する
# おわり
> * 参考文献 : [GitHib Commit エラー](https://teratail.com/questions/293943)

Gitのobjectsとmergeについてのメモ

#### ./gitの構成
“`
.
├── COMMIT_EDITMSG
├── HEAD
├── config
├── description
├── hooks
├── index
├── info
├── logs
│   ├── HEAD
│   └── refs
│   └── heads
│   ├── master
│   └── test
├── objects
│   ├── 1e
│   │   └── asdfa887932510deeecdfa800000082341743a
.
.
.
│   ├── fa
│   │   └── cad48f0ac69f851bsdb8aefcc81234asba1782
│   ├── a8
│   │   └── 8d8325673948adacefdab7485f0c5b80f01112
│   ├── info
│   └── pack
├── packed-refs
└── refs
├── heads
│   ├── master
│   └──

【便利】VSCodeでGitの差分プレビューファイルのみを全て閉じる方法

# はじめに
VSCodeでGitを用いて開発してる際、画面左側のメニューバーからファイルの差分を視覚的に確認している人は多いのではないのでしょうか。
コミット前とかに変更した全ファイルの差分を一ファイルずつ確認していくかと思います。
しかし画像みたいに差分プレビューファイルがタブにどんどん溜まってしまう…

そこで、差分プレビューファイル（作業ツリーやWorking Treeと書かれてるファイル）のみをすべて閉じる方法をお伝えします！


# やり方
1. コマンドパレットを開く
1. Macの場合、`command+shift+p`を同時押しで開ける
1. Windowsの場合、`ctrl+shift+p`を同時押しで開ける
1. 検索バーで、「Close All Diff Editors」と検索し、それをクリックす

git10本ノック！！！【前半】

gitコマンド10本ノックの前半です。
git初学者や自信がない方向けです。

## 1本目
あなたはfeature/fooブランチで作業しています。
実装する中で、過去のバージョンのファイルを使って色々と試してみたいことがでてきました。
過去のコミットであるaコミットの時のapp.pyだけを作業ツリーに復元するにはどうすればよいですか？

“`mermaid
gitGraph
commit id:”init”
branch feature/foo
commit id:”a”
commit id:”b”
commit id:”c”
“`

筆者の回答

“`bash
git checkout a — app.py
“`

解説

`git reset a`は不正解です。resetコマンドでは全てのファイルが書き変わってしまいます。
また、`git reset a — app.py`も不正解です。resetコマンドではpath指定はで

Git 2種類のマージについて(Fast-ForwardとNon Fast-Forward)

## マージには2種類ある
– Fast-Forward
– Non Fast-Forward

### Fast-Forward
##### ブランチのポインタの移動だけを行い、新しいコミットは作成しない。
コミットが画像１の状態のとき、mainブランチはコミットDに移動するだけでsub1ブランチの内容を取り込むことができる。
mainブランチのコミット：A
sub1ブランチのコミット：ABCD
移動後のmainブランチ　：ABCD

もし画像2の状態でFast-Forwardを行うと、commitEが消えてしまう。
mainブランチのコミット：AE
sub1ブランチのコミット：ABCD
移動後のmainブランチ　：ABCD
![image.png](https://qiita-image-store.s3.ap-northeast-1.a

GitのHEADについて少し理解が深まったのでメモ

## GitのHEADについて
今までHEAD？なにそれ？状態だったが、色々調べているうちに少し理解できたのでメモ。

## 要するに現在地を指している
Gitは変更履歴を記録していくためにコミットを積み上げていく。
開発者は基本的に、それぞれのブランチの最新のコミットに対して作業をすることになると思う。

その、作業をしている場所を指すのがHEADとなる。
ブランチを移動するというのは、HEADを移動させること、と言っても良いかもしれない。

おしまい。

Gitのチェックアウトについて今まで勘違いしていた

### Gitのチェックアウトについて
チェックアウトについて、以前より理解が少し深まったのでメモ。

### 今までの認識
– ブランチを移動しているんだな、程度の認識。

### 厳密には
– HEADがそのブランチの最新コミットに移動する。
– 指定したブランチの内容が作業ツリーに展開される。
– コミットされるブランチがチェックアウトしたブランチになる

などなど、まだまだ細かいところはたくさんあるのでしょうけど、今回はこんなところで。

おしまい。

Gitのpre-pushフックでmainブランチへの誤pushを防ぐ方法

# はじめに

ブランチの切り替えを忘れてしまい、誤ってmainブランチに直接pushしてしまった経験はありませんか？ GitHubなどではリポジトリの設定を変更することで、mainブランチへのpushを制限できますが、その設定がなされていない場合でも、ローカル環境で特定のブランチ（例えばmain）へのpushを防ぐ対策があります。Gitでは、特定のアクションが起こる前後に実行されるスクリプト、つまり「フック（hook）」という機能を利用することで、このような問題を未然に防ぐことが可能です。今回は、pre-pushフックを用いて、mainブランチへのpushを防止する方法を紹介します。

# 目次

1. [方法](#Chapter1)
1. [結果](#Chapter2)
1. [おまけ](#Chapter3)

# 方法
リポジトリのルートディレクトリに移動します。

“`言語名:bash
cd /path/to/your/