タグ付けされた質問 「pull-requests」

6
プルリクエストに対してgitコミットをスカッシュするのはなぜですか？
プルリクエストを行うすべての深刻なGithubリポジトリが、コミットを1つのコミットにまとめるように要求するのはなぜですか？ gitログがあると思ったので、すべての履歴を調べて、どこでどのような変更が発生したかを正確に確認できますが、それを潰すと履歴から引き出され、すべてが1つのコミットにまとめられます。ポイントは？ これは「早期にコミットし、頻繁にコミットする」というマントラにも反するようです。
4
プルリクエストでTODOを処理する方法
この質問は、Software Engineering Stack Exchangeで回答できるため、Software Quality Assurance＆Testing Stack Exchangeから移行されました。 昨年移行し ました。 プルリクエストの変更を確認すると、「TODO」のメモが付いたコメントに出くわすことがあります。 問題を解決するために使用されるソリューションは改善できますが、かなりの時間投資が必要になります。作成者はより迅速なソリューションを選択しましたが、より良いオプションが潜在的に利用可能であるというコメントを入れました すぐに修正する必要がある既存のバグを回避するための一時的なコードがあります TODOsが一般的にコードベースの存続期間中コードベースに留まることを知っているので、プルリクエストでそれらにどのように対応する必要がありますか？どうすればそれを避けるよう丁寧に要求できますか、またはそれが本当に正当化された場合、PRの作者が将来それをフォローアップすることをどのように確認できますか？
1
私のgithubプルリクエストはマージされましたが、この段階での規約は何ですか？
Githubでプロジェクトを分岐し、小さな変更を加えて、プルリクエストを元のメンテナーに送信しましたMerged pull request #11 from my_username/master。 これは私がこれをしているのは初めてなので、エチケットが今何であるのかわかりません：私はgit pull upstream masterそれからをしましたgit push origin master、そして今私自身のリポジトリの最後のコミットは私Merged pull request #11 from my_username/masterにはかなり奇妙に感じます。これは人々が通常行う方法ですか、「歴史をきれいにする」ために何かする必要がありますか？ 注：これは小さなドキュメントの変更であったため、ブランチを作成していませんでした。ブランチに変更を加えmaster、プルリクエストを送信しました。そのため、その部分で実行するクリーンアップはありません。
4
プルリクエストの作成者がマージする必要があるコードレビューワークフロー
私の会社のいくつかのチームは、今まで見たことのないコードレビューワークフローを実践しています。会社全体の一貫性を保つことには価値があるという考えで、その背後にある考え方を理解しようとしています。（私は複数のコードベースに貢献しており、過去の違いにつまずいたことがあります。） コード作成者がプルリクエストを送信する レビュアーはコードを調べます レビュー担当者が承認すると、「よさそうだ、気軽にマージしてください」という行に沿ってコメントを残します レビューアに懸念がある場合は、「マイナーな問題XおよびYを修正してからマージしてください」などのコメントを残します（大きな変更については、手順2に戻ります） コードの作成者は、必要に応じて変更を加え、自分のプルリクエストをマージします 次の懸念事項があります。 ステップ3での承認の場合、このワークフローはプルリクエストの作成者に対して一見不必要なラウンドトリップを作成します。すでにコードを見ているレビューアは、ただちにコードをマージできます。 ステップ3で変更が要求された場合、プルリクエストをマージする機関は、PRの作成者のみに任されています。著者以外の誰も、マージする前に変更を見ません。 このワークフローのその他の長所と短所は何ですか？このワークフローは他のエンジニアリングチームで共通ですか？
1
GitHubプルリクエストでピアレビューを行う方法
BitbucketからGitHubに移行していますが、私たちが苦労しているのは、次のようにBitbucketで非常にスムーズに機能するピアコードレビューです。 著者がプルリクエストを開きました（GitHub：同じ） 著者は同僚をレビュアーとして追加しました（GitHub：?? 複数の譲受人とここで苦労しています） レビュアー： 緑のチェックマークが付いたPRを承認しました（GitHub：??） コメントを追加（GitHub：同じ） 軽量タスクを作成しました（GitHub：- [ ]PRの説明で構文が使用されている場合に似ていますが、タスクでは機能しないことが残念です） 一目で確認できるPRのリストがあり、レビューされていてマージしても問題なく、さらに注意が必要なものがあります（GitHub：??） 可能な限りサードパーティのコードレビューツールを避け、何らかの回避策を備えたバニラGitHubを使い続けたいと思います。
1
誰かのプロジェクト全体を誤ってオーバーホールしました。要求をプルするための受け入れ可能な方法はありますか？
便利な中央機能を備えたGitHubで素晴らしいプロジェクトを見つけましたが、エラー処理、ロギング、構成、およびセットアップの「研磨」には大雑把です。このプロジェクトは5年間そのままで、わずか数百行のコードです。それでも、かなりの数のウォッチャーと少数のフォークに注意を向けることは十分に有用です。 私の使用には特定の追加が必要でしたが、その前にいくつかのクリーンアップを行いました。その後、エンジニアに少し夢中になり、1週間かけて、ログシステム、大量のログ、自動セットアップ、コードから外部構成ファイル（およびそれらを読み取るコード）に組み込まれた構成を追加しました。さらに、私が見つけたバグ修正もいくつかあります。 私の変更はすべて合理的/良いものであり、視聴者が使用できるようにする必要があると思います。しかし、多くのコミットがあり、レポジトリが元々持っていたのとほぼ同じ数です（この一般的なものを維持するために数を避けます）。さらに、git blameは、この（小さな！）コードベースのほぼすべての行に触れたことを示しています。私はプロジェクトの管理を求めているわけではありませんし、自分がやったことの信用を求めているわけでもありません。しかし、選択を考えると、私の未知のgithubの分岐点に隠れることなく、誰もがそれらの恩恵を受けることができるように、私の変更をマージしたいと思います。 以前にプルリクエストを送信したことはありませんが、それらは小さくてレビューしやすいはずです。しかし、ここで私は去り、多くの変革的な変化を遂げました。 コミットメントは非常にクリーンで、全体を通して歴史を慎重に扱っていました。しかし、それらの多くは必然的にそれ自体の上に構築されるため、それらを複数のブランチ/プルリクエストに分けるのは難しいでしょう。たとえば、構成の外部化はいくつかの準備的なクリーンアップに基づいて構築され、それらの構成を設定するためのセットアップが一部存在し、ログはセットアップで作成された外部構成によって有効化および構成されます。この巨大な錠剤をより美味しくするために私ができることをしてください、私はそれがどうなるかわかりません。いくつかのコミットを分割することもできますが、大規模なオーバーホールはまだ大きなものです。 誰かのプロジェクトを誤ってオーバーホールした場合、どうすればよいでしょうか？ これを行わず、自分の変更を自分のフォークに保持するように、レッスンを学ぶ必要がありますか？プルリクエストを行い、何が起こるかを確認する必要がありますか？説明で自分自身を説明する言葉をたくさん使うべきですか？特定の方法で提示する必要がありますか？
2
プルリクエストを開始するか、マスターでローカルマージコミットを実行する方が良いですか？
私はGitHubをかなり長い間使用しており、通常は機能ブランチをプッシュしてから、自分でマージしたプルリクエストを開始していました。ブランチをマージした場所を追跡するのに役立つことがわかりました。 しかし最近、Gitの仕組みについてますます読んでおり、マージコミットを使用してブランチをマージするときに参照できることに気付きました。 マスターに機能ブランチをマージするときだから、私は何をすべき： 実行し、マージコミットマスターにして、それが上流押しORローカルブランチを押して、プルリクエストを開始しますか？ 2人のチームのプルリクエストの紹介を読みました-自分のリクエストをマージしますか？そしていただきましたプロジェクトの2人との作業の流れと公式レポや私のフォーク上の枝から万一Iオープンプル要求？しかし、彼らは誰も私が探しているものに答えていないようです。
6
プルリクエストはジュニアをトレーニングする場所です
マスターへのプルリクエストのすべてのコードは、本番環境で使用できるようにする必要があるという概念があります。これは理にかなっており、私の意見では公正な声明です。 ここでの考え方は、PRを作成したら、これをマスターにしたと述べているが、一部のレビュアーがあなたと単に「同意」して、見逃したことを見つけて欲しいということです。 私たちは人間なので、間違いを犯し、他のレビュアーがユニットテストでは見つけられなかった項目を見つけることを期待しています-スペルミス、誤ったjavadocなど。 しかし、プルリクエストは、開発者に何らかのレベルの支援/トレーニングを提供する必要がある場所ですか、そうであれば、どのレベルまでですか？ 新しい変更をプッシュするたびに、レビュー担当者は変更を再レビューする必要があります。これは、開発時間からかかり、変更の再レビューを引き起こします。 それでは、プルリクエストではどのくらいのトレーニングが予想され、許可されるべきですか？私の一部は、それがジュニアからシニアまで変化すると感じます。しかし、それはジュニアにとってさえ、膨大な量の問題を見つけるための場所ではないはずだとも感じています。 開発者に「私のプルリクエストは本番環境で使用できるようにする」という目標を達成させるために苦労している人はいますか？
1
2人のチームのプルリクエストの紹介-自分のリクエストをマージしますか？
私はジュニアチームメンバー（生協）にgitを紹介しています。 追加、コミット、プッシュ、プルの基本的な操作に慣れています。 次に、プルリクエストとブランチにそれらを紹介したいと思います。 ブランチでプルリクエストを実行し始めた場合、進行中の作業にも同じことをする必要がありますか？ プルリクエストをマージするのは私です。ブランチで作業するのが最も理にかなっているかどうかはわかりませんでした（通常、私は知っている良い習慣ですが、2人の開発者が1人のジュニアといるこの特定の状況に興味があります）そしてもしそうなら、私は自分のブランチをマスターにマージするだけだということを意味します。とにかく自分の仕事/ブランチのプルリクエストを行うこともできますか？通常、これらの変更には基本的なgithub機能分岐ワークフローを使用します：https : //www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow 私が唯一の開発者である場合、自分のリポジトリでプルリクエストを使用する目的はありますか？便利ですが、それほど具体的ではありません。 プロジェクトに2人での作業の流れはいただきました！また、より一般的なようです そして 公式リポジトリまたは私のフォークのブランチからプルリクエストを開く必要がありますか？フォークについてのようです。
1
Mercurialでプルリクエストを真剣に実装できないのはなぜですか？
1週間前、私はLFNWにいて、講演後にラリーヘイスティングスと話していたとき、彼は言った（言い換え）： Mercurialにはないプルリクエストワークフローを可能にするGitの機能があります。これが、BitBucketのプルリクエストが適切でない理由です。 （コンテキストについては、file-bug-then-attach-patchワークフローとは対照的に、PRワークフローのために、PythonがMercurialからGitに移行しているという事実について議論していました。） 彼はここで何を話しているのですか？私たちのどちらもそれが何であるかの名前を思い付くことができませんでした。運が悪いのでウェブを検索しました。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.