今さら聞けないGit　2023年10月04日

“Git SOS: 間違えて別のブランチにpushしてしまったときの対処法”

# 概要
皆さんはコミットしてpushした後に作業ブランチが間違っていることに気づいたことはないでしょうか？(僕はよくこのポカミスをよくします)
そんな時の対処法を備忘録として残しておきます。

:::note warn
私はプログラミング初学者のため間違った記述があれば教えていただけると幸いです。
:::
:::note alert
今回は個人開発ですが、–force オプションを使用してpushする場合は注意が必要です。他の人とブランチを共有している場合、この操作は他の人の作業を上書きする可能性があるので共同作業者と事前に相談してください。
:::
## 状況
個人開発の際、routes_setupブランチで作業していると思い、コミットし“push“し“Pull request“した際、ボタンが出てこず確認してみるとtop_pageブランチで作業してしまっていました。
## 対処法
###### ローカルで正しいブランチにコミットを移動する
まず、現在のブランチでの変更を確認しコミットハッシュをメモします。
“`ruby:
git log
“`
正しいブランチ（rou

[超初心者] Github入門

# 概要
超初心者がGitHub関して纏めます。
また、シナリオに沿ってどのような操作が必要になるかも纏めます

まずは、Gitが生まれた背景を見てみましょう

## ソースコード管理の歴史
ソースコード管理（Source Code Management, SCM）は、ソフトウェア開発における欠かせない要素であり、その進化はソフトウェア開発プロセスの革命をもたらしました。

### 中央集中型バージョン管理（CVCS）の課題
ソフトウェア開発の初期には、中央集中型バージョン管理システム（CVCS）が主流でした。CVCSでは、プロジェクトのソースコードは中央リポジトリに集約され、開発者は中央リポジトリからコードをチェックアウトして編集しました。しかし、CVCSには以下の課題がありました

– 競合とコンフリクトの管理: 複数の開発者が同時にコードを変更すると、競合やコンフリクトが頻繁に発生しました。これを解決する手段が必要でした。

– 履歴の管理: プロジェクトの変更履歴を効果的に追跡し、特定のバージョンを特定する方法が不足していました。

### BitKeeperとDVCSの出現

WSL上で[safe] directory = %(prefix)///wsl….を設定しても、fatal errorが出てしまう

当方Windows11を使用しています。
Source treeを使いたく、wsl上にgit cloneしたものをgitconfigへ設定しようとしていたのですが

“`
fatal: detected dubious ownership in repository at (省略)
To add an exception for this directory, call:
git config –global –add safe.repository ‘%(prefix)///wsl.localhost/Ubuntu/home/username/repository_name
“`

とエラーが出るばかりで上手くいきませんでした。

ubuntu上でvimを使って設定したり、git config –global –add safe.repository ‘%(prefix)~~を打ち込んだりしていました。

結論ubuntu上で触っていたのがよくなかった….

## 解決策
Source Treeのターミナルから設定したら上手くいきました。

そもそもSource Tr

マージの手順解説

# はじめに
本記事ではマージの手順について書きます。
GitHubを使って開発している方のお役に立てれば幸いです。

# 作業環境
Windows
GitHub
VSCode

# 作業手順(簡易版)
※見やすさを重視するために簡単な説明しか書いていませんが、最初の慣れないうちはそれぞれのコマンドの意味を理解し、今何をしようとしているのかイメージしながら入力してください。
※Gitでの管理は他の方に迷惑をかける可能性があるので、何をするにしても慎重に行う癖をつけておきましょう。(今回はマージするだけなので、基本的には他人に迷惑はかからないはずです。)


| コマンド | アクション |
|:-|:-|
|① [メニュータブ]でFile→Open Folder→対象のフォルダを選択 | プロジェクトを行っているディレクト

過去の黒歴史（gitのコミットメッセージ）を修正する方法

# はじめに
急いでいてgitのコメントを適当にしてしまったりして、あとから修正したい…ってなりますよね。
過去の黒歴史（gitのコメント）は消せます！！！
__Sourcetreeからでも消せます！！！__(*’▽’)

# 記事の要旨
・[最終コミットのコメントの修正](#最終コミットのコメント修正)（[git Bash](###1.git-Bashから変更)/[Sourcetree](###2.Sourcetreeから変更)）
・[2回以上前のコミットのコメントの修正](#2回以上前のコミットのコメント修正)（[git Bash](###3.git-Bashから変更)/[Sourcetree](###4.Sourcetreeから変更)）

# 環境
“`bash:git Bash
$ git –version
git version 2.41.0.windows.3
“`
既定のエディタはVScodeを設定しています。

# 最終コミットのコメント修正
画像中の「ccc」というコミットコメントを「cccを追加」に変更しようと思います。
![image.png](http

本気で一ヶ月働いてみて思ったこと

# tech企業の実践就業型インターンシップに参加

一ヶ月の間、平日週5回毎日朝から夕方までフルタイムで働いて思ったことをとにかく書き下していく
いろいろ思い出したり感じたことがあれば随時更新していく

Javaを使って社内システムの開発を行なった
スクラム開発（二週間ごとに課題を決めて毎日報告）

## 開発者としての意識
何年も使えるコードを作る
メンテナンスのしやすさや他人が見やすいか
ー＞　コードは個人のものではなく会社のもの！

## バックログを明確に
多分これが一番苦労したし一番重要だと思うこと
序盤には「え、俺今何してるの」と思う瞬間がかなりあった
なぜこのようなことに陥るのかというとタスクの優先順位がしっかり設定できていないからである
これができていれば、「何のために何をしているのか」がはっきりし、コーディングを進めることができる
これは研究など普段の生活でも役立つだろう
とてもいいことを学ばせてもらった

脳のリソースは無限じゃないしなんなら自分はその容量が小さいほうだと思う
だからこそ外部記憶装置（ノートとかnotion）を使って実装に集中できるようにする
タス

コミットメッセージのプレフィックスにブランチ名を入れるようにする

# 背景

ブランチ名をチケット番号にする運用かつスカッシュマージやリベースを行うフローでないため、各コミットメッセージからチケットを辿れるように、ブランチ名をプレフィックスに自動で付けたかった

# 対応

`.git/hooks/prepare-commit-msg` を作成し、現在のブランチ名プレフィックスにする。

“`bash
#!/bin/sh

BRANCH_NAME=$(git symbolic-ref –short HEAD)
echo “[$BRANCH_NAME]　” > $1
“`

パーミッションを付与する

“`bash
chmod +x .git/hooks/prepare-commit-msg
“`

# 動作確認

コミット時に開かれる vim 上でプレフィックスが既に入力されている

“`bash
$ git commit
“`

“`
[feature/hogehoge]
“`

ScoopでインストールしたGitでTortoiseGitを使用したい。。「git.exe not correctly set up()」を解消する必要あり

## 環境
– Windows10 Pro
– git 2.39.1 (scoopでインストール)
– TortoiseGit 2.41.0.1

## 参考記事
https://mebee.info/2021/02/27/post-29631/

## エラー内容
“`
git.exe not correctly set up()
Check TortoiseGit settings and consult help file for “Git.ext Path”
“`

## 解決方法
– 検索で「settings」を入力して、「Settings」をクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2711955/426d6e37-

【Gitコマンド】コミットメッセージ変更方法

自分がコミットメッセージを間違えた時に実行する方法を備忘録として残しておきます。

:::note alert
記載されている内容は、プッシュする前のコミットメッセージの変更方法です。
:::

### 目次
* 直前のコミットメッセージを変更する方法
* 2つ以上前のコミットメッセージを変更する方法

## 直前のコミットメッセージを変更する方法
まずは過去のコミットを確認しましょう。
“`
git log –oneline
“`
`–oneline`をつけることで、以下のようにコミット番号とコミットメッセージが1列に揃った形で表示されます。

“`
00000000 直前のコミット //ここのコミットメッセージを変更する
11111111 2つ前のコミット
22222222 3つ前のコミット
“`
今回は、直前にコミットしたコミットメッセージを変更します。
直前のコミットを修正する場合は、`–amend`オプションを使用します。

“`
git commit –amend -m “修正後のコミットメッセージ”
“`

:::note info
–amendオプ

一歩目のGitとGitHub設定方法

初めてGitを使用する際に、自分なりにメモとして残します。

私が使用しているのはMacですので、Mac用の設定方法についてご説明します。ご了承ください。

まず、前提としてGitとGitHubは異なるものです。

私はこれを理解するのに、時間がかかりました。

簡潔に説明すると、Gitはプロジェクトのコードを記録するためのソフトウェアです。

一方、GitHubは記録したコードを他人と共有したり、自分自身が分かりやすく管理できるようにしたものと認識しています（もし間違っていたら、すみません）。

以下は超基本的な設定手順の順番になります。

# ①GitとGithubをインストール
GitはMacでは標準でインストールされているため、別途インストーラーを用いた環境構築などの作業は不要です。

インストールされているかどうかは、ターミナル上で以下のように確認できます。

“`
ユーザー名@PC名 ~ % git -v
“`
~　はホームディレクトリの為、そこで実装する方が後々良いです。

-vは`git –version`の略であり、どちらでも同じ挙動が確認出来ます。

実行結果

CodeCommitを使用した開発におけるGit操作（Part1）

## はじめに

AWS CodeCommitを使用した開発では、Gitコマンドによる操作を頻繁に行います。ですが、私も含めGit初学者の方は、なんとな〜くコマンドを叩いている方も多いのではないでしょうか？

そこで本記事では、開発の流れに沿ったGitコマンドの使い方を解説していきます。

今回想定している開発の流れは大まかに以下の通りで、この流れの中で登場するGitコマンドについて紹介していきたいと思います。なお、以下の流れではGitのブランチ機能を使用した運用方法であるGit-flowを活用した開発を前提としています。

“`mermaid
graph TB
Start([CodeCommitにリポジトリを作成])–>B([リポジトリのクローン])
B–>C([ブランチを切る])
C–>D([コードの編集])
D–>E([ステージング])
E–>F([コミット])
F–>G([プッシュ])
G–>H([プルリクエスト])
H–>I([マージ])
“`

※本記事の内容は、2023年9月時点のものです。AWS CLIやGitのバージ

ブランチの概要

ブランチの役割は、履歴の流れを分岐させることである。
分岐させたブランチは最終的に統合を行う。
その方法にはいくつかあり、それぞれの違いをこの記事でまとめた。

この記事では、
まず必要となる前提知識のブランチの種類について定義し、
そのあと本題である統合方法(コマンド)を概要図と共に説明する。

# 目次
[ブランチの種類](#ブランチの種類)
・[ローカルブランチ](#ローカルブランチ)
・[リモートブランチ](#リモートブランチ)
・[上流ブランチ](#上流ブランチ)
・[リモート追跡ブランチ](#リモート追跡ブランチ)
[概要図](#概要図)
[統合コマンド](#統合コマンド)
・[git commit](#git-commit)
・[git fetch](#git-fetch)
・[git merge](#git-merge)
・[git pull](#git-pull)
・[git push](#git-push)
[stash領域](#stash領域)

# ブランチの種類
### ・ローカルブランチ
　　ローカルリポジトリで管理されているブランチのこと。
　　リポジトリ

gitで一時的に特定のリビジョンに戻す方法

“`bash
git checkout リビジョンID
“`

上記で特定のリビジョンの状態に戻すことができます。

“`bash
git checkout リビジョンID ファイルパス
“`
上記で特定のファイルを特定のリビジョンの状態に戻すことができます。

git commitしたけど、git pushしていないファイルを抽出するコマンド

# コマンド

“`sh
git diff @{u}.. –name-only
“`

# 背景

husky使って、`pre-push`(push前） に、pushしたくないファイルがあったら、pushを阻止するようなアクションをしたかった時に探したコマンド

Gitでの基本的な開発フローについて

# はじめに
オフショアを含めた複数人での並行開発を行っています。この際に運用していたGitでの開発フローについて自分用の忘備録としてまとめておきます。

おかしい点などがありましたら、コメントでご指摘頂ければ幸いです。

### 登場するブランチの種類

| ブランチ名 | 説明 |
| – | – |
| master | 運用中のバージョンを管理するブランチ |
| develop | 開発用のブランチ |
| feature-xxx | developから派生する。開発の単位、機能単位で作成し、developにマージ後に削除する。|
| release-xxx | リリース前テスト用のブランチ。developから派生する。masterとdevelopにマージ後に削除する。|
| hotfix-xxx | 緊急バグ対応用ブランチ。masterから派生し、masterとdevelopにマージ後に削除する。|

### 各ブランチの全体関連図
![image204.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.c

raspberry pi4にインストールするソフト

家にいるときWindowsマシンを他人が使うってことになったとき、タブレットが不調中なのでraspberry pi4 (RPi4)使うことにしたいです。なにをインストールしたらいいのか？記録してみました。アーキテクチャが`Arm64`なので、インストールに場合によっては苦労しそうです。

1. pandoc
1. groff (おそらくterminalにpreinstalled)
1. ghostscript
1. okulah (pdf viewer)
1. gawk (おそらくterminalにpreinstalled)
1. marp-cli
1. muttmua
1. todo.txt
1. gnu-plot
1. julialang
1. git
1. docker
1. inkscape
1. NN-SVG
1. mermaid.js
1. mpv

ほんとうは`docker`を導入して、他のソフトは`docker-image`で導入できればいいのですが、`docker`にもアーキテクチャ依存があるらしいので、うまくいく`image`といかないのがありそう。

## 文書

EC2上のソースコードを自動でGitHubにバックアップする

こんにちは！
今日はAWS EC2インスタンス上にあるソースコードを、定時になると自動でGitHubにcommit、pushしてくれる仕組みを作りたいと思います。
筆者はプログラミング歴1年半ほどの学生で、調べながらだいたい4時間弱で出来ました。AWS歴は半年ないほどです。
# 目次
1. [完成イメージ](#anchor1)
1. [前提条件](#anchor2)
1. [EC2とGitHubを繋ぐ](#anchor3)
1. [バックアップするスクリプトを組む](#anchor4)
1. [スクリプトを定時に実行する](#anchor5)
1. [参考](#anchor6)

## 完成イメージ
毎日0時5分になると、自動で対象のディレクトリのソースコードをGitHubにcommit、pushする。

# 前提条件
– GitHubアカウントを持っている
– バックアップするレポジトリが存在する
– EC2インスタンスが立ち上がっていて、ソースコードが置いてある
– gitコマンドが使用できる
–

変更状況を確認できる&元に戻すことができる

## 変更状況の確認
`git status`
確認

## 変更内容の確認
`git diff`
内容を確認

## 変更履歴
`git log`
履歴を表示する

`git log –oneline`
より簡潔に履歴を表示する

## ファイルの変更の取り消し

`git checkout — <ファイル名>`
ファイルを直前のコミットの状態に戻す方法

## ステージの変更の取り消し
`git reset file_name`

`git add` でステージングしたファイルを取り消す

—

#### *ソースコードやプロジェクトファイルの変更や保存に関する一般的なフロー*
ワーキングツリー → インデックス → ローカルリポジトリ → リモートリポジトリ

ワーキングツリー : 最新のファイル状態
インデックス : コミットするためのファイル状態
ローカルリポジトリ : ファイルの変更履歴を記録(ローカル環境)
リモートリポジトリ : ファイルの変更履歴を記録(共有できる)

下記の用にそれぞれに変更履歴を反映させていきます。

`git add`

コミットができる

## ローカルリポジトリの新規作成
新規ディレクトリを作成してください。
作成したディレクトリに移動して、Git のローカルリポジトリを新規作成してください。

`mkdir （ディレクトリ名）`
ディレクトリ作成

`cd （ディレクトリ名）`
作ったディレクトリに移動。

`git init`
ローカルリポジトリの新規作成

## 変更をステージに追加
作成したディレクトリの下にファイルを作成して、ステージに追加する。

`touch （ファイル名）`
ディレクトリの中にファイルを作る。

`git status`
正しく作成されているか確認

`git add （ファイル名）`
ワークツリーの変更をステージングエリアに追加する

## 変更を記録
`git commit -m “（変更内容を記載）”`
コミットする

`git log`
確認

## その他Gitのコマンド
備忘録的に残しておきます。

`git diff`
リポジトリとワークツリーの差分をチェック

`git diff -staged`
リポジトリとステージの差分をチェック

`git restore

エンジニア1年目が思うGitとGitHubの基礎（ここだけは押さえるべきと思うポイント）をまとめる

# はじめに
はじめまして。エンジニア1年目のみーと申します。
今の案件でGitを使ってシステム開発を進めています。
この記事では、未経験でGitが何かすらわかっていなかった頃の自分にアドバイスするなら…といった観点でGitの基礎（ここだけは押さえるべきポイント）をまとめようと思います。
読み物として書いてますので、事前準備は特にありません！

# 対象者
– Gitってなに？と思っている方
– Gitに触れてこなかったが次の案件から必要になる方
– まだGitの学習を全くしていなくて、書籍を買う前になんとなく触りだけ知りたい方
– まずは概要の理解、覚えておいた方がよいことのみ把握したい方

# 前提条件
特になし
（強いて言うならWindowsPCを触ったことがあり、通常操作は行えるレベルであること
例：フォルダ、ファイルと言われて何を指しているか分かること）

# GitとGitHubとは
これは調べればすぐわかることですが、Gitとはバージョン管理システムのことです。どのサイトでもそう書いてありますが、本当にそれに尽きます。システムやアプリのバージョンを管理するためのものな