- 1. 入社3年目、業務以外の知識がない自分がGWを捧げてサービス・アプリケーションを勉強してみた!〜4日目Git:リポジトリの作成からPull Requestまで〜
- 2. 途中でリモートリポジトリの名前を変更した時にやること
- 3. Git conventional commitまとめ
- 4. Gitのrebaseに関して
- 5. The ‘.git/hooks/pre-commit’ hook was ignored because it’s not set as executable.の対処
- 6. Gitのマージに関して
- 7. 【リファレンス】よく使うGitコマンド
- 8. 業務フローから学ぶgit、GitHub入門
- 9. 【備忘録】4月3週目学んだこと(Git編)
- 10. 【備忘録】1Passwordでの複数Githubアカウント利用時のSSHキー管理方法
- 11. 初めて git rebase してみた
- 12. 「git rebase origin/main」と「git rebase origin main」の違いとは?
- 13. FlutterWeb + Firestoreを連携した超簡単なサンプルアプリを作成して自動デプロイする
- 14. Gitの使い方備忘録(Windows)初期設定編
- 15. Gitで管理しないファイルの指定方法
- 16. Xserverでgitを使う
- 17. 入社3年目、業務以外の知識がない自分がGWを捧げてサービス・アプリケーションを勉強してみた!〜0日目〜
- 18. やらかしたときによく使うGitコマンド
- 19. 細かいつまずいたことをメモしておく(4月編)
- 20. git stashを誤って削除した際の復元方法
入社3年目、業務以外の知識がない自分がGWを捧げてサービス・アプリケーションを勉強してみた!〜4日目Git:リポジトリの作成からPull Requestまで〜
# はじめに
前記事(https://qiita.com/hugo-crt/items/aa128860f7b0f494e6e3)
の続きです。一旦AWSからは離れてGitのハンズオンを行います。
以下の記事を見てハンズオン学習します。https://qiita.com/TakumaKurosawa/items/79a75026327d8deb9c04
## 前提知識
リポジトリ:ソースコードなどのファイルをプロジェクト単位で区切った単位のこと。
リモートリポジトリ:GitHub上に作成されたリポジトリのこと。
ローカルリポジトリ:リモートリポジトリから作業端末に複製されたリポジトリのこと。ブランチ:ある時点以降における、リポジトリの異なる世界線。例えば最終成果物であるmasterブランチがメインであるのに対して、メインのブランチをきれいに保てるよう、機能改善などで修正する際に、世界線を変えて編集すること。
(あくまで現時点で抱いているイメージです)
プルリクエスト:切り分けたブランチから最終的に積み上げる際に、積み上げてよいか確認するためのメッセージのこと。
マージ
途中でリモートリポジトリの名前を変更した時にやること
今回はGitに関するちょっとしたTips。
Githubで新しくリポジトリを作ったものの、「この名前ちょっと違うなあ」と名前を変えた時に実行したことをまとめました。### ローカルリポジトリにも名称変更を反映させる
リモートの方だけで名前を変えても意味がないので以下のコマンドで反映させました。
“`git:git
git remote set-url origin 名称変更後のURL
“`
`git remote -v`で反映されたことを確認する。
Git conventional commitまとめ
# はじめに
gitのcommitメッセージについて、開発チーム内で規約などを定めているでしょうか?
私は前職の開発チームでは、メンバー間でgitのcommitメッセージに関して規約などを定めていない中で開発を進めておりました。
一方で現職の開発チームでは、社内の開発チームのメンバー間で共通された規約を用いてcommitメッセージを書くことが定められており、commitメッセージに関してチーム内で共通のフォーマットを用いて運用を行うことに一定のメリットがあることに気がついたので記事にまとめます。# conventional commit
社内の開発チーム内では全チームで共通して、基本的には `conventional commit` に従ってコミットメッセージを残しております。https://www.conventionalcommits.org/en/v1.0.0/
# 業務内で頻繁に利用するcommitメッセージのフォーマット
“`
chore: some message
chore(module name): some message
“`“`
feat:
Gitのrebaseに関して
・Gitのrebaseに関して
rebase
=>変更履歴を綺麗に修正(分岐していたコミットを1つにまとめて統合)●コマンド
git rebase ブランチ名
例)
“`
git rebase master
=>現在作業しているブランチの親コミットをmasterブランチに変更・修正
“`●リベースの流れ
①リベース
②リベースした親ブランチに移動
③親ブランチをリベースしたブランチとマージ(Fast Foward)
例)featureブランチをmasterブランチにリベースする場合
“`
git switch feature
git rebase master
git switch master
git merge feature
“`●注意点
GitHubにプッシュしたコミットをリベースしてはいけない。
これを行ってしまうと、ローカルデータとGitHubデータ間の親コミットが異なるものとなってしまい、push出来なくなる。
The ‘.git/hooks/pre-commit’ hook was ignored because it’s not set as executable.の対処
### 結論
pre-commitに対して実行権限を付与。
“`
chmod +x .git/hooks/pre-commit
“`### 環境
OS: macOS Big Sur
PHP: 8.0
Laravel: 8.0Docker Desktop for macも使用
### 現象
phpmdやphp-cs-fixerをpre-commitフックを使って、コミット時に問題の検出とコード整形を自動化しようとして、
`[プロジェクト名]/.git/hooks/pre-commit`にpre-commitのスクリプトを記述。「よっしゃこれで手動でコマンド打たんでもよーなったで!」
“`console:コンソールに表示されたエラー
hint: The ‘.git/hooks/pre-commit’ hook was ignored because it’s not set as executable.
hint: You can disable this warning with `git config advice.ignoredHook false`.
“`
Gitのマージに関して
・Gitのマージに関して
●マージ・・・他の作業者の変更内容を取り込む作業●コマンド
git merge ブランチ名
git merge リモート名/ブランチ名
例)
git merge origin/master
=>作業中のブランチにoriginリポジトリのmasterブランチをマージする●マージの種類
マージには3種類存在する。
①Fast Foward
=>枝分かれしていないブランチを最新の状態に更新するマージ
“`
git pull リモートリポジトリ名 ブランチ名
“`
で可能
②Auto Merge
=>最も基本的なマージで、枝分かれしているブランチを1つにまとめるマージ
※git mergeコマンドを使用
③Conflict
=>同じファイルの同じ行に対して異なる編集を行った複数のファイルをAuto Mergeした際に起こるエラー
※マージ後のファイルを編集後、再度git add, git commitすることにより解決する
【リファレンス】よく使うGitコマンド
### 編集済みファイルをステージング
“`
git add -A
“`### ステージングされたファイルをコミット
“`
git commit -m “comment”
“`### リモートリポジトリにアップ
“`
git push origin <ブランチ名>
“`### リモートリポジトリからダウンロード
“`
git pull origin <ブランチ名>
“`### ブランチ切り替え
“`
git checkout <ブランチ名>
“`### 管理対象から指定したファイルのキャッシュを削除
“`
git rm –cache <ファイル名>
“`### 管理対象から指定したディレクトリのキャッシュを削除
“`
git rm –cache -r <ディレクトリ名>
“`### 管理対象から全てのファイルのキャッシュを削除
“`
git rm –cache -r .
“`### 作業ブランチに指定したブランチをマージ
“`
git merge <マージしたいブランチ名>
“`### 作業ブランチに指定した
業務フローから学ぶgit、GitHub入門
# はじめに
社内勉強会を開催するにあたって、扱った内容の一部を記事にしました。
今やweb系エンジニア業界でほぼ必須と言えるgit、GitHubについて
「なんとなく分かるけど実際、業務でどう使うの?」
と感じているエンジニア1年生のための記事になります。近頃は便利なGUIツールが多く存在しますが基本的な概念を知らずにそれらのツールを使用してgitがブラックボックス化してしまうとチームメンバー迷惑をかけてしまうことや自分の進捗が吹っ飛ぶことにつながりかねません。
# 前提知識
– gitの基本的概念がざっくり分かる(ローカルリポジトリ、リモートリポジトリ、クローン、コミット、プッシュなど)
– GitHubとは何か知っている上記の二つは分かりやすく説明されている記事が大量にあると思うので今回は割愛します…
# git-flowを知ろう
> git-flowとは簡単にいうと、gitのブランチにおける分岐モデルのことです。多くの企業ではgit-flowやそれに類似したモデルに沿って開発していくと思います。
git-flowの概念図↓

初心者です。間違いに気付いたら適宜直し、書ききれなかったことは加筆もしていきます。
## Gitとは
ファイルのバージョン管理システムのこと。
GitHubは、自分のGitの内容をサーバ上で預かってくれるサービス
※GitHubのほかにも類似したサービスにBitbucketなどがある## Gitの仕組み
まず個人の環境(ローカルな環境)の中に、**ワークツリー**:作業している場所(ディレクトリ)
**ステージ**:リポジトリの前段階
**リポジトリ**:ワークツリー内のファイルを圧縮したファイルやコミットの履歴などを入れておく場所がある。これらすべてローカルの話。
### add と commit
`Git`では、`add`によって作業場(ワークツリー)の内容をステージ内に保存し、`commit`でリポジトリに正式なコミット(変更)として保存する##### 具体的には、
`git add`によって、ワークツリーのファイルすべてを圧縮してリポジトリに格納し、さらに、ステージにインデックスを作成する
インデックスには、圧縮ファイルとワークツリーのファイルが格納されてい
【備忘録】1Passwordでの複数Githubアカウント利用時のSSHキー管理方法
# はじめに
1PasswordのSSHエージェント機能により、GitHubのSSHキー管理ができるようになりました。
かなり便利なため最近使い始めたのですが、仕事用/プライベート用といった**複数のGitHubアカウントを利用する場合**の設定方法に少しつまづいたため、設定手順を備忘録として残しておきます。– MacOS環境での設定手順
– 執筆時点(2022/5/1)では、1PasswordのSSHエージェント機能はベータ版のみの提供# 1Passwordのインストール、単一アカウントのSSHキー設定手順
インストールと**単一の**GitHubアカウント(メインアカウント)使用時の設定は以下クラメソさんの記事がわかりやすいため、こちらを参考にしてもらえると良いと思います。
[Github等で利用するSSH keyの作成及び管理を1Passwordで行う](https://dev.classmethod.jp/articles/1password-git-ssh/)今回はメインGitHubアカウントにSSHキーに“`Github-main“`を登録しました。
!
初めて git rebase してみた
# はじめに
こちらの記事では、今まで GitHub Desktop に頼り切っており、最近漸く Git のコマンドに手を出した私が、rebase について勉強したこと・実際に rebase を実施した結果をメモとして残します。# rebase とは
## Git の歴史を改変するコマンド
– 改変例
– コミットメッセージを変更(reword)
– コミットを修正(edit)
– コミットを前のコミットとまとめて、コミットメッセージを変更(squash)## メリット
– Git の歴史が綺麗になる
– `main` ブランチの最新の内容を取り込んだ上で開発を進めることができる
– 参考:[あなたはmerge派?rebase派?綺麗なGitログで実感したメリット](https://style.biglobe.co.jp/entry/2022/03/22/090000)# rebase コマンドのオプションの一例
## `$ rebase -i`
– rebase を開始
– 各コミットに対して、どのコマンド(pick、reword、edit、squa
「git rebase origin/main」と「git rebase origin main」の違いとは?
更新されたmainブランチを作業ブランチに取り込みたいときは
“`
$ git rebase origin/main
“`
ですよね。ただ、間違えて
“`
$ git rebase origin main
“`
とやってしまいましたそしたら、作業ブランチから、いつの間にか mainブランチにいました。
なにかをrebaseしていました。。
調べたところ“`
$ git rebase origin/main
“`は以下のコマンドと同義ということがわかりました
““
$ git checkout main
$ git rebase origin
““ただ、他のリポジトリで同じようなことをやったら、以下のエラーが出ましした。
“`
fatal: invalid upstream ‘origin’
“`ただ、以下で成功する理由が分からない。
“`
$ git rebase origin
“`そこで、上記が成功するリポジトリと成功しないリポジトリを調べたところ
以下の違いが分かりました。以下のコマンドを打つと
“`
$ git br
FlutterWeb + Firestoreを連携した超簡単なサンプルアプリを作成して自動デプロイする
## 0. はじめに
Flutter + Firestoreを連携してアプリを作成する手順についてまとめました。
FloatingActionButton押下時のカウンターをFirestoreへ登録するだけの簡単なアプリになります。
ついでに自動デプロイする方法についても記載しています。:::note warn
以下を前提とさせてください。
– FlutterWebプロジェクトを登録するためのリポジトリが作成されていること。
– Firebaseアカウントが登録済みであること。
– Node.jsがインストールされていること。
:::## 1. Firebase編
### 1-1. プロジェクトを作成する
①まずはFirebaseにプロジェクトを作成していきましょう。
以下にアクセスします。https://console.firebase.google.com/
②「プロジェクトの追加」ボタンを押下します。
初期設定編
# はじめに
今更ながらgitを使い始めたが、忘れやすので必要なものを書いておく。# 使用環境
OS: Windows7 Professional
Tool:Git
Terminal:Mintty# Gitって
出遅れたので、今さら説明するのも何なので、詳細は割愛。
分散型バージョン管理システムというものらしい。
CVSとの違いは、ざっくりと言うと集中型か分散型かの違い。つまりコミット先がローカルにあるから、コミット(チェックイン)できるよってことかなぁ。# 初期設定
#### 必要に応じて
まずは何はともあれ、やってみよう!ということで初期設定。
コマンド実行後どうやらエディタに引き渡されて編集することがあるらしいので、エディタを設定しておいた方が良さそう。
`.gitconfig` は直に修正しても良いし、コマンドを実行すると登録されるのでそれでも良い。
最終的にこうなっていれば大丈夫。#### いつものがいいって人はこっち。例は秀丸
~~~ ~/.bash_profile
export GIT_EDITOR=”‘/C/Program Files/hidemar
Gitで管理しないファイルの指定方法
・Gitで管理しないファイルの指定方法
作業フォルダ内に「.gitignore」ファイルを作成する。※使う対象
●自動生成されるファイル
●パスワード等機密事項が含まれているファイル※「.gitignore」ファイルの記述方法
●コメントアウト
行頭に#
●指定したファイルを除外
ファイル名を記述
例)index.html
=>これで「index.html」はgitで管理されない
●ルートディレクトリを除外
/root.html
●ディレクトリ以下を除外
dir/
●/以外の文字列を含むファイルを除外
例)「.css」を含むファイルを除外
/*/*.css
Xserverでgitを使う
# Xserverでgitを使う
2022/4時点
## 前提
– Xserverにssh接続している
## 作業前に
Xserverにほぼ初めてsshしたけどlsコマンドすら使えなかった。
`-bash: ls: コマンドが見つかりません`“`
$ /usr/bin/ls
“`
フルパスで実行すると正常に動作した。PATH設定がおかしいとのことでbash_profileを以下のように変更します。変更箇所はコメントアウト部分です。
#PATH=$PATH:$HOME/bin
PATH=$HOME/bin:$PARH“`
$ /usr/bin/vi ~/.bash_profile
“`“`.変更前
# .bash_profile# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi#PATH=$PATH:$HOME/bin
PATH=$HOME/bin:$PARHexport PATH
“`“`.変更後
# .bash_profi
入社3年目、業務以外の知識がない自分がGWを捧げてサービス・アプリケーションを勉強してみた!〜0日目〜
# 進捗
https://qiita.com/hugo-crt/items/3cebbbf16db1d2fde063https://qiita.com/hugo-crt/items/40c4bcb883c74085e539
https://qiita.com/hugo-crt/items/662eb5726d7d12b83bfe
https://qiita.com/hugo-crt/items/61ad9a60d599ee5d9b47
https://qiita.com/hugo-crt/items/7819a61ea4cb63532787
https://qiita.com/hugo-crt/items/aa128860f7b0f494e6e3
https://qiita.com/hugo-crt/items/24c4147d851cf30bcf22
# はじめに
入社3年目、新卒入社の頃から気持ちは変わらないものの、
徐々に自分の裁量で仕事をできるようになっている私。通勤電車で日経新聞を読むサラリーマンを横目に、
Quitaで目についた記事を読んではストックし
やらかしたときによく使うGitコマンド
やらかしたときに都度調べ直すので備忘録。
いい加減やらかすの止めたい。## ブランチ削除
#### ローカルのブランチを削除する場合
“`
git branch -d {ローカルブランチ名}
“`#### リモートのブランチを削除する場合
“`
git push origin –delete {リモートブランチ名}
“`## コミット打ち消し
“`
git revert {コミットのハッシュ値}
“`
– 指定したコミットの状態にまで戻してコミットを行う## コミットを取り消す
#### 直前のコミットだけ消す
“`
git reset –soft HEAD^
“`
– HEAD^ : 直前のコミット
– –softのオプションをつけることでワーキングツリーはそのままの状態にできる#### 直前のコミットを消し、ワーキングツリーも消す
“`
git reset –hard HEAD^
“`
– –hardのオプションを付けることでワーキングツリーも1つ前のコミットの状態に戻せる#### コミット後の変更を全部消す
“`
g
細かいつまずいたことをメモしておく(4月編)
# はじめに
今月は資格の勉強を開始したので、そこまでアウトプットするようなトラブルには遭遇しませんでした。
環境構築をする機会があったのでその内容が中心です。# 問題
## VPNにつなげるとdocker-compose upでのインストールで止まるこれはDocker内部のネットワークとVPNの間で問題がおきることでインストールが遅くなってしまうのが原因っぽい
`wsl-vpnkit`というのをインストールすることで改善するようになったhttps://github.com/sakai135/wsl-vpnkit
[ダウンロード](https://github.com/sakai135/wsl-vpnkit/releases/tag/v0.3.2)から最新のtar.gzを取得します。
そのあとPowerShellを開いて、ダウンロードした場所にディレクトリを移動して以下のコマンドを叩きます。“`
# PowerShellwsl –import wsl-vpnkit $env:USERPROFILE\wsl-vpnkit wsl-vpnkit.tar.gz –
git stashを誤って削除した際の復元方法
下記手順を行うことで誤って削除したgit stashを戻せると紹介している記事が多数ありますが私の環境では復元できませんでした。
※復元できなかった原因はわかりません……。
1. git fsck | awk ‘/dangling commit/ {print $3}’
2. git cherry-pick -n -m1 1.で見つけたsha1上記手順に加え下記手順を行うことで誤って削除したstashを復元することができました。
3. git cat-file -p 1.で見つけたsha1
4. git cherry-pick -n -m1 3.で見つけたsha1下記コマンドを実行することで詳細を確認することができます。
git show 3.で見つけたsha1