pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
Version Badge provides a consistent way for the community to learn about the package associated with a particular Github repository and other documentation pages. Once the package owner adds this badge to their README file, it will inform and link all visitors to the latest version of that package. If you have any questions, problems, or suggestions please don't hesitate to let us know.
先日とある方と開発ワークフローについてお話していて初めて知ったのですがgit-commitには--allow-emptyという空の(親コミットと差分がない)コミットを作成できるらしいですね。 僕が今関わっているプロジェクトでは WIP PR を用いたワークフローを取り入れているのですが、このgit commit --allow-emptyを用いるともう一段階快適なワークフローになるかと思ったのでメモがてら書き留めておきます。 WIP PR って何? Work In Progress Pull Request の略です。 Github に Pull Request (以下、PR と表記)という機能があるのは皆さんご存知だと思います(知らない方はググってください)し、業務で取り入れている方も多いと思いますが、それを作業途中の状態で出すことを WIP PR と呼びます。 作業途中のトピックブラン
概要 Slack / Hubot / GitHub / CircleCI などをつかってChatOpsにチーム開発できるフローをつくったので、ChatOpsによるデプロイ方法を中心にその方法をまとめてみます。 ChatOpsの主役であるチャットアプリには今回Slackを使いました。 HipChatでも同じように出来ますが、Slackの方がUIが優れていており、外部サービスとの連携も洗練されていたのでこちらを選択しました。 ChatOpsな環境の概要 SlackとHubot(PaaSであるheroku上にデプロイ)を連携させる SlackからHubot経由でGitHubにプルリクエストをつくる GitHub上の変更を監視し、CircleCIでテストを実施 デプロイ用のブランチに変更があった場合(GitHubのWEBコンソールでデプロイ用ブランチへのプルリクエストをマージした場合)、Circl
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
これはGit Advent Calendar / Jun.20日目の記事です。前回は、fukajunさんの変更を一時的に退避!キメろgit stashでした。 この記事ではgithubでpull requestを送る時に私が気をつけていることを共有したいと思います。 私が気をつけていることは次の3つです。 masterにコミットしない 簡潔なコミットメッセージを書く コミットを1つにまとめる この話の前提 以降では、次の2つのリモートリポジトリが登録されている前提で説明します。 upstream: fork元のリポジトリ origin: upstreamからforkされた自分のリポジトリ masterにコミットしない 修正作業は必ず新しいブランチを作ってから行ない、masterブランチはあくまでupstreamの更新を取り込むためだけに使って下さい。 このルールを守らないでpull req
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
About pull requests A pull request is a proposal to merge a set of changes from one branch into another. In a pull request, collaborators can review and discuss the proposed set of changes before they integrate the changes into the main codebase. Pull requests display the differences, or diffs, between the content in the source branch and the content in the target branch. Note: When working with p
タグの付け方については、この記事の最後の方でちょろっと書いたけど、間違って付けちゃったりしたタグを消す方法がわからなくて調べたのでメモ。 前提 こうやって付けたタグを消したい場合の話。 $ git tag -a 0.2 -m 'hogehoge' $ git push --tags タグの消し方 git tagに-dオプションを付けて消した上で、GitHubのクローン用アドレスに向かってpushすると消せるみたい。 $ git tag -d 0.2 $ git push git@github.com:ruedap/hello-github.git :0.2 git remoteにoriginとしてGitHubが登録されているなら、わざわざアドレスを打たずにoriginでいける。 $ git remote heroku origin $ git tag -d 0.2 $ git push o
何か? git commitのオプション--allow-emptyご存知でしょうか? これは、オプションの名前の通り空のコミットの作成を許可するオプションです。 通常変更がないとコミットが作れないようになってるので 空コミットを作るにはこのオプションを指定する必要があります。 add(もしくはrm)もしない(stageに何も載せない)で commitしたときの注意文には登場するので知ってましたが使ってませんでした。 最近、開発フローの中で使い道を思いついて使うようになったので紹介です。 その1 空Pull Request作れる プルリクって、基準になるブランチから変更されたコミットがないと作れないと思ってます。 でも、変更はないんだけどプルリクのcommentに変更の「概要」「目的」「ビジネスインパクト」「どの数値が改善するのか」など色々さきに書いておきたいこととかありますね。 考えてる内
GitHubなどに自分のツールやライブラリを公開するとき,README.mdは重要な役割を担っている.レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている,と言っても過言ではない.実際自分が使う側になったときも,まずREADME.mdを読んで判断していると思う. 成功しているプロジェクトを参考にしつつ,自分が実践していることをまとめておく.ここに書いていることはあくまで(自分の中で)最低限的なものである.プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う. READMEの役割 README.mdには大きく2つの役割がある. プロジェクト,ツールの使い方,インストール方法 プロジェクト,ツールの宣伝 元々READMEは前者の役割しかなかったが,GitHubの仕組み上,後者の役割も徐々に重要になっている. さらに
http://ianfeather.co.uk/css-at-lonely-planet/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約5時間前 CSS STATSが話題になったからでしょうか、自社のCSSの構成を分析して、記述方針について紹介するポストが続いています。 1) Lonely Planet Lonely Planetは旅行サイトらしく、写真/動画満載の構成です。 Quick Facts Sass Indented Syntax 150+ソースファイル キャッシュを考慮してコンパイルしたCSSは二つのスタイルシートに CSSはページ当たり35kb (gzip) 基本的には、remとpixelでサイズ指定。一部 em あり。 Preprocessor Railsを使っているが、Sprocketsは
# masterブランチに移動 git checkout master # masterブランチを最新にする git pull origin master # 新しい作業ブランチを作成 git checkout -b new_branch # 空コミットを作る git commit --allow-empty -m "[WIP] 今回開発する内容を書く" # push git push origin new_branch この後、Githubの画面に行ってpull requestを送ります。 2.タスクを洗い出す Githubのプルリクエストにタスクを積みましょう。 下記のようにコメントすればチェックリストが作れます。
Let's talk about GitHub Pages; what they are and how you can use the service in minutes to deploy static pages for free. Let's get started! What it is According to GitHub, GitHub Pages are: ... public webpages freely hosted and easily published through our site. What does this mean to you? It means free, reliable hosting of static content. In general, this was created by GitHub to support open-sou
GitHubには Releases という機能があります。 Release Your Software Creating Releases · GitHub Help GitHubのリリース機能を使う - Qiita 簡単に言えば、gitのtagやbranchに文章や添付ファイルを追加して公開出来るページです。 基本的にはgit tagと連携してるので、tagを付けてgit push --tagsをしていれば、自動的に追加されます。 メリットとしては以下のような事が行えます。 git tagにパーマネントリンクがつく(重要!) メッセージ(リリースノート等)が書ける 添付ファイル(zip)をアップロード出来る(配布するバイナリとか) RSS Feedsが自動的に生成される(TagとReleaseの2種類がある) ライブラリ等にtagがついてると利用しやすい。 git tagとGitHub
昨年のFrontrend/06では、全くもってながら個人的な趣向のもと継続インテグレーション(CI:Continuous Integration)をテーマに開催した。もはや、フロントエンドとは!という感じだが、非常に良いイベントだったと思う。 基本的に昨今のフロントエンドは膨大なタスクに追われている、そのようなタスクを手動でちまちまやっていては手戻りやミスなど必ず発生するので自動化すべきである。フロントエンドの自動化はGruntなどがあるが、結局フロントだけで問題を解決しようとすると問題(限界)があったりするので、CIサーバーとか使ったほうがいいよね。てかフロントエンドの人も慣れておいたほうがいいよねって話。 しかし、フロントエンドの人がいちからJenkinsを立ち上げたりするのもさほど面倒でもないが多少の心理的障壁があるので、もっとカジュアルに利用したい。 Frontend/06の佐竹さ
ProductIntroducing a simpler, faster GitHub for MacFollowing the recent release of GitHub for Windows 2.0, we’ve been working hard to bring our two desktop apps closer together. We’ve just shipped a significant new update to GitHub… Following the recent release of GitHub for Windows 2.0, we’ve been working hard to bring our two desktop apps closer together. We’ve just shipped a significant new upd
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く