概要 コミットメッセージの内容を揃えることを目的にGitのコミットメッセージテンプレートを作成し登録します。 そうすることでコミットの際に「こう言うことを書けばいいんだな」と意識できます。 さらに、絵文字Prefixを使っているのであればこの絵文字はこう言う意味だよみたいなものをコミットの際に表示させることができます。 業務としてGitを使った開発をしなければ一生、目に触れることのない知識だったでしょう。 目次 概要 目次 参考サイト様 commit message templateの作成&登録 commit message templateの作成 commit message templateの登録 commit message templateを使ってcommit 雑感 参考サイト様 Git - Git Configuration Gitのコミットコメントを絵文字Prefixにして楽し
Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報(sensitive data)について調査を実施し、対応
CommunityEngineeringOpen SourceHighlights from Git 2.31The open source Git project just released Git 2.31 with features and bug fixes from 85 contributors, 23 of them new. Last time we caught up with you, Git 2.29… The open source Git project just released Git 2.31 with features and bug fixes from 85 contributors, 23 of them new. Last time we caught up with you, Git 2.29 had just been released. Tw
An interactive Git visualization tool to educate and challenge!
こんにちは、フロントエンドエキスパートチームの小林(@koba04)です。 本記事では、Lerna と Yarn Workspaces を使った Monorepo 管理について解説します。 Monorepoとは 本記事では、単一のリポジトリで複数のモジュールやパッケージ(今回の場合は npm パッケージ)を管理する手法を Monorepo と呼んでいます。 有名なところだと、Babel や Jest、Create React App などが後述する Lerna を使い複数パッケージを単一のリポジトリで管理しています。 他にも React も Lerna は使っていませんが単一リポジトリで複数パッケージを管理しています。 また、上記のようなライブラリ以外にも企業で利用している npm パッケージを Monorepo として管理している例もあります。下記は Shopify の例です。 pack
いきなりがっつりとした記事を書くよりは慣れるために軽めの話を。 こんにちは、すーです。 今回は普段僕がコードレビュ(GitHubのPull Requestのレビュー)の時に気をつけていること、大切にしていることを書いてみます。 (※以降話は主にGitHubのPullRequest(PRと略します)上での話がメインだと捉えてもらえますと) 自分がレビューをするときまずは自分がレビュワーだった場合に、気をつけていることを。 ・ PRの概要、関連するIssueの内容をしっかり読む まずはじめにPRの概要や、関連するIssueの内容を確認します。 何も見ずにいきなりコードに目をやってしまうと的外れなレビューをしてしまう可能性もありますし、コードの善し悪しだけを追いがちになってしまいます。 どういう意図や背景があってこのPRが出されたのかを確認するのはとても大事になります。 ・ コメントに`[MUS
前回の続き。 前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えてお
2014年6月1日(日)、東京・渋谷マークシティにおいて、GitHubユーザグループ主催によるイベント「GitHub Kaigi」が開催されました。500人の定員に対し800人を超える参加申し込みのあったこのイベントには、日本におけるGitHub活用の第一人者たちはもちろん、米GitHub社から招いた開発者たちも登壇し、いずれ劣らぬ濃いセッションが繰り広げられました。ここではその様子を紹介します。 GitHub実践入門 ── Pull Requestによる開発の変革 トップバッターとして登壇したのは、WEB+DB PRESS plusシリーズ『GitHub実践入門 ── Pull Requestによる開発の変革』の著者である大塚弘記氏です。 『GitHub実践入門』の著者、大塚弘記氏 同氏はまず、「GitHubを利用した開発の世界を知る」「GitHubを(利用|活用)する違いを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く