今さら聞けないGit　

【Git】コマンドまとめ

## 概要
いつもはネットワーク関連の記事を書いているのですが、気分転換として
今回は自分が実際に使ったりしているGitのコマンドを簡単にまとめてみました。

今回の記事とは特に関係ありませんが、ネットワークについての基礎を学びたいという方は是非下記の記事を読んでみてください。

https://qiita.com/nakamura_slj/items/5841195df35a8325427e

# Gitのコマンド一覧
## コミット
“`
git commit -m “コミット名”
“`

## Gitログの確認
“`
git log
“`
簡潔にみたい場合は下記
“`
git log –oneline
“`

## ブランチの一覧を表示
“`
git branch
“`

## 他のブランチを現在のブランチにマージ
“`
git merge [ブランチ名]
“`

## 他のリポジトリのデータを取得してローカルのブランチにプル
“`
git pull [リポジトリ] [ブランチ名]
“`

## ローカルブランチのデータをリモートブランチに送る
“`

gitにてremoteのタグを削除する方法

## ローカルタグの確認

“`
> git tag
“`

## ローカルタグの削除
-dを付けて削除する
rel-1.0.0のタグを削除
“`
> git tag -d rel-1.0.0
“`
再び、ローカルタグの確認をして削除されていることを確認。
リモートにタグをpushしている場合、リモートのタグが消えない。

## リモートのタグを確認
“`
> git ls-remote –tags
“`

## リモートのタグを削除
–delete
“`
> git push origin –delete rel-1.0.0
“`
または、コロン:をつかって削除
“`
> git push origin :rel-1.0.0
“`

リモートのタグを確認して削除されていることを確認。

リモート追跡ブランチを知り、Gitへの理解が深まった話

開発に入って数ヶ月後、origin/mainってなんやねんと気になって調べ、リモート追跡ブランチを認識しgitが完璧になった気がしました。
リモート追跡ブランチを理解することで、git fetch, git mergeなど他のものの解像度も上がりました。

githubでのコード管理を想定しています。

## リモート追跡ブランチとは？

origin/mainはリモートリポジトリoriginのmainブランチを追っている追跡ブランチ。
普段作業しているローカルブランチとは別のもの。

（githubを使っている場合、リモートリポジトリはgithubのリポジトリになります）

https://qiita.com/uasi/items/69368c17c79e99aaddbf

上記の記事を読んで、リモート追跡ブランチを認識しました。

その後、git fetch, git mergeが何をしているのかわかるようになりました。

## git fetch

“`jsx
git fetch
“`

上記で更新がかかるのはリモート追跡ブランチ

“`jsx
git fetch –

[tips]masterかmainか確認せずデフォルトブランチでrebaseしたい

何かのリポジトリで作業している際、最新の`master`ブランチに追従したい場合このようなコマンドを使うことは多いと思います。

“`sh
git fetch && git rebase origin/master
“`

ただ、現在GitHubの新規に作成されたリポジトリのデフォルトブランチは原則`main`です。

The default branch for newly-created repositories is now main

２０２０年にこの変更が行われた結果、デフォルトブランチが`main`と`master`両方存在してしまっている組織は多いと思います。
自分でなんとかできる範囲のものなら統一するように動けば良いですが、範囲外の場合確認する必要があります。

## デフォルトブランチを確認するだけなら `git remote show origin | grep ‘HEAD branch’ | awk ‘{print $NF}’`

こちらのコマンドはブランチ一覧から`HEAD

知らなくても開発できるけど、知っているととても便利なコマンド集① / revert

今回は、知らなくても開発できるけど、知っているととても便利なコマンドである’ revert ‘について紹介します。

### revertコマンドとは？
Gitの’ revert ‘コマンドは、リポジトリの履歴において特定の変更を取り消すために使用されます。具体的には、過去のコミットを”元に戻す”（revert）新しいコミットを作成します。これにより、過去の変更がなかったかのようにリポジトリが更新されますが、実際には過去の変更は履歴に残ります。

### なぜrevertを使用するのか？
1. **安全性**：’ revert ‘はリポジトリの歴史を改変せずに変更を元に戻すため、他の人が作業しているリポジトリへの影響が少ないです。
1. **追跡可能性**：’ revert ‘による変更は新しいコミットとして記録されるため、何がいつ変更されたのかが追跡しやすくなります。
1. **協力作業による利便性**：共有リポジトリで作業している場合、’ revert ‘は他の共同作業者の作業に影響を与えずに問題のある変更を取り消すことができます。

### ‘ revert ‘の基本的な使用方

git add .の使い方

# そもそもGitとは
Gitは、ソフトウェアのバージョン管理システムです。
コードの変更を追跡し、複数の開発者が同じプロジェクトで効率的に協力できるよう設計されています。

Gitには多くのコマンドがありますが、”git add .” はその中でも基本的かつ重要なコマンドの一つです。

それでは、”git add .” の基本的な理解を深めていきましょう。

# ”git add .” の基礎
#### 役割:
git add .コマンドは、カレントディレクトリ（.で示される）とそのサブディレクトリにある変更された全てのファイルをステージングエリアに追加します。ステージングエリアとは、コミット（バージョン履歴に記録するための行為）する前の一時的な領域です。

#### 用途:
このコマンドは、変更されたファイルを選択し、それらを次のコミットに含める準備をするために使用されます。

#### .の意味:
.は現在のディレクトリを指します。つまり、git add .は「現在のディレクトリとその中の全てのファイルとサブディレクトリを追加する」という意味です。

# Gitの基本的な

Gitでブランチ間の差分行数を取得する

大したものではないですが。
開発後で規模感を取得したいときとかにどうぞ。

“`
git diff –shortstat —
“`

ファイル毎に取りたいときは –stat でいけますね。

現場で使っていたgitコマンドまとめ

##概要
メモしてたやつを整理しただけです。

## git add 取り消し
“`bash
git reset HEAD
“`
https://qiita.com/yukure/items/89562e5eb1d03995dc5b

## ローカルとリモートのブランチ名を変更する
“`bash
git branch -m 古いブランチ名 新しいブランチ名
git push -u origin 現在のブランチ名 // $ git push -u origin HEAD とするとブランチ名を入力しなてもpushできるので便利です。
git push origin :リモートのブランチ名
“`
https://qiita.com/shungo_m/items/4218e70751375b4bfeec

## 直前のコミット操作を取り消す
“`bash
git reset –soft HEAD^
“`

## PRでコードを埋め込みつつ、折りたたむ

必ず一行開けてあげる

“`bash
“`
<

Git操作備忘録

## はじめに
Gitの使い方について、基本的なコマンドや流れについて、備忘を兼ねてまとめました。

## 目次
| 項番 | 目次 |
|:—-:|:————-|
| 1 | [はじめに](#はじめに) |
| 2 | [Git管理の流れ](#Git管理の流れ) |
| 3 | [用語](#用語) |
| 4 | [その他コマンド](#その他コマンド) |
| 5 | [参考サイト](#参考サイト)|

### Git管理の流れ

＜図：Git管理の流れ（イメージ）＞

1 git init・・・リポジトリの作成
2 git add・・・ステージングエリアへの追加
3 git commit・・・ローカルリポジトリへの追加
4 Git Hub操作・・・リポジトリの作成（Git Hub）
5 git remote add or

githubのUI上で作成したcommitにつけられるgpg署名を検証してみよう

# 初めに

GithubのUI上でcommitを作成すると、githubによってgpg署名されます。

最近は、この場合`Committer: GitHub `となるようです(Authorが自分の名前)。

さて、最近になって、このgpg鍵は更新されました。

[Rotating credentials for GitHub.com and new GHES patches – The GitHub Blog](https://github.blog/2024-01-16-rotating-credentials-for-github-com-and-new-ghes-patches/)

さて、そんな新しいcommitの署名を検証してみましょう。

# 検証する準備をする

まずは公開鍵を取ってこないといけません。`gpg –recv-keys`してもいいのですが、せっかくGithubが公開鍵をホストしてくれているのでこれを使います。

>[Rotating credentials for GitHub.com and new GHES p

.gitignoreを紛失した

.gitignoreなくした……。

## どうした？
GCPのJupiter Notebook上で、GitHubからクローンしてきたリポジトリに、.gitignoreを作り忘れていた。

慌てて作ろうとして調べたコマンドを打ってみたが、Jupiter Notebookのエクスプローラー上には何も出てこないし、lsしても.gitignoreが見当たらない。

**結論：隠しファイルなので、見えていないだけだった。**

## .gitignoreとは

Gitで、管理外にする（＝リモートリポジトリへのアップロードに含めない）ファイルを指定するためのファイルです。
中身はテキストファイルになっていて、テキストエディタで開いて編集することができます。

.gitignoreと拡張子だけのファイルなので、エディタによっては名前を変更できないそうです。また、隠しファイルなので、Windowsのエクスプローラーなんかで隠しファイルをみえる設定にしておかないと見えません。

たとえば、APIのキーや環境設定（env.txtなど)や、変更の管理が必要ないビルドファイル、大きめの素材ファイルなどは除外

Node-REDのGit機能を学ぶ(3) フローの変更履歴を管理

　[前の記事](https://qiita.com/kazuhitoyokoi/items/2d16662d18b9158f9b92)では、1つのNode-RED環境で複数のフローを切り替える方法を紹介しました。


本記事では、1つのフローに焦点を当てて、フローの変更履歴の記録方法について紹介します。

一般的なコード開発で「Git」を利用する際は、Gitのコマンド操作かVisual Studio Codeなどの開発環境の習得が必要でしょう。一方、Node-REDではフローエディタ上で操作ができるため、「Git」に詳しくない開発者にとっても簡単です。

# フロー開発での問題
　もし、Git機能が有効化されていないデフォルトの「Node-RED環境」を使い続けた場合、以下の問題に遭遇

Node-REDのGit機能を学ぶ(2) フローの切り替え

　[前回の記事](https://qiita.com/kazuhitoyokoi/items/56ee43658f287f80156c)では下の図を用いて、Node-REDのGit機能の概要を紹介しました。


本記事では、Node-REDのGit機能のうち赤色でハイライトした「フローを切り替える機能」を紹介します。はじめに概要の記事で紹介したフロー開発での問題をもう少し深掘りして解説します。

# フロー開発での問題
### [問題1] グローバル変数の衝突
Node-REDは、複数のノードの間で値を共有できるコンテキスト機能を備えています。これは一般的なプログラミング言語ではグローバル変数と呼ばれる機能です。このコンテキストを利用する際、フロー開発者は変数名が重複しないよう、慎重に

Node-REDのGit機能を学ぶ(1) 概要編

本記事では、Node-REDで本格的なフロー開発を行う際に必須となるGit機能を紹介します。
　Node-REDは産業向けIoTアプリをコーディング不要で構築できる開発環境として近年、工場データの見える化ダッシュボードや、工場のファクトリーオートメーションなどのシステムで利用されています。しかし、これらのミッションクリティカルシステムのフロー開発では以下の問題に遭遇しがちです。


# フロー開発で起きがちな問題

### [問題1] すべての機能が1つのフローに存在
　Node-REDの環境が1つしか存在しない場合、多数のノードを含む巨大なフローがその1つの環境で実行されることになります。このようなフローはメモリやCPUのリソースを大量に消費するため、パフォーマンスの問題が発生しがちです。また、同じ名前のコンテキスト

自作ライブラリ作成の初心者がGitHubとComposerでソースをパッケージ化する

## はじめに

自作していたライブラリを

**”GitHubとComposerを使ってダウンロードできるようにしておけばカッコいいし便利そう”**

と思って

**”Composerって依存関係をJSONで書いておけば簡単にダウンロードできるんだったよねー”**

ってくらいの気持ちでComposerの初心者がやろうとした結果かなりハマってしまったので（色んな意味で）メモを残しておきます。
また、ハマりポイント（自分の場合ですが）を補足として入れておいたので参考になればと思います。

以下では **”ライブラリ公開側の設定”** と **”ライブラリ利用側の設定”** に分けて話を進めます。

:::note info
本記事ではPackagistへの登録なしでできる方法をご紹介しています。
:::

## 環境

プラットフォーム

Windows10

Composer

v2.6.5

Git

v2.31.1

【CodePipeline・CodeDeploy】リモートブランチにpushするだけで、EC2に自動デプロイする（ハンズオン）

## 概要
GitHubで管理しているブランチにpushするだけで、自動でサーバーにデプロイする方法をご紹介します。
ハンズオンなので、深く考えなくても構築できるはずです。

## 図解
完成図は↓のようなものです。

①ローカルのブランチをGitHubにpushする
②GitHubの対象のブランチの変更をトリガーとして、CodePipelineが走る
②対象のEC2インスタンスにデプロイする

自動デプロイが実現すれば、ファイルをいちいちサーバーにコピーしなくても、pushするだけでコードの変更が反映されるようになります。

## 作業の流れ
### 事前準備
#### デプロイ先のEC2インスタンスを立ち上げる
今回デプロイしたいEC2インスタンスを立ち上げておきます。
インスタンスの起動方法はGitで既にコミットしたファイルをバージョン管理から外す方法

# はじめに
開発を進める中で「既にコミットしたファイルを後からバージョン管理の対象から外したい」という状況に直面することがあります。
たとえば、機密情報を含むファイルを誤ってコミットした場合や、ビルド生成物をリポジトリに含めたくなくなった場合などです。
こうした場合、.gitignoreファイルを使っても、すでに追跡されているファイルはその対象外となりますので、別のアプローチが必要になります。
この記事では、その方法をステップバイステップで説明します。

# 手順1 .gitignoreにファイルを追加
最初のステップは、バージョン管理から外したいファイルやディレクトリを.gitignoreファイルに追加することです。
これにより、これらのファイルが今後のコミットで無視されるようになります。

“`.txt:.gitignore
sample.py
app/
“`

# 手順2 キャッシュからファイルを削除
既にコミットされているファイルをGitの追跡から外すために、キャッシュから該当ファイルを削除します。
この操作はファイルを作業ディレクトリに残した状態で行います。
ファイルの

MQL4、MQL5のファイルをGitHubで差分表示する方法

## やりたいこと
掲題の通り、MQL4,MQL5のファイルをGit(GitHub)管理するときに差分を表示するようにしたい。
デフォルトだと.mq4/5のどちらもバイナリファイルとしてgitに認識されてしまう。


## 解決策
.gitattributesファイルに以下URLの適当なリポジトリからファイルを拾ってきて
ちょちょっと修正して利用しました。

https://github.com/orgs/EA31337/repositories

コメントは削除しております。
mq4/5ファイルに対してのみの設定で良い場合、無駄な記述も多いので適宜修正が必要かなと思います。

“`
[attr]utf8 text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,

コンテナ版GitLab間のproject移行

## A. やりたいこと

#### 条件

* 同一サーバに2つのコンテナ版GitLabを起動している。共通のSSL証明書を使用している。
* publishしているhttpsポート番号を443と4443に分けている。以下のようなかんじ
* https://gitlab.hogehoge.net/fugafuga/PJ.git
* https://gitlab.hogehoge.net:4443/fugafuga/PJ.git

ここの、443から4443に、プロジェクト(リポジトリ)をコピーしたい

## B. 手順

1. 4443側(コピー先)に同名で空のプロジェクトを作成する。README等も作らない。
1. 「コピープロジェクトスクリプト」を実行する
1. 以上

#### コピープロジェクトスクリプト

“`
#!/bin/bash
PJ=$1
cd /tmp
git clone https://gitlab.hogehoge.net/fugafuga/$PJ.git
cd $PJ
git remote rename origin old-origin
git

基本的なGitHubへのプルリクエストの方法

## アジェンダ
この記事では、GitHubでのブランチ管理の基本的なフローを紹介します。ブランチの最新化、ブランチの切り出し、変更のpush、プルリクエストの作成、そしてブランチの削除まで、開発プロセスをスムーズに進めるためのステップを順に説明します。

## フロー
### ブランチの最新化
開発を始める前に、ローカルの`develop`ブランチが最新の状態であることを確認します。これを行うには、以下のコマンドを使用します。
1. `git fetch`：リモートの変更をローカルに取得しますが、ローカルブランチにはマージしません。
2. `git pull origin develop`：リモートの`develop`ブランチから変更を取得し、ローカルの`develop`ブランチにマージします。

### ブランチの切り出し
新しい機能の開発を始めるには、`develop`ブランチから新しい`feature`ブランチを切り出します。例えば、`feature/test`ブランチを作成するには、以下のコマンドを使用します。
“`
git checkout -b feature/test