今さら聞けないGit　

Git GUIツールについて

こんにちは！
株式会社OGIX クライアントエンジニアのY.Kです！
（弊社については最後に紹介があるのでぜひ見てください）

みなさんはGit GUIツールを使用していますか？
私はGit触り始めての頃にコマンドラインツールでのGit操作していた所、先輩にGit GUIツールの使用を勧められました。
最初はコマンドラインでの操作と比べて段違いで操作しやすい！！！と感動していました。
ですが最近になってGit GUIツールでのできないこと、ツールならではのデメリットなどに気が付いたのでGit GUIツールについて簡単に紹介しようと思います。

## Git GUIとは？
GUI（グラフィカルユーザーインターフェース）は、ユーザーが直感的に操作できるグラフィカルなインターフェースのこと。
マウスやタッチパネルなどの入力デバイスを用いて、ウィンドウやアイコン、メニューなどを操作でコンピュータプログラムの機能を利用できるインタフェースを指します。

## Git GUIツールのメリット
#### 1.視覚的に操作ができる
コマンドラインツールでは、コマンドを覚えたり、入力することが必要です

.gitignoreファイルに記載のファイルが除外されない

## 本日のお悩み
既に作成済みの.gitignoreファイルに記載したファイルが、除外されない

## 本日の処方箋
**コマンドラインのVimで修正する**
詳しいやり方は長くなりそうなので割愛。下記参考記事に全て記載。超わかりやすいです。

MacOSで.gitignoreファイルを後から修正して反映する。Vimの基本操作も覚えよう

間違えてgit initをしてしまった時の対処法(取り消し)

## 本日のお悩み

“`
git init
“`

間違えて `git init` コマンドで関係ないgitリポジトリを作成してしまった。
このコマンドを取り消し、やり直したい。

## 本日の処方箋
“`rb
# git initをしたディレクトリで行う
rm -rf .git
“`
このコマンド操作を取り消しやり直したい場合、間違えて作成してしまったローカルリポジトリを、上記コマンドを入力し削除すればOK!
上記コマンドを入力したらもう消えているので、あとは該当のディレクトリでもう一度`git init` をする

git-svnを使ってSVNの変更差分をGitに取り込む方法

# はじめに
git-svnを使ってSVNのリポジトリをGitに移行した後、SVNが更新されてしまった場合にSVNの変更差分をGitに取り込む方法を備忘録として残しておく。

# 操作手順
### SVNの変更差分を取得する
“`
git svn fetch
“`

### GitのカレントブランチをSVNの変更差分を取得したいブランチに変更する
“`
git checkout [ローカルブランチ]
“`

### SVNの変更差分をGitのローカルブランチに同期する
“`
git svn rebase
“`

### ローカルブランチに同期したSVNの変更差分をリモートブランチにプッシュする
“`
git push origin [リモートブランチ]
“`

# メモ
– `[svn-remote “svn”] unknown`といったエラーが出る場合は事前に`git svn init`を行う必要がある
– 一度ローカルリポジトリを削除してしまった後、リモートリポジトリから再度クローンしてきた場合などにはgit-svnの設定ファイルがないため?
“`
git

Gitでの変更取り消し：revert の使い方

# Gitの `git revert` コマンドを詳しく解説

Gitで間違った変更を取り消す方法として、`git revert` コマンドは非常に便利です。このコマンドは選択したコミットを効果的に「打ち消す」新しいコミットを作成し、リモートリポジトリにプッシュされた変更を安全に取り消すことができます。以下にその詳細と、使用方法を解説します。

## 打ち消したいコミットハッシュの取得方法

コミットハッシュは、Gitの各コミットを一意に識別するIDです。これを取得するには、以下のコマンドを使用します。

“`bash
git log
“`

このコマンドを実行すると、リポジトリのコミット履歴が表示され、各コミットの詳細とともにハッシュも表示されます。例えば以下のような出力が得られます。

“`bash
commit 1a2b3c4d5e6f7g8h9i0j (HEAD -> master, origin/master, origin/HEAD)
Author: Your Name
Date: Mon Sep 14 16:00

Commit Message Driven Development (CMDD) について

みなさんはコードを書くとき、何を大事にしていますか？

私は「タスクを細かく分解し、着手している間はそのタスクに集中する」ことを重視しており、人に教える際もこの観点が非常に役立っています。

この観点は git のコミットメッセージによく表れていると考えており、コミットメッセージを起点に開発する手法はないかと調べつつ、自分なりの方法を考えてみました。

## コミットメッセージ駆動開発 (Commit Message Driven Development, CMDD) とは

巷でよく言われるテスト駆動開発が

– テストを書いて失敗させる
– コーデを書いてテストを成功させる
– リファクタリングする

というサイクルで進むのに対し、コミットメッセージ駆動開発 (Commit Message Driven Development, CMDD) は

– コミットメッセージを書く
– コードを書く
– コミットする

というサイクルで進みます。

## CMDD の実践方法

ここでは git の empty commit を利用して CMDD を行う方法を紹介します。

まず、コミッ

GitHub issue へのラベル付けを強化する

# はじめに
皆さんはissueテンプレート[^1]を使っていますか?
テンプレートには幾つかのフォーム要素があります。具体的な要素としてmarkdown, checkboxes, textareaなど色々とあります。
この中でもdropdownタイプは環境報告(例えば OSの選択など)等、色々な所で使われることがあると思います。そしてdropdownで選択されたもののラベルを付与したいと思ったことがないでしょうか?
今回は[Advanced Issue Labeler](https://github.com/marketplace/actions/advanced-issue-labeler)を使って自動的にラベル付けさせてみたいと思います。

本記事で作成したものは以下のリポジトリより確認できます。

https://github.com/yui10/issue-labeler-sample

# issueテンプレートを作成
今回はバグ報告のissueを想定して入力フォームを作成していきます。

“`yml:.github/ISSUE_TEMPLATE/bug_report.y

gitでpushできない時の解決策　(ローカルリポジトリとリモートリポジトリに差がある)

# 初めに
webアプリの保守をしていた時にpushができなかったのでその解決方法を紹介します。

# エラー内容
“`
To https://~
! [rejected] main -> main (non-fast-forward)
error: failed to push some refs to ‘https://~’
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you want to integrate the remote changes, use ‘git pull’
hint: before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.
“`
# 原因
そもそも僕はリモートリポジトリに何かしらデータを反映させてました。
でもwebアプリの保守のためにローカルリポジト

Gitで特定のコミットまで戻る方法　(git reset)

# 初めに
Webアプリの保守をするために前のコミットに戻る必要があったのでその方法を調べました。
その方法を紹介します。
# 開発環境
macOS Sonoma 14.4.1
# Gitで特定のコミットに戻る方法
ログを確認後リセットをします。
まずログを確認してどのコミットに戻るのかハッシュ値を特定します。
“`
git log
“`
をwebアプリのプロジェクト内で実行します。
その後

こんな感じでgitのログを確認できます。

commit

の文字の横にあるハッシュ値を覚えておいてください。
その後
“`
git reset –hard ハッシュ値
“`
ハッシュ値を「ハッシュ値」に入れて上記を実行してください
これで完了です。
お疲れ様でした。
# 参

【Git】まずはこれを読め！Gitの基本

# はじめに

こんにちは、エンジニア3年目の嶋田です。
この記事を開いていただきありがとうございます！
先日、新入社員と話していてGitの使い方についてもっとわかりやすく伝えたいなと思ったので記事にしてみました。
Gitの基本を学びたい初学者の方や、未経験のエンジニアの方にもわかりやすく、役に立つ内容を目指します！

# 目次
– [Gitとは何か](#Gitとは何か)
– [リポジトリって何？](#リポジトリって何？)
– [基本的なGitコマンド](#基本的なGitコマンド)
– [ブランチの扱い方](#ブランチの扱い方)
– [マージとは？](#マージとは？)
– [最後に](#最後に)

## Gitとは何か
「Git」とは、ソースコードのバージョン管理を行うための分散型バージョン管理システムです。
このツールを使うことで、開発中のプロジェクトでの変更点を効率的に追跡し、複数の人との共同作業がスムーズに進行します。

バージョン管理システムとは、ファイルの変更履歴を記録し、過去のある時点の状態に戻すことができるシステムのことを指します。これに

“個人開発で Git 管理を行う簡単な方法” 記事の具体的な手順を紹介【Unity】

この記事では下記の記事の
具体的な手順を紹介したいと思います。

[【Unity】Git 初心者でもできる個人開発で Git 管理を行う簡単な方法](https://qiita.com/uni928/items/f185f9b1d04c60979f49)

上記の記事を見て
失敗した人はこの記事を
是非ご参考下さい。

***

この記事で使用した SourceTree のバージョン

この記事は Version 3.4.14 で作成しております。

この記事が投稿されて何年か経過した場合は
見た目が変わっている可能性があるためご注意下さい。

おおまかな手順は未来のバージョンでも
変わらないとは思います。

***

SourceTree のインストール

私が既に SourceTree を
インストールしてしまっており
アンインストールするのが怖いため
インストール手順については省略したいと思います。

何卒ご容赦下さい。

「SourceTree インストール　手順」等で
Google 検索頂くようお願いします。

***

Unity プロジェクトの Assets フォルダで

【図解】初心者向け、Gitで開発を行うときに最低限必要になるGitコマンドとその操作フロー

GithubやGitlab等を使って開発を行うときにローカル側での操作で、最低限必要になるGitコマンドとその操作順をフロー図を加えて説明します。

# はじめに

一般的にGithubやGitlab等をリポジトリとして利用する場合、開発フローとしては「git-flow」か「Github Flow」を採用することが多いです。これらのフローの詳細についてはここでは省略するので、以下のリンクなどを参照してください。

– https://atmarkit.itmedia.co.jp/ait/articles/1708/01/news015.html

基本的にはどちらもmain or developブランチから開発する機能やissueごとにフィーチャーブランチを切って開発を進め、リモートリポジトリにプッシュしてプルリクエストを作成し、レビューを受けてマージするという流れになります。

今回は、これらのフローを実践する場合に最低限ローカルで必要になるGitコマンドを解説します。

# ローカルでの操作と使用するGitコマンド

開発はリモートのリポジトリをクローンしてローカルに持ってくる

Git フックを使ってみる

## Gitフックって？！

Git フックはGitを用いた特定の作業に応じて処理を走らせるものです。

Git フックを活用することで「コミットをする前にlinter（コードの自動補正ツール）を走らせる」なんてことも可能です！

多分この記事より、公式ドキュメントを見たほうが分かりやすいのでリンクを置いておきます！

https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%83%95%E3%83%83%E3%82%AF

## Gitフックの基礎

– Git フックの処理はシェルスクリプトで記載します。
– フック処理のファイルに拡張子は必要ありません。

## Gitフックの種類

### コミット系

#### git commitコマンド実行直後に実行されるフック 〜pre-commitフック〜

– pre-commitフックはgit commitコマンド実行直後に動作させたい処理を記載します。
– 公式ドキュメントに

Gitのローカルを戻す方法　〜Git statusで確認しよう~

## 見出し
この投稿は初投稿となります。温かい目でご覧いただくとありがたいです！
アウトプットの一つとしてQiitaを使ってみます！
今年の１６日から未経験のプログラマーとして働くのでGitを再度復習しようと思って投稿いたします。
Gitのローカルで間違えて変更してしまったものを元に戻す方法をまとめていきます。

## ステージングされていないGitの変更を元に戻す方法

まずGit statusコマンドで現在のGitの状態を確認します！

“`ruby:new.html.erb
git status
On branch basic-login
Changes not staged for commit:
(use “git add …” to update what will be committed)
(use “git restore …” to discard changes in working directory)
modified: app/views/users/new.html.erb

SourceTree(Revert)のやり方と実戦解説(Xcode)

# はじめに
SouceTreeでたまにマージしているけど、特定のコミットは含めたくない（削除したい）時などがあると思います！
そんな時に使えるRevertを振り返る為に備忘録として残します。

# 前提条件
– Souce Treeを日頃使っている方
– gitの知識がある程度ある方

#
Revertとは
元々すでにマージされているコミットを削除してくれるくらいの感覚です！
色んな記事があるので正しい情報はそちらをみて頂けたらと思います。

# 実戦！

gitにリポジトリとXcodeの準備が終わっているところから進めていきます！

### 1
まずはxcodeとgitignoreあたりをgit管理します！

![スクリーンショット 2024-05-11 16.43.32.png](https

Git-4 ブランチについて

# 前提知識
gitでは、gitリポジトリにコミットを積み上げることで、プロジェクトの各時点での状態及びその変更の軌跡を辿ったり、任意の時点の状態を復元することができる。

コミット同士の前後関係は、コミット自体が「直前のコミット（親コミットと言う）は何か」という情報を持っているため、親コミットを辿っていくことにより知ることができる。


# ブランチ
## 概要
ブランチとは、特定のコミットへの参照を保持するポインタのような領域である。

このように説明すると「ブランチとは枝分かれするための機能である」というイメージと乖離しているかもしれないが、結果的にはこの「特定のコミットへの参照を保持するポインタ」がコミットの軌跡を枝分かれさせることを可能にしている。

![d.png](https://qiita-image-store.s3.ap-nort

ブランチ間の差分がみたい

ファイル単位

“`
git diff master origin/master –oneline –stat-width=800
“`

細かいところまでみたい

“`
git diff master origin/master
“`

gitでpycacheフォルダをリモートリポジトリから消す方法

# はじめに
djangoでwebアプリケーションの作成をしていたときに、.gitignoreを作成していないことに気づき、作業途中でgitignoreを追加しました。
しかし、途中から.gitignoreを追加すると追跡はしなくなりますが、リモートリポジトリにはpycacheフォルダが残ってしまいます。
なので、リモートリポジトリからpycacheフォルダを消そうと思います。

# ターミナルでコマンドを実行
以下のコマンドをターミナルで実行します。

“`
git rm –cached `git ls-files | grep __pycache__`
“`

コマンドで行っていることは以下のとおりです。

– `git rm –cached <対象ファイル>`
リモートリポジトリのみから削除

– `git ls-files`
Gitリポジトリに含まれるすべてのファイルのリストを出力

– `grep __pycache__ <対象ファイル>`
__pycache__を検索

– `git ls-files | grep __pycache__`
|は左側の出力

【ざっくり分かるGit】鶏と卵と図で分かるマージの種類

## 早めの結論
`dev` から `feat` ブランチを切って作業しており，
`feat` の変更内容を `dev` にマージしたいとします


– `fast-forward` マージ（早送りマージ）
– `dev` で変更が無かったマージ
– `feat` ブランチの変更内容を `dev` の後に付け加えられるマージ
– 卵が先で鶏はいないの
– `no-fast-forward` マージ（3-wayマージ）
– `dev` に変更があったマージ
– `feat` の変更内容を取り込みましたよっていうコミット（マージコミット）が作られる
– マージコミットがあるので，変更がどっから切ったブランチのやつだったかが分かる
– 鶏が先で卵が後
– `squash` マージ（スカッシュ

Gitの基本的なコンフリクト解消方法

## コンフリクトの解決

### 問題
複数の人が同じファイルの同じ部分を編集したときに発生します。これを「コンフリクト（衝突）」と呼びます。

### 解決法
コンフリクトが発生したら、Gitはファイルにマークをつけて、どの部分が衝突しているかを示します。以下のような形式になります。

“`plaintext
<<<<<<< HEAD 自分の変更 ======= 他人の変更 >>>>>>> branch-name
“`

これを見て、どちらの変更を保持するか、または両方の変更を組み合わせるかを決め、マークを手動で削除します。その後、ファイルを再びステージングし、コミットします。