今さら聞けないGit　

git stash メモ

GUIに頼りきりですぐ忘れるので、メモ。

**作業中のファイルの退避**。ステージングしていない変更も含めて退避する。ブランチを移動したいときはこれ。
“`bash
$ git stash -u
“`

**直前に退避した作業の復旧**。stash一覧からは取り除かれる。
“`bash
$ git stash pop
“`

**特定の目的のパッチの作成**。必要な部分だけステージングし、名前を付けて退避する。
“`bash
$ git stash -m ‘パッチの説明’
“`

**特定の目的のパッチの適用**。“`git stash list“` で一覧から目的のパッチを探し、番号を指定して適用する。stash一覧には残す。
“`bash
$ git stash apply n
“`

**不要になったパッチの削除**。“`git stash list“` で一覧から目的のパッチを探し、番号を指定して削除する。
“`bash
$ git stash drop n
“`

detached HEADとは？？

## 初めに
git rebaseをした時に、git branchコマンドで自分の今いるブランチを確認すると　detached HEADと表示されている時ありますよね。そのdetached HEADとは何かについてまとめてみました。

## detached HEADとは
HEADがcommit IDを直接指し示している状態のことです。

そもそもgitのブランチとは、コミットを指す軽量なポインタに過ぎません。

コミットとコミットの間はどうなっているのかというと、コミットがコミットを指すことによって、結び付けられています。

なので、detached HEADは、過去のコミットIDを直接指定して、checkoutすると生じます。

解決策

“`
git branch <ブランチ名>
“`

を実行することで、ブランチの先頭にあるcommit IDをすれば直すことができます。

## 最後に
gitのブランチについての理解が足りてませんでした。ブランチってコミットを指してたんですね。勉強になりました。

revertのrevertで復活させたファイルが別ブランチで復活しない

一度revertで削除したファイルをバグがなくなったため復活させることにした。
開発ブランチでrevertのrevertを実施すると問題なくファイルが復活するが、releaseブランチにマージしてもreleaseブランチではファイルが復活していなかった。
開発ブランチにあるファイルがマージで反映されない事態に違和感を覚えたため調査した。

以下revertのrevertは長いのでreapplyと呼ぶ。

## 再現コード

簡略化したコードは下記。

“`sh
echo “hello, world” > file
git add file
git commit -am “add file”

git branch dst
git revert –no-edit

git switch dst
git cherry-pick

git switch src
# revertのrevert
git revert –no-edit

git switch dst
git merge

毎回ignoreするのが面倒くさいと思うファイルはグローバルignoreしよう!

みなさん、下のようなことを思ったことがありませんか?

「IDEの設定ファイルをignoreに追加するのめんどくさいな」

私は、Jetbrains系のIDEを使用するため、プロジェクトを触った際に.ideaファイルが生成されてしまうので、共同開発の際に.ideaファイルを一々.gitignoreしていました。

ですが、流石にめんどくさくなってきましたし、個人依存な部分が大きいと思うので、プロジェクトの.gitignoreファイルに追加しなくてもいいように、自分の環境下では自動的にignoreしてくれるグローバルなgitignoreの設定の仕方を調べてみました。

# 設定の仕方

`$HOME/.config/git`に`ignore`というファイルを生成するだけで、自分の環境下では設定したファイルがgitignoreされるようになります。

例えば、Macユーザでは`~/.config`が存在していると思われるので、以下のコマンドでgitの設定ファイルに移動します。

“`
cd ~/.config/git
“`

:::note
もし存在しない場合は、`mkdir`コマンド

Mermaidで図表作成を楽しもう！

## はじめに

皆さん、こんにちは。今日は「Mermaid」というすばらしいチャートツールについてお話しします。Mermaidを使えば、複雑な図表やダイアグラムを簡単に作成できるんです。しかも、特別なソフトウェアは必要ありません。テキストエディタさえあれば十分です。

それでは、Mermaidの世界に飛び込んでみましょう！

## 第1章：Mermaidとは

Mermaidは、テキストベースの図表作成ツールです。簡単な記法を使って、フローチャート、シーケンス図、ガントチャートなど、さまざまな種類の図表を作ることができます。

Mermaidの特徴は以下の通りです：

– テキストベース：図表をコードで表現
– 多様な図表：フローチャート、シーケンス図、ガントチャートなど
– 簡単な記法：短時間で習得可能
– 高い再現性：コードを共有すれば、誰でも同じ図表を作成可能

## 第2章：Mermaidの基本構文

Mermaidの基本構文は非常にシンプルです。以下の形式で記述します：

“`text
graph TD
A[開始] –> B[処理1]
B –> C[処

git rebaseによるローカルとリモートのずれの発生と解消

## 背景
git rebaseを行ったところ、ローカルとリモートでずれた状態になった。
あまり実務では実施しないため、どのような動きで実現・解消できるか記載。

## 目的
rebase が起こす問題を知る

## 実施内容
もともと上記画像のorigin/feature-1にいたfeature-1を下記でrebaseしたのが上記画像の状態
“`git
git rebase develop
“`
しかし、上記操作によりリモートとずれてしまっている。（feature-1とorigin/feature-1がずれている）
そのため、下記を実施してリモートの状態を強制的にローカルと合わせた。

“`git
git push –force origin feature-1
“`
実施後が下記の図。

「git pull」はgitの内部では何をしているか

## 背景
昨日gitの内部の仕組みを学習した。
git pullの時の解説がなく、何が行われているか疑問に思った。

## 復習
・git fetch の際に行われているのは、リモートのgitオブジェクト＆リファレンスを「origin/〇〇」としてローカルに持ってくること。つまり、ローカルのリファレンスやブランチは変化しない。
・git merge の際に行われているのは、リファレンスの付け替え（commitオブジェクトの生成はない）。

## git pullは何をしている？

答えは書いてあった。
pull = fetch + merge

つまり、下記を行っている。
1. fetchでリモートのgitオブジェクト、リファレンスをローカルに持ってきた後、
2. mergeでリファレンスを動かす（コミットオブジェクトは作成されない）

![スクリーンショット 2024-09-18 22.22.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/644072/f8b51313-cfc2-f4cc-db

WindowsサービスとしてGiteaを設置する

# この記事の概要

Gitベースのソース管理ツールである[Gitea]を、Windowsサービスとして登録、設置する。

[Gitea]:

# 用意するもの

## Gitea

まずはじめにGiteaです。
公式文書で[さまざまな方法が紹介](https://docs.gitea.com/category/installation)されていますが、この記事ではビルド済みの[gogit-windowsビルド](https://docs.gitea.com/installation/install-from-binary#choosing-the-right-file)というWindowsバイナリを使います。
[ダウンロードエリア](https://dl.gitea.com/gitea/)から最新版をダウンロードしてください。

この記事執筆時点では[gitea-1.22.2-gogit-windows-4.0-amd64.exe](https://dl.gitea.com/gitea/1.22.2/gitea-1.22.2-gog

[5分でマスター]初心者はまずREADMEを書け[テンプレート付き]

突然ですがgitにプロジェクトをあげる際に***README***を書いていますか？
エンジニアを志す者であれば必ず耳にしたことがあるであろうREADME、今回はその書き方を簡潔に分かりやすくまとめていきます。

## READMEとは？
READMEとは、プロジェクトやソフトウェアの情報や使用方法を説明するためのファイルです。通常、プロジェクトのルートディレクトリに置かれ、他の開発者やユーザーがプロジェクトの目的、設定、使用方法を理解するのに役立ちます。

https://github.com/vim/vim

上のリンクのファイルのすぐ下に見れる長い文章がREADMEです。

## そんなのいらなくね？
READMEを書く理由は様々あります。(プロジェクトの説明、インストール方法、使用方法など)

ですが、あえて初心者がREADMEを書くべきである理由は **「カッコいいから」** につきます。

最近プログラミングについて学び始めたあなたが、友人に目に見える成果で自慢をする最も簡単で効果のある方法はREADMEのあるgitを見せつけることです。
READMEがない

git 内部の仕組みを見ての学び

## 背景
誤ってdevelopにまだレビュー前のコードをコミットしてしまった。
その際、下記を行った。
`git reset –hard　コミットハッシュ`
しかし、コミットハッシュを指定して、developブランチが元に戻る、とは何が起きているのか？？と疑問が生じたため、gitの深いところが理解したくなった。

## 目的
今まで雰囲気で使用していたgitを、より何が起きているか理解し、コマンドをより安心して使用できるようにしたい。

## 本文
– gitには2つが存在する
– gitオブジェクト：blob,tree,commit,tag
– gitオブジェクトはイミュータブルで追加されていくのみ
– リファレンス：branch,head,tag
– ポストイットみたいなもので、ハッシュ値を参照する
– イメージ的には、非巡回グラフ（gitオブジェクト）が作成されて、ポストイット（リファレンス）がついている
– HEAD
– 現在チェックアウトしているリファレンス（ブランチ）を指す
– 現在さし示しているコミットオ

TradeWaltz: 貿易のデジタルトランスフォーメーション 貿易DX

概要
TradeWaltzは、ブロックチェーン技術を活用した貿易情報連携プラットフォームです。このプラットフォームは、
貿易に関わる全てのステークホルダー（輸出入者、物流会社、銀行、保険会社、行政機関など）を繋ぎ、
貿易業務のデジタルトランスフォーメーションを実現します。

主な機能と特徴

貿易情報の一元管理:
TradeWaltzは、貿易に関する情報や書類をクラウド上で一元管理します。これにより、紙ベースの書類や分散したデータの管理が不要になり、業務効率が大幅に向上します。

ブロックチェーン技術の活用:
ブロックチェーン技術を活用することで、データの改ざん防止や信頼性の確保が可能です。これにより、貿易書類の真正性が保証され、トラブルのリスクが低減されます。

多様なステークホルダーとの連携:
輸出入者、物流会社、銀行、保険会社、行政機関など、多様なステークホルダーが一つのプラットフォーム上で情報を共有し、効率的に連携できます。

業務プロセスの可視化と効率化:
貿易業務の進捗状況をリアルタイムで把握できるため、業務の可視化と効率化が実現します。また、重複作業の削減やミスの防止に

Github – mainなどのブランチへの強制 pushを禁止する設定 ( 組織のレポジトリ > 保護ルール )

# Githubでの設定

レポジトリのSettings -> Branches からルールを追加する

これだけで git での強制pushを禁止できるようだ

## git のエラー例

“`sh
$ git push –force-with-lease
“`

“`
! [remote rejected] some-branch -> some-branch (protected branch hook declined)
error: failed to push some refs to ‘https://github.com/xxx/yyy.git’
“`

# コミットを積んでのpushは禁止できるのか？

保護ブランチに対して、強制pushではなく、コミットを積んでのpushは禁止できるのか？

試したところ、

–

結局 Git のブランチ戦略ってどうすればいいの？

## 背景

9/5に開催された弊社ミライトデザインが運営しているペチオブ勉強会に参加しました。

https://phper-oop.connpass.com/event/326850

みんなで話し合ったGit運用の中のブランチ戦略パターン(**Git Flow**, **GitHub Flow**, **GitLab Flow**, **Trunk Based Development**)について勉強して、個人的に情報を整理したいなと思ったので記事にしました。
イベントの動画や議事録もconnpassのリンクから確認できます。

## PR

:::info
弊社[ミライトデザイン](https://miraito-inc.co.jp)では、他にも様々なお役立ち記事や動画、勉強会を公開しています。よかったら[ミライトデザインOrganizationページ|Qiita](https://qiita.com/organizations/miraito-inc)、[MIRAITO CHANNEL|YouTube](https://www.youtube.com/c/MiraitoDes

GIthubの操作をミスったときによく使うコマンドメモ

①直前のコミットを取り消し、変更はステージングエリアに残されたままにする（git addされたままにする）

“`powershell
$ git reset –soft HEAD^
“`

②直前のコミットも取り消し、ステージングエリアからも変更を取り消す

“`powershell
$ git reset –hard HEAD^
“`
**※過ってマージコミットしてしまった場合も、これを使うことでマージ前の状態に完全に戻せる**
____

③git addしたファイルを全て git addされていない状態に戻す

“`powershell
$ git reset
“`

④git addしたファイルのうち、特定のファイルを git addされていない状態に戻す

“`powershell
$ git reset
“`
____

⑤マージの途中で何らかの理由で取り消したい場合、進行中のマージを中止する

“`powershell

githubのpull request はgitlabのようにmerge requestにした方がしっくりくると思う

ソフトウェア開発において，コード変更の提案と統合は重要なプロセスだ．GitHubとGitLabという二大プラットフォームは，この機能に異なる名称を与えている．なぜGitHubは「プルリクエスト」，GitLabは「マージリクエスト」と呼ぶのか．この違いの背景を詳しく探ってみよう．

Githubのpull request
と
Gitlabのmerge request
どっちも同じイラストで内容も同じである．

(git3)tig(Gitツール)操作方法

# ■概略
オープンソースエンジニア歴30年超の筆者が2023年からIBMiを学びだした学習記録です
gitツールのtigを弊社で設定した操作方法をまとめました

## ■tigの基本
### ◯gitコマンドでソースコードの取得
IFS上のホームディレクトリにgit cloneでソースを取得する
“`
$ ssh as400dev ※VSCodeのterminalかsshクライアントから
$ cd ~
$ git clone {gitプロジェクトのURL}
“`
## ◯tigの起動
“`
$ cd {gitプロジェクトのディレクトリ}
$ tig ＊起動直後はcommit履歴画面(main)
“`
## ◯tigの画面とキーバインド
tig を起動後、 r でブランチ一覧を表示
(画像はmainになっているがmasterブランチのこと)
![develop_tig01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3875673

Homebrewがインストールできない [M3 mac]

## はじめに
今回、Macを修理に出すと見事に全てのデータが吹き飛んだため、環境構築をし直しました。
その際Homebrewのインストールに躓いたため、備忘録として残しておきます。

## 問題点

https://brew.sh/ja/

公式サイトの通りにインストールを試してみても、インストールできない

“`zsh:zsh
/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
“`

“`zsh:error
error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8)

error: 7720 bytes of body are still expected

fetch-pack: unexpected disconnect while reading sideband packet

fatal: early EOF

fatal:

(git2)IBMi(AS400)でのgitコード管理の流れ

# ■概略
オープンソースエンジニア歴30年超の筆者が2023年からIBMiを学びだした学習記録です
筆者が行っているFFRPGのgitコード管理の流れをまとめました

### ◯ブランチの役割

目的	ライブラリ	ブランチ名
本番	本番機のCGILIB	master ※feature/fixからmasterに 　開発者がマージリクエストし、管理者がマージする
開発	開発機のCGILIB	develop ※feature/fixからdevelopに 　開発者がマージリクエストし、開発者がマージする
バグ修正	個人ライブラリ	fix/#イシ 元記事を表示 【 自動化 】Huskyとpost-checkoutフックを使って新規ブランチのファーストコミットを自動化する方法 ## はじめに Gitフックを管理するためのライブラリ Husky を使って、post-checkout フックを活用し、新規ブランチをチェックアウトした際にファーストコミットを自動で実行する方法を紹介します。 通常、新しいブランチを作成したら、ブランチ名をコミットメッセージにして空コミットを作成する作業が必要です。 これを Husky を使って自動化する方法について解説します。 ## 1. 環境設定 公式サイトを参考にしてください https://typicode.github.io/husky/get-started.html ## 2. ディレクトリ構成 “` client/ ├── .husky/ │ ├── _/ │ │ └── post-checkout.sh │ └── post-checkout server/ “` ## 3. post-checkout フックの意味 post-checkout は、Gitのフックの一つで、ブランチやファイルをチェックアウトした直後に実行されます。 post-checkout フックは、主に次 元記事を表示 wslからもgithubにプッシュしたい # はじめに 今までwindows terminalでgit使用していて、wsl側でもそのままgithubにプッシュしよーて思ってたらできなくて詰まった。 # 手順 ※以下はwindows terminalでgithubにpushできる場合を前提 #### ◯ WSLとWindowsのファイルシステムの共有とSSHキーの設定 WSL（Windows Subsystem for Linux）とWindowsのファイルシステムを共有することで、WSLとWindows間でのファイル管理やSSHキーの共有が可能になるっぽい #### ◯ WindowsのSSHキーの使用 Windowsに保存されたSSHキーをWSLで使用する場合、キーが保存されている場所（例えば、`C:\Users\your_username\.ssh\id_ed25519`）にWSLからアクセス。 #### ◯ WSLでキーのコピー WSLにキーをコピーして、WSLの ~/.ssh フォルダーに配置することができる。 “`sh # wslに.sshなかったら作成 mkdir -p ~/.ssh # 元記事を表示 OTHERカテゴリの最新記事 2024.09.19 JavaScript関連のことを調べてみた 2024.09.19 JAVA関連のことを調べてみた 2024.09.19 iOS関連のことを調べてみた 2024.09.19 Rails関連のことを調べてみた 2024.09.19 Lambda関連のことを調べてみた 2024.09.19 Python関連のことを調べてみた