A interactive Git visualization tool to educate and challenge!
Learn Git Branching
A interactive Git visualization tool to educate and challenge!
Travis CIからgh-pagesへデプロイする設定 via SSH/git push
最近はGitHubリポジトリのgh-pagesブランチでサイトを公開する機会が増えているのですが、 リポジトリが更新されたら自動でサイトも更新できるようにしたいです。 以前は、GitHub Access Tokenを発行して、Travis CIのconfig(secret)にそのTokenを埋め込んで、Tokenを使ってpushをしていました。 しかし、GitHub Access Tokenは簡単に発行できるとはいえリポジトリ単位で管理できる権限となっていないため、Tokenが漏れてしまうと管理ができないという問題があります。 (実際 git push url-with-secret >/dev/null 2>&1などしないと簡単に漏れてしまう) Best Practices in Securing Your Data - Travis CI そのため、最近はSSH鍵を使ってリポジトリへp
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
GitHubで複数アカウントを使う場合のSSH configファイルの設定
Security Software GitHubで複数アカウントを使う場合のSSH configファイルの設定※当サイトにはプロモーションが含まれています。 GitHubにsshでアクセスする場合、使用する鍵ファイルをsshのconfigファイルに指定していると思います。GitHubの仕様上、複数のアカウントを使うと必然的にSSHの鍵もそれぞれ用意することになるわけですが、そうなると github.com という1つのホスト(というかドメイン)に対して複数の設定が必要になります。この設定方法についてのメモです。 これはGitHubに限った話ではなく、任意のホストに対して複数のssh鍵(やその他の設定)を使い分けることができます。 以下の状況を仮定しますアクセスするホスト(またはドメイン)github.com設定するアカウントとそれぞれの鍵ファイルへのパスfoo アカウント~/.ssh/gi
View Issue/Pull Request buttons for Gmail
ProductView Issue/Pull Request buttons for GmailIf you're a Gmail user who gets GitHub notifications via email, you'll notice that we've added subject-line links to issues and pull requests on notification messages. You can use these… If you’re a Gmail user who gets GitHub notifications via email, you’ll notice that we’ve added subject-line links to issues and pull requests on notification message
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
ローカルで作ったリポジトリをgithubに初めてpushする方法 2013-05-05 - 未来のいつか/hyoshiokの日記
例えば以下のようにローカルにgitで管理していて、ふとgithubあたりで公開したくなったとする。はじめからgithubにレポジトリを持っていた場合は、それを $ git clone して、ローカルでごにょごにょして $ git push すればいいのだけど、その順番が逆の場合。 $ git init $ git add . $ git commit -m "initial commit" ... ここで、あー、githubにpushしたいなーとふと思う。 おもむろにgithubにsign inしてrepositoryをnewする。仮にユーザ名がuser-nameでリポジトリがrepositoryというのを作ったすると、ローカルからのpushは下記のような感じになる。 $ git remote add origin git@github.com:user-name/repository 最
Jenkinsを使ったiOSアプリビルド自動化11 GitHubとJenkinsの連携 – なんてこったい
Hookの機構を使うと、GitHubに変更がプッシュされたタイミングで自動的にJenkinsのジョブが走るようにすることができます。ポーリングに比べて、プッシュからビルドまでの時差が減り、無駄な通信も減りますが、アクセス制御が有効になっている場合の設定で少しはまってしまったので方法を書いておきます。 Hookをトリガーにしたビルド Gitには、コミット直前やプッシュ完了時など、任意のタイミングでスクリプトを実行できるHookという機構があります。この機構を利用すると、レポジトリに変更がプッシュされたタイミングでJenkinsのジョブを実行させることができます。 GitHubの場合は、レポジトリのAdmin -> Service Hooksページ内でHookの設定ができます。幸い、Jenkinsと連携させるための項目が最初から用意されています。ここでJenkins内のジョブ実行用のURLを指
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
