dfltweb1.onamae.com – このドメインはお名前.comで取得されています。このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.
GitHub Issueはテンプレート化で、綺麗に書かせる！ - Qiita
まず、クリックしてみてください Issue作成はこちら GitHubのIssueは、URLにparamsを渡すことで、デフォルトのvalueが入れられます。 ※paramsの渡し方は、/issues/new?title=test&body=contentのようにします。 バグ報告はこちらとかアイディア投稿などのリンクをREADMEなどに置き、みんなそれに従ってIssueを作成してもらいましょう。 指定できるparams 指定できるパラメーターは以下です。 params一覧 title body assignee labels milestone ※ラベル、マイルストーンはcontributorsのみ使用可能 文字列のエスケープ URLに入力するので、改行コードなどをエスケープする必要があります。 文字 エスケープ後
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
俺聞け6行ってきました、あとGitHubとかTestFlightとかHubotを使った開発について発表しました - ローファイ日記
俺聞け6 in Tokyo と言うイヴェントに行ってきたのでシェアします。発表もしてきて、なんだかんだAimingで最近やってるような感じの内容を紹介しました。 クラスタがかぶらない気がしていたのですが、結局けっこう知り合いがいたのでボッチは回避できました...。 皆さん発表が上手だったのでぼくは壇上でビールを飲む他なかったです。先駆者のsendさんありがとうございました。 実はこういうテクニカルじゃない会合に行くことがほとんどなかったので、新鮮で楽しかったです。機会をくださったmsngさんに感謝。 GitHub とデザイナーさん、プランナーさんについて 社内でこの内容を再演したところ「この発表ではまだデザイナーやプランナーがGitHubを使うメリットが分かりにくい」と言われたりもしたのでもう少し具体的にフローを説明すると、 プランナさんがマスタデータをいじる→プログラマが足りないところを
初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
Introducing split diffs
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
PSD Viewing & Diffing
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
GitHubが僕たちを、仕事の現場を変えた！──「GitHub Kaigi」レポート | gihyo.jp
2014年6月1日（日）、東京・渋谷マークシティにおいて、GitHubユーザグループ主催によるイベント「GitHub Kaigi」が開催されました。500人の定員に対し800人を超える参加申し込みのあったこのイベントには、日本におけるGitHub活用の第一人者たちはもちろん、米GitHub社から招いた開発者たちも登壇し、いずれ劣らぬ濃いセッションが繰り広げられました。ここではその様子を紹介します。 GitHub実践入門 ── Pull Requestによる開発の変革 トップバッターとして登壇したのは、WEB+DB PRESS plusシリーズ『GitHub実践入門 ── Pull Requestによる開発の変革』の著者である大塚弘記氏です。 『GitHub実践入門』の著者、大塚弘記氏 同氏はまず、「GitHubを利用した開発の世界を知る」「GitHubを（利用｜活用）する違いを
個人のリポジトリレベルの開発の話をしよう - ローファイ日記
最近、個人のリポジトリレベルの開発でも、自分のためのIssueを立て、自分しか見ないPull Requestを作ったりしている。 docker-registry をインストールするぞ〜 · Issue #1 · udzura/docker-playroom · GitHub Install Ruby recipe by udzura · Pull Request #3 · udzura/docker-playroom · GitHub First version of ikachan module by udzura · Pull Request #1 · udzura/ikachan-node · GitHub この際気を付けていることとして： Issue、最初のdescriptionは最初のTODOへのポインタだけ書いておく プルリクエストは 生煮え の状態で出す 思ったこと、詰まった
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば 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 と連携するこ
非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog
前提: GitHub flow を使っていてCIサーバーはJenkins 最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。 この改善をやる前の悩み: pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。 コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。 コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-req
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Adtech College#7 GitHubを中心とした開発フロー
GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。
エンジニア×デザイナー GitHubで変わるコミュニケーション（PHPカンファレンス2014 P4Dセッション）
Developer-first Project Management for Teams on GitHub | Waffle.io
はてなブログチームの開発フローとGitHub
Git・GitHubに隠された便利な機能 | GitHub Cheat Sheet（日本語訳） - Qiita
https://github.com/hail2u/github-cheat-sheet/blob/master/README.ja.md
