開発を爆速化！GitHub CLIで覚えるべきコマンド5選
本記事では、GitHubを使って日々システム開発している人に向けて、開発スピードを爆速化するために覚えるべきコマンドを5つほどご紹介します。 GitHub CLIとは GitHub CLIは、コマンドラインからGitHubを直接操作できるツールです。リポジトリの作成やクローン、Pull Requestの作成やマージ、Issueの管理など、GitHub上のさまざまなタスクを素早く効率的に実行できます。 インストールしていない人はこちらの記事を参考にインストールしてください。 私のGitHub CLIの活用方法 ここまでの記事を読んで「GitHub CLIを使ってあらゆる操作をシェルで完結させるのか(難しそう)」といった先読みをした人もいるかもしれません。私自身そのような崇高な使い方はできていませんし、実際にはWebブラウザでGitHubにアクセスすることも頻繁にあります。 WebブラウザでG
GitHub Copilotの全社導入とその効果 - ZOZO TECH BLOG
はじめに こんにちは、CTO/DevRelブロックの堀江（@Horie1024）です。ZOZOではGitHub Copilotを全社へ導入しました。本投稿では、GitHub Copilotの導入に際して検討した課題とその課題の解決策としてどのようなアプローチを取ったのかを紹介します。 目次 はじめに 目次 GitHub Copilotとは何か？ GitHub Copilot導入の背景と目的 導入する上での課題 セキュリティ上の懸念 ライセンス侵害のリスク GitHub Copilot for Businessの利用 導入による費用対効果 試験導入による費用対効果の見積もり 試験導入の実施 対象者の選出 アンケートの設計 試験導入の実施 アンケート結果の集計 アンケート結果の考察 費用対効果の見積もり 全社導入の判断 導入決定後のGitHub Copilot利用環境の整備 社内LT会 おまけ
コードレビューでコメントタグを使い、心理的安全性を担保しよう
こんにちは。リンクウェル対面診療システムチーム、テックリードの山本です。 今回はコードレビュー時に開発部で実施しているコメントタグのご紹介です。 多分イケてる開発チームではすでに取り組んでいる試みだとは思いつつも、今回はなぜ必要なのかを改めて考えてみたいと思います。 GitHubのプルリクレビューについて 弊社のコードレビューではまず第一に「要求を満たすよう動くこと」が重視されます。その上で次のような点に注視しながら指摘を行います。 外部サービスの特殊な挙動やセキュリティ機構などが考慮されているか。 不具合が発生した時に検知できるようになっているか。 将来的に修正しづらくなる構造になっていないか。 N+1問題などパフォーマンスに問題がないか。 その上でコメントを書く際に次のようにタグを付けて分類しています。 must: 絶対に直して欲しいとき。強い指摘になるので言葉遣いに気をつけるべき i
基本的な書き方とフォーマットの構文 - GitHub Docs
見出し 見出しを作成するには、1 つから 6 つの # シンボルを見出しのテキストの前に追加します。 使用する # の個数によって、見出しの階層レベルと書体のサイズが決まります。 # A first-level heading ## A second-level heading ### A third-level heading 2 つ以上の見出しを使用すると、GitHub では自動的に目次が生成されます。この目次には、ファイル ヘッダー内の をクリックするとアクセスできます。 各見出しのタイトルが目次に一覧表示され、タイトルをクリックして選択したセクションに移動できます。 テキストのスタイル設定 コメント フィールドと .md ファイルでは、太字、斜体、取り消し線、下付き、上付きのテキストで強調を示すことができます。 スタイル構文キーボード ショートカット例出力
SlackとGitHubを連携してissueコメントやプルリク通知をチャンネルに流す方法（2020年版） - Qiita
「Connect GitHub account」をクリック。 Web画面が開くので、対象ワークスペースを確認し「Connect GitHub account」をクリック。 これでGitHubアカウントとSlackワークスペースの接続連携が完了です。 リポジトリの購読を開始する GitHubリポジトリの通知を流したいチャンネルに移動し、以下コマンドを叩きます。 owner：オーナー名 repo：リポジトリ名 これで購読開始となります。 簡単ですね。 通知をカスタマイズする デフォルトで通知される機能は以下のとおり。 issues (イシュー) pulls (プル) statuses (ステータス) コミット deployments (デプロイメント) public (パブリック) 以下の機能はデフォルトでは通知されません。 reviews (レビュー) comments (コメント) bra
Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0 概要 Conventional Commits の仕様はコミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。 コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は SemVer と協調動作します。 コミットメッセージは次のような形にする必要があります: 原文： <type>[optional scope]: <description> [optional body] [optional footer(s)] 訳： <型>[任意 スコープ]: <タイトル> [任意 本文] [任意 フッター] あな
Github レビューでの Approve / Request Changes / Comment の使い方 - Qiita
Approveとは (…を)よいと認める、(…に)賛成する、(…を)(正式に)承認する、認可する 使い方 PRを見て「この変更でOK」って思ったら、Approveを選んでレビューを送ろう。 ( ちなみにレビューコメント0個でも Approve を送れる ) 一覧 PR ではこんな風に、Approveを付けた人が分かる。 レビュアーの誰がPRを承認していて、誰がしていないのかが分かりやすい。 Request Changes 「この状態ではPRは通せない」「修正が必要だ」と思ったら Request Changes を選んでレビューを送ろう。 Comment 承認も非承認もしない場合は、 Comment を選んでレビューを送ろう。 「Approve とか Request changesとか、運用的に使わない」って場合は、この Comment だけでOKだ。 取り消し いったん Approve /
GitHubが大変身！Web開発向けの万能ツールに変えてくれるサービスをまとめてみた！ - paiza times
どうも、まさとらん（@0310lan）です！ 今回はGitHubと連携してソースコードをさまざまな用途に活用できる便利なWebサービスを厳選してご紹介しようと思います。 特にWeb開発を便利にしてくれるサービスを中心に、GitHubだけでどこまで作業効率を向上できるのかをぜひ確認してみてください！ なお、paizaラーニングでは「Git入門編」講座を公開しています。そちらも合わせてチェックしてみてください。 ■GitHubをフル装備のクラウドIDEに変えるサービス！ 【 Gitpod 】 GitHubに置いているリポジトリのソースコードを統合型のクラウドIDEで自由に編集できるサービスが「Gitpod」です。 TheiaをベースにしたVS Codeライクなコードエディタで、豊富な機能と拡張性を備えておりプログラミングに最適なIDEの一つと言えるでしょう。 使い方は簡単で、リポジトリのページ
Github APIを使ってOAuth2を理解してみる - techium
OAuth2で認証し、Githubのデータにアクセスしてみましょう。 ライブラリなどを使うと簡単にアクセスすることはできると思いますが、その中で何をやっているかを理解するためにブラウザとcurlを使って通信し、手動で一つ一つ動作せてみましょう。 OAuthの特徴はパスワードを知ることなく特定のサービスのデータを取得や操作ができるようにできることになります。 そのためにやらないといけないこととしては次の事になります。 OAuth アプリケーションの登録 認証 アクセストークンの取得 データアクセス データへアクセスするためにはデータアクセスまでに次の情報を集める必要がああります。 Client ID Client Secret code アクセストークン これらの情報を収集することができればデータのアクセスが可能です。 それぞれのデータの取得方法についてご説明します。 OAuthアプリケーシ
Markdown記法 チートシート
markdown-cheatsheet.md Block Elements Headers 見出し 先頭に#をレベルの数だけ記述します。 # 見出し1 ## 見出し2 ### 見出し3 #### 見出し4 ##### 見出し5 ###### 見出し6 見出し1 見出し2 見出し3 見出し4 見出し5 見出し6 Block 段落 空白行を挟むことで段落となります。 段落1 (空行) 段落2 段落1 段落2 Br 改行 改行の前に半角スペース を2つ記述します。 hoge fuga(スペース2つ) piyo hoge fuga piyo Blockquotes 引用 先頭に>を記述します。ネストは>を多重に記述します。 > 引用 > 引用 >> 多重引用 引用 引用 多重引用 Code コード `バッククオート` 3つ、あるいはダッシュ~３つで囲みます。 print 'hoge' print
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
Slack / Hubot / GitHub / CircleCI によるChatOpsなデプロイ方法 - Qiita
概要 Slack / Hubot / GitHub / CircleCI などをつかってChatOpsにチーム開発できるフローをつくったので、ChatOpsによるデプロイ方法を中心にその方法をまとめてみます。 ChatOpsの主役であるチャットアプリには今回Slackを使いました。 HipChatでも同じように出来ますが、Slackの方がUIが優れていており、外部サービスとの連携も洗練されていたのでこちらを選択しました。 ChatOpsな環境の概要 SlackとHubot（PaaSであるheroku上にデプロイ）を連携させる SlackからHubot経由でGitHubにプルリクエストをつくる GitHub上の変更を監視し、CircleCIでテストを実施 デプロイ用のブランチに変更があった場合（GitHubのWEBコンソールでデプロイ用ブランチへのプルリクエストをマージした場合）、Circl
Confluence モバイル - Confluence
検索入力のクリア キャンセル 結果はありません 検索中… Confluence Mobile
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LGTMoon - 最もシンプルなLGTM画像ジェネレーター
Emoji Cheat Sheet
[GitHubとクラスメソッドの勉強会]DevOpsとAWSについてお話しました。資料をアップします。 | DevelopersIO![[GitHubとクラスメソッドの勉強会]DevOpsとAWSについてお話しました。資料をアップします。 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/faf3334bbe958772b09453f1a088d21cca899bfd/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F07%2Fdevops.png)
GitHub - KnVerey/alfred-datadog-dashes: List and filter your Datadog dashboards from Alfred3.
Redirecting...