同僚のボブと私は、一緒に完成するはずだったプロジェクトに取り組んでいます。彼の時間管理の不備により、1ヶ月以上もバグに悩まされていました。今日、ボブはいくつかのコードをマスターブランチにマージしました。
問題は、ボブがマスターブランチにマージしたコードは、私が書いたコード（一行一行）でした。私は、私が最初にコードを書いたことを証明することができますが、それは問題でさえありますか？
どのように1つは、パッシブマネージャでこの問題に対処することについて行くでしょうか？
この種の製品ではリビジョン履歴が重要なので、あなたがしたようにメインブランチにコードを切り貼りするのは避けるべきです。この種の製品ではリビジョン履歴が重要であることを心に留めておいてください。これにより、同僚の不正行為を直接非難することなく、上司に問題を認識させ、個人的な信用ではなくプロジェクトの整合性への懸念としてフレーム化することができます。
あなたはその同僚に決闘を申し込むほど怒っているように聞こえますが、多くの開発者はもっと落ち着いていて、正義を貫くための微妙なアプローチを評価しているかもしれません。
あなたの開発中のコードがmasterに表示されていることについての「懸念」をメールで伝えれば、プルを受け入れた人にメールを送ることができます。何も主張する必要はありません。あなたのコードは良いはずなのですが、あなたはテストと微調整が終わっておらず、あなたがプルリクエストを提出せずにそれがどのようにしてマスターに入ったのかについて困惑していると言ってください。私は、いくつかの技術志向の人々が紛争によってオフになって、それを掘り下げることについて彼らをあまり興奮させて見ることができますが、彼らはほぼ確実に、彼らはようであるかのようなとんでもない主張の代わりに “WTF "としてアプローチされた場合に何が起こったのかを把握したいと思うでしょう。それはあなたがとにかくより良い労働者であるように聞こえるので、時間は籾殻から小麦をふるいにかけるでしょう;寛大であり、オフィスの政治で "パンチダウン "しないでください。
Woah Betty, Let’s break down this:
Coworker stole code entirely and claims claims he wrote it all
^ That’s pretty serious. もし彼が「これは私がやった仕事だ」と言って回っているのであれば、あなたの上司に「ボブはこのマージをしただけなのに、私がこの仕事のすべての作者であることを示すために、このgithubのページを指し示してあげたい」と言ってください。私の仕事をしていないという印象を持ってほしくないから指摘しているのですが、同時に、ボブが自分がやっていない仕事を自分の手柄にしようとしているのが気になります。それとも、彼は単にmasterにブランチをマージし、誰も知らない/そのマージコミットの隣にある名前を気にしているのでしょうか？私の会社では、経営陣が何か災害のレビューをしていない限り、誰がどのコミットを書いたのかなんて誰も見向きもしませんでした。
git 以外にも、マネージャーがみんながどれだけの作業をしているかを見るために使っているプロジェクト管理ツールはありますか？もしそうなら、コミットに名前がついていても何の意味もありません。もしそうでないのなら、その管理が十分にできていないので、git の履歴を見ている人はいないと思います。
コードを持っていたのね 彼はそのコードを使って タスクを完了させた その部分は完全に受け入れられる 既存の解決策が機能しているのに解決策を書く理由はありません。あなたは、あなたのコードを含むgitコミットの中で、彼がMeやIのような言語を使ったと言及しています。Git commitsは管理ツールであってはいけませんし、作業を行ったことのクレジットを割り当てるためのツールであってはいけません。プロジェクト管理ソフトウェアやシステムが、誰が何のために何のクレジットを得るのかを管理するべきです。二人が同じタスクを担当していた場合、管理者はお互いのアイデアやコードを使うことを期待しているはずです。それが共同作業であるならば、あなたは両方とも正直に同じブランチにいるべきです。それはこの特定の事件とは別に対処されるべきです。現時点では、これは一度しか起こっていないように聞こえます。私はしばしば同僚のコードをコミットし、同僚に私のコードをコミットさせたことがあります。もし気になるのであれば、git の履歴が重要で、コミットされたコードに自分の名前を付けてほしいということを気軽に伝えてください。もしコードにバグがあった場合は、彼を不当に責められたくないと主張しましょう。
もし彼が仕事でのパフォーマンスの悪さを続けているのであれば、管理職に彼のパフォーマンスについて話しましょう (コミットのことではなく)。彼のコミットがあなたのコードをよく使っていることに言及することはできますが、それだけでは何も本質的に悪いことはないので、それがポイントにならないようにしてください。あなたのコードだからといって、彼のスキルや労働倫理を評価するためにコミットを使うべきではないということを明確にする必要があるだけです。
あなたがこれを報告するときにも、同様に、それが書面/電子メールであることを確認してください、あなたが後でそれを参照する必要がある場合は、あなたはそれが非常によく、これが起こったことを文書化されている必要がありますし、苦情が行われました。
あなたの目標は、あなたが書いたコードのクレジットを確実に得ることですか？
コードが「あなたのもの」であるという考えは、一般的には、あなたが会社のために行う仕事について考えるのに適した方法ではありません。あなたが書いたコードはあなたのものではなく、会社のものです。コードがあなたのブランチからコミットされたものであろうと、ボブのブランチからコミットされたものであろうと、違いはないはずです。あなたとボブは、製品に必要なタスクを完了させるという共通の目標を持っています。
上司が、あなたが自分の力を発揮していないのにボブが力を発揮していると信じているのは一つのことですが、あなたの質問は、あなたが奪われたように感じているように聞こえます。しかし、あなたの上司がコミットログを見て、あなたとボブがそれぞれ十分な作業をしていることを確認していない限り、私はこの状況について何かをする必要性を感じないでしょう。変更点をマージすることで、変更点をコピー/ペーストするよりも、より良いリビジョン履歴を得ることができたでしょう。このことを彼に説明し、その理由を説明するのは合理的です。しかし、質問の中にある情報からすると、これは正式に何かを書き上げて、あなたの上司のコピーを確実に取る必要がある問題ではありません。ただ、さりげなくその旨を伝えればいいのです。
なぜこのようなことが起こるのかを正確に知るために git をよく理解しているわけではありませんが、IDE を使ってマージの衝突を解決しようとしたときに Visual Studio がローカルリポジトリにコミットを作成してしまうことがあります。これは、リモートリポジトリへのすべての変更を自分のリポジトリに適用してコミットし、そのコミットをリモートリポジトリに適用したと履歴に表示されます。
ここでの合理的な説明は、Bob がマージのプロセスを理解せずにクリックしてしまったために、誤解を招くようなソースコントロールの履歴が生成されてしまったということです。その仮定の上で、どのように適切にマージするかを教育するために、彼に問い合わせて、問題が間違いであることを疑ってもらうようにしてください。
まず、何が問題なのかを_特定してください。
もし問題があなたの名前がGitの履歴から削除され、彼の名前に置き換えられているのであれば、それはハウスキーピングの問題であり、同僚の悪意のある行動の兆候ではありません。もし同僚が一ヶ月もバグに悩まされているのなら、それは彼らがバージョン管理を含めたツールの使い方に少し錆びついている可能性をkind of示唆していることになります。これはプライドの問題でもなければ、あなたに借りがあるという信用の問題でもありません - 誰がどのコードを書いたのか、将来バグや奇妙なデザイン決定に遭遇したときに誰に相談すればいいのかを知るために、あなたはその履歴をそのままにしておく必要があります。もしあなたの名前が書かれていないのであれば、あなたの同僚があなたのコードについて質問を受け、バグの責任を取ることになります！
IDEやソース管理ツールを使ってコードに注釈をつけ、彼の名前が実際にすべての行に書かれているかどうかを確認してください。一般的に、誰がコードをマージしたかは問題ではありません - 名前が出るのはそのコミットだけで、そのコミットの全行に名前があるわけではありません。もし彼が正しくブランチをマージしていなければ、それは破綻してしまいます。
もしあなたが「どれだけのコードを書いたか」ということが、昇進のために使われるような組織で働いているのであれば、このことを経営陣に報告すべきです。彼は私から盗んだ」（彼がやったことを知らない）とは言わず、「もしあなたが昇給や昇進のために私たちのメリットを評価するためにソース管理の履歴を見ているのであれば、彼のマージによって私が何も貢献していないように見えるのではないかと心配している」と言ってください。私の場合（ほとんどのプロフェッショナルなソフトウェア会社では普通だと思いますが）、自分が書いたコードから自分の名前が消えてしまうことは、半端なく嬉しいことでした。これで、何ヶ月も前に私が書いたコードの中で行った愚かな決定について質問されることがなくなりました。:)
正直なところ、提供された詳細を考えると、誰もが「報告しろ！」と言っているのは、私には大きな過剰反応のように思えます。
私の同僚と私は、2年以上プロジェクトで働いていました。私のアドバイスは、何らかの形での報いを求めて命令系統を駆け上がらないことです。もしそれがあなたにとって大きな問題であるならば、あなたのマネージャーと話し合って、物事のクレジットを決定する方法について話し、彼らが説明する方法で文書化してください。
私が最も取り上げたかったポイントは、あなたの同僚との関係です。私の正直な意見としては、もし私の同僚がある日私のところに来て、「私のコードを使うな！」と叫んだとします。私のコードだよ！」と言って、私が故意でも悪意でもないことを理由に経営陣とトラブルになったとしたら、私は彼のことを自分勝手なバカだと思うでしょう。私はこのことを心に留めておきたいと思います。なぜなら、質問からは、彼らが本当にあなたのコードを盗んだのか、それとも変な方法で変更をマージしただけなのかがはっきりしないからです。あなたが正しいなら大したことはありません。私は「自分の墓穴は自分で掘る」タイプの考え方が好きですが、もしあなたが間違っていたら、仕事上の関係に与えるダメージは相当なものになるかもしれません。オフィスの政治は厄介なものです！
もしあなたが彼が盗みをしていて、彼がしていないことの手柄を取っていることに絶対的に確信があるならば、あなたのマネージャーに連絡して、彼がそのような行為で叱責されることを確認するための適切な措置を取ることは自由です - しかし、もしあなたが本当に確信がないならば、おそらく再考してください。盗作は軽々しく主張するものではありません。特に、それがかなり長い間、あなたの日常生活に影響を与える可能性がある場合には。
しかし、彼らの意図を非難してはいけません。
何が事実上起こったかというと、彼らはあなたのコードをあたかも自分のものであるかのようにマージしたということです。これはあなたを馬鹿にするための個人的な復讐のために行われたのかもしれませんが、それは意図を告発するものであり、証明するのはずっと難しく、あなたが投稿したものだけを見れば、あなたの同僚の悪意を示すものは何もありません。
彼が git を正しく使う方法について無知であると仮定して、これを教えることに集中しましょう。Git には、開発者が他の開発者のコードを再利用するための多くの方法が用意されています。ここでの主なツールは merge と cherry-pick コマンドです。
プロジェクトではメタデータと履歴のオーサリングを保存することが重要であることを意識するように伝えましょう。
オーサーシップのようなメタ情報が git のようなバージョン管理システムに存在するのは、ownership を追跡するためではなく、何かがどのようにして今のような形になったのかを理解するためです。
リファクタリングのようなことや、新しく確立された空白のルールをコードのブロックに適用することも、git が新しいオーサリングとみなすものを含むことになります。
他の多くのケースでは、ある新しい問題の解決策を、会社のコードベース内の古い問題の解決策からコピーしたコードをベースにしているように見えますが、VCS を見る限りでは本物の新しいオーサリングのように見えます。
完璧とは程遠いですが、私は既存の作業(特に誰か他の人のものを移設したり、大幅に作り直したりしたもの)の大部分に基づいてコミットを作成するときには、コミットメッセージの中でその由来を言及するようにしています。これは多少なりとも信用を得るためのものですが、それ以上に 他のコードとの関係を記録するためのものです。例えば、新しい使用法にバグが見つかった場合、そのコードがコピーされた場所にもバグが存在するかどうかをチェックする価値があります。
このことを考えると、コードレビュープロセスを使って、論争のあったコードの最終的なマージを、そのコードの実際の起源を記述した、より説明的なメッセージの下で行うようにするのが、良い行動でしょう。そして、貢献の「所有権」を維持するためではなく、コードがどこから来たのか、他のコードとの関係がどうあるのか、そして、困難な場合には誰からの入力を求めるべきかのより完全なリストを持つための知識を維持するために、この議論をすることです。
これに気づいているかどうかはわかりませんが、ソースコード管理システムを持っていて、二人の人が同じ変更をした場合、"マージコンフリクト “がたくさん発生し、マージに時間がかかり、エラーが発生しやすい作業になってしまいます。
だから、次のチームミーティングでいろいろなことが議論されたときに、「…そして将来的には、誰も私のブランチから不完全な変更を取り除いてメインブランチにマージしてくれないとありがたい。私はこのためにマージの競合を解決するために何時間もの作業を無駄にしました。これで、あなたの上司が誰がそんな無意味なことをしたのか聞いてくる可能性は十分にありますし、密告者のように見られることなく上司の名前を挙げることができるようになりました。
彼のコードをマージするには、彼が書いたことを明記してください。GITの仕組みを知らず、自分の変更に同期するのを忘れていたようです。他の人のコードは、ソースツリーのようなツールで自動的に生成されています。一ヶ月間バグに滞在したことがない）と私は変更をマージするときには、私のbugfixに加えて、他の人からの以前のコードを含めてマージすると具体的に言っています。テストしてください。その後、自分のブランチをマージし直します。そうすることで変更履歴を残すことができます。
もし彼がマージせずにあなたのブランチからコードをコピーして提出した場合、彼はさらに悪いことをしています。
私はコミットポリシーを導入して、全員がそのポリシーを尊重するように強制したいと思います。私はむしろ彼のGITスキルの方が心配です。それはハボックを引き起こす可能性があります。
はい、私の身にも一度だけ、とても変わった同僚と同じことが起こりました。ある日、QA担当者が私のコードがこの同僚と全く同じに見えると言いました。GitHubにログインしてみて、私のコードが不気味に似ていることに気付きましたが、最初は「同じファイルを共有している複数のサイトをホストしているから、同じことをしているからコードが同じなのではないか」と思っていたのですが、そのうちに「同じファイルを共有しているサイトをホストしているから、同じことをしているだけだ」と言われてしまいました。
時間が経つにつれ、私はその同僚がスプリントの最終日まで毎日のスタンドアップで「コードのリファクタリング」に取り組んでいると言っていたのを観察し、その後、彼女のコードは最終日に準備ができていないと言い、追加の日を必要とし、不思議なことに翌日には数百行のコードがプルリクエストでプッシュされていました。私はコードを見て、そのコードが私のコードと似ていることに気付きました。そして、私はその人が私のブランチをプッシュアップするまで待っていたことに気づき、彼女はそれを観察してコピーしていました。主に、その同僚は、私が喜んで助けるか、指示するかを尋ねるために私のところに来なかったからです。それは私が気にしていないように見えたマネージャーにそれを持ってきた後、私は会社を辞めることを決めた数少ない理由の一つでした。**私のアドバイスは、マネージャーにそれを持って来ることです、あなたが偶然に複製することができなかったことを証明することができるスペルミスを入れてください。そうすれば、単なる偶然の一致ではないと言えるでしょう。