GitHubのWebhook活用
2017年7月からGMOアドマーケティングのSSP開発チームにJoinしたKA.Mです。 先日、試用期間も無事終え落ち着きました。 GMOアドパートナーズグループには、住宅補助手当という オフィスビル近隣に住んでいる人が対象となる福利厚生があるので、 そろそろオフィスビル近くに引越かと考えています。 早速本題です。 Webhookってなに? Webhookとは特定の条件を満たした際に他のアプリケーション/URLへリクエストする仕組みとなります。 SSP開発チームでは今回紹介するGitHubの他にSlackのWebhookも活用しています。 活用事例 SSP開発チームはGitHubのレビュー機能を利用したGitHubフローで開発しています。 Pull Request = レビュー依頼ではないため、レビュー依頼はラベル機能を利用していますが、 レビューNGとなった場合、主に3つ問題がありました
よりよいGitの設定 | Yakst
.gitconfigファイルに記入するオプションをカスタマイズすれば、Gitをより上手に、便利に使うことができる。著者のGit設定の紹介と、便利な設定の解説。 私はGitが大好きで、いつでもGitを使っています。私は時々、何かについて深く調べてみたり、ドキュメントを一通り読んでみたり、設定を見直してみたりするのですが、今回はGitについてそれをやってみました。私の書いた4番目の技術スタックの改善に関する記事にようこそ！ Gitのすべて 私がコーディングを始めたのは、ただのファイルシステム上でコピーしていたあの辛い日々、そしてチェックアウトに排他的ロックが必要だったVisual SourceSafeを使っていた時でした。それでもその時、ソース管理のコンセプトは私にとって素晴らしいものに思えましたし、家でコーディングする時にはそういったものにアクセスできたらな、と思っていました。 その後カリフ
Google Cloud Source Repositories で作る Git リポジトリの使い方
Google Cloud Source Repositories は、プライベート Git リポジトリを簡単に作成することができる Google Cloud Platform（よく「GCP」と略されます）のサービスのひとつです。ユーザー5名、容量50GBまでなら無料で使うことができます。公開してもかまわないソースコードであればGitHubを利用するのが手軽ですが、仕事などでソースコードが公開できない場合には Google Cloud Source Repositories が活用できそうです。 そこで今回は、GCP の利用登録から、Google Cloud Source Repositories にプライベートGitリポジトリを作成して、リモートリポジトリにプッシュするまでの手順をまとめてみました。 Google Cloud Platform（GCP）の利用登録 まずはじめに Google
Gitをソースからビルドしてインストールする方法 - TASK NOTES
Git をソースからビルドしてインストールする方法です。 ダウンロード ソースファイルは GitHub 上のリポジトリか Kernel.org からダウンロードします。 $ curl -LO https://www.kernel.org/pub/software/scm/git/git-2.12.2.tar.gz $ tar zxvf git-2.12.2.tar.gz $ cd git-2.12.2/ GitHub - git/git: Git Source Code Mirror Git source repository コンパイルとインストール Git公式の手順は以下の通りですが、Makefile はリポジトリに含まれてるためmake all && sudo make prefix=/usr/local installのみでも大丈夫です。依存ライブラリを先にインストールしてください
個人開発環境にGithub Flowを適用する - chroju.dev
Github、joinしたのは2013年で作ったものは軒並みちゃんと突っ込んではいるんだけど、単に一区切りついたらadd => commit => pushしているだけでちゃんと使っていなかったので、個人開発ではあるがGithub Flowを取り入れてみた。 What is Github flow ? Githubを用いた開発作業を進めるにあたっての指針みたいなものです。基本的にはmasterブランチ上では作業せず、作業工程ごとにブランチ作って、終わったらプルリクしてmasterにマージしてもらうことでデプロイとしましょうね、というものだと理解している。至ってシンプルではあるけど、これを取り入れるだけで従来やっちゃってた「masterで作業してるのでデプロイしても動かないレポジトリがGithub上にある」みたいな状態が防げて良さそうだと思った。 ちなみにGit-flowというのもあるようだ
Gitリポジトリをメンテナンスして軽量化する - Qiita
この記事はGit Advent Calendar 2015の8日目の記事です。 Gitリポジトリのメンテ？ Gitリポジトリにあるファイルは .git がバージョン管理をしています。 今回はその .git をメンテナンスする話です。 はじめに リポジトリに容量の大きいファイルをコミットしてしまった git clone がやたらと時間がかかる（知らない間に容量の大きいファイルがコミットされている可能性がある） 複数あるリポジトリを統合したい こんな悩みを持ったことはないでしょうか。大型のプロジェクトでないと発生しないと思うので、個人プロジェクトではなかなか遭遇することはないでしょう。 今回は上記を解消するための リポジトリメンテナンス方法 をご紹介します。 !! 注意 !! Gitリポジトリのメンテナンスは破壊的なため、Gitのコマンドを理解している方のみ行ってください。 この記事を読んで実
よいコミットメッセージ・よくないコミットメッセージ - 弥生開発者ブログ
こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の
ソースコード管理(git)の説明資料を作るのに gitgraph.js を使ってみた - Qiita
ある程度大きな(人数的にも、ツール等の依存環境的にも)プロジェクトになってくると、気づかないうちにソースコード管理に属人的なファクターが生まれるもので、そういうのをドキュメント化するのにそこらに転がっているgit-flowの絵とかでは説明しきれない場合があります。 というかありました。 なにかないかなーと彷徨っていた時に、jsでサクッとコードを書くとgitのヒストリーの図を出せるライブラリがあったので、これを使って資料作ったら捗ったので紹介します。 gitgraph.js http://gitgraphjs.com/ とりあえず図がほしいだけなので適当な下準備 gitgraph.js はnpm/bowerだけでなくCDNにも上がっているので、ペライチでHTML書いて、使う準備をします。 js/cssをロードします bodyにcanvasを用意します jsの <html> <head> <s
リファクタリング時のデザインパターン、PHP開発者向けのgit hook管理ツール・静的解析ツール〜ドイツのPHPカンファレンスレポート 3日目 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは！ドイツの美味しいご飯に思いを馳せている、ぐるなびエンジニアの宮原です。 2016年10月末に、海外出張としてドイツ・ミュンヘンで開催されたInternational PHP Conferenceに同僚1人と行ってきました。ホテルの朝食も、レストランの食事も、カンファレンス会場でのご飯も、みんなとても美味しかったです！ 前回に引き続き、3日目のセッションを紹介していきます！今回は、（ちょっぴりPHP開発者に特化した）git、静的解析、リファクタリングとデザインパターンの話が出てきます。 （1日目、2日目の様子もレポートにしています） セッション紹介（3日目） Mastering git GitのTips系のお話や、PHP開発者向けのgit hook libraryであるCaptainHookの紹介。スピーカーは@movetodevnullさん。 CaptainHookは@move
難しいGitコマンドは、仕組みから理解してみよう - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こちらはLife is Tech ! Advent Calendar 2016 22日目の記事です。 自己紹介 こんにちは！先日GitHubのIDがha1fha1fからha1fになりました、はるふ(@_ha1f)と申します。 Life is Tech ! では、主にiPhoneコースのメンター・講師をしています。 本記事について Gitについての記事は、世の中に多くあります。 gitコマンドの使い方 gitの仕組み gitを用いたプロジェクト管理・運用 subversionなどとの比較・歴史 など、テーマが色々有ると思いますが、本記事で
【古い情報です】 pull は本当に fetch + merge なの？ - Qiita
※ 【追記】もうだいぶ古い情報です。 Git の pull は fetch + merge と同じというのをよく目にしますが、自分の中では違う気がしていて混乱しているので整理してみます。 認識が誤っている点などがございましたら、ご指摘いただければ幸いです。 3種類のブランチ この記事では Git の 3 種類のブランチを以下のように表現します。 リモートブランチ トラッキングブランチ ローカルブランチ リモートブランチ リモートのリポジトリで定義されているブランチのことを指します。 トラッキングブランチ リモートブランチを追跡するローカルリポジトリで定義されているブランチを指します。 ローカルブランチ ブランチを切ったり、コミットなどをしていく実際に作業をするローカルリポジトリで定義されているブランチを指します。 これらを図にすると以下のような感じです。 fetch + merge の挙動
【GitHub】1年以内に作成された人気リポジトリ20個をまとめました | HRナビ by リクルート
コードレビューや情報収集など、エンジニアの開発シーンに欠かせないGitHub。 技術者の興味関心や開発トレンドが詰まったサービスなので注目が集まることも多々。今年に入ってからはFreeCoodCampの総スター数が、長年トップだったbootstrapを上回ったことが話題になっています。 今回は、2015年9月30日〜2016年9月30日に作成されたリポジトリのなかでスター数が多いリポジトリ上位20個を集めました。 本稿のスター数、フォーク数は2016年9月30日9時現在の数値、メイン言語にはリポジトリ内の上位2言語を表示しています。 スター数が多い上位20リポジトリ 第1位：swift 2015年12月にオープンソース化したSwiftがスター数トップに。2016年9月13日にはSwift3.0がリリースされている。
すぐ忘れる！SourceTreeを使ったリベースとスカッシュの手順 - Qiita
Git操作をGUIで行えるSourceTreeは、私にとって今では無くてはならない存在です。 コレのお陰で、ターミナル恐怖症のデザイナーさんにもGitでファイルの変更を管理してもらえるようになって、デザイナーさんとの連携がとても楽になりました。 もう、これなしでは開発したくないと思えるほど便利です。 でもSourceTreeのいくつかの機能はお世辞にも直感的とは言えず、間違った操作を誘発する危険性をはらんでいます。私もハマって結構大変な目に会いました。 私が、そして私のような方が同じ過ちをおかさないように、ここにハマりそうなSourceTree操作を記録しておきます。 リベース手順 例えば、developブランチから分岐したfeature/hogeブランチで作業している途中で、他の開発者のコミットがdevelopブランチにマージされた場合、後々大きなコンフリクトが発生するのが怖いので、早め
Gitでsubtree mergeによるライブラリ管理
※ これから新規に外部ライブラリの管理をする場合は、 Git のバージョンが1.7.11以降である必要がありますが、 Git subtree のほうがお勧めです。 背景 Git では外部ライブラリ（これまた Git で管理されている）を取り込む仕組みとして、 submodule が用意されています。たんなるソースのスナップショットをコピーして置いておくのに比べると、外部ライブラリのバージョンアップに追随できるという利点があります。しかし、 submodule は運用上の問題をいくつか抱えています。 1. git clone した直後に git submodule update をしなくてはならない リポジトリをクローンしてすぐにコードをいじり始めたくても、余計なひと手間が必要になります。 GUI クライアントの中には、この作業を忘れないように通知してくれるものもあります。 2. 外部ライブ
Git subtreeによるライブラリ管理について
前回は Git subtree merge について説明しましたが、今回はそれに深い関係がある Git subtree コマンドについての説明です。 まず基本的なこととして、 Git subtree は Git subtree merge と同じものではありません。 subtree merge はマージ戦略として subtree を指定したマージにすぎませんが、 Git subtree は明確に外部ライブラリの取り込みと submodule の代替を目的として設計された機能です。 Git 1.7.11 以降であれば、 Git subtree を使用するのが望ましいでしょう。 なぜなら、 Git subtree には、 Git subtree merge にはない、下記のような機能があるからです。 取り込んだライブラリ側の歴史を"潰し"(squash)てコンパクトな歴史にできる。 自分のプロ
gitignoreまとめ - maeharinの日記
Gitで無視ファイルを細かく設定する際にはまったので、メモ ヘルプ こまったら、これで $ man gitignore web版 前提 まずは前提を抑えておかないと、はまる 既にトラックされたファイルはgitignoreが効かない $ git init $ touch hoge.txt $ git add hoge.txt # トラックされた後に $ vim .gitignore # 無視設定しても hoge.txt $ git status # 効かない 既にトラックされたファイルを無視対象にしたければ、git rm --cached $ git rm --cached hoge.txt # 上記のトラックされたファイルをインデックスから削除すれば（ワークツリーはそのまま） $ git status #gitignoreが効く # もしhoge.txtをcommit済みの場合 $ git
gitコマンド 備忘録 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに タイトル通り、「あれって何だったっけな？」の時のための自分用メモ。 記載コマンドは -help した時の表記となるべく同じようになるように記述しておく。 更新は随時行っていく。 ブランチ操作 リモートブランチを作成/更新 チェックアウト中のローカルブランチをそのままpushする場合 git push <repository> <refspec> リモートブランチを指定してpushする場合 git push <repository> <localbranch>:<remotebranch> ローカルブランチの作成 ブランチを作成
Git: バージョン管理の対象から外したいファイルを「.gitignore」に記述する - すたらブログ
最終更新: 2017年4月8日 目次 「.gitignore」の基本 すでにGitの管理下にあるものを除外したい 除外指定に該当するものを確認する 「.gitignore」の基本 キャッシュファイルなど、バージョン管理の対象から外したいファイルは.gitignoreに記述します。 .gitignoreを設置した階層からそれ以降の階層にかけて有効になります。 (.gitignoreの記述例) # 「.AppleDouble」フォルダを除外 .AppleDouble/ # 「.DS_Store」や「._.DS_Store」を除外 *.DS_Store # あらゆる階層の「cache」フォルダの中身だけを除外。 # 「cache」フォルダ自体は無視しない。 # 詳しくは下記のリンクを。 **/cache/* !.gitkeep 公式: https://git-scm.com/docs/gitig
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitでローカルの共通ライブラリを異なるgitリポジトリで同時に利用する方法（Windows環境）
git の監視から逃れる方法 - Qiita
