Merge YJIT: an in-process JIT compiler by maximecb · Pull Request #4992 · ruby/ruby
This PR introduces YJIT, a just-in-time compiler built using a Lazy Basic Block Versioning (LBBV) compiler architecture. For more details about the technique, please refer to Maxime’s published paper and recorded talks: ECOOP 2015 paper: https://arxiv.org/pdf/1411.0352.pdf ECOOP 2015 talk: https://www.youtube.com/watch?v=S-aHBuoiYE0 RubyKaigi 2021 talk: https://www.youtube.com/watch?v=PBVLf3yfMs8
こんにちは。メルカリのweb platformチームの@urahiroshiです。 この記事は、Mercari Advent Calendar 2021 の9日目の記事です。 今回は、メルカリWeb版のアプリケーションの開発に利用している検証環境の実現方法について記載します。 メルカリWeb版の開発では、フロントエンドアプリケーションのリポジトリに対してPull Requestを作成すると、そのコードベースの検証環境（以下ではPR環境と記載します）が自動で構築され、変更箇所に対するマニュアルテストや自動テストに利用されています。 ステージング環境やInternalリリース(https://engineering.mercari.com/blog/entry/2019-10-30-105936/ に記載しているTrialリリースに相当します)を用いた本番環境でのテストも実施しているのですが、
Pull requestの理想的なサイズとその理由
この記事は、Lancers（ランサーズ） Advent Calendar 2022 の2日目の記事です。 モチベーション 一般的にPull Requestはサイズが小さいほうが良いとされていますが、理想的なPull Requestのサイズは具体的に何行なのでしょうか？ また、なぜPull Requestのサイズは小さい方が望ましいのでしょうか？ 本稿ではPull Requestの理想的なサイズとその理由について、リサーチした内容をまとめます。[1] 本稿で取り扱う観点について Pull Requestのサイズを考察するにあたり、主に注目される観点は以下の2つがあります。 リーン思考に基づいたフロー効率の観点 コードレビューに関する観点 本稿では、理想的なPull Requestのサイズについて具体的な数字を示したいというモチベーションから、コードレビューに関する観点について取り扱うことにし
TechTargetは「git pull」と「git fetch」の違いを解説する記事を公開した。主な違いは、git pullではリモートリポジトリの変更が作業ディレクトリに直接コピーされるのに対し、git fetchでは作業ディレクトリへのコピーが行われない点たが、それぞれをどう使い分ければいいのか。
GitHub Pull Request マージキュー(beta)を試す | 豆蔵デベロッパーサイト
ブランチを作成してから PR を作成するまでに発生した main ブランチの変更を取り込む必要があるケースはけっこうあります。特に規模の大きい開発ではマージの作業コストは大きくなります。マージキューの ChangeLog の文章には以下のように書かれています。 開発者はマージ前に PR ブランチを更新して、マージ時に変更が main ブランチを壊さないようにする必要がしばしばありました。PR ブランチ更新のたびに、CI によるチェックの新たなラウンドが発生し、開発者がマージを試みる前に終了する必要がありました。別の PR がマージされた場合、すべての開発者はプロセスを再度実行する必要があります。 マージキューは、マージのためにキューに入れられた各 PR がキュー内の先行する PR でビルドされるようにすることで、このプロセスを自動化します。 つまり、PR を作成したらマージする代わりにマー
【書き起こし】The World Is at Your Pull Request! – How to Make a Dynamic QA Environment on Kubernetes and Istio - Yuki Ito【Merpay Tech Fest 2021】 | メルカリエンジニアリング
【書き起こし】The World Is at Your Pull Request! – How to Make a Dynamic QA Environment on Kubernetes and Istio - Yuki Ito【Merpay Tech Fest 2021】 Merpay Tech Fest 2021は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りで、2021年7月26日（月）からの5日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。 この記事は、「The World Is at Your Pull Request！」の書き起こしです。 伊藤雄貴氏：「The World Is at Your Pull Request！」というタイトルで、メルペイの伊藤が発表
Core: Migrate from AMD to ES modules 🎉 by mgol · Pull Request #4541 · jquery/jquery
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
Variadic tuple types by ahejlsberg · Pull Request #39094 · microsoft/TypeScript
// Variadic tuple elements type Foo<T extends unknown[]> = [string, ...T, number]; type T1 = Foo<[boolean]>; // [string, boolean, number] type T2 = Foo<[number, number]>; // [string, number, number, number] type T3 = Foo<[]>; // [string, number] // Strongly typed tuple concatenation function concat<T extends unknown[], U extends unknown[]>(t: [...T], u: [...U]): [...T, ...U] { return [...t, ...u];
QAがPull Requestから影響範囲を調べてリグレッションテストを実施している話 - Commune Engineer Blog
はじめに 初めまして。QAチームの三木と申します。 commmuneモバイルアプリのQAを担当しており、入社して7ヶ月が経ちました。 モバイルアプリチームでは、新機能開発だけでなく既存機能の改修や不具合修正を日々並行して進めています。 特に、「既存機能の改修や不具合修正」は小さい単位で行われるため、その変更起因で意図しない箇所に新しい不具合が発生する可能性があり、リグレッションテストでの確認が必要です。 現状、モバイルアプリのテストはほとんどが手動テストのため、リグレッションテストも手動で実施しています。 今回は、「意図しない不具合」をなるべく減らすために、影響範囲をどのように調べているかについて書きます。 リグレッションテストの定義 まず、リグレッションテストの一般的な意味や目的を定義します。 システムに対する修正や変更によって、意図せずに振る舞いに影響を与えることがある。 そういった意
GROWI に draw.io 連携機能を PR (Pull Request)して v3.7.0-RC としてリリースされた話 - Qiita
GROWI に draw.io 連携機能を PR (Pull Request)して v3.7.0-RC としてリリースされた話JavaScriptMarkdownReactDraw.ioGrowi はじめに GROWI に draw.io 連携機能を実装して Pull Request し、無事マージされて、バージョン 3.7.0 RC(Release Candidate) としてリリースされました！ (今は docker image のみ提供されてます) weseek/growi Add draw.io Integration #1685 使い方のドキュメントはこちらです。 draw.io で様々な図を作成する | GROWI Docs この記事では簡単な機能紹介と実装のモチベーション、どうやって実装したかなどをお話しようと思います。 GROWI って何？ 株式会社 WESEEK が OS
勝手を知らないプロジェクトにPull Requestを送るときに気にしていること - Kengo's blog
初心者向けのPull Request（PR）作成方法はopensource.guideをはじめとして数多く見るのですが、もうちょっと突っ込んだというか中級的な内容の記事を読みたかったので自分で書きます。題材として主に直近で書いた大きめの機能追加用PRを使っています： github.com 修正や新機能を入れる利点を明確に伝える 何かを提案する場合、その背景には必ず動機となる利点があるはずです。これはとても単純に伝えられることもあれば、テストやグラフを作成しないと伝わりにくいものもあります。 今回の変更では、GitHub Actions workflowの定義ファイル簡素化とパフォーマンス改善が利点でした。定義ファイルが簡素化されることはドキュメントで簡単に伝えられますが、パフォーマンスは測定しなければわかりません。よってパフォーマンス検証用のリポジトリを作成し測定を行うことで、ビルド時間が
Amplify ConsoleでPull Requestでのプレビューを試してみた | DevelopersIO
こんにちは。 AWSのアップデートをみてたらPull Request単位でのプレビューができると書いてありました。 便利そうだったので試してみたら便利だったので共有したいと思います。 Amplify Projectの作成 この機能を試す前にまずAmplify Projectをさくさく作っていきます。 フレームワークにNuxt.jsを使用してバックエンドなしのシンプルな構成で作ります。 Nuxt.jsプロジェクトの準備 まずはNuxt.jsプロジェクトを作成していきます。 $ npx create-nuxt-app sdx-amplidy-console-101 create-nuxt-app v2.11.1 ✨ Generating Nuxt.js project in sdx-amplidy-console-101 ? Project name sdx-amplidy-console-1
Linus が Git comes with a nice pull-request generation module, but github instead decided to replace it with their own totally inferior version. https://github.com/torvalds/linux/pull/17#issuecomment-5654674 Gitにはniceな pull-requestモジュールがあるのにGitHubは劣化版に置き換えた、と言っていて I believe he's referring to git-request-pull. https://github.com/torvalds/linux/pull/17#issuecomment-5660608 それは git request-pull のことらしい
Shodo AI校正APIのベータ版に申し込み、利用させていただいています。Shodo、日本語校正のSaaSということで注目していて、今回のAPIベータ版の話がTLに流れてきたので申し込み、当選することができました。 日本語校正サービス・ソフトウェアは商用のものの質はやはり高く、例えば老舗ジャストシステムのJust Right!などは友人のライターが利用していて、評判の良さも聞いています。 ただ、それらはいかんせん良いお値段します。もちろん、良質なサービスに対価を払うことはやぶさかではありませんが、私のようなホビーライターからするとちょっと厳しいお値段です。 ただ、私もブログは細々と継続していて、不定期で有償の記事や執筆をお受けすることもあるため、何らかの校正サービスを使いたいと思っては常々思っていました。 その点、スポットで従量課金的に利用できるSaaSモデルであるShodoは魅力的です
watch: add initial implementation for `node --watch` by MoLow · Pull Request #44366 · nodejs/node
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
任意のPull Requestの内容を複数のリポジトリに対して一括コピーするツールpr-bulletを作った - Copy/Cut/Paste/Hatena
GitHub Actions便利ですよね。 ペパボではGitHub Enterprise Server（以下、GHES）が運用されており、GHESでもGitHub Actionsが利用できます。 uses: だけで利用できるリポジトリを横断で再利用可能なActionの存在はかなり生産性を上げていると思います。 そういった便利なワークフローを複数のリポジトリに対して適用していきたいことが時々あります。 一気に複数のリポジトリに同じワークフローを適用したいこともあれば、「あ、このリポジトリにはあのリポジトリのワークフローをいれたほうがいいな」となることもあります。 その時、それぞれのリポジトリに対して「突然のデフォルトブランチへのpush」はあまりにも乱暴なのでPull Requestを作成していくことになります。 ただ、適用したいレポジトリが2桁あったとき、Pull Requestを作成する
GitHub - tenacityteam/tenacity: Mirror of https://codeberg.org/tenacityteam/tenacity. Pull requests are IGNORED!
Please note that we do NOT accept any pull requests or issues on GitHub anymore. See https://codeberg.org/tenacityteam/tenacity to file your bug report or submit your pull request. Tenacity is an easy-to-use multi-track audio editor and recorder for Windows, macOS, Linux and other operating systems. It is built on top of the widely popular Audacity and is being developed by a wide, diverse group o
【Git】エラー、コンフリクトのお悩み解決 - Gitの気持ちになって理解する checkout/merge/pull - Qiita
error: Your local changes to the following files would be overwritten by checkout: test.txt Please commit your changes or stash them before you switch branches. Aborting メッセージの意味、その対処法や背景までわかる人は、おそらく先を読む必要はないでしょう。 そうでない人はこの記事を読むことで、いままでより自信をもってgitを使うことができるようになるかもしれません。 この記事で説明すること チェックアウトするときに、なぜエラーが発生するのか マージやリベースするときに、なぜコンフリクトが発生するのか チェックアウト時のエラーやコンフリクトを理解するためのgitのキホン チェックアウトやマージ、プルが具体的になにをやっている
DockerHub による2020/11からのコンテナイメージ Pull 回数制限のCircleCIへの影響
CircleCIとしてもDocker社との協議等含め、影響の有無や影響範囲等、公式なドキュメントは取りまとめを進めていますが、現在の状況等、(公式扱いではなく)速報として、こちらのスレッドで説明させていただいております。 10/23日本語訳追加 Docker Hubのレート制限に関するFAQ 10/23追加 CircleCIからの匿名イメージプル、Docker社とのパートナーシップにより当座は制限の対象外 (なお、アカウントの中で言語を設定し、ログインした状態で地球儀アイコンをクリックすると、機械翻訳された投稿を見ることができます) また、FAQはこちらになります。 英語: https://support.circleci.com/hc/en-us/articles/360050623311-Docker-Hub-rate-limiting-FAQ 日本語: https://support
git pullを実行する際に、ローカルで未コミットの変更に対して、リモートの状態で上書きせず、ローカルでの変更を保持したい場合や、やっぱりリモートの変更で上書きしたくなった場合の対処方法についてのご紹介です。 こんにちは、CX事業本部の若槻です。 git pullを実行する際に、ローカルで未コミットの変更をリモートに反映させずローカルでだけ保持したい場合があります。 例えば、以下のようにhoge.txtの変更がローカルで行われていますが、この変更はリモートには反映したくないため、未コミットとしています。 $ cat hoge.txt ローカルでの変更 $ git fetch $ git diff remotes/origin/master diff --git a/hoge.txt b/hoge.txt index 48ee78d..e3130ae 100644 --- a/hoge.t
Gitlab.comを使った開発でDocker Hubからのpull制限を回避するためにDependency Proxyを使う - Qiita
Gitlab.comを使った開発でDocker Hubからのpull制限を回避するためにDependency Proxyを使うGitLabDockerDockerHub 開発中に何度もDocker Hubからpullを実行しているとpull制限に引っかかってしまいます→ダウンロード率制限 これを回避するためGitlab.comではDependency Proxyが用意されています。pull先をDependency ProxyにすることでDocker Hubから落としたイメージがDependency Proxy上にキャッシュされ以後、Dependency Proxy上のキャッシュを参照することになるので、Docker Hubのpull制限にほぼ引っかからなくなります。 使い方 通常の場合 DockerHubのalpine:latestを使いたい場合は以下のようになります。login先がreg
Pull Request を作るのに一時間以上かかったら捨ててる - Object.create(null)
一時間は大体の目安でちゃんと測ってない. PR の作成に時間がかかるときは, 何らか良くないことが起きている可能性が高い 試行錯誤を繰り返している 変更の規模が過大になっている 良くないことが起きているなら, そのまま続けて余計なコストをかけるよりも捨てた方が良い 試行錯誤を繰り返していたなら, そこまでは勉強か練習だと思って捨てる 変更の規模が過大になっていたなら, 分割して作り直すために捨てる 捨てることを躊躇わない 時間をかけるほど引き返しづらくなるので, 一時間くらいで打ち切る 一時間の手戻りなら一時間で取り返せる. なんなら知識が増えている分もっと短くて済む 思ったより進んでいなくても, そのまま思っていたところまで進めようとはせずに諦めて捨てる. とにかく良くないことが起きている可能性が高いので立ち止まるべきで, 思ったところまで進められる (良くない状態に陥らなくなる) 状態
概要、背景みなさまこんにちは。フロントエンドエンジニアのはしばです。 現在までにありがたいことに複数名の エンジニアになりたい or 新人エンジニア の方のサポートを経験してきました。 その中でほぼ毎回共通して伝えていることがあったので記事にしてみました。 これから初めてチーム開発するという方も、学習開始したばかりの方にも参考になる内容かと思いますので是非最後まで見ていって下さい~ PRを出すその前に①developの更新を都度作業ブランチに反映していますか?これをやりたくない気持ち...少し分かります。僕も最初Git使うの恐怖だったので。 コンフリクトも怖いし、マージ??プル??リモート?????と最初四苦八苦しながら対応したのを覚えています。 ただ、この重要性を理解できていない === Gitを利用したチーム開発のフローが理解できていないのでしっかり挑戦しましょう。 むしろコンフリクト
OSS(Open Source Software)のコミュニティー(本家)のリポジトリにPull Requestを出す時にいつも手順が分からなくなってしまいます1。例によって調べながらやりますが、ページによって記載がまちまちだったりします。そこで備忘録として手順をまとめておくことで迷わずスムーズにPull Requestを出せる様にしておこうと思いました。また、ただGitのコマンドを羅列しただけの備忘録では無く、実際にVega EditorというOSSにコントリビュートしてみた行程をまとめて残しておこうと思います。 GitHubを例に解説しますが、その他のGitベースのサービス(GitLab, BitBucket等)も基本的に(コマンド)操作は同じです。 OSSのリポジトリをForkする 今回はVega EditorというOSSにコントリビュートしてみようと思います。たまたま今回この記事を
Pull Requestでレビューしたい！ はてなブログでホストされたエンジニアブログだとしても - LIVESENSE ENGINEER BLOG
どうも、かたいなかです。 採用広報チームでのブログ推進の一環として、はてなブログにある弊社エンジニアブログ記事をGitHubで管理するしくみを整えました。 この記事では、どのようなGitHubでの記事編集フローを構築したかをまとめます。 記事のレビューのフローがバラバラ・・・ GitHubで記事を管理できるように GitHub Actionsでtextlintを実行 GitHub Actionsではてなブログ側の変更を取り込む 定期実行のワークフローで公開された記事を公開済み記事のディレクトリに移動 GitHubで記事を管理できるようにしてどうだったか 参考 記事のレビューのフローがバラバラ・・・ 弊社のエンジニアブログの記事の運用での大きな問題のひとつに、レビューのフローが記事によってバラバラになってしまっていることがありました。 具体的には、以下のような一長一短ある複数のフローが、記事
GitHub Actions / Azure Pipelines で Pull Request に特定のラベルが付けられた時だけ処理を行う - しばやん雑記
個人的によく使っていて時々 Pull Request も投げている Durable Functions の開発リポジトリでは、全ての Pull Request に対しては基本的なテストのみ実行し、full-ci というラベルが付いた時のみ全てのテストを実行するようになっています。 実際に以前投げた Pull Request は影響範囲の広い修正だったので、full-ci ラベルが付けられてテストを全て実行し、パスしたのを確認してマージされました。 理想的には全ての Pull Request で全てのテストを実行するべきなのでしょうが、テストに関しては時間的な制限もあって難しいので、この運用は個人的にかなり良い感じだと思っていました。 常に全てのテストを実行する必要がないことは開発中していて気が付きますし、テストに時間がかかってマージやリリースが遅れ始めるとテストが邪魔扱いされかねません。そ
git／git pullコマンドとは？ 「git」は「Git」という分散型バージョン管理システム用のコマンドです。Gitは元々Linuxカーネルのソースコードを管理するために作られた「バージョン管理システム」で、現在は多くのソフトウェアのソースコードやWebサイトのコード、ドキュメント管理などに用いられています。 ソースコードを管理する際、最新版だけを保存するやり方はうまくいきません。開発中のさまざまなタイミングで状態を管理し、必要に応じて比較、参照したり、元に戻したりできるようにする仕組みが「バージョン管理システム」です。 Gitでは、テスト版など複数に枝分かれした状態も管理できます。複数のメンバーによる開発を前提としており、開発中の各時点におけるコメントや、コメントへの返信なども管理できるようになっています。 gitのサブコマンドとGitの仕組み gitコマンドはほとんどの場合、「サブ
Support `where` with comparison operators (`>`, `>=`, `<`, and `<=`) by kamipo · Pull Request #39613 · rails/rails
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
Deploy your pull requests with GitHub Actions and GitHub Deployments - Sander Knape
Deploy your pull requests with GitHub Actions and GitHub Deployments May 6, 2020 by Sander Knape Performing (automated) tests on pull requests is a powerful mechanism to reduce the feedback loop on code changes. Known as shift left, the idea is that the earlier you find an issue with your code, the easier it is to fix it. For one, as you wrote the code recently it’s easier to get back into it. And
GitHubのPull Requestのコメントから任意のGitHub Actionsを実行する必要があり、やり方に少々癖があったので紹介します。 issue_comment ドキュメントを眺めているとPull Requestに関連するイベントはいくつかありますが、Pull Requestのコメントをトリガーとしたイベントが無いように見えます。 pull_requestイベントはPull Requestの作成やラベル付けをトリガーとするイベント pull_request_reviewイベントはレビューされたときをトリガーとするイベント pull_request_review_commentイベントはレビューについたコメントに関するイベント どうにかPull Requestのコメントをトリガーに起動できないか調べていたらCommunity Forumで以下の投稿を見つけました。 github
Pull Request駆動で小説を開発する
謝辞 先日、こんな記事を書いた。 ありがたいことに多くの反応をいただいた。 この場を借りて御礼申し上げる。 要点 Pull Request 駆動で小説を開発する 情報整理の場としての Pull Request 校正の場としての Pull Request Pull Request 駆動で小説を開発する 小説を書いて GitHub にアップロード(コミット→プッシュ)していく中で、「こういう表現にしたほうがよくなるんじゃないか」と思いつくことがある。 GitHub ではいつでも過去のデータにアクセスして文章を取り戻せるから、大掛かりな変更や修正も気軽にできる。 だが、更新頻度の高いファイルほど、取り戻したい特定の時点を探し出す手間が増える。 コミットメッセージを記載していたとしても、同じ箇所を別の時点で修正している可能性がある。 あなたがコマンドラインを使うのに抵抗がなければ、こういった検索方
Mackerelが公開しているOSSにPull RequestしてOSS慣れしてみる - stefafafan の fa は3つです
こんにちは、株式会社はてなで最近はマンガサービスのコードを書いている id:stefafafan です。この記事はMackerel Advent Calendar 2020の13日目の記事です。 qiita.com 今回はMackerelのOSSにPull Request送ったときの話をしてみます。 前提 一応簡単に前提から話すと、Mackerelというのは株式会社はてなが開発しているサーバ監視サービスです mackerel.io Webサービス本体のコード自体は公開されていないですが、監視対象のサーバにインストールされるエージェントやプラグイン、また公式ドキュメントのマークダウンなどは大体GitHubにオープンに公開されています。プラグインなどはAPIが公開されているので誰でも簡単に作れます。 github.com 今回はこの公開されているコードに対して誰でも気軽にPull Reques
Amazon Elastic Container Registry (Amazon ECR) now supports pull through cache repositories, a new feature designed to automatically sync images from publicly accessible registries. With today’s release, customers now benefit from the download performance, security, and availability of Amazon ECR for the public images. Organizations rely on public registries for images to build or complement their
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
Convert the codebase to modules by jakebailey · Pull Request #51387 · microsoft/TypeScript
This is it; the PR that converts the TypeScript repo from namespaces to modules. TL;DR: The TypeScript compiler is now implemented internally with modules, not namespaces. The compiler is now 10-25% faster. tsc is now 30% faster to start. Our npm package is now 43% smaller. More improvements are in the works. If you're reading this and the 5.0 beta is out, now that the above results were as of thi
lib: add require('🦕') by bnoordhuis · Pull Request #35478 · nodejs/node
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
チケットの正しい書き方！Pull Requestの発行の仕方も解説 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
どうも！ テクニカルディレクターのおきくです。 本日は、普段BiTT事業で実際にCODYメンバーに実施しているGitHubやAsanaを使ったディレクション方法についてまとめました。この記事が少しでも皆さんの参考になれば嬉しいです。 ここでお話する内容は、自分のGitHubプロジェクトにもなりますが、以下GitHubのリポジトリにフォーマットとしてまとめています。もしよければこちらも参考にしてください。 チケットの書き方のポイント（エンハンスメント、新規機能作成時） フォーマットはこちらから。 ポイント① 1チケット = 1PRの粒度でまとめましょう これは世界共通のルールなので、いわずもがなでしょうか。基本はグローバルスタンダードなルールに則って行いましょう。 ポイント② 概要をしっかりとまとめましょう メンバーに何のためにどうしてこのチケットが発行されているのか、どんなタスクなのか全容
Improve Password Length Validation for BCrypt Compatibility by guilleiguaran · Pull Request #47708 · rails/rails
[Fix #47600] Motivation / Background This Pull Request has been created because we identified a need to improve password length validation for BCrypt compatibility in the ActiveModel::SecurePassword module. The current validation only considers the character count, which may not accurately reflect the byte size limit imposed by BCrypt. Detail This Pull Request changes the password length validatio
Comments on individual commits made outside a pull request no longer appear in the pull request timeline
Comments on individual commits made outside a pull request no longer appear in the pull request timeline pull-requestsrepositories August 4, 2022 Code review on GitHub has evolved a lot since we introduced the ability to comment on an individual commit in 2008. Users today can propose a change using a pull request, which provides a first-class experience for reviewing, discussing, evolving, and ul
今までなんとなく、fetchしてmergeするのを一気にやってくれるのがpullという理解で、詳しく調べたことがありませんでした。 改めて調べてみたのでまとめます。 前提知識 fetch, merge, pullを理解する上で欠かせないのが以下の言葉です。 リモートリポジトリ: GitHubなどリモート上に存在するリポジトリ ローカルリポジトリ: PC上に存在するリポジトリ リモート追跡ブランチ: origin/mainなど、リモートリポジトリを追跡するブランチ ローカルブランチ: mainなど、ローカル上で実際に扱うブランチ 図にすると以下のようになります。 すこしわかりにくいのがリモート追跡ブランチですね。 これはリモートブランチの状態をとりあえずローカルに持ってきている場所というような理解であっていると思います。 ここで大事なのは、リモート追跡ブランチはあくまでローカルにあるブランチ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
メルカリWeb版のPull Request環境の構築方法について | メルカリエンジニアリング
「git pull」と「git fetch」の違いとは？
GitHub Pull Request ではなく git request-pull - ログ日記
Shodo校正APIの結果をpull requestのレビューコメントに自動反映する | おそらくはそれさえも平凡な日々
git pull実行時にローカルで未コミットの変更を保持する方法 | DevelopersIO
初めてのpull requestのその前に聞いてほしい話 - ちょっと株式会社 社員ブログ
【超図解】OSSにPull Requestを出す時の備忘録 - Qiita
【 git pull 】コマンド――リモートリポジトリの変更内容を取り込む
Pull RequestのコメントからGitHub Actionsを実行する - あかいものログ
Amazon ECR announces pull through cache repositories
Rust YJIT by XrXr · Pull Request #5826 · ruby/ruby
Gitのfetch, merge, pullって何やってるの？ - Qiita