GitHubでQiitaの:::noteみたいな強調をする - Qiita
2023年11月21日 追記: 初回投稿時（2022年6月）の内容を，2023年11月現在の内容に更新しました はじめに Qiitaの:::noteみたいな強調表示とは，上のような表示（コールアウト）のこと Qiitaでは :::note infoや :::note warn などと入力すると強調して表示ができる GitHubでの対応状況 2023年11月現在，5種類の表示が利用できる [Markdown] An option to highlight a "Note" and "Warning" using blockquote (Beta) というわけで試してみた． 使い方 IssueなどのMarkdownに，以下のような記法で書き込む > [!NOTE] > こんな感じに書き込むと強調表示される > [!TIP] > `TIP` の例 > [!IMPORTANT] > `IMPORT
ドキュメント駆動開発v2
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
モダンなPull Requestの回し方
はじめに 今の時代、GitHub を使って複数人で開発する場合は、基本的に Pull Request(以降 PR)を使って開発することが殆どだと思います。 GitHub 側もここを重要視しているようで、色々な新しい機能や改善を継続的に投入してくれています。しかし、実際の利用シーンではこれらの機能があまり使われておらず、原始的な PR を見ることが多々あります※1。 エンジニアならば自動化/効率化はして当たり前だよね！※2ということで、PR 周りの便利な機能や運用方法を紹介したいと思います。 ※1 ... 注: 個人の感想です ※2 ... 本音は「レビューめんどいからもっと楽させて」 準備編 PR を建てる前にリポジトリの設定をしておきましょう。 Pull request template 公式の説明ページ(English) PR のテンプレートを設定できる機能です(そのまま)。.gith
GitHubで画像を保存してREADME.mdに表示する - よしたく blog
初級者の人や、プロジェクトにあとから入ってきた人がわかりやすいようにGitHubのREADME.mdを詳細に書いていくことは大切です。しかし、文字ばかりになるのも味気ないですし、やはり絵や図があったほうがわかりやすいはずです。ふと、画像を貼るにはどうしたらいいのだろうと思ったので調べて実践してみました。 README.mdに画像を貼る手段はいくつかあるようで、外部サービスを利用するものもあります。外部サービスに保存し、そこを参照しに行く方法です。 GitHubでREADME.mdに画像を使用したい - Qiita 個人的にはGitHubの同じリポジトリの中だけで閉じておきたいなと思ったので、空のブランチを用意しその中に画像だけ保存しておく方法を選択しました。今回はそのメモです。 空のブランチを作る方法 空のimagesのブランチを作成します。orphanオプションをつけることによって、元の
githubで最もやべー関数を発掘する - Qiita
はじめに 先日、職場で「自分が 改修したor 書いちゃった いちばんやべー関数」ネタで盛り上がりました。 みんないろいろ話してくれましたが、やっぱり僕の書いた「コマンドパターンのメインループ関数(1500行)」の圧勝でした。 なんであんなコード書いたんだろ。 そこで、今日は僕の傷ついたプライド癒すべくgithubから「世界でいちばんやべー関数」を発掘します。 つまり、「俺が書いた関数よりやべー関数に会いに行く」 結論 マジでやべー関数は次の2つ 「opencvリポジトリのcv::agast_cornerScore<AgastFeatureDetector::AGAST_7_12s>関数」(複雑度1868) 「SuiteCRMリポジトリのOpenTag関数」(複雑度1509) 言語毎の傾向に着目すると... javascriptにはやべー関数が多い python/java/swift/rub
GitHub、オープンソースのコードを1000年以上にわたって保存する「GitHub Archive Program」発表。北極圏の非武装地帯永久凍土層地下250mに保管庫を設置
GitHubは、オープンソースは現在の文明の基盤であり人類の共有財産であるとして、このコードを次世代の人類に確実に残していくための「GitHub Archive Program」を発表しました。 「GitHub Archive Program」は、スタンフォード大学図書館やオックスフォード大学ボドリアン図書館、一万年時計で知られるロングナウ協会、Internete ArchiveやSoftware Heritage財団、GHTorrent、Microsoft Researchなど、さまざまな団体がパートナーとして協力しています。 コードの保存はもっとも更新頻度の高いホットなレイヤから、定期的なアーカイブが行われるウォームレイヤ、そして長期的な保存が行われるコールドレイヤまで複数のレイヤにわたって行われます。 もっともホットなレイヤはGitHubのリポジトリそのものであり、GHtorrent
【GitHub】少人数のチームで開発するときのGitHubのブランチ運用Flow - Qiita
概要 少人数のチームでGitHubを用いてプロダクト開発するときのブランチ運用フローについて． GitHub Flowを参考にシンプルさと運用のしやすさを重視している． チームの全員が6つのルールを守るだけで，masterが綺麗な状態で保たれる． 全体像 6つのシンプルなルール 1. master は本番環境にデプロイされているバージョン 2. develop はテスト環境にデプロイされているバージョン 3. feature ブランチ（作業ブランチ）は develop から分岐する 4. feature ブランチは頻繁に push する 5. pull-request（PR）で develop にマージする 6. マージされた feature ブランチは削除する 実際の作業例 1. develop からある機能を実装する作業ブランチを作る
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
