- 1. Amazon Linux2のsecurityアップデートに追加された”/bin/scalar”について
- 2. あなたのgitクライアント、これできますか？ lazygit の神機能5選（動画付き）
- 3. formatが通らないとcommitできないようにした話
- 4. コマンドを使わずに理解するGit
- 5. 作業中の変更を一時退避させる git stash ハンズオン
- 6. アカデミアポッター 不死鳥の博士学生
- 7. 【Cloud9 Advent Calendar Day2】ガチで作業が捗るIntelliJのおすすめプラグイン7選
- 8. git initの取り消しをしたい
- 9. Git 差分の無いブランチにコミットする方法
- 10. fatal: ambiguous argument ‘branch_name’: both revision and filenameの解決方
- 11. GitHub Wiki の更新をSlack で知りたい！！
- 12. git day job(ぎっとだいじょうぶ）
- 13. SI向けGitHub-flow改
- 14. satyrographos-repo-bin でパッケージをバイナリ配布している話
- 15. httpプロトコルでもgit認証情報を保持する (nixos設定も)
- 16. プルリクエスト（PR)を作るときに意識したいこと
- 17. Web開発でgitのコミットにprefixをつける
- 18. git pushできない。エラー：remote: Permission to [ユーザ名]/[プロジェクト名].git denied to [ユーザー名]. fatal: unable to access ‘https://github.com/[ユーザー名]/[プロジェクト名].git/’: The requested URL returned error: 403
- 19. gitのコミットメッセージをかわいく＆分かりやすくしたい?
- 20. Vimで快適なgit生活を送る
Amazon Linux2のsecurityアップデートに追加された”/bin/scalar”について
運用しているサーバで自動的にSecurityアップデート(`yum -y –security update`)を適用しています｡
さらにAIDEで定期的にファイル改ざん検知を行っています｡本日のSecurityアップデートで`/bin/scalar`なるものが追加されていて｢なんだこりゃ?｣と~~慌てた~~思ったので調べてみました｡
“`bash
-rwxr-xr-x 1 root root 2245096 11月 19 04:39 /bin/scalar
“`manを実行したGitのツールだと表示されます｡確かに`version`を実行してみると`git`のバージョンが表示されます｡
“`bash
$ man scalar
NAME
scalar – A tool for managing large Git repositories
“`“`bash
$ scalar version
git version 2.38.1
“`で､調べてみたら､ScalarはMicrosoftが開発した大規模Gitリポジトリ管理用のツールで､2.38で
あなたのgitクライアント、これできますか？ lazygit の神機能5選（動画付き）
## 初めに
いろんなGitクライアントを使い回したが、やっと[lazygit](https://github.com/jesseduffield/lazygit)に定着しました。
いくつ便利な機能を紹介します。## ① コミットの前後を決める
`Ctrl+j`・`Ctrl+k`でコミットの前後を決められます。
（tmuxキーバンドと競合するため`Ctrl+b`・`Ctrl+g`にしました）
## ② ステージした内容を既存のコミットに追加
「あ、これコミット忘れた、、」ってありますか？
対象コミットに`shift+a`でコミットの修正できます！
（ノーモア、「fix lint」・「fix test」というつまらないコミット）
 の12月7日の記事です！
弊社で初めてのアドベントカレンダーの1週間目を迎えています〜！さて、本題ですが今回はタイトルの通り、formatが通らない限りはcommitできないようにしたお話をしていこうと思います。
開発でなんらかのフォーマッターを使っている方なら、どなたでも読んでいただけると嬉しいです！
# モチベーション
セーフィーではバックエンドをPythonで実装していて、コードのフォーマッターに[black](https://black.readthedocs.io/en/stable/index.html)と[flake8](https://flake8.pycqa.org/en/latest/index.html#quickstart)を使用しています。これらのフォーマットのチェックはPR作成時、PRブランチへのpush時などにCIでチェックを行なっています。そのため、pushしたあとにf
コマンドを使わずに理解するGit
この記事は[Nuco Advent Calendar 2022](https://qiita.com/advent-calendar/2022/nuco)の7日目の記事です
# はじめに
株式会社Nucoでエンジニアをしている@noshishiです。
今回は、ついついその場限りのコマンド実行で乗り越えがちなGitを、コマンドを使わず理解するための記事を書こうと思います。# Gitとは
### バージョンを管理し、作業を分散する
Gitは、分散型バージョン管理システムと呼ばれるソースコードの管理システムの1種です。
Gitは、ファイルの**変更履歴（バージョン）を記録・追跡**することで、過去と現在のファイルを比較し、変更点を明らかにすることで、円滑に開発作業を進めるためのツールです。
また、一度に**複数の開発者がファイルを編集**できるシステムなので、作業を分散して行うことができます。### Gitを使うということ
まず、みんなで共有できる保存場所（以下、リモートリポジトリ）にあるファイルなどを、手元のパソコン（以下、ローカルリポジトリ）にコピーを作って、新しいコー
作業中の変更を一時退避させる git stash ハンズオン
# 背景
プルリクを出している最中に別の作業をしていたり、コミットしたくないけどとりあえずどこかに保存させておきたい場合に使えるstashを使うと便利なのを紹介したい# 覚えて欲しいコマンドと効果
“`bash
git stash -u # untracked file を含めて退避するgit stash list # 一覧表示をする
git stash pop # 最後のshashを退避から取り出し、対比場所から削除する
“`# 使ってみた
ブランチの準備
“`bash
git switch -c branch_a
“`test_a.mdを作成後、以下のようにファイルを保存する。
“`markdown:test_a.md
# aでの作業branch_aで作業しました
“`
stashをする
“`bash
git stash -u
# Saved working directory and index state WIP on branch_a: xxxxxx add workspace setting
“`これでworkspaceの
アカデミアポッター 不死鳥の博士学生
この記事は[闇の魔術に対する防衛術](https://qiita.com/advent-calendar/2022/yaminomajutu)7日目の記事です。
Qiitaではご無沙汰しております。青ポス（[@bluepost125](https://twitter.com/bluepost125)）です。年々闇の魔術のキレが落ちていましたが、今年は飛び切りのネタが入荷したので書いておきます。
:::note info
この記事を特に読んでほしい人
* B4や修士で研究に行き詰っている人
* 修士を修了して博士に行くか就職するか迷っている人
:::# 経緯
5年ほど前にアカデミアに囚われていた人です。この後囚われの身から解放されますが、実はこの度再びアカデミアに戻ることになったので、体験談を書いておきます。過去作：若さゆえの過ちでかなり独りよがりな文書ですが、戒めとして残しておきます。
https://qiita.com/bluepost59/items/a08c0eb0a57f8b28abdf
# 前編：懺悔と教訓
学生時代、自分は典型的な[モヒカン](https:
【Cloud9 Advent Calendar Day2】ガチで作業が捗るIntelliJのおすすめプラグイン7選
この記事はCloud9 Advent CalendarのDay2です。
**こんにちは！Cloud9サーバーサイドエンジニアの折原です！**
アドベントカレンダーをやってみると言い出したはいいものの、他の社員が業務に忙殺されていて執筆の時間が取れないため、昨日に引き続き私がDay2の記事を書かせていただきます。
思い返すといつもいつもやることが唐突で行き当たりばったりの人間なんですが。
毎回付き合ってくれる社員の皆様には本当に感謝しております。というわけでDay2行ってみましょう！
## Javaエンジニアが選ぶ！ガチで作業が捗るIntelliJのおすすめプラグイン7選
今回も〇選！系の記事になります。
実は私、今まで現場でEclipseしか使ったことなくて、今のプロジェクトに入って初めてIntelliJを触ったんです。プライベートの開発では使ったことはあったんですが、仕事で使うのは初めてです。**強力なコード補完機能、検索機能のほか、MavenだけでなくGradleプロジェクト等の各種ビルドツールにも対応していて拡張性がかなり高く、それでいてEclipseよりも軽
git initの取り消しをしたい
git initを行ったディレクトリに移動後、下記コマンドを実行する。
（.gitフォルダが削除されます。）
“`
rm -rf .git
“`ちなみに.gitフォルダの中身の詳細については下記記事が参考になります。
https://qiita.com/tatane616/items/dbad66179754be57d2e2
Git 差分の無いブランチにコミットする方法
いわゆる空コミットの方法
※ 複数人が関わるブランチの場合は運用ルール等を事前に確認してからやりましょう
# 手順
1. 空コミットしたいブランチに切り替え
2. 以下コマンドを実行
“`git commit –allow-empty -m “[コメント]”“`コメントには空コミットを行った理由(「初回コミット」とか)を残しておくと良いです
## 何に使うん？
* 新しく作ったブランチの最初のコミットに
* プルリクを送りたい時に
* 他開発・保守作業上必要な場合に
fatal: ambiguous argument ‘branch_name’: both revision and filenameの解決方
ブランチを操作しようとしたときにでたエラー
“`
fatal: ambiguous argument ‘branch_name’: both revision and filename
Use ‘–‘ to separate paths from revisions, like this:
“`
「branch_name」という名前のブランチと、「branch_name」という名前のファイルまたはディレクトリがあることを示しています。コマンドで「branch_name」をブランチとして扱いたい場合は、
“`git log –oneline branch_name –“`
「branch_name」をファイルとして扱いたい場合は、
“`git log –oneline — branch_name“`ブランチ名とファイル/ディレクトリが同じだと今後もトラブルが出そうなのでブランチ名を変更することにしました。
**ローカルのブランチ名を変更する方法**
“`git branch -m <古いブランチ名> <新しいブランチ名>“`
今開いているブランチをリネー
GitHub Wiki の更新をSlack で知りたい！！
# 初めに
2022年10月19日以降、GitLab のFree プランのユーザ制限が5人までとなりました…>< (詳しくは[こちら](https://about.gitlab.com/blog/2022/03/24/efficient-free-tier/)を確認ください:bow:) 弊社ではGitLab, GitHub の両方を使っており、今回のGitLab のプラン変更に伴い 社内でいろいろ議論があった結果、GitLabで管理しているプロジェクトを全てGitHub に移行することにしました。 そこでGitHub とGitLab の違いで出たのが、wiki 更新のSlack 通知がGitHub では画面ぽちぽちで設定できない...ということが発覚しました :innocent: 調べてみるとGitHub Actions でなら通知可能なことがわかったのでその設定方法を記事にまとめました。 同じような問題等でGitHub wiki の追加/更新をSlack で知りたいという方がいたらご参考になれば幸いです。 # 完成系 - wiki を新規追加/更新したかをSlack か
git day job(ぎっとだいじょうぶ）
git ちゃんと使ってない。
https://qiita.com/kaizen_nagoya/items/17a092c37908476482ba
去年の投稿から、一ミリも進化していないかも。去年は、他の方の記事を並べただけに終わった。
今年は、自分の記事を並べることによって、加速する機会となれば幸いです。GitHub入門 (1) 入門
https://qiita.com/kaizen_nagoya/items/b6f5b1532fd21fec79c8
設計はgit, dockerで。docker(13)
https://qiita.com/kaizen_nagoya/items/5e85a825709f7f5f56ee
# git day job
gitの日毎の作業としては、
## 今日は何の作業をするか。
製品用のコードを触るのか、試験用のコードを触るのか。
## 分岐させるか、させないか。
製品のコードは、製品の分岐がない場合には、自分の意思で分岐させることはない。
試験コードは、自分用の試験、試験の分類などによって分岐## 1日の作業
SI向けGitHub-flow改
# はじめに
– SIとしてGitブランチ戦略を考えた時、何が最適か見つからなかった
– GitHub-flowは都度リリースする形態が前提なので、SIの様にフェーズという長い期間を経てリリースするのに向かない
– Git-flowはdevelopブランチとmainブランチの定義が曖昧、きっちり管理しないとカオスになる
– GitLab-flow, gitworkflows…
– 運用としては単純明快なGitHub-flowがいいが、SIにおける運用や各ブランチの明確化、CICD運用を踏まえて改良して運用することにした。# 概要
– `main`がメインである
– タスク作業は`feature/#{issue番号}`で行う
– 不具合対応は`hotfix/#{issue番号}`で行う
– 環境確認用ブランチ(検証: `env-staging` / 本番: `env-production`)を用意する
– 各環境にデプロイする際に対象ブランチで上書きし、デプロイする
上書き元と同一のブランチとしたいため、コンフリクトリスクがあるmerge
satyrographos-repo-bin でパッケージをバイナリ配布している話
:::note info
これは「[SATySFi Advent Caleandar 2022](https://adventar.org/calendars/7515)」の5日目の記事です。
（4日目は [yozu さん](https://qiita.com/yasuo-ozu/items/bc8f4615ae20d936add9)、6日目は [yozu さん](https://adventar.org/calendars/7515)です。）
:::SATySFiパッケージ[^1]のインストールは重いことで知られています。この原因として以下の2点が考えられます。
[^1]: SATySFi向けのライブラリパッケージも依存関係としてSATySFiを持っているため、ここでいう「重い」に含みます。
– ソースコードで配布されているため、ダウンロード容量が大きく、またコンパイルするのに時間がかかるため。
– 上記のコンパイルを行うためにはocaml-compilerやdune等、ocamlの世界で使われているツールが多数必要となり、それらをダウンロード＆コンパイル＆インストールする必
httpプロトコルでもgit認証情報を保持する (nixos設定も)
本記事は[クラスター Advent Calendar 2022](https://qiita.com/advent-calendar/2022/cluster)（2ページ目）の6日目の記事になります。
前回は [@Swanman](https://qiita.com/Swanman) さんの「[# Slackで同じワークフローのショートカットを複数チャンネルに設置する](https://qiita.com/Swanman/items/c7ebc94f7ee5e2418d00)」でした。
SwanmanさんのCSとは思えない技術力とユニークな着眼点はいつも楽しませてもらってます。さて1日目に引き続き僕です。
本記事はnixosにおけるhttp protocolのcredential helper設定で詰まってしまったので、その解決方法になります。## httpsプロトコルでの認証
httpsプロトコルで`git push`をすると毎回usernameとpasswordを聞かれて面倒。という問題がまれによくあります。
“`
Username for ‘https://gith
プルリクエスト（PR)を作るときに意識したいこと
自分が実際に実務で実践出来ているかどうかは置いておいて今までの経験や技術書を読んでプルリクエストを作る上で大事だと思うことをまとめてみます。
## レビューアーの立場（気持ち）で考える
これから説明することの全ての原点はこれに帰着すると思う。
コードレビューはそれなりに工数がかかる作業のためレビューアーの負担が少なくなるように前提知識や拝見等を漏れなく列挙するのが大事である。– プロジェクト全体でかけるコストが少なくなるように意識する
– レビューアーが差分をみたらすぐにレビューできる状態にしておく
– レビューアーのコスタが低くなるようにレビューを依頼する## レビューアー向けの説明を書く
– 適切なタイトルをつけ、本文に目的、背景を書く
– 実装の根拠を書く
– 仕様や設計をまとめる（リンクや画像があれば
– コードを改善する（リファクタリング）
– 差分の説明をする
– 成果物のリンク、画像、動画等を貼る何を実装したのか？について重点的に書く人は多い印象を受けるが意外と「なぜ」そのように実装したのか？を書く人は少ない印象を受ける。
極論、何をやっているのかはコード
Web開発でgitのコミットにprefixをつける
## 導入してよかったこと
gitを使い始めてしばらくしてもコミットに何を書けばいいのか迷う時期がありました。
そこでOSSのとあるJSライブラリ開発ではprefixを付けていることを知り取り入れてみたところ
– コミット内容のカテゴリ付けされているみたいになりコメントの取っ掛かりになる。
– コミットに含める内容を意識しやすくなった。
– prefixを見ればロジックに影響がある変更なのかわかりやすくなった。
– 漠然と使っていても体験すればするほど理解が深まっていく。という効果を実感してきました。
ただライブラリ開発とWeb開発の違いから補足したところや2,3年使ってみて理解が進んだ部分があったのでそれらも一緒にまとめてみます。## prefix付きコメントについて
コメント例
`feat: Validation種類追加のためValidator追加`やってることはこのように prefixは `feat:` の部分で内容に合うものを付けてからコメントを書くようにするだけです。
元は Angular.js でのcommit format 内の `
` 部分で他
git pushできない。エラー：remote: Permission to [ユーザ名]/[プロジェクト名].git denied to [ユーザー名]. fatal: unable to access ‘https://github.com/[ユーザー名]/[プロジェクト名].git/’: The requested URL returned error: 403
git push -u origin main
で下記のエラーが発生。remote: Permission to [ユーザ名]/[プロジェクト名].git denied to [ユーザー名].
fatal: unable to access ‘https://github.com/[ユーザー名]/[プロジェクト名].git/’: The requested URL returned error: 403解決策：アクセストークンの発行画面でrepoにチェックが入っていなかった。
gitのコミットメッセージをかわいく＆分かりやすくしたい?
## gitのコミットメッセージ?
皆さんgitつかってますか！？
開発者だと、gitにコミットすることは多々あると思いますが、コミットメッセージのルールをチームで定めたので、さらーっと書いてみます！
少しでもみなさんの参考になればうれしいです！## 自分たちのコミットメッセージのルール
[Emojis] [Prefix] [バージョン] [issue 番号] [コミットの内容]
例) ✨ add v0.1 #100 △△機能の○○する処理を追加
それぞれどんなルールなのか、ちょっと詳細にかいてみます。
### 目次
* [Emojis](#emoji)
* [Prefix](#prefix)
* [バージョン](#バージョン)
* [issue 番号](#issue番号)
* [コミットの内容](#コミットの内容)## Emoji
絵文字は一目見ただけでどんな修正をしたのかを把握することができます。
?だったら、バグ直したんだな～～とか、
?だったら、なんかのドキュメント追加か更新したんだな～となります。あとなんといっても、、コミットのログがカラフルでかわ
Vimで快適なgit生活を送る
# はじめに
gitを使いソフトウェアを管理することは多いです。
今回はVimに依存することで、git生活をより快適に送るTipsを紹介します。## 1. git commit実行時のテンプレートにprefixを追加する
commitメッセージを書く際にprefixを先頭に書くことは多いです。
よく使うprefixなら、commitメッセージを書くときに逐一確認できる環境を作りたいですよね。
gitコマンドを使うことで、git commitを実行した際に特定の文字列をテンプレートとして挿入できます。
コミットメッセージの書き方自体は、以下の記事を参考にしました。
> https://qiita.com/konatsu_p/items/dfe199ebe3a7d2010b3e
“`txt
# feat: A new feature
# fix
