You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
GitHub が GitHub Copilot Enterprise というサービスをはじめました。かなり革命的なのですが、とにかく高い。利用するには一人 60 ドル/月 (GitHub Enterprise Cloud 21 ドル/月 + GitHub Copilot Enterprise 39 ドル/月)かかります。なので、気になってる人向けに実際に使ってみて何が嬉しいのかを雑に書いてみます。 Pull-Request サマリーの自動生成GitHub の Pull-Request を出すとき、レビューして貰うためにこの Pull-Request の変更点を整理して書くと思うのですが、これを自動生成してくれます。 https://github.com/sile/pixcil/pull/2これは弊社の社員が個人のリポジトリで GitHub Copilot Enterprise の機能を利用
ProductGitHub Copilot Enterprise is now generally availableOur most advanced AI offering to date is customized to your organization’s knowledge and codebase, infusing GitHub Copilot throughout the software development lifecycle. Since the early days of GitHub Copilot, our customers have asked us for a copilot that is customized to their own organization’s code and processes. Developers spend more
Community5 tips for making your GitHub profile page accessibleYour profile’s README invites the world to know you and your work, so it’s important that everyone can read and understand it. In this post, we share some tips for making your README more accessible. The README on your GitHub profile acts like a front door to your work, skills, and professional self, so it’s important that everyone who
はじめに このガイドでは、Node.js プロジェクトの例の設定方法を紹介します Visual Studio Code Web クライアントを使用する GitHub Codespaces で。 codespace でプロジェクトを開き、事前定義済みの開発コンテナーの構成を追加および変更するプロセスについて説明します。 このチュートリアルを完了すると、VS Code Web クライアントまたは VS Code デスクトップ アプリケーションを使用して、独自のリポジトリに開発コンテナー構成を追加できるようになります。 dev コンテナーの詳細については、「開発コンテナーの概要」を参照してください。 ステップ 1: codespace でプロジェクトを開く まだサインインしていない場合は、GitHub.com にサインインします。 https://github.com/microsoft/vsc
"Think globally, act locally" Run your GitHub Actions locally! Why would you want to do this? Two reasons: Fast Feedback - Rather than having to commit/push every time you want to test out the changes you are making to your .github/workflows/ files (or for any changes to embedded GitHub actions), you can use act to run the actions locally. The environment variables and filesystem are all configure
golangci-lint is a Go linters aggregator. Join our slack channel by joining Gophers workspace and then joining channel #golangci-lint. Follow the news and releases on our twitter @golangci. Features⚡ Very fast: runs linters in parallel, reuses Go build cache and caches analysis results.⚙️ YAML-based configuration.🖥 Integrations with VS Code, Sublime Text, GoLand, GNU Emacs, Vim, GitHub Actions.🥇
はじめに 「Git補完をしらない」「commitブランチを間違える」「git statusを1日100回は使う」そんなあなたに朗報です。 bashの説明だけに絞っています。zsh? tcsh? 知らない子ですね。 いきなり完成形 # スクリプト読み込み source $HOME/.git-completion.bash source $HOME/.git-prompt.sh # プロンプトに各種情報を表示 GIT_PS1_SHOWDIRTYSTATE=1 GIT_PS1_SHOWUPSTREAM=1 GIT_PS1_SHOWUNTRACKEDFILES= GIT_PS1_SHOWSTASHSTATE=1 ############### ターミナルのコマンド受付状態の表示変更 # \u ユーザ名 # \h ホスト名 # \W カレントディレクトリ # \w カレントディレクトリのパス # \
概要 Git・GitHubを利用したシンプルで強力なワークフローであるGitHub Flowを図にまとめました。 GitLabでも利用可能なFlowです。GitLabの場合は Pull Request を Merge Request に読み替えてください。 前提 実際にGitHub Flowを実践したことはありません。(2014/06/12時点) これからチームで導入予定で、メンバーとワークフローを共有するために図を作成しました。 ワークフローの誤りなどご指摘いただけると幸いです。 アクティビティ図をベースに作成してありますが、厳密な記法よりも 相手に伝わればいいかな、という点を重視しています。 基本原則 masterブランチは 常時デプロイ可能 である 機能追加、バグフィックスなどは 説明的な名前のブランチ をmasterから作成する 機能追加の例: add_user_notice (ユ
基盤チームの川井 (@fohte) です。 今回は、monorepo と呼ばれる複数のリポジトリを単一のリポジトリで管理する運用方法の紹介と、実際にその運用に切り替えた話をします。 弊社は GitHub Enterprise を使っており、Git Flow を独自に拡張した master, develop, feature ブランチの 3 種類からなる運用フローを採用しています。 今回はその環境を前提としてお話します。 monorepo とは? monorepo は、複数リポジトリを単一のリポジトリで管理するという Git リポジトリの運用方法の一つです。 monorepo のメリットとしては以下の点が挙げられます。 密結合なリポジトリの運用が楽になる 複数リポジトリに横断した修正が簡単にできるようになる 例えば、あるリポジトリ A の変更に従って別のリポジトリ B も変更するとき、リポジ
先日github.comのTeamとEnterprise CloudプランでCodespacesがご利用いただけるようになりました。Codespacesはソフトウェアチームに対して、クラウド上でより速く、よりコラボレーティブな開発環境を提供します。詳しくはCodespacesのページをご覧ください。 GitHub.comのコードベースはもうすぐ14歳になります。GitHub.comの最初のコミットがプッシュされたとき、Railsはできてからまだ2年しか経っていませんでした。AWSはできてから1年で、AzureやGCPはまだ存在していませんでした。14年という歳月はCOBOLの世界では長くないかもしれませんが、インターネットの世界ではかなりの長さです。 この14年の間に、GitHub.comのコアリポジトリ(github/github)では100万回以上のコミットが行われました。これらのコミ
チーム内でなんとなくやっていたIssueやPR作成についてガイドライン化してCONTRIBUTING.mdに書き起こしてみた 暗黙のうちにこなすことで内容が人それぞれ様々になりがちなIssueやPRについて、精度を一定に保つことを目的としてCONTRIBUTING.mdにガイドラインを書き出してみました。暗黙の了解というやつはひとぞれぞれで、往々にして膨大でした。 リポジトリへのコントリビューター(Contributer,貢献者)として活動する場合に、リポジトリによっては厳密なルールを課しているところもあれば、そうでないところもあります。 暗黙の前提でやっていた場合、新しく参画したメンバーにとってはどう動いていいものやらと迷うこと間違いなし。ガイドラインのようなものを立てておくことで混乱を回避できますが、設定に沿った配置にすることでSaaS側がナビゲーションもしてくれるなら一石二鳥です。
Issueまで至らない要望やメモ書き等をGitHub上でどうやって管理するか悩みものでした。Projectの動作を一つ一つ確認してみて、現状のワークフローに合わせて極力管理の負担が増えずに実現する方法を模索してみました。 以前チーム内でタスク管理の精度を上げるためにIssueとPRについてルール付を行い、ガイドラインとしてのテキストも作成しました。 これで迷いはなくなったと思っていましたが、一つ難点が。予めルール付したIssueの定義を埋めることができない、つまりはやるべきことが確定していない「ふわっとした」状態の所謂「提案」や「願望」を置くことができません。 コントリビューター向けテキストに書いた「マイルストーン」での解決も試みましたが、このマイルストーンはIssueとして確定したもののみを含めることができる仕様でした。要は私の動作把握漏れ。代わりの手段は無いものかとGitHubリポジト
ブランチを保護していますか? master ブランチにマージしたらテストに失敗! みたいな経験をしたことはないでしょうか?開発の中心となるブランチは、問題なく動作する状態を健全に保ちたいですよね。 GitHub では、リポジトリの設定にて ブランチの保護 が可能です。この機能を使うと、以下のような保護を実施できます。 CIが通らなければマージできない 他のメンバーからレビューを承認(Approve)されなければマージできない 特定のメンバーはマージできない 設定方法 ブランチの保護の設定は「Settings」の「Branches」から行うことができます。何もコミットがないリポジトリは、設定そのものが出てきませんのでご注意ください。 「Protect branches」セクションの「Choose a branch...」をクリックし、保護対象とするブランチを選択します。 ページが切り替わりま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く