このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
弊社では GitHub のレポジトリ管理に Terraform GitHub provider を使用しています。 いちいち手元で terraform plan や terraform apply を叩くのは面倒なので、 GitHub Actions を利用することを考えました。 tf ファイルと現実のリソースとの不整合を避けるために、 これらのコマンドは排他的に実行する必要があります。 例えば terraform apply を実行している最中に terraform plan を実行することはできません。 ここで問題になってくるのが GitHub Actions のジョブ並列数です。 2020-12-30 現在、GitHub Actions は同時に 20 並列まで実行可能ですが、逆に並列数を制限できないという贅沢な悩みがあります。 一応 Matrix Build の並列数を制限するオプ
$ gh issue list gh pr status gh pr checkout gh pr create gh pr checks gh release create gh repo view gh alias set View and filter a repository’s open issues. Check on the status of your pull requests. Check out pull requests locally. Create a new pull request. View your pull requests’ checks. Create a new release. View repository READMEs. Create a shortcut for a gh command.
アメリカ合衆国の首都ワシントンでは、法律がGitHubを使用して管理されています。法律のオープンデータ化を推進するサービス「GovTrack」の創設者であるジョシュア・トーベラーさんが条文のタイプミスを見つけてからプルリクエスト機能を使って修正するまでの流れが海外ニュースメディアのArs Technicaで公開されています。 How I changed the law with a GitHub pull request | Ars Technica https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/ ある日、トーベラーさんが法律を調査していた時に条文の参照が誤っていることを発見したとのこと。問題となったのは「公開政府省は、第2編第5章のIの実施に関して助
Firefoxの拡張機能でGitHubのプルリクエストを匿名化し、コードレビュー時の性別や人種などによるバイアスを取り除く実験開始。ソフトウェア分野のダイバーシティに向け コードレビューを行うときには、それが誰が書いたコードであろうともコードの品質そのものにフォーカスされるべきです。しかし現実には、コード作者の性別、年齢、国籍や人種などから、もしかしたらレビュアーは何らかのバイアスを持ってコードレビューをしてしまうかもしれません。 Mozillaは、コードレビュー時に作成者の名前をあえて隠すことで、コードレビュアーのバイアスを取り除く実験をしていると、ブログ「Mozilla experiment aims to reduce bias in code reviews」で書いています。 The experiment has two parts: there’s an effort to bu
作成: 2017-10-16 更新: 2018-10-16T21:25:53+09:00 GitHub 単純なコマンドラインでmergeする方法が使えない時 本の虫: GitHubで他人のプルリクエストに対しコンフリクト解消や追加の修正を行いつつマージする方法を読んで, そう言えば私もバイトで最初にチーム(私と社長で2人)で作業を行うときに戸惑ったなあと思い出しました. なので, 今のバイト先の社長から教えてもらった, もう1つの方法を紹介します. 江添さんの述べた方法は, シンプルでわかりやすいですが, 我々のチームでは使えません. 何故ならば, 我々のリポジトリにはTravis CIによる自動テストが導入されているからです. そして, コードレビューで承認を貰い, 自動テストが成功していない限り, 原則masterにはそのpull requestをmergeしてはいけないというルールが
みなさん、Git使ってますか?僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
GitHub や GHE を使って多人数で開発していると,プルリクエストを横断して試す必要が頻繁に発生すると思います. プルリクエストを次々に試したり,#30 と #31 をマージした結果を試したい!なんてケースもあるのではないでしょうか. GitHub では git ls-remote すれば分かるように,プルリクエストの番号と対応したブランチがリモートに存在しているので,これを取得してみます. .git/config に追記(あるいは git remote add とかで適当に) [remote "pr"] url = git@github.com:yourusername/yourrepos.git fetch = +refs/pull/*:refs/remotes/pr/* あるいはこんな感じ(丸投げ): https://gist.github.com/3342247 git fe
gitflowが便利で気に入っています。人のプロジェクトをforkしたときは、どういう流れで使えばいいのかまとめている文書が見つからなかったので書いておきます。 プロジェクトをfork 手元にclone upstreamの登録など git flow init git flow feature start XXXX いい感じに編集 git commit git flow feature publish XXXX GitHubのSwitch branchesからXXXXを選択 Pull requestボタンを押してリクエスト送信 レビューされる 取り込まれたらgit flow feature finish XXXX 僕は先日featureブランチをfinishしてからpull requestを送ってしまいまったんですが、GitHubのヘルプにはpull requestはトピックブランチからやれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く