Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報（sensitive data）について調査を実施し、対応

オンライン診療とは、自宅にいながら医師に直接毎日のスキンケアを相談したり、医薬品や漢方薬の処方を受けることができたりする診察のこと。お薬が処方された場合は郵送で薬局等にお薬を取りにいかなくても、自宅に届けられます。 普段、病院では発生する診察費用や処方箋費用はもちろん、お薬代以外の費用は一切かかりません。

はじめに Gitをそこそこ使いこなすにあたって必要な基礎知識やコマンドをまとめました。 Gitは少しかじったけど挫折したくらいの人が対象レベルになるかと思います。 当方、Subversionをまともに触ったことないゆとり世代なので集中管理型との違いとかはよく分かりません。 一部諸事情のため、XXXXXで情報を隠蔽しています。 この記事長いです。。。 Gitとは 分散型バージョン管理システム。 今時ソースコードなどをバージョン管理するってなったらGitを使うことになるでしょう。 GitHub(Enterprise含む)とかGitLabとかGitBucketとかBitBucketとかGitのサービスは複数ありますが、どれを使うかはチーム事情や会社事情などから決まる。 ローカルにリモートリポジトリの複製を作成するため、複数人が各々のローカルで変更履歴を利用して自由にファイルの編集やローカルコミッ

こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ

論理性の高い commit を作る方法 git rebase -i コマンドを活用する。 rebase -i を使用することで commit の 結合/分割/書き換え/順序入れ替え が可能。 以下では一番使うであろう結合(squash)について紹介します。 $ git log --oneline bfc2a57 (HEAD -> master) TOP画面の実装 e84e22e エラーメッセージのtypo修正 ba76419 エラーメッセージの追加 こんな感じの commit log があったとします。 よくありがちなケースだと思いますが typo修正だけのコミットなんてまとめてしまいたいですよね。 そこで git rebase -i の出番です。 $ git rebase -i HEAD~3 # HEAD は @ とも書ける、便利 $ git rebase -i @~3 上のコマンドでH

Rails Developers Meetup 2018: day 1 (https://techplay.jp/event/639872)

0. はじめに 業務で技術指導を行うにあたり、Git、GitHubについて説明する機会が多くなってきました。そこで、そんな時に使えそうな資料を整理してみました。 今後も新しい資料を見つけたら、随時更新していきたいと思います。またおすすめがあれば、是非ご紹介ください。 0.1. 読者対象 本記事の対象は、以下の様な方々です。 Git、GitHubの使い方について、他のメンバーに説明、指導する必要がある。 Git、GitHubの使い方について自習したい。 本記事にて紹介する資料は、以下の様な方々を想定して選別しています。 コンソールの操作にはある程度慣れている。 Subversionなど、他のバージョン管理システムの使用経験がない。 1. インタラクティブなチュートリアル Webブラウザ上で動作するインタラクティブ（対話的）な教材です。gitコマンドなどの環境構築は不要で、環境を破壊してしまう

こんにちはー！こねひとちほーのえんじにあのフレンズ@Utmrerだよー！ 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…？ タイトルにIssue Idを含めてもらえますか？ WIPみたいなんですがレビューして大丈夫ですか？ Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F

サーバレス（Walter + GitHook）で成果物を Nexus Repository (Maven Central) に自動登録するJavaMavenGitwalter この投稿は @takahi-i が投稿したブログ記事、 Automatic Java Artifacts Upload to Nexus Repository with Walter and Git Hooksの日本語訳です。 TL;DR Maven リリースプラグインの対話的な処理はミスが起こりやすくて辛い Walter を使って Nexus Repository （Maven　Central） への登録を自動化 GitHook　を利用してバージョンアップするコミットをしたときに自動でリリース処理が走るように拡張（Jenkins や Tranvis などのサービスが必要ない） Maven release プラグイン

これまで使っていた会社のSubversionをGitへ移行した時の備忘録。 移行の際、リポジトリの分割作業も行ったので合わせてまとめる。補足情報は箇条書きで記載している。 SVNからの移行は、GitにSVN連携用のgit svnコマンドが用意されている。基本的な流れは以下。 git svn initでSVNと連携したGitのリモートリポジトリを作成。 git svn fetchでSVNからデータを取り出し。 途中Warrningで処理がストップした場合は、git pruneの後に再度git svn fetchで再開する。 全てfetchし終えたら、git gc --aggressiveでガーベジコレクトする。 まずは、initとfetchから。

一通り最低限必要なコマンドは覚えました。 普通にコミットしてrebaseやmergeを行ってプルリクを出すことが出来ます。 誤コミットをreset HEAD^で取り消すことも出来ます。 でも、commit --amendやrebaseで誤コミットしてしまってパニック！！ そんなあなた(ちょっと前の自分)に必要な知識をまとめました。 コミットしたものは消えない そう、消えないのです。 たとえ、git commit --amend やら、git rebase で既存のコミットを編集しても、 編集前のコミットがそのまんまの状態で残っているんです。 どういうことかというと。 コミットが、A -> B ->C と行われた状態から、 Cに対して git commit --amend すると、 このように新しいコミットC'が作られブランチが付け替えられているだけなのです。 なので、ブランチの情報を元のC

空のディレクトリをコミットに含めたいときは、2つのやり方があります。.gitkeep を使う方法 と、 .gitignore をおいておく方法（例えばPHPのフレームワーク Laravel で用いられている方法）です。 空のディレクトリを保持する目的で使用する .gitignore は、たいていの場合、以下のような内容になっています。 使い分けの基準 .gitkeep と .gitignore は、「空のディレクトリにファイルが追加されたときに、そのファイルを Git での管理対象に含めたいか？」という基準で、使い分けられます。 含めたい場合は .gitkeep 、含めたくない場合は .gitignore を使います。 .gitkeep を使う基準と例 .gitkeepは、「デフォルトではファイルが存在しないけれど、ファイルが追加されたら、そのファイルを Git での管理対象にしたい」場合

Git Advent Calendar / Jun. 最終日(30日目)の記事です．29日目は「いざという時のためのgit reflog」でした． Git Advent Calendar最後なので，git操作でやりがちなミスからどう回復するかをまとめます．他にもあればコメントもらえるとマージしていきます． ブランチを切り忘れてmasterでコミットしてしまった その時点でブランチを切る&reset --hardで間違ったコミットたちをmasterから消す $ git checkout -b new-branch # masterの最新コミットを消す $ git checkout master && git reset --hard HEAD~

皆さんこんにちは. 現在はfluctにてfluct DRという広告配信システムの開発を行っております, 大関です. GitHub上でのチーム開発では, レビューの依頼や, CIが通ったことを確認した上でのPull Requestのマージといった複数の作業が発生しますが, これらはGitHubのUIを複数回クリックする必要があり, 非常にストレスフルな作業です. 本稿では, こうした定形作業を自動化するbotとしてpopukoを開発・導入することで, 我々開発者のストレスを軽減するとともに, より堅牢かつフィードバックの多い開発が実施できるようになった事例を紹介します. GitHubでの開発はとてもクリック操作が多い 前段でも述べたように, GitHubを用いたチーム開発においては, 数多くの定形作業が存在します. コードレビューの可能な人を探してレビューを依頼する, 依頼の度に対象者をAs

はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu

※本稿は諸事情により過去の投稿を再投稿したものです。 はじめに git-svn を使うと、素直な SVN リポジトリーなら簡単に移行できますが、実運用してきた SVN リポジトリーを移行する際はつまづくことも多々あります。 また Git リポジトリー化ができてもブランチやタグは手作業で作ることになります。 今回、たまたま移行を検討する機会があったので、その予行作業のなかで得た知識をメモしておきます。 作業を行ったクライアント環境は Ubuntu 14.04 / Git 1.9.3 です。 SVN リポジトリーは HTTPS でアクセスできる状態です。 移行の第一歩 まずは SVN リポジトリーからローカル環境に Git リポジトリーを作成します。 git svn clone または git svn init + git svn fetch を使います。 ヘルプや Book にも記載されてい

こんにちは、GUIは甘えだと信じて疑わないフロントエンド、じぇしーです。 皆さん、gitはもちろんCUIで使ってますよね。OSに依存しない統一したインターフェースが提供されていたり、他のコマンドと組み合わせることが容易であるなど、様々なメリットがあるCUIですが、初期状態ではtabによるコマンドの補完が効かないのが玉に傷です。特にブランチを指定した操作をする時が辛いです。 そうは言っても、個人開発のユーティリティやサードパーティではサポートに不安があります……。 そこで、今回は公式ドキュメントでも紹介されているgit-completionを導入して、コマンドやブランチ名を補完できるように設定しましょう。

ローカルリポジトリの作成 初期化して、現在あるファイルを追加して、コミットすればOK ファイルがなければgit initのみでOK

git では通常、リポジトリと作業ディレクトリとが一組になっています。git clone をすると、作業ディレクトリの中に .git ディレクトリ（＝リポジトリ）が作成されます。 そして、この作業ディレクトリの中でブランチを切り替えて作業するのが一般的かと思います。 さて、作業ディレクトリの中で何かの作業中に、別の割り込み作業が発生して、一時的にブランチを切り替えたくなったとしましょう。そんなときは、いったん現在のブランチに作業中の変更をコミットしておいてからブランチを切り替えたり、作業中の変更を git stash を使って保存してからブランチを切り替えたり、という操作をすることになります。 そういった操作が簡単に素早くできるのが git の特徴ではあります。しかしそれでも、そういった切り替えが多くなってくると、作業中の変更を失ってしまったり、現在のブランチを勘違いして作業してしまったり