- 1. 顧客から「〇〇エラー」のエラーメッセージってどの段階でリリースしたものですか？と聞かれたときの調査用コマンド（git log）
- 2. 最強（）のテンプレートリポジトリを作った
- 3. git merge解説
- 4. git push解説
- 5. Git認証を求められる対処法
- 6. git commit解説
- 7. git add解説
- 8. モダンなWebアプリのあるべき姿 Twelve-Factor App (AWSやIaCであるTerraformと絡めたら)
- 9. git config –global –add safe.directory ‘…’ が出たとき
- 10. gitでrevertした後に、revertしたコミットを再度マージはできない
- 11. git resetを2回やってunknown revision or path not in the working tree.と出た時の対処法
- 12. 【Git】メモ
- 13. 【Git】コマンドの基本操作
- 14. 【Git】私たち、やり直しましょう？
- 15. ファイルを追加する、ステージの状態を見る
- 16. 絶対してはいけない。仕事やってるアピールするためにgithubに自動でコミットする方法。
- 17. GitHubでの作業の流れと使うコマンド
- 18. 世界一よくわかるgit操作~vscode編~
- 19. remote: Large files detected. Please consider using Git LFS(Large File Storage) が出てハマった話
- 20. Windows環境にてgitリポジトリへssh接続する
顧客から「〇〇エラー」のエラーメッセージってどの段階でリリースしたものですか？と聞かれたときの調査用コマンド（git log）
# 顧客から「〇〇エラー」のエラーメッセージってどの段階でリリースしたものですか？と聞かれたときの調査用コマンド（git log）
# 結論（どうすればよいか）
“`src
git log -S “〇〇エラーメッセージ”
“`
あとはハッシュから逆算してリモートのリポジトリのグラフなりコミットログを追ってどうぞ。~~git log -S で調べると幸せになれるかもしれませんが、
私はここに書くのが面倒なので、各自調べてどうぞ~~
コミットメッセージというよりは、変更内容に引っかかったものが表示されるっぽい# 余談
①そもそも、ちゃんとリリースノート的なものに
・〇〇のエラーメッセージが追加されました
（エラー発生の条件）
※リリースノートの参考はみんな大好きVSCodeのリリースノートを参考にしてみてはいかがだろうか（戒め）みたいにすればいいのでは ~~（顧客が結局丸投げして聞いてくるのはナシで）~~
~~②そもそも、エラーメッセージのマッピング表をちゃんと作るべきでは~~
最強（）のテンプレートリポジトリを作った
## 概要
言語やフレームワークに依存せず、ほぼあらゆるプロジェクトに共通するリポジトリの設定ファイルなどがあります。それらをまとめたテンプレートリポジトリとして、ベーステンプレートリポジトリ（Base Template Repository）を作りました。
## GitHub リポジトリ
### 英語版（本家）
https://github.com/haru52/base_template
### 日本語版
https://github.com/haru52/base_template_ja
## 背景
ソフトウェア開発をする中で生産性の低さという課題に直面することがあると思います。開発生産性を低下させる要因の一部として次の 3 点が挙げられます。
1. 無駄な作業の多さ
– 句読点の付け方やインデントにおけるスペースの個数など本質的でないコードレビューで疲弊
– リリースや依存ライブラリ更新など毎回同じような単純作業の繰り返しが面倒。特に複数リポジトリを運用する場合に顕著
2. コミュニティへの不親切さ
– コントリビュートしようと思っても、開発
git merge解説
以下は社内向け勉強会のLT枠で話した内容をベースにして編集増補したものである。増補しただけでなくそもそも1回分を記事にしたものではなかったりもするので、この内容を5分で話したわけではない。
## git mergeコマンドの概要
git mergeはブランチの履歴にないコミットのファイル変更を取り込むためのコマンドである。
git mergeはgit pullによっても暗黙的に実行される。つまり、git pullは内部的にはgit fetchを行い、続けてgit mergeを行っている。ただしgit pullに–rebaseオプションを指定していればgit mergeの代わりにgit rebaseが実行される。
## git mergeコマンドの形
git mergeコマンドには、これからマージを開始する時に実行するコマンドと、競合によって等でマージが中断している時に実行するコマンドの2種類がある。
これからマージを開始するためのgit mergeコマンドは`git merge [オプション]
…`である。取り込まれる先はHEADの参照先、つま
git push解説
以下は社内向け勉強会のLT枠で話した内容をベースにして編集増補したものである。増補分があるので、この内容を5分で話したわけではない。
## git pushコマンドの概要
git pushはローカルリポジトリのオブジェクトをリモートリポジトリに送信して更新を行うコマンドである。
オブジェクトはコミット、[ツリー](https://qiita.com/yunano/items/f3133ea64efed762df2f#tree-ish)、ブロブ（[ツリー](https://qiita.com/yunano/items/f3133ea64efed762df2f#tree-ish)に含まれるファイル）、タグの補足情報（git tagの-aや-sや-uのオプション付きで作ったタグに付けられる）の総称である。
英単語上の逆コマンドであるgit pullは内部的にはgit fetchの後git merge（あるいはgit rebase）を行うコマンドだが、git pushは2つに分けられることはない。
共通のコミットを持たない複数のリポジトリから、1つのリポジトリに向けてpushすること
Git認証を求められる対処法
以下のような認証を求められるため、一度打った認証情報の保存をする
“`
$ git pull origin master
Username for ‘https://gitlab.com’:
Password for ‘https://user@example.com@gitlab.com’
“`# 対応方法
まず、以下を打つ。
“`
$ git config –global credential.helper cache
“`その後、認証を突破する
“`
$ git pull origin master
Username for ‘https://gitlab.com’:
Password for ‘https://user@example.com@gitlab.com’
“`もう一度実行すると認証を聞かれなくなる。
“`
$ git pull origin master
From https://gitlab.com/directory/project
* branch master -> FETCH_HEAD
git commit解説
以下は社内向け勉強会のLT枠で話した内容をベースにして編集増補したものである。増補分があるので、この内容を5分で話したわけではない。
## git commitコマンドの概要
git commitはインデックスにあるファイルの変更を、ローカルリポジトリに記録するコマンドである。つまり、リポジトリへ記録することをコミットと呼ぶわけである。
## git commitの対象範囲
`git commit [–] <ファイル名>`で指定したインデックス内にある最新コミットとは変更があるファイルを対象としてコミットする。
ファイル名は複数指定、ワイルドカード、「.」（そのディレクトリとサブディレクトリにあるすべてのファイル、の意味）も指定可能である。「.」を使って「dir/.」のような指定も可能であり、この場合dirとそのサブディレクトリのすべてのファイルが対象になる。
ファイル名の直前の「–」はこの後の引数をオプションとして使用しない、という意味であり、ファイルパスがマイナスで始まるものを指定する場合に有用であるが、特にそういうのがなければ省略しても良い。習慣として付ける人もい
git add解説
以下は社内向け勉強会のLT枠で話した内容をベースにして編集増補したものである。と言ってもgit addに関しては追加で書きたいこともあまりないので増補部分は少ない。
## git addコマンドの概要
git addはワークツリーからインデックスへのファイルの登録を行うコマンドであり、それ以外の機能はほとんどない。
ワークツリーおよびインデックスの説明は[git checkoutの方で行っている](https://qiita.com/yunano/items/f3133ea64efed762df2f#インデックスとワークツリー)。
## git addの対象範囲
`git add [–] <ファイル名>`で指定したファイルを対象としてインデックスに登録する。
ファイル名には複数指定、ワイルドカード、「.」（そのディレクトリとサブディレクトリにあるすべてのファイル、の意味）も指定可能である。「.」を使って「dir/.」のような指定も可能であり、この場合dirとそのサブディレクトリのすべてのファイルが対象になる。
ファイル名の直前の「–」はこの後の引数をオプションとして使
モダンなWebアプリのあるべき姿 Twelve-Factor App (AWSやIaCであるTerraformと絡めたら)
# 概要
* 先日、弊社の情報システム部門で開催されている勉強会にお呼ばれいたしまして、「モダンなWebアプリのあるべき姿 The Twelve-Factor Appとは?」という内容でお話しさせていただきましたので、その内容についてブログとして記載していきたいと思います。
* 内容なのですが、The Twelve-Factor AppのそれぞれのベストプラクティスとAWSを使った場合の適合方法、それぞれについての理解とモダンなwebアプリ開発など絡めたものになっております。# Twelve-factor Appって??
* モダンなWebアプリケーションのあるべき姿として、12のベストプラクティスにまとめた方法論
* Herokuプラットフォーム上で開発・運用・スケールした何百何千ものアプリケーションから得られた知見が基になっている
* 2012年に提唱。少々古い一面もあるが、現在でも示唆に富む数々のプラクティスが得らる**対象 : サービスとして動くアプリを開発しているすべての開発者**
> 引用 : https://12factor.net/ja/
# 何が
git config –global –add safe.directory ‘…’ が出たとき
# はじめに
USBメモリ上のディレクトリに対してリモートリポジトリ設定を行おうとすると，中々うまくいきませんでした．
かなり手こずってしまったので，私の場合の解決方法を残しておきます．# 環境
– Windows 10
– USB3.0 メモリ# エラー内容
USBのファイル名は `F:` で対象ディレクトリは `workspace` です．“`bash:コマンドプロンプト
F:\workspace>echo “# my-repo” >> README.mdF:\workspace>git init
Reinitialized existing Git repository in F:/workspace/.git/F:\workspace>git add README.md
fatal: unsafe repository (‘F:/workspace’ is owned by someone else)
To add an exception for this directory, call:git config –global –a
gitでrevertした後に、revertしたコミットを再度マージはできない
## なぜか
– 履歴上にすでにコミットが含まれているので## どうすればいいか
– revertコミットをrevertする“`
git revert
“`## 参考
https://zenn.dev/yoichi/articles/git-merge-again
git resetを2回やってunknown revision or path not in the working tree.と出た時の対処法
今すぐに2回目のresetをしたい人向け。本質的な解決方法ではないです。
# 起きたこと
1回目のgit reset –hard HEAD~xxはできたが、2回目をすると以下のエラーが出た。
“`
fatal: ambiguous argument ‘HEAD~xx’: unknown revision or path not in the working tree.
Use ‘–‘ to separate paths from revisions, like this:
‘git[ …] — [ …]’
“`
“HEAD~xx“という引数が曖昧だと言っている。# じゃあid指定しよう
“git reflog“の一番左に表示されるIDを引数に渡せば流石に曖昧じゃないだろう、と思い実行すると成功した。
“`
$ git reflog
…
e1499887 HEAD@{15}: commit: docker化した
$ git reset –hard e1499887
HEAD is now at e1
【Git】メモ
## なんかがみやすい
“`sh
$ git log .
“`## wslもコンテナ
エミュレーション（ホストマシン上で異なるOSを仮想的に動かす）してる## .gitフォルダ
objects,refs
→履歴管理をしている## 選択行のみgit add
stage selected rangeshttps://qiita.com/eyuta/items/a26bcc327139e9fd81d4
## HEAD
今いるブランチの一番先頭https://nebikatsu.com/6367.html/
【Git】コマンドの基本操作
# はじめに
ターミナル上でGitを使用ためのコマンド入力方法をおさらいしていきます。## clone
GitHub(リモートリポジトリ)からソースコードをダウンロードします。
ダウンロードに使用するURLはGitHub上の`Code`というボタンを押すと表示されます。
“`
$ git clone <リモートリポジトリのURL>
“`
## init
ローカルのソースコードをGitで管理するときの最初に入力するコマンドです。
このコマンドを入力することでソースコードをGitの管理下にすることができます。
“`
$ git init
“`## add
ファイルをインデックス(ステージング)に追加します。
※指定するファイル名の箇所はディレクトリ名などでも可能です。
.(ドット)を使用すると階層配下の全ファイルを指定できます。
“`
$ git add <ファイル名>
“`## commit
ファイルをコミットします。
“`
$ git commit <ファイル名>
“`## status
現在のファイルの状況を確認します。
“`
$ git stat
【Git】私たち、やり直しましょう？
未来のわたしのために最近覚えたやり直し方をメモ
## MR
今回のかなしい流れ
1. MRだす
1. 間違ってMerged
1. Revertで取消
1. 再MRの出し方が分からん！！！### Revertとは
既存のコミットを取り消すためのコマンド### 解決方法
もう１回Revertで、「取消」を取り消す！！→って教えてもらったけど、そしたらMerged状態に戻ってしまうのでは…？
アドバイスをいただいただけで、まだ実践できていないので、自分でやって確かめたら再度記事を詳しく更新したい！！## GitLab上のブランチを削除
GitLab>Branchで、ごみ箱マーク押す## TESTブランチの作成
覚えきれないほどのコマンドやGUIがあるので、とにかく試してみたかったら開発中のブランチからブランチを作成する！
（開発中のブランチが一番開発が進んでいるので、その時点でブランチをきると開発中のブランチから派生してブランチを作成することができる）## おまけ
### git pull origin master
定期的にやった方が良い
理由：MASTERブラ
ファイルを追加する、ステージの状態を見る
# ファイルをさらに追加する
## ファイルをステージする
“`
git add ファイル
“`
# 演習１
以下の内容をもつファイルhello.txtを作業ツリーに作り、ステージしよう。まだコミットしない。
“`
*********@mbp training % vim hello.txt
*********@mbp training % git add hello.txt
*********@mbp training % git status
On branch master
Changes to be committed:
(use “git restore –staged…” to unstage)
new file: hello.txtChanges not staged for commit:
(use “git add…” to update what will be committed)
(use “git restore…” to discard changes in working
絶対してはいけない。仕事やってるアピールするためにgithubに自動でコミットする方法。
仕事やってるアピールするためにgithubに自動でコミットする方法です。
絶対にしないでください。https://github.com/PeterTakahashi/auto-commit
このgithubリポジトリをforkにして、このコマンド実行するだけ
“`
git clone {git_url}
git remote set-url origin {git_url}
sh commit.sh
“`草生えますw
GitHubでの作業の流れと使うコマンド
## ①リモートから情報取得
### ゼロからの場合（ローカルはまっさらな状態）
`git clone` ### 既に以前のリモートの状態がローカルにある場合
1. `git fetch <リモート名> <ブランチ名>`
2. `git merge <リモート追跡ブランチ名>`## ②ローカルで作業〜プルリクまで
1. `git checkout -b <ブランチ名>` （ブランチ名はfeature/developなど）
2. 作業進めて `git add`
3. `git commit`
4. `git push <リモート名> <ブランチ名>`
5. GitHubページ上でプルリクエスト作成## ③プルリクマージ後
1. GitHubページ上でリモートブランチ削除
1. `git pull`
2. `git fetch –prune`（リモート追跡ブランチ削除）
3. `git branch -d <ブランチ名>`（ローカルブランチ削除）## 参考
– [Gitで不要なローカル・リモート追跡ブランチを削除するコマンドまとめ](https://www.
世界一よくわかるgit操作~vscode編~
# 世界一よくわかるgit操作~pushまで~
githubは変更履歴を管理、共有するためのツールです。今や、世界中でエンジニアが利用しているツールとなっています。そのため、これからエンジニアになるには超絶必須ツールです。ですが、初学者の方は苦手意識を持ちがちだと思います。そこで、gitと友達になってもらうことを目標にこの記事を書かせてもらいました。
#### Make friends with Git !
## Gitをインストール
#### 1. Gitがインストールされているか確認
– Mac
“`
git –version
“`
– Windows
“`
git version
“`
##### 2. 下記のようにバージョンが表示されればOK
“`
git version 2.32.1 (Apple Git-133)
“`
#### 3. Gitがインストールされていなかった場合、インストールする
– Macはこちらから
– https://git-scm.com/download/mac
– windowsの方はこちらから
– https://g
remote: Large files detected. Please consider using Git LFS(Large File Storage) が出てハマった話
# TD;DR
先日、業務にてGoogle Source Repo → Backlogへのリモートリポジトリ移管作業が発生しました。
移管といっても、基本的にはpushするremoteの目先を Google Source Repo → Backlog にして、pushするだけだろうと思っていたのですが、こういうエラーが出てきた。
“`
remote: Large files detected. Please consider using Git LFS(Large File Storage).
remote: See https://xxx.backlog.jp/help/git-lfs-about for more information.
remote: File docker/xxx/hoge.zip exceeds Backlog’s file size limit of 100M
remote: File docker/xxx/hoge2.tar.gz exceeds Backlog’s file size limit of 100M
remote: File doc
Windows環境にてgitリポジトリへssh接続する
# TL;DR
先日windowsマシンにて、backlogのリポジトリへssh接続にてpushを行うにあたって若干ハマったので備忘録です。
vscodeからでもコマンドからでも実行できるようになります。# なににハマったのか？
ssh接続を行うにあたって必要なのが、当然ながら公開鍵と秘密鍵が必要になってきます。
そこでssh-keygenを叩いたのですが、鍵の名前を何にするか聞かれます。
自分の環境には、すでにC:\Users\ユーザー名\.ssh配下にデフォルトの名前である、– id_rsa(秘密鍵)
– id_rsa.pub(公開鍵)があり、「はいはいすでにおるもんな。(チガウナマエツケー)」で鍵を作成。
公開鍵を意気揚々とbacklogへ登録し、いざpush！
…しても、当然ssh接続時にエラーとなりました。
原因は、「当該backlogのリポジトリへのssh接続にあたって、どの鍵を使うのか？」をsshちゃんが分かってないからだなとすぐに気づいたのですが、Windowsマシンでsshの設定ってどうするんだ？となったので、その時に調べたことのメモとなります。#
