- 1. 【macOS版】Homebrewを使ってgitをインストール
- 2. 【Git】Git初期設定 for Mac OS
- 3. Gitメモ
- 4. モノレポ管理していたFrontend/Backendで分けたくなった場合のやり方
- 5. GitHubにPushするときは1回のPushを10MBくらいにした方が良いのでスクリプトを書いた
- 6. [備忘録シリーズ] gitで過去のcommitを修正する方法
- 7. pushとpullで毎回Enter passphraseと言われてしまう(Windows)
- 8. [AWS IAM Identity Center] SSO環境下でAWS CodeCommitの認証を行う
- 9. 誤ったコミット情報を修正する: Git LogのAuthorとCommitter変更ガイド
- 10. GitHubで複数のコミットメールアドレスを使い分ける
- 11. ハンズオンで学ぶGit(2023年_新人研修用)
- 12. WSL2 にて Git Clone がうまくできなかった話
- 13. git cryptをやめるときにハマったこと
- 14. 【Git初心者向け】使い終わったブランチは削除していいの？
- 15. マージ済みのブランチだけを対象としてローカルのブランチを一括で削除する方法
- 16. rails sでPostgreSQLが実行できないエラー
- 17. 現在のブランチを保留にして新たなブランチで作業をしたい[stash]
- 18. 作業ブランチを最新にする手順
- 19. 【初心者殺し】GitHub Flowの基本（OSS開発）をなんとか言語化してみた。
- 20. git-flow, pull requestについて
【macOS版】Homebrewを使ってgitをインストール
# はじめに
gitをインストールする方法は他にもありますが、今回はHomebrewを使ってgitのインストールを行います。Homebrewはgitのバージョン管理や拡張機能のインストールなどプログラミング言語の環境構築等によく使われるツールです。
今回はHomebrewを使ったgitのインストール方法を紹介しますので、Homebrewをまだインストールしていない方は[【macOS版】初心者でもわかる！Homebrewのインストール手順を徹底解説](https://qiita.com/inakuuun/items/431918811c351e46e3bc)を参考に先にインストールを済ませてください。## gitが自身のPC上に存在するか確認
gitはMacにデフォルトでインストールされていることもあるため、まずはgitが自身のPC上にインストールされているかをターミナルで`which git`コマンドを実行して確認します。“`
# gitがPC上に存在するか確認するコマンド
%which
【Git】Git初期設定 for Mac OS
## はじめに
MacOSでGit初期設定をする方法についてのメモとなります。
(何回やっても忘れてるので。。?)## 環境
■ MacOS
13.4.1
■ チップ
Apple M2## 1.Homebrewをインストール
HomebrewはmacOS上で動作するパッケージ管理ツールのひとつとなります。
Homebrewを用いて様々なパッケージをインストールすることができます。■ Homebrew
https://brew.sh以下のコマンドでインストールできます。
コマンドが変わる可能性があるので、ホームページで確認するのをお勧めします！“`terminal:Terminal
$ /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
“`
Homebrewをインストールしたものの、以下のエラーが発生していました。
バスが通ってないことが原因となるため、Homebrewのパスを通すことにより、解決できます。“`te
Gitメモ
#初回のセットアップ
ユーザー直下にファイル作成
→git init
→git clone https://github.com/～#githubへのアップ流れ
git add
→ git commit
→ コメント
→ git push origin main## コマンドメモ
**git init**
.gitディレクトリを作成（隠れファイル）**git clone**
“リポジトリ→ローカルにコピーを作成”**git add**
“ワークツリー→リポジトリとステージに追加（コミットする変更準備）”**git commit**
”ステージに保存されているファイルを変更した事を保存する”**git commit -m “<メッセージ>“**
(１行目に変更内容の要約)
(２行目に空行)
(３行目に変更した理由)
**git status**
”現在の変更状況を確認する”**git diff**
”ワークツリーとステージの変更差分を確認する”**git diff –staged**
“ステージとコミットとの間の変更内容を表示する”
モノレポ管理していたFrontend/Backendで分けたくなった場合のやり方
## これは何
FrontendとBackendをモノレポで管理していて、途中で、FrontendとBackendで分けたくなった場合の方法の備忘録## やり方
– 対象となるリポジトリをcloneしてくる
` git clone https://github.com/username/app-name.git`
– server / client と2つのリポジトリに分かれてることを確認
`git filter-branch –subdirectory-filter 対象のサブディレクトリ(ここでは client ) HEAD`
– 注意すべきこととして、git `fileter-branch` コマンドは、ルートディレクトリで行うこと
– 新しくGitHub上に要した場所にpush
– 完了## `git filter-branch` コマンドとは何者？
Gitのリポジトリ履歴を再書き込みするための強力なツール。
主な目的は、履歴の内容をフィルタリングしたり、部分的に切り出したりして、リポジトリの歴史を変更すること。
これを使うことで、過去のコミットを修正、削除、
GitHubにPushするときは1回のPushを10MBくらいにした方が良いのでスクリプトを書いた
# はじめに
GitHubに大量のファイルをPushしたらサイズ制限で弾かれた。
１つのファイルはLFSを使用するまで大きくないものの、1回のPushの容量が大きいと制限がかかるみたいです。
というわけで、10MBぐらいずつadd&commitしてpushするスクリプトを書いた。“`bash
#!/bin/bash# 現在のディレクトリがGitリポジトリであることを確認
if [ ! -d .git ] && ! git rev-parse –git-dir > /dev/null 2>&1; then
echo “Error: must run this script in a Git repository”
exit 1
fi# カレントディレクトリを保存
root_dir=$(pwd)# ファイルサイズの合計を保持する変数を初期化
total_size=0# 10MBのサイズをバイト単位に変換
commit_size=$((10*1024*1024))# カレントディレクトリ内のすべてのファイルを再帰的に走査
find . -type
[備忘録シリーズ] gitで過去のcommitを修正する方法
# 直前のcommitの場合
1. `git commit –amend -m “修正コメント”`
2. `git rebase –continue`
3. `push -f origin` # 2個以上前のcommitの場合
1. `git rebase -i HEAD~n` （nは戻りたいcommitが直前のcommitから見て何番目かを入れる）
2. 変更したいcommitを全て`pick`から`edit`へ変更し、保存
3. `git commit –amend -m “修正コメント”`
4. `git rebase –continue`
5. HEADが`edit`したcommitを古い順に移動するので、#3→#4を繰り返す
5. `git push origin`(差分で問題があれば`-f`オプションを使う。気をつける） # ログの確認
1. `git log –oneline`でHEADやcommit idの確認ができる
pushとpullで毎回Enter passphraseと言われてしまう(Windows)
pullとpushをするたびに毎回passphraseを求められる．
面倒くさい．．．passphraseを入力しないでsshの操作を行いたい．けど若干手間取ったのでその過程を備忘録的に残しておく．“`
Enter passphrase for key ‘/c/Users/user/.ssh/id_ed25519’:
“`
うーん…公開鍵と秘密鍵関連のsshらへんの設定がうまくいっていない模様．まず，接続先がsshになっているかを確認．httpsになっていると毎回passphraseを求められる．もし`git@github.com:`で始まっていたらOK．httpsで始まっていたらssh用のものに変更が必要．
“`
git config remote.origin.url
// httpsで始まっていたら設定を変更する
git remote set-url origin git@github.com:<ユーザID>/＜リポジトリ名＞.git
“`まだpassphraseを聞かれる．
リモートとやり取りする際の設定ファイルの有無を確認する．
“`
cd ~/
[AWS IAM Identity Center] SSO環境下でAWS CodeCommitの認証を行う
※この記事は[自分のブログ](https://blog.morikapu.com/awssso-with-awscodecommit/)から持ってきたものです。Qiitaにも残しておきたいため投稿しています。
会社などでAWS IAM Identity Center + SSOを使用しているときにちょっと躓いたのでメモ。
AWS Cliなどはインストールしてある前提とする。# 環境
Windows + Git for Windows + AWS Cli# 1. SSOの設定
コマンドプロンプトで以下を実行
※aws configure sso はGit Bashでは実行できないので注意
“`
aws configure sso
“`質問にいくつか聞かれるので入力していく。
SSO Start URLなどはAWS IAM Identity Centerポータルページで「Command line or programmatic access」を押すと表示される。
“`
SSO session name (Recommended): <適当な名前>
SSO start U
誤ったコミット情報を修正する: Git LogのAuthorとCommitter変更ガイド
どうもこんにちはたくびー(@takubii)です。
皆さんはGit Logを詳しく見たことはありますか？
普段はVisual Studio Codeのソース管理でしか見ない、あるいは拡張機能を使って確認するだけだったりしませんか？私自身、そうでした。
Githubなどでコミッターの名前を見てみると、自分の意図していない名前でコミットしていたりということがあります。
今回はそういった場合に、どう変更していくのか紹介したいと思います。## Git Logの確認
まずはGitのログを確認しましょう。
“`zsh:terminal
git log –pretty=fuller
“`
`git log`でもログの確認はできますが、`–pretty=fuller`オプションを使用することで、Author、Committer情報、さらにその時間まで表示してくれます。
今回はCommitterだけでなく、Authorも自分が意図した名前なのか確認してみましょう。“`zsh:terminal
commit [コミットハッシュ]
Author: [Author Name] [<
GitHubで複数のコミットメールアドレスを使い分ける
GitHubでは、個人用と仕事用とで同じGitHubアカウントを使うことが推奨されています。たとえば、「[複数の個人アカウントのマージ – GitHub Docs](https://docs.github.com/ja/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-personal-account/merging-multiple-personal-accounts)」にヒントとして書かれています。
一方、Gitのコミットにはメールアドレスが記録されます。そのため、個人用のコミットには個人用のメールアドレスを使い、仕事用のコミットには仕事用のメールアドレスを使いたくなります。そこで、GitHubで複数のメールアドレスを使い分ける方法を紹介します。
:::note
なお、これらの内容はGitHubのドキュメントに書いてあります。この記事内からもリンクを張っています。
:::# GitHubへのメールアドレスの追加
GitHubアカウントには、複数
ハンズオンで学ぶGit(2023年_新人研修用)
# 目次
1. [Gitのインストール](#Chapter1)
1. [Gitの初期設定](#Chapter2)
1. [ローカルリポジトリの新規作成](#Chapter3)
1. [Gitの基本的なフロー](#Chapter4)
1. [【課題1】addとcommit](#Chapter5)
1. [【課題2】status,diff,log](#Chapter6)
1. [GitHubとの連携](#Chapter7)
1. [リモートリポジトリの作成](#Chapter8)
1. [ローカルリポジトリのプッシュ](#Chapter9)
1. [ブランチとは](#Chapter10)
1. [ブランチを操作する際に必要なコマンド](#Chapter11)
1. [トピックブランチから統合ブランチへの反映](#Chapter12)
1. [【課題3】トピックブランチの作成とマージ](#Chapter13)
1. [コンフリクト](#Chapter14)
1. [【課題4】コンフリクトへの対応](#Chapter15)
1. [git clon
WSL2 にて Git Clone がうまくできなかった話
Fatal Error とか吐かれて結構苦しんだのでメモ。
**Git Credential Manager がカギ。**## 環境
Windows11 Home
WSL2 (Ubuntu 22.04.2 LTS)## やらないといけないこと
### windows に Git を入れる
**この時 Git Credential Manager のインストールの確認をされるのでそれを入れておく**
デフォルトだと有効なので連打しておけばとりあえずインストールされる。—–
### windows上で適当なレポジトリなんかをクローンする
これをすると初回には Github との連携が求められるので対応する。
これによって資格情報が保存される。変に資格情報が保存されているのであれば、一度削除してからやってみるといい。
—-
以下 WSL 上での作業
### ubuntu 上の git バージョンを確認
“`terminal:terminal
git version
> git version 2.34.1
“`
**バージョンによって次の手順が変わるら
git cryptをやめるときにハマったこと
## はじめに
git cryptで暗号化していたファイルを平文に戻し、GitHubの画面上でレビューできる状態にするまでに時間がかかってしまったので、経緯を共有します## 経緯
– git cryptという技術を使って、秘匿化したい環境変数ファイルを暗号化し管理していたが、別の管理方法に移行することにした
– 一部の環境変数は秘匿化の必要がなかったので、git cryptで暗号化するのをやめ、平文の環境変数ファイルとして残す方針にした## 作業環境
– VSCode
– GitHub## 行った作業
1. `git crypt unlock` を実行し、ローカル上の環境変数ファイルを復号化
– この時点で、ローカル(VSCode)では平文の状態になっている
2. 環境変数ファイルを更新後、 `git add / commit / push`
– 秘匿化の必要がない情報だけ残した
– この時点で、githubのプルリクの差分画面には、バイナリファイル(=暗号化された状態)が表示されている
3. `.gitattributes` ファイルを `gi
【Git初心者向け】使い終わったブランチは削除していいの？
プログラミング初学者です。
Gitコマンドについて学習する中で、気になった点を調べたので、備忘録としてまとめておきます。# ローカルに作成したブランチ、使い終わったら削除していいの？
正直に言いますと、これまでローカルで作成したブランチを残したままにしていましたが、`マージが終わったのなら削除した良い`ということに今更になって気づきました?一人でのアプリケーション作成を行なってきたことで、この時期まで「ローカルブランチはとりあず残しておこう」と思ってきました。
# ブランチを残しておくことで起こる弊害
– マージ後のブランチに誤ってcheckoutしてしまう。
– どのブランチがマージ済みなのか分からなくなる。このように、ブランチが増えると、管理が大変になるという弊害が起きる可能性があります。
なので、通常は、ローカルのマージが完了したブランチは削除してブランチが最低限のものだけ残すという形が良いようです。# ブランチ削除関連のコマンド
“`
$ git branch –merged# マージが完了しているブランチを表示
“`“`
$ gi
マージ済みのブランチだけを対象としてローカルのブランチを一括で削除する方法
プロジェクトを進める中で、利用しなくなったブランチがたまってしまうことはよくあります。
そこで、ブランチを1つ1つ手動で削除するのは手間がかかるため、マージ済みのブランチだけを対象としてローカルのブランチを一括で削除する方法を紹介します。
## コマンド実行
以下のコマンドを使用することで、マージ済みのブランチだけを対象としてローカルのブランチを一括で削除することができます。
“`zsh
git branch | xargs git branch -d
“`このコマンドは、以下の手順で動作します。
1. `git branch –merged`: このコマンドは、現在のブランチがマージされたブランチの一覧を表示します。
2. `grep -v “\*”`: `grep`コマンドはテキストを検索するためのコマンドです。-vオプションは、指定したパターンに一致しない行を表示することを意味します。ここでは、アスタリスク（*）に一致しない行（現在のブランチを除く）を表示します。
3. `xargs -n 1 git branch -d`: `xargs`コマンドを使って
rails sでPostgreSQLが実行できないエラー
# １．現状
ローカルでアプリケーションを実行しようとしたところ、以下のエラーがでました。
“`
ActiveRecord::ConnectionNotEstablished (connection to server on socket “/tmp/.s.PGSQL.5432” failed: No such file or directory
Is the server running locally and accepting connections on that socket?翻訳
ActiveRecord::ConnectionNotsteaded (ソケット「/tmp/.s.PGSQL.5432」上のサーバーへの接続に失敗しました: そのようなファイルまたはディレクトリはありません)
サーバーはローカルで実行されており、そのソケットでの接続を受け入れていますか?
“`# 2.直近で行った変更
AWS-s3の導入を行いました。# 3.エラー文から考えられる原因
postgresqlが立ち上がっていないことが原因と予測しました。# 4.解決のために行った
現在のブランチを保留にして新たなブランチで作業をしたい[stash]
# 1.はじめに
作業中に別ブランチを切って作業したいときに`stash`を使用して現在のブランチでの変更を退避させることができます。
退避した変更をもとに戻して作業を再開することも可能です。# 2.stashコマンド一覧
### 1.作業を退避させる
以下コマンドでメッセージをつけて変更を退避させることができます。
あとからみたときにわかりやすいメッセージをつけておくことをおすすめします。
“`
$ git stash save “メッセージ”このコマンドを使うと未追跡のファイルも退避できる。
$ git stash save -u “メッセージ”
“`### 2.退避した作業の一覧を表示させる
“`
$ git stash list
“`### 3.退避した作業を戻す
“`
$ git stash apply stash@{0}
“`### 4.退避した作業を消す
“`
$ git stash drop stash@{0}
“`### 5.退避した作業の詳細を確認する
“`
$ git stash show stash@{0}
“`
以下
作業ブランチを最新にする手順
### 1. masterブランチへ移動
“`
git checkout master
“`### 2. masterを最新に更新
“`
git pull origin master
“`### 3. 開発用のブランチへ移動
“`
git checkout 開発用ブランチ名
“`### 4. masterの内容を取り込む
“`
git merge master
“`### 5. 取り込んだものをリモートにpush
“`
git push origin 開発用ブランチ名
“`
【初心者殺し】GitHub Flowの基本（OSS開発）をなんとか言語化してみた。
## 前書き
HappinessChainの課題でGit週間でしたので、GitHub Flowを知識0状態から学んでアウトプットするために書きました。多分、ほとんどの初心者の方がこの流れがつかめないで混乱すると思います。（多分実際に開発しながら使わないと難しい）ですが、基本的な流れだけでもつかめれば少しは楽になるので参考になればなと思います。
また **「リモートリポジトリも含めた全体の流れ」** にフォーカスしてますので、**GitHub上でのリポジトリの作成の仕方**や**ローカルでの作業内容**などなどに関しては詳細を省かせていただきます。## GitHubを用いた開発フローまとめ
### 前準備として、新規ディレクトリ作成でgit initして移動しておく。
“`
mkdir my_project
cd my_pro
git-flow, pull requestについて
Git-flowは、ソフトウェア開発プロセスにおいてGitを使用する際のブランチモデルの一つです。Vincent Driessenによって提案された、効果的なコードの管理とチームワークを支援するためのブランチ戦略です。主にフィーチャー開発とリリース管理をスムーズに行うことを目的としています。
Git-flowの基本的な考え方は以下の通りです：
メインブランチ
master: 安定して動作するコードのみを保持するブランチ。本番環境にリリースされるコードがここにマージされます。
develop: 開発用のブランチ。開発者がフィーチャーや修正を行うためのベースとなるブランチです。
サポートブランチfeature: 新しい機能の開発に使用されるブランチ。developブランチから派生して作成し、開発が完了したらdevelopにマージされます。
release: リリースの準備が整ったときに、developブランチから派生して作成します。リリース前の最終的なテストやバグの修正を行い、テストが終わったらmasterとdevelopにマージされます。
hotfix: 本番環境で発生した緊急
