Coworker apresentou o meu código como seu

Deve enviar-lhe um e-mail dizendo algo do género:

Vejo que empurrou o código da minha sucursal para a sucursal principal. Por favor tenha em mente que o histórico de revisões é importante neste tipo de produtos, por isso ter o código cortado e colado na filial principal, como fez, deve ser evitado; em vez disso, o código deve ser empurrado da filial em que foi desenvolvido.

e cc o seu gerente. Isto sensibilizará o seu gestor para o problema sem acusar directamente o seu colega de má conduta e enquadra-o como preocupação pela integridade do projecto e não pelo crédito pessoal.

Não é ilegal como num tribunal, mas é errado e o seu gestor deveria saber. Diga-lhe que, se ele o fizer novamente, o senhor deputado o denunciará novamente.

Você parece zangado o suficiente para desafiar o colega de trabalho para um duelo, mas muitos dos desígnios são mais moderados e poderiam apreciar uma abordagem mais subtil para obter justiça.

Você poderia enviar um e-mail a quem quer que aceitasse a atracção com as suas “preocupações” sobre o seu código ainda em desenvolvimento aparecendo no master. Não tem sequer de fazer alegações; deixe-os “descobrir” o que aconteceu por si próprios. Diz que o teu código deve ser bom, mas ainda não acabaste os testes e ajustes, e estás intrigado/concertado com a forma como ele se tornou mestre sem que submetas um pedido de puxar.

Isto remove a maior parte do drama, mas preserva uma boa possibilidade para o teu colega de trabalho ser repreendido, uma vez que eles descubram como é que o código chegou indevidamente ao mestre. Posso ver algumas pessoas de espírito técnico a serem desligadas pelo conflito, tornando-as menos entusiasmadas com a investigação, mas quase de certeza que vão querer descobrir o que aconteceu se forem abordadas como uma “WTF” em vez de uma alegação aparentemente ultrajante.

Se as coisas forem como se diz, a investigação será breve e conclusiva. Parece que, de qualquer forma, é um trabalhador melhor, por isso, o tempo vai peneirar o trigo do joio; seja magnânimo e não “esmurre” na política de escritório.

Woah Betty, vamos decompor isto:

Coworker roubou o código por completo e afirma ter escrito tudo

^ Isso é muito sério. Se ele anda por aí a dizer às pessoas “este é o trabalho que eu fiz”, então com certeza diga ao seu gerente “Ei, eu só gostaria de o apontar para esta página do github para mostrar que eu sou o autor de todo este trabalho, enquanto o Bob só fez esta fusão. Estou a apontar porque não quero que tenham a impressão de que não tenho feito a minha parte do trabalho e, ao mesmo tempo, incomoda-me que o Bob esteja a tentar ficar com os louros do trabalho que não fez”

But

Hoje, o Bob fundiu algum código no nosso ramo principal.

O Bob está mesmo “a dizer” que escreveu tudo? Ou será que ele simplesmente fundiu um ramo em mestre, e ninguém sabe/cuida-se do nome que está ao lado desse compromisso de fusão? Na minha empresa, a menos que a gerência estivesse a rever algum desastre, ninguém olharia para quem é o autor desse compromisso.

Além do git, existe alguma outra ferramenta de gestão de projectos que o seu gestor utilize para ver o trabalho que todos estão a fazer? Se assim for, um nome num compromisso não significa nada. Se não, então a gerência é suficientemente pobre para que eu não pense que alguém esteja a ver o histórico do git em qualquer caso.

O senhor tinha código. Ele usou esse código para completar a sua tarefa. Essa parte é perfeitamente aceitável. Não há razão para escrever uma solução quando uma solução existente funciona.

O senhor queria crédito pelo código. Mencionou que ele usou uma linguagem como Eu e eu no git commits contendo o seu código. O Git commits não deve ser uma ferramenta de gestão, ou uma ferramenta para atribuir créditos pelo trabalho feito. O software de gestão de projectos ou sistema a ser utilizado deve lidar com quem recebe crédito pelo quê. Se ambos foram atribuídos à mesma tarefa, a gerência provavelmente espera que vocês usem ideias e códigos um do outro. Ambos devem estar honestamente no mesmo ramo se for uma tarefa conjunta.

A verdadeira questão é a sua preocupação com as suas competências e/ou ética de trabalho. Isso deve ser tratado separadamente deste incidente em particular.

Deve falar primeiro com o seu co-trabalhador. Neste momento, parece que isto só aconteceu uma vez. Já cometi muitas vezes o código dos meus colegas de trabalho e deixo os colegas de trabalho cometerem o meu código. Mas se lhe diz respeito, sinta-se à vontade para lhe dizer que a história do idiota é importante e que gostaria que o seu nome fosse anexado a qualquer código que tenha cometido. Insista que se houver um erro no código, não quer que ele seja falsamente culpado.

Se ele continuar a ter um mau desempenho no seu trabalho, fale com a gerência sobre o seu desempenho (não sobre os commits). Pode mencionar que os commits dele usam frequentemente o seu código, mas não faça disso um argumento, porque não há nada de intrinsecamente errado nisso por si só. Você só precisa esclarecer que eles não devem usar os commits para avaliar a sua habilidade ou ética de trabalho porque é o seu código.

Relate isto à gerência. Leia também o manual do colaborador da sua empresa, eles provavelmente têm uma política sobre comportamento antiético e qual é também o seu processo de reportar.

Quando reportar isto, também, ** certifique-se que é por escrito / um e-mail*** , como se precisasse de o referir mais tarde, deve ter muito bem documentado que isto aconteceu e que foi feita uma queixa.

O seu objectivo é certificar-se de que obtém crédito pelo código que escreveu?

A ideia de o código ser “seu” não é geralmente uma boa maneira de pensar no trabalho que faz para a empresa. O código que escreves não te pertence; pertence à empresa. Não deve fazer diferença se o código foi cometido pela sua sucursal ou pela sucursal do Bob. Você e o Bob têm um objectivo comum de completar as tarefas que são necessárias para o produto.

Uma coisa é se o seu gerente acredita que você não está a puxar o seu peso mas o Bob está, mas a sua pergunta faz com que pareça mais que você se sente roubado.

Alguns dos comentários abordaram esta questão; mas as respostas (especialmente a resposta aceite) parecem ir numa direcção muito diferente. A linha de acção correcta depende dos seus objectivos reais; mas a menos que o seu gestor esteja a rever os registos de compromisso para se certificar de que você e o Bob estão a fazer trabalho suficiente, então eu não sentiria necessidade de fazer nada acerca desta situação.

Parece que a pior coisa que o Bob fez aqui foi não seguir as melhores práticas com a forma de usar o controlo da fonte. A fusão nas suas alterações teria permitido um melhor histórico de revisões do que copiar/colar as suas alterações. É razoável explicar-lhe isto, e explicar-lhe as razões porquê. Mas a partir da informação que temos na pergunta; não se trata de uma questão em que tenha de escrever formalmente algo e certificar-se de que copia o seu director. Basta mencioná-lo casualmente.

Isto soa como uma fusão que se tornou um fracasso; não pretendo entender bem o suficiente para saber exactamente porque é que isto acontece, mas o Visual Studio por vezes cria compromissos no repositório local quando se usa o IDE para resolver conflitos de fusão. Isto aparece no histórico como tendo levado todas as alterações ao repositório remoto, aplicando-as ao próprio repositório, submetendo-as e depois aplicando esse commit ao repositório remoto.

A explicação racional aqui é que o Bob clicou no processo de merge sem realmente o compreender e gerou um histórico de controlo de origem que é enganador. Trabalhando nesse pressuposto, questione-o com ele com a intenção de o educar sobre como fundir adequadamente, dando o benefício da dúvida sobre o assunto sendo um erro.

Primeiro, identificar qual é o problema. Não é totalmente claro a partir da sua pergunta tal como foi feita.

Se a questão é que o seu nome foi riscado do histórico de Git (assumindo que está a usar Git) e substituído pelo dele, isso é um problema de limpeza da casa e provavelmente não é um sinal de comportamento malicioso por parte do seu colega de trabalho. Se um colega de trabalho estiver preso a um bug durante um mês que uma espécie de sugere que pode estar um pouco enferrujado com o uso das suas ferramentas - incluindo o controlo de versões.

O seu nome deve estar em todo o código que escreveu. Isto não é uma questão de orgulho ou de receber crédito que lhe é devido - precisa dessa história intacta para que as pessoas saibam quem escreveu que linha de código e com quem falar quando encontrarem bugs ou decisões de design estranhas no futuro. Se o seu nome já não estiver nele, então o seu colega de trabalho é quem tem de colocar questões sobre o seu código e assumir a culpa pelos seus bugs!

Use o seu IDE ou uma ferramenta de controlo de fontes para anotar o código e ver se o seu nome está realmente em todas as linhas. Em geral, não importa quem fundiu o código - o seu nome só vai naquele commit, não em todas as linhas de código naquele commit. Isso desmorona-se se ele não fundiu correctamente as filiais para que isso acontecesse, e isso é algo que ele precisa de fazer correctamente.

Se você trabalha numa organização onde “quanto código eu escrevi” é uma métrica que eles seguem e eles usam-na para fins de promoção, então você deve levar isto à gerência. Não digam “ele roubou-me” (não sabem que ele o fez), digam “estou preocupado que se estão a olhar para o nosso histórico de controlo de fontes para avaliar o nosso mérito para aumentos e promoções, a sua fusão faz parecer que eu não contribuí nada”.

Isto depende muito da dinâmica da vossa empresa. No meu caso (que penso ser a norma para a maioria das empresas de software profissional), eu ficaria semi-desenvolvido para que o meu nome desaparecesse do código que escrevi… Agora não tenho pessoas a fazer-me perguntas sobre decisões tolas que tomei no meu código meses antes! :)

Honestamente, tendo em conta os detalhes fornecidos, todos os que dizem reportar! parece-me uma grande reacção exagerada.

O meu colega e eu trabalhámos num projecto durante mais de 2 anos a trocar compromissos para trás e para a frente, e sim , por vezes reutilizávamos ou optimizávamos o código uns dos outros.

Não sei em que tipo de cultura se trabalha, mas se, de alguma forma, define o trabalho em linhas de código em vez de produto final e contribuição global, parece bastante tóxico e competitivo. O meu conselho seria que você não corra pela cadeia de comando à procura de alguma forma de retribuição. Se é assim tão importante para si falar com o seu Manager sobre como determinar o crédito pelas coisas e depois documentar da forma que descrevem.

O ponto que mais queria abordar era a sua relação com o seu colega. Na minha sincera opinião, se um dia o meu colega de trabalho se aproximasse de mim e exclamasse: “Não uses o meu código! É my code!”, e depois me meteu em problemas com a gestão por algo que eu não estava a fazer de propósito ou maliciosamente, eu pensaria que ele era um idiota auto-importante. Eu teria isto em mente, porque a partir da questão não é claro se eles realmente roubaram ou não o seu código, ou talvez estivessem apenas a fundir-se em mudanças de uma forma estranha.

A acusação (que é uma grande acusação a fazer ) - se não arruinar completamente a sua relação profissional, irá certamente diminuir a sua opinião pessoal sobre si. Nada de mais, se estiver certo. Sou um fã do tipo “cavas a tua própria sepultura” - mas se estiveres _ errado_, os danos na tua relação de trabalho podem ser bastante substanciais. Política de escritório é uma coisa complicada!

Agora, se tem a certeza absoluta de que ele está a roubar e a ficar com os louros por coisas que não fez, sinta-se à vontade para contactar o seu Manager e tomar as medidas apropriadas para se certificar de que ele é repreendido por esse tipo de comportamento - no entanto, _ se não tem a certeza absoluta_, talvez reconsidere. O plágio não é algo a reclamar de ânimo leve, especialmente quando pode afectar o seu dia-a-dia durante muito tempo.

Erga uma discussão com o seu colega de trabalho e gerente sobre o que de facto acontece, mas não os acuse da sua intenção.

O que de facto acontece é que eles fundiram o seu código como se fosse o seu próprio código. Isto pode ter sido feito por vingança pessoal para o fazer parecer um tolo, mas isso é uma acusação de intenção, o que é muito mais difícil de provar, e com base naquilo que publicou não há nada que indique qualquer intenção maliciosa do seu colega de trabalho.

Concentre-se em fazer disto um momento de ensino, assumindo a sua ignorância sobre as formas de usar correctamente o git. Git fornece muitas formas de permitir a um programador reutilizar o código de outro programador enquanto preserva a autoria. As duas principais ferramentas aqui são o comando merge e cherry-pick.

Diga a eles para estarem cientes de que preservar metadados e a autoria da história é importante no projeto.

Meta-informação como a autoria existe num sistema de controlo de versões como o git não tanto para rastrear a propriedade mas mais para ajudar a entender como algo tem de ser como é.

Embora os fluxos simples de compromissos tenham fusões de compromissos com autoria individual, há muitos casos em que isto não funciona, ou não capta a história completa nos campos de objectivo fixo de um compromisso.

Algo como refactoring ou mesmo a aplicação de regras de espaço em branco recentemente estabelecidas a um bloco de código envolve o que o git considera ser uma nova autoria, uma vez que o git apenas entende detalhes literais, não significando. E isso é apenas nos casos em que o código continua a ser utilizado na sua função original e localização exata do arquivo.

Muitos outros casos, como basear a solução para um novo problema em código copiado da solução de um problema antigo dentro da base de código de uma empresa, procura por todo o mundo um VCS como genuíno, nova autoria.

Embora longe de ser perfeito fazê-lo, quando crio um compromisso baseado em grande parte no trabalho existente (especialmente o de outra pessoa ou deslocalizado ou substancialmente retrabalhado) tento mencionar a sua origem na mensagem de compromisso. Isso é de algum modo digno de crédito, mas tanto ou mais para criar um registo da relação com outro código*. Assim, por exemplo, se for encontrado um bug na nova utilização, vale a pena verificar se ele também existe no local de onde o código foi copiado.

Dado isto, um bom curso de acção poderia ser tentar utilizar um processo de revisão do código para que a fusão final do código contestado seja feita sob uma mensagem mais descritiva, que descreva as suas origens reais. E fazer este argumento não tanto para preservar a “propriedade” da contribuição, mas para preservar o conhecimento de onde o código veio, qual a sua relação com outro código e ter uma lista mais completa de quem procurar em caso de dificuldade.

Não sei se já repararam nisto, mas quando tiverem um sistema de controlo do código fonte e duas pessoas fizerem alterações idênticas, terão muitos “conflitos de fusão” que transformam a fusão numa operação morosa e sujeita a erros.

Assim, na próxima reunião de equipa, onde todo o tipo de coisas são discutidas, podem dizer “… e no futuro, agradecia que ninguém pegasse nas alterações incompletas da minha sucursal e as fundisse na sucursal principal. Perdi horas e horas de trabalho na resolução de conflitos de fusão por causa disto”. É bem possível que o seu chefe pergunte então quem fez esse tipo de disparate, e agora pode dar nomes ao chefe sem se parecer com um bufo.

Fundir o seu código, especificando que ele o escreveu. Gerir-se a si próprio é uma estratégia viale. parece que ele não sabe como funciona o GIT e esqueceu-se de se manter em sintonia com as suas mudanças. Commits with all’ the code of other people are automatically generated by tools like source tree in case of people using poor merging strategy

O que está errado é especificar “o meu código” na descrição comunità.

Quando sou atingido num bug por um dia ( um mês parece demasiado. Nunca fiquei num bug durante um mês) e eu fundo alterações, digo especificamente que a fusão inclui a minha correcção de bug mais o código anterior de outros, e mesmo assim não parece que eu tenha cometido código de outros.

Se o seu colega de trabalho está a trabalhar numa sucursal, deve primeiro fundir a sucursal principal na sua própria. Teste. Depois funda a sua sucursal de volta. Se ele começar a copiar o código da sua sucursal sem fundir e depois submeter, ele está a fazer ainda pior. Ele está a trabalhar em torno de versões potencialmente introduzindo novos bugs.

Eu introduziria uma política de compromisso para seguir e forçar todos a respeitar a política. Eu preferia estar mais preocupado com a sua habilidade em GIT. Poderia causar o havok

Sim, já me tinha acontecido isto uma vez com um colega de trabalho muito invulgar. Um dia, uma pessoa de GQ disse-me que o meu código é exactamente igual ao desse outro colega de trabalho. Entrei no GitHub e reparei que o código é estranhamente parecido com o meu, mas, no início, retirei a ideia de que talvez, uma vez que alojamos vários sites que partilham o mesmo ficheiro, o código é simplesmente o mesmo, uma vez que faz a mesma coisa.

Com o tempo observei a colega de trabalho dizer que ela estava a trabalhar em “refactoring the code” durante os standups diários até ao último dia do sprint, depois diz que o seu código não está pronto no último dia e precisa de um dia adicional, e misteriosamente no dia seguinte centenas de linhas de código foram empurradas para cima num pedido de puxar. Eu olhei para o código e reparei que o código é semelhante ao meu, até a um erro ortográfico que eu cometi. Depois percebi que a pessoa estava à espera até que eu empurrasse a minha filial para cima e ela observava e copiava coisas dela.

Eu estava tão furioso como tu. Principalmente porque a colega de trabalho não veio até mim para me perguntar o que eu de bom grado ajudaria ou dirigiria. Foi uma das poucas razões pelas quais decidi deixar a empresa depois de a ter apresentado a um gerente que parecia não se importar. O meu conselho é que o levem a um gerente, pondo um erro ortográfico que se possa provar que não pode ser duplicado por acaso. Assim, pode dizer-se que não é uma mera coincidência.