今さら聞けないGit　

頻出Gitコマンドまとめ

## アジェンダ
個人的に頻出Gitコマンドだと思うものを備忘録としてまとめます。

## コマンド
|コマンド|意味|
|:-:|:-:|
|git init|Gitリポジトリを初期化|
|git clone [URL]|指定したURLからリポジトリをクローン|
|git add [ファイル名]
git add .|指定したファイルをステージングエリアに追加|
|git commit -m “コミットメッセージ”|ステージングエリアの変更をメッセージ付きで記録|
|git remote add origin [URL]|リモートリポジトリを`origin`として登録|
|git push origin [ブランチ名]
git push origin HEAD|指定したブランチをリモートリポジトリにプッシュ|
|git push origin –delete [ブランチ名]|リモートリポジトリの指定したブランチを削除|
|git fetch|リモートリポジトリの変更をローカルに取得|
|git pull origin [ブランチ名]
git pull|指定

共同開発の8割はプルリクエストの書き方で決まる！(プルリクエストの作成方法とマークダウン記法の説明)

共同開発をするにあたってこんなことありませんか？
**「これなんのプルリクなん？」**
**「そもそも何してるの？」**
**「あれ？どの機能を修正してるんだっけ？」**
**「バグの原因は？解決策は？」**
**「どのコミットで何をしているの？」**

このようにプルリクエスト(PR)の書き方が開発チーム内で共有出来ていないと各々が好きな方法でPRを作成するのでレビュアーは管理する事が難しい．
本記事ではプルリクエストの書き方の例とそれをチーム内で共有することの大切さを記載する．
>PRの概要については以下の記事を参考にすること(gitの基本)
>https://qiita.com/tarakokko3233/items/ad7e1a1a14d3e2f10da3

# そもそも
PRはソースコードと一緒に提出するおまけではない．また，単にソースコードの説明をして，マージするための判断材料でもない．
PRの目的は

**1.変更箇所をレビューし，マージしても大丈夫かどうか判断する**

**2.後で開発した機能が不具合を起こした時にどのPRでの作業が原因か特定する**
**3.他の開発

PR,MR提出時のコミット整理方法 #Git

## はじめに
いつものように開発を行っていたある日のこと。
開発完了！さあレビュー依頼だ！　…ん？ちょっと待った
コミット履歴を見てみると、コミットした修正をやっぱり違うなと戻してみたり、テスト作成中にメソッドのタイポを発見して一緒にコミットしていたりとぐちゃぐちゃ…　
ということで、レビュワーの負担軽減のために（自分を頭良く見せるために）コミット履歴を整理したのでその手順メモを共有します。
PR,MRを作るときに参考になれば幸いです（余談ですが、PR：プルリクエスト → GitHubの用語、MR：マージリクエスト → GitLabの用語らしいです）。

## 手順
### 1. git checkout -b 整理用ブランチ
せっかくの修正が消えてしまっては困るので、コミット整理用ブランチを新しく作り移動します。
“`bash
git checkout -b develop_MR
“`

### 2. git log –oneline
“`git log“`で、整理が必要なコミット数を確認します。
“`bash
git log –oneline
“`

“

SeedSigner OS Emulator

# 趣旨
SeedSignerのHowTo動画を作るにあたって画面のスクショがあったほうがスムーズな編集ができるのでエミュレータを探して実践してみたので、忘れないために備忘録を残しておきます。

以下、Githubページです。

https://github.com/enteropositivo/seedsigner-emulator

# 実践
まずはSeedSignerをダウンロードします。
“`
git clone https://github.com/SeedSigner/seedsigner.git
cd seedsigner/src
“`

次に専用のエミュレータをダウンロードします。
“`
git clone http://github.com/enteropositivo/seedsigner-emulator.git
rsync -a seedsigner-emulator/seedsigner ./
“`

仮想環境を用意します。
“`
python3 -m venv myenv
source myenv/bin/activate
“`
必要なライブラリ

Gitで現在の状態や変更箇所を確認する方法（diff,log）＋.gitignoreについて

# この記事を書くきっかけ
Webアプリケーションをデプロイした後も、何度もファイルを修正してきました。主に、VSCodeのソース管理やSourceTreeを利用してきました。でも、いちいちVSCodeやSourceTreeを開かなくても、コマンドラインで直感的にコミット履歴やステータスを確認できたら良いですよね。

というわけで、今回はGitで現在のファイルの状態や変更箇所を確認する方法を勉強します。また、Gitで管理したくないファイルを設定するファイル（.gitignore）についても併せて勉強します。

# 現在の状態の確認

**コミットの情報を確認する方法**
| コマンド | 内容 |
|:-|:-|
| git log | コミット履歴を確認する |
| git log –oneline | コミットメッセージだけを表示する |
| git log -1 | 直近から1件だけコミットログを表示する |
| git log -2|直近から2件だけコミットログを表示する|
| git log -p | ファイルの差分を確認できる |

`git log`を実行する

SourceTreeを使ってGitを管理する

## はじめに

これからプログラミングを学んでいくにあたって、Gitの知識は必要だと思い、色々調べました。他の方やサイトで上手くまとまっているものも多くありますが、自分で書いた方が知識として定着しそうなので投稿します。Gitは通常、CLI(コマンドライン)を使って操作をしますが、SourceTreeを使うことでGUIとしてGitを管理できるようになります。まずは、学習の手始めとしてSourceTreeで管理してみようと思います。

#### 注意！

この記事は、初学者である著者が知識を定着させることを目的として執筆しています。その点をご留意いただけると幸いです。

## そもそもGitとは?

Gitは、プログラムのソースコードやファイルなどを、簡単に変更履歴を記録・追跡を行うための、バージョン管理システムのことを指します。プログラムを書かれている方ならば分かると思いますが、日々ファイルの中身はその都度、更新または上書き保存がなされます。その際のバージョン、ファイルの状態をその都度保存するのに便利なツールです。

## Gitがないとどうなる？

アプリケーションを使うときに、Ve

目的別gitコマンドメモ

### はじめに
たまに実行するコマンドがいつまでたっても覚えられない。。
自分の忘備を兼ねて目的別にgitコマンドをまとめる。

### addを取り消したい
“`
git reset HEAD
git reset HEAD [ファイル名/ファイルパス]
⇒ステージング前の状態に戻る
“`

### commitを取り消したい
“`
git reset –soft HEAD^
⇒ステージング状態(addした状態)に戻る
“`

### コミットをまとめたい
“`
git rebase -i HEAD~4
⇒直近4コミット分まとめる
“`

### ローカルブランチ削除
“`
git branch -d [ブランチ名]
⇒マージされていないコミットがある場合はエラー
git branch -D [ブランチ名]
⇒コミットを無視して強制削除
“`

### リモートブランチ削除
“`
git push origin –delete [ブランチ名]
“`

### 別ブランチの特定のコミットのみ、現在のブランチに取り込みたい
“`
git cherry-pi

Gitでコードの変更を記録する方法（add, commit）

# 記事を書いた目的　
DjangoでWebアプリを作成し、デプロイしてからというもの、何度もコードを修正してきました。その度に、SourceTreeやVSCodeのソース管理などのGUIな方法でコミットしてきました。ただ、書籍に書いてあったコミットの手順をそのまま利用するのみで、Gitやバージョン管理そのものについてはほとんど理解していませんでした。

なんか修正がうまくいっているみたいだけど、なんでうまくいっているのか説明できなくて気持ち悪いな〜。GitとかGitHubとか、わかったんだかわかっていないんだか、よくわからないな〜。こんな状態が長くてずっとモヤモヤしていました。今後、ずっと一人でWebアプリを開発するなら問題ありませんが、将来複数人で開発をするときには、Gitについてわかっていないとお仕事にならないみたいですね。そういうわけで、今更ですが、Gitについて勉強しています。

今回は、Gitでコードの変更を記録する方法（add, commit）を勉強します。
Gitに登場する専門用語は簡単に記事にしましたので、ぜひ参考にしてみてください。

記事: [Gitとは](h

Gitのrebaseとcherry-pick：基礎とベストプラクティス

Gitを使っていると、複雑なブランチ構造やコードの統合に直面することが多々あります。その際、rebaseとcherry-pickは非常に便利なコマンドです。しかし、これらを誤って使用すると、履歴が複雑になったり、他の開発者に迷惑をかける可能性があります。本記事では、rebaseとcherry-pickの基本から、どのように使用すれば効果的かを解説します。
Git rebaseの基礎
rebaseとは？
rebaseは、あるブランチのコミット履歴を他のブランチの先頭に持ってくる操作です。mergeとは異なり、rebaseは新しい履歴を作成し、ブランチの歴史を「きれい」にします。
基本的な使い方
1. ## 他のブランチの変更を取り込む
“`
git checkout feature-branch

git rebase master
“`
上記のコマンドは、feature-branchにmasterの変更を取り込むことを意味します。

2. ## インタラクティブなrebase
“`
git rebase -i HEAD~3
“`
これにより、直近の3つのコミットを再配置または編

2人目の開発者を迎える前に決めておきたいルール/設定

本記事はQmonus Value Streamの投稿キャンペーン記事です。

## はじめに(対象読者)

今までありがたいことに1人開発体制から開発者を増やしていったり少人数から10名以上に拡大していく過渡期のチームに参画させていただいた経験が何度かあり、その都度ドキュメント整備屋さんのようなことをしてきたのですが、その中で「このルール/設定は最初からあった方がよかったな～」と思うものをピックアップしました。
今まさに1人開発体制からチーム開発体制へ移行しようとしている方、あるいは既に拡大を始めているものの開発者を増やすたびスピードと品質に影響が出ている(気がしている)方の見直し用にもなればいいなと思っています。

またこんなのもあれば便利だったよ～というものがあればコメントなどで教えてください。

## 目次

– **Git/GitHub関連**
– ルール
– ブランチ構成
– コミットメッセージの書き方
– Pull Requestの書き方
– ラベルの使い方
– タスク管理ツー

error: failed to push some refs to の解決

## git merge origin/master –allow-unrelated-historiesを使おう！
初心者エンジニア志望のメモです。
error: failed to push some refs to でpullなどしても解決しないときは
“`ruby:console
git merge origin/master –allow-unrelated-historie
“`
を使うことで解決する場合があります。
このコマンドはgitで祖先が違うもの同士をmergeできるコマンドのようです。
とりあえずの解決策なのでより良い方法があったら教えていただけると幸いです。

参考
https://dev.classmethod.jp/articles/git-merge-option-allow-unrelated-histories/

githubにpushしたらCircleCiでサーバーに「git pull」させる

# 背景
githubに上げた後自動更新したかった。
リモートリポジトリにPush後自動デプロイをCircleCIを使ってやってみた
が…めちゃ時間かかったので備忘録として…
# 前提
– githubのリポジトリとアクセストークン作成済み
– CircleCIアカウント作成し、githubリポジトリと連携済み
– サーバーにssh接続して「git pull」ができる
# 手順

### サーバーに「git pull」するシェルスクリプト作成
「.git」と同階層に「deploy.sh」
中身↓
“`shell
cd /”リポジトリがある場所” && sudo git pull https://”githubアカウント名”:”githubアクセストークン”@github.com/”githubアカウント名”/”リモートリポジトリ名.git”
“`
動かすことしか考えていないので今回はこの構成

### シェルスクリプト動かしてみる
“`shell
source deploy.sh
“`

### CircleCIでSSHキーの設定
CircleCIの「Proje

中級者向けのGitコマンド

## 中級者向けの Git コマンド

開発時に利用する git コマンドをひととおり使えるようになってから、利用したくなるコマンドを紹介します。

## ブランチの切り替え：git switch

`git checkout` はブランチの切り替えに使われるコマンドですが、`git switch` はブランチの切り替えに特化したコマンドです。`git checkout` とは異なり、ブランチを作成しないためブランチを間違えて作成してしまう心配がありません。

“`bash
git switch branch-name
“`

ちなみに `-c` オプションをつけるとブランチを作成して切り替えることができます。

“`bash
git switch -c branch-name
“`

## 変更の取り消し：git restore

`git restore` はファイルの変更を取り消すために特化したコマンドです。

“`bash
git restore file-name
“`

`git checkout` でも同様のことができますが、個人的には `git check

Gitとは

# この記事を書くきっかけ
私はプログラミング初心者です。昨年から勉強を始めました。毎日少しずつ、技術書を読んだり、プログラムを書いたりして、3月にはじめてWebアプリをデプロイしました。具体的には、Pythonを利用してDjangoでWebアプリを開発しました。利用したサービスはPostgresql、Git（SourceTree）、GitHub、Nginx、Gunicorn、AWSなどです。

独自のアイディアを盛り込んだオリジナルのコードを書く努力をしましたが、GitやNginxなどのサービスとその設定方法はすべて書籍を参考にしました。そのため、それぞれのサービスへの理解に不安があります。そのサービスがどういうもので、どんなコマンドを使えばいいのかがわからなければ、トラブルが起きたときに対処できません。そこで、自分が利用したサービスを最低限でも理解したいと思い、記事にしました。今回はGitについて勉強したいと思います。

# Gitとは
私たちは日々ファイルにいろいろな変更を加えています。ファイルを新規作成したり、下書きしたり、修正したり、加筆したり。このように、変化を加えられたフ

コミットの日付を編集しようとしたら、Author Dateが4か月先になっていた件について

去る日は2024年6月10日のこと。

「さて、長いブランチをrebase -iしたから、日付も今日に合わせておくか。」

男には、自身の作業ブランチを`rebase i`で1コミットに纏める癖があった。
特に、タスクのウェイトが重かったりしてコミットログが汚れている場合には、この作業をすることがそれなりに楽しみでもあった。

しかし、`rebase -i`をしただけでは、後にログを見た時の日付（Author Date）が、幹のブランチから分岐した後の最初のコミットの日付になってしまい、少し不自然になってしまうのだ。
何より細かいところにこだわる彼にとっては、これは非常に大事な作業であった。

“`bash:Git Bash
#git rebase -i …..

git commit –amend –date “`date`”
> [detached HEAD …….] MSG…
> Date: Sun Oct 6 10:14:08 2024 +0900
“`

男「ん？なんか日付がOctopa🐙…October、10月になってね？？？」

不審に思った

gitでGitHubから取ってきたNext.jsのプロジェクトを動かすやつ入門

前回の記事は↓こちら

https://qiita.com/every-month/items/9a3d7f1e53d8572525a2

たまたまプライベートで人にNext.jsを叩き込む過程でgitを叩き込む機会がありまして、せっかくなので再びこの場をお借りしていっしょに復習します。

## 前回までのポイント（再掲）（抜粋）

– `cd`
– フォルダの中に入る
– `npm run dev`
– （作ってる途中の）Next.jsを動かす
– だいたい`http://localhost:3000`で見れる

## 今回のポイント

– `git`はバージョン管理のツール
– 作業のきりがいいところ毎にフォルダまるごと記録するツール
– `..`は上のフォルダ
– `git clone ほしいやつ`
– `git`で取ってきたNext.jsのプロジェクトには`npm i`

## `git`をインストール

今回も環境によってまちまちなので、説明をふんわりさせてください😢
多くの場合↓このページの説明にそって、コマンドでインストールするのがかんた

MacOSでの.gitignoreと.dockerignoreの最適な設定方法

# はじめに

開発プロジェクトを管理する上で、.gitignoreと.dockerignoreは重要なファイルです。これらの設定を正しく行うことで、リポジトリやDockerイメージのサイズを最適化し、不要なファイルを無視することができます。特にMacOS環境では、特定のファイルやディレクトリを無視する設定が重要です。この記事では、MacOSでの.gitignoreと.dockerignoreの最適な設定方法について解説します。

## 基本的な構文
.gitignoreと.dockerignoreに共通する基本的な構文です。

### #で始まる行はコメントとして扱わる
特定のファイルやディレクトリを無視する場合は、その名前を記述します。
“`text
# コメント
filename.txt
“`
### ワイルドカード（*）を使用して、複数のファイルを一度に指定できる
“`text
*.log
“`

### ディレクトリを無視する場合は、スラッシュ（/）を使用する
“`text
/directory_name/
“`

### ネストしたディレクトリやファイルを無視す

既存のGitリポジトリをorganizationに移行する

## 自分の環境
– macOS Sonoma 14.4
– コンソール : zsh

## 経緯
今まで個人リポジトリで管理していたプロジェクトを企業用リポジトリに移行することになったので、今後同様の機会があった時の為にも備忘録として残しておきます。
新しく企業用リポジトリを作成する際にも参考になります。

## 注意
これからの手順はコミット履歴を引き継ぐことはできません。私の場合はコミット件数が少ないかつ、完全個人で管理していたため下記手段を実施しましたが、状況に応じて適切な手段を取ってください。

## 1. 既存のプロジェクトから.gitを削除
既存のプロジェクトをコンソールで開きます。（以下参考）
“`
cd /Document/Develop/{プロジェクト名}
“`

念のため.gitが存在するか確認しておきます。
“`
ls -la
“`

![スクリーンショット 2024-06-10 13.52.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/839842/cd3e1e3

GitHub Actionsとgit diffを使って差分に応じて処理を変えるワークフローを作成するには

## 概要
GitHub Actionsを使って例えばModelを追加したときのみModelのテストも行いたいなど、gitを使って差分に応じてテストする項目を変更したい場合(実行時間を短縮したい)場面があるかと思うので今回はその方法について解説したいと思います

## 前提
– 言語/FWはPython/Djangoを使用
– DBはMySQLを使用

## ディレクトリ構成
“`
tree
・
├── .github
│ └── workflows
│ └── test-without-model.yml
└── application
├── application
│ ├── __init__.py
│ │ ├── models
│ │ │ ├── __init__.py
│ │ │ ├── customer.py
│ │ │ └── user.py
│ ├── admin.py
│ └── apps.py
├── manage.

コミット履歴が ” きれい ” なPRはすごく助かる。ありがたい。好き。

# はじめに

こんにちは、この世すべてのレビュワーの代弁者です。

# もくじ

– [” きれい ” なコミット履歴とは](#-きれい–なコミット履歴とは)
– [コミットが意思決定の最小単位になっている](#コミットが意思決定の最小単位になっている)
– [コミットメッセージが簡潔で分かりやすい](#コミットメッセージが簡潔で分かりやすい)
– [意思決定のプロセスが妥当である](#意思決定のプロセスが妥当である)
– [コミットメッセージ以外の差分が含まれていない](#コミットメッセージ以外の差分が含まれていない)
– [コミット履歴が多すぎない](#コミット履歴が多すぎない)
– [レビュワーに優しいプルリクエストを作ろう](#レビュワーに優しいプルリクエストを作ろう)
– [おわりに](#おわりに)

# ” きれい ” なコミット履歴とは

PR（プルリクエスト）において、個人的に『あ～きれいでありがたいコミット履歴だな～』と思うコミット履歴には以下のような性質が備わっています。

– その１：**コミットが意思決定の最小単位になっている**
–