Join over 150 of the industry’s most influential thought leaders at GitHub Universe. Explore the full schedule and get tickets now.
GitHubがMicrosoft Teamsと連携可能に。Teamsのチャットからリポジトリのアクティビティ参照やコメント返信など実現 マイクロソフトは、GitHubをMicrosoft Teamsと連携させ、Microsoft Teamsのチャット機能からGitHubのリポジトリ情報の参照や、GitHubのイシューやプルリクエストにコメント返信を可能にする、Microsoft Teamsの拡張機能を発表しました。 We know that a lot of teams use GitHub and Microsoft Teams to get their work done, and today we’re sharing a new integration available in public beta. We hope you’ll try it out! https://t.co
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のTemplate Repository機能の紹介です。 リンターやらテストライブラリの設定等は、ほぼどの環境でも行いますが毎回設定するのは地味に面倒ですよね。 GitHubのTemplate Repository機能を使えばその環境構築が不要で、本質的な開発をすぐに始められるようになります。 GitHubのTemplate Repositoryとは? あるリポジトリのコードベースをそっくりそのまま新規のリポジトリ作成で利用できる機能です。 「え、それってforkと違うの?」っと思った方もいるかもですが、以下の点でforkとは異なります。 1つのリポジトリから複数作成できる(forkだと、同名のリポジトリとなるので1人のユーザー内で複数作成は不可) 元となったリポジトリのコミット履歴を継承せず、クリーンな状態でスタートできる 使い方 以下実際にTemplate Re
GitHubがnpmの買収を発表、JavaScriptのパッケージ管理サービス。将来的にはGitHubとnpmを統合へ GitHubは、JavaScriptのパッケージ管理サービスを提供するnpmの買収を発表しました(GitHubの発表、npmの発表)。 We’re excited to announce that @npmjs will be joining GitHub. Millions of JavaScript developers rely on npm, and we’re honored to support this community in a new way. Learn more at https://t.co/MsQMc1rIJd pic.twitter.com/CUuPojccpm — GitHub (@github) March 16, 2020 npmはNo
GitHubが「Pull Panda」買収を発表。プルリクのSlackリマインダーやレビュアーの公平な割り当てなど、全機能が無料に GitHubは、GitHub関連ツールベンダ「Pull Panda」の買収を発表しました。この買収発表と同時に、Pull Pandaが提供していた3つのソフトウェア「Pull Reminders」「Pull Analytics」「Pull Assigner」はすべてGitHub Marketplaceで無料公開され、だれでも使えるようになりました。 Pull Remindersは、プルリクエストに対する作業を自動的にSlackにリマインドしてくれる機能を提供します。これによりプルリクエストへの対応が忘れられたままになるのを防ぐことができます。
twitter とか facebook のタイムラインを見てると、URL が共有されてて場合にいい感じにその URL 内で使われてる画像が表示されるはず。 今回 GitHub の変更でリポジトリの URL を共有する際に表示される画像である og:image をカスタマイズできるようになった。 github.blog こんな感じで好きな画像を設定できるが、最低限の画像サイズとして 640×320px、 推奨として 1280×640px が挙げられてる。 はてなブログでも小さく反映されてる。 github.com 追記 なんか反映されないなと思ってたら Some platforms have tag caching that may initially affect your link’s unfurling. (一部のプラットフォームでは、タグのキャッシュ機能があり、最初はリンクの展開に影
これは「BASE Advent Calendar 2018」の2日目の記事です。 devblog.thebase.in Native Application Group の右京です。 ネットショップ作成サービス「BASE」では日々機能追加や改善の為、無数の Pull Request が作成され、レビューされています。今日はそんな中で知っているととっても便利な機能を紹介します。 レビューをしていたら typo をみつけてしまった... ありませんか?前後に真面目なレビューがあるとなんとなく指摘するのを躊躇してしまいますね...。シレッと修正するにも編集するなりブランチを切るなりして...はコンフリクトの可能性などもあり、コストが高く面倒ですよね。 そんなときはこれ、「Suggested change」です。 Incorporating feedback in your pull reques
All Microsoft Global Microsoft 365 Teams Windows Surface Xbox Deals Small Business Support Software Windows Apps AI Outlook OneDrive Microsoft Teams OneNote Microsoft Edge Skype PCs & Devices Computers Shop Xbox Accessories VR & mixed reality Certified Refurbished Trade-in for cash Entertainment Xbox Game Pass Ultimate PC Game Pass Xbox games PC and Windows games Movies & TV Business Microsoft Clo
「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう これはもともとGitHub社内で行われていた運動を広げ、誰でも参加しやすいようにしたもの。 下記はOpen Source Fridayの提唱を紹介する同社ブログの記事「Contribute on Open Source Friday · GitHub」からの引用です。 Over the last three years, we've encouraged GitHub employees to take time at least every fourth Friday to work on open source and share what we're working on with each other. Open Source Friday has grown from t
いざPull Requestのレビュー!と挑んだ瞬間、「ここタイポな」という先制パンチをくらうのはとても残念なことです。 また、これは指摘しているほうにとってもチェックが負担で、気が重いものです。 人間は人間にしかできないチェックに集中すべきですし、貴重なレビュー時間を誤字脱字の修正に使うのはもったいないです。そこで開発したのが、タイポの自動検知と修正を代行するBot。その名もtypotです。 chakki-works/typot こちらは先日公開がアナウンスされたGitHub Marketplaceと共に公開された、新しいGitHubアプリの形態であるGitHub Appsで作成しています(それまではWebhookかOAuthだった)。 GitHub AppsはOAuthのようにユーザーではなく、リポジトリにひもつく形態になります。そのため、管理者ユーザーがいなくなった(あるいは権限を失
GitHub でコードを見ていると,ハイライトがおかしいのを見つけることがたまにあります.ここではその直し方を紹介します. 次の2パターンを想定しています. 自分のリポジトリのあるファイルのハイライト言語がおかしい 構文ハイライトが間違えている,言語の新機能に対応していない 自分のリポジトリのあるファイルのハイライト言語がおかしい コードをどの言語でハイライトするかは自動判別されますが,実はある程度ユーザ側で制御する方法があります. Vim や Emacs のモードラインを書く ファイル単位で Vim や Emacs の設定をマジックコメントとして書けるモードラインですが,実は GitHub もそれを参照しています // C++ だけど拡張子は .h … C じゃなくて C++ でハイライトしてほしい // vim: set ft=cpp // // または // // -*- mode:
概要 OSSのメンテナっぽいことをやるとき、githubで特定のpull requestの正当性を確認したいということがあると思う。ブランチチェックアウトすれば良くね?って単純に考えていたけど、結構面倒くさかったので、メモっとく。 やり方 とりあえず、repositoryをcloneして、branchを見てみる。 $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/feature/support_gemfile remotes/origin/master remotes/origin/test_1.0.0
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです!!!!」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった(後述あり) いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの? 従業員が10人未満
新しい言語やフレームワークを学ぶことは、時には苦闘になることがあります。従来のアプローチは、概念を説明し簡単な例を提供するドキュメントを読むことです。それで十分な場合もありますが、ドキュメントに高度な例や実際のプロジェクトでの使い方が書かれていない場合も多々あります。 ドキュメントに記載されていない問題に出くわすと、大抵の人はStack Overflowで解決策を探します(またはソースコードを丹念に調べます)。しかし、「使っているフレームワークが登場してから十分に期間が経っておらず、思い浮かぶ質問全てにStack Overflowが答えてくれない」ということもありえます。 今まで問題にはまって、こう考えたことはありませんか? 「誰かが既にこの問題を解決しているはずだ!では、なぜこの問題に対する答えがStack Overflowにないのだろうか?」 そのとおりです。恐らく誰かは既にそれを解決
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く