Un collega ha presentato il mio codice come suo

Dovresti mandargli un'email dicendogli qualcosa del tipo:

Vedo che hai spinto il codice dal mio ramo al ramo principale. Vi prego di tenere presente che la storia delle revisioni è importante in questo tipo di prodotti, per cui il codice tagliato e incollato nella filiale principale, come avete fatto voi, dovrebbe essere evitato; piuttosto, il codice dovrebbe essere spinto dalla filiale su cui è stato sviluppato.

e cc il vostro manager. Questo renderà il vostro manager consapevole del problema senza accusare direttamente il vostro collega di cattiva condotta, e lo inquadra come una preoccupazione per l'integrità del progetto piuttosto che come un credito personale.

Lo riferirò sicuramente al vostro manager con la prova che l'avete scritto voi per primi.

Non è illegale come in un tribunale, ma è sbagliato e il vostro manager dovrebbe saperlo. Ditegli che se lo fa di nuovo lo denuncerete di nuovo.

Sembri abbastanza arrabbiato da sfidare il collega a duello, ma molti sviluppatori sono più docili e potrebbero apprezzare un approccio più sottile per ottenere giustizia.

Potresti mandare un'email a chi ha accettato il tiro con le tue “preoccupazioni” sul tuo codice ancora in sviluppo che appare su master. Non dovete nemmeno fare alcuna accusa; lasciate che “capiscano” cosa è successo da soli. Dite che il vostro codice dovrebbe essere buono, ma non avete finito di testare e modificare, e siete perplessi/interessati su come sia diventato master senza che voi abbiate presentato una richiesta di pull.

Questo elimina la maggior parte del dramma, ma conserva una buona possibilità per i vostri colleghi di essere rimproverati, una volta che hanno capito come il codice sia finito su master in modo inappropriato. Vedo che alcune persone con una mentalità tecnica che viene disattivata dal conflitto, rendendoli meno entusiasti di scavarci dentro, ma vorranno quasi sicuramente capire cosa è successo se affrontati come “WTF” invece che come un'apparente accusa oltraggiosa.

Se le cose stanno così, l'indagine sarà breve e conclusiva. Sembra che tu sia comunque un lavoratore migliore, quindi il tempo setaccerà il grano dalla pula; sii magnanimo e non fare “pugni” in politica d'ufficio.

Woah Betty, analizziamo la situazione:

Il collega ha rubato il codice interamente e afferma di averlo scritto tutto

^ È una cosa piuttosto seria. Se va in giro a dire alla gente “questo è il lavoro che ho fatto”, allora di sicuro dite al vostro manager “Ehi, vorrei solo indicarvi questa pagina github per dimostrare che sono l'autore di tutto questo lavoro, mentre Bob ha fatto confluire solo questo. Lo faccio notare perché non voglio che tu abbia l'impressione che io non abbia fatto la mia parte di lavoro, e allo stesso tempo mi preoccupa che Bob stia cercando di prendersi il merito per il lavoro che non ha fatto”

Ma

Oggi, Bob fonde un po’ di codice nella nostra filiale principale.

Davvero Bob “sostiene” di aver scritto tutto lui? O ha semplicemente fuso un ramo in master, e nessuno sa/si preoccupa di quale sia il nome accanto a quel commit merge? Nella mia azienda, a meno che il management non stesse esaminando un qualche disastro, nessuno guarderebbe chi ha scritto quale commit.

Oltre a git, c'è qualche altro strumento di project management che il tuo manager usa per vedere quanto lavoro stanno facendo tutti? Se sì, un nome su un commit non significa nulla. Se no, allora il management è talmente povero che non credo che nessuno guarderebbe la storia di git in ogni caso.

Avevi un codice. Ha usato quel codice per completare il suo compito. Quella parte è perfettamente accettabile. Non c'è motivo di scrivere una soluzione quando una soluzione esistente funziona.

Volevi credito per il codice. Hai detto che ha usato un linguaggio come me e me nel git commits contenente il tuo codice. Git commits non dovrebbe essere uno strumento di gestione, o uno strumento per assegnare il credito per il lavoro svolto. Il software di gestione del progetto o il sistema utilizzato dovrebbe gestire chi si prende il credito per cosa. Se entrambi siete stati assegnati allo stesso compito, la direzione probabilmente si aspetta che usiate l'uno le idee e il codice dell'altro. Se si tratta di un compito congiunto, dovreste essere entrambi nello stesso ramo in modo onesto.

Il vero problema è la vostra preoccupazione per le sue competenze e/o la sua etica del lavoro. Questo dovrebbe essere affrontato separatamente da questo particolare incidente.

Dovreste prima parlare con il vostro collega. Al momento, sembra che sia successo solo una volta. Ho spesso impegnato il codice dei miei colleghi e lascio che siano i colleghi a farlo. Se riguarda te, però, sentiti libero di dirgli che la storia del git è importante e che vorresti che il tuo nome venisse allegato a qualsiasi codice che è stato commesso. Insistete sul fatto che se c'è un bug nel codice, non volete che sia falsamente incolpato.

Se continua a svolgere male il suo lavoro, parlate con il management delle sue prestazioni (non degli impegni). Potete dire che i suoi commit spesso usano il vostro codice, ma non fatene un caso, perché non c'è davvero nulla di intrinsecamente sbagliato in questo. Dovete solo chiarire che non dovrebbero usare i commits per valutare la sua abilità o l'etica del lavoro perché è il vostro codice.

**Leggere anche il manuale per i dipendenti della vostra azienda, che probabilmente hanno una politica sul comportamento non etico e su quale sia il loro processo di segnalazione.

Quando segnalate anche questo, assicuratevi che sia per iscritto / un'e-mail , come se aveste bisogno di farvi riferimento in seguito, dovreste avere una documentazione molto ben documentata che questo è accaduto e che è stato fatto un reclamo.

Il vostro obiettivo è quello di assicurarvi di ottenere credito per il codice che avete scritto?

L'idea che il codice sia “vostro” non è generalmente un buon modo di pensare al lavoro che svolgete per l'azienda. Il codice che scrivi non ti appartiene, ma appartiene all'azienda. Non dovrebbe fare alcuna differenza se il codice è stato commesso dalla vostra filiale o dalla filiale di Bob. Lei e Bob avete un obiettivo comune per completare qualsiasi compito sia necessario per il prodotto.

Una cosa è se il suo manager crede che lei non stia facendo la sua parte, ma Bob sì, ma la sua domanda fa sembrare più che altro che lei si senta derubato.

Alcuni dei commenti hanno affrontato questo aspetto; ma le risposte (soprattutto la risposta accettata) sembrano andare in una direzione molto diversa. La giusta linea d'azione dipende dai vostri obiettivi reali; ma a meno che il vostro manager non stia esaminando i registri dei commit per assicurarsi che voi e Bob stiate facendo abbastanza lavoro, allora non sentirei il bisogno di fare nulla per questa situazione.

Sembra che la cosa peggiore che Bob abbia fatto qui sia stata quella di non seguire le migliori pratiche su come usare il controllo delle sorgenti. L'unione delle vostre modifiche avrebbe permesso una migliore storia di revisione rispetto al copia/incolla delle vostre modifiche. È ragionevole spiegarglielo e spiegargli le ragioni. Ma dalle informazioni che abbiamo nella domanda; questo non è un problema per il quale è necessario scrivere formalmente qualcosa e assicurarsi di copiare il proprio manager. Basta menzionarglielo casualmente.

Questo suona come una fusione che è andata a puttane; non pretendo di capire abbastanza bene il git per sapere esattamente perché questo accade, ma Visual Studio a volte crea dei commit sul proprio repository locale quando si usa l'IDE per risolvere i conflitti di fusione. Questo appare nella storia come se avesse preso tutte le modifiche al repository remoto, applicandole al proprio repository, effettuando il commit, e poi applicando quel commit al repository remoto.

La spiegazione razionale qui è che Bob ha cliccato attraverso il processo di merge senza comprenderlo veramente e ha generato una storia di controllo dei sorgenti che è fuorviante. Lavorando su questo presupposto, interrogatelo insieme a lui con l'intenzione di educarlo su come eseguire correttamente la fusione, dando il beneficio del dubbio che il problema sia un errore.

Per prima cosa, identificare qual è il problema. Non è del tutto chiaro dalla tua domanda come è stata fatta.

Se il problema è che il tuo nome è stato cancellato dalla cronologia di Git (supponendo che tu stia usando Git) e sostituito con il suo, questo è un problema di gestione della casa e probabilmente non è un segno di comportamento maligno da parte del tuo collega. Se un collega è rimasto bloccato su un bug per un mese che _può suggerire che potrebbe essere un po’ arrugginito nell'uso dei suoi strumenti - incluso il controllo di versione.

Il tuo nome dovrebbe essere su tutto il codice che hai scritto. Non è una questione di orgoglio o di ricevere crediti che ti sono dovuti - hai bisogno che la storia sia intatta in modo che la gente sappia chi ha scritto quale linea di codice e con chi parlare quando incontrerà dei bug o delle strane decisioni progettuali nel futuro. Se non c'è più il vostro nome, allora è il vostro collega a dover rispondere alle domande sul vostro codice e a prendersi la colpa per i vostri bug!

Usate il vostro IDE o uno strumento di controllo dei sorgenti per annotare il codice e vedere se il suo nome è effettivamente su ogni riga. In generale, non importa chi ha unito il codice - il loro nome va solo su quel commit, non ogni riga di codice in quel commit. Questo cade a pezzi se non ha unito correttamente i rami per far sì che ciò avvenga, ed è qualcosa che deve fare correttamente.

Se lavorate in un'organizzazione in cui “quanto codice ho scritto” è una metrica che loro tracciano e la usano per scopi promozionali, allora dovreste portare questo al management. Non dite “mi ha derubato” (non sapete che l'ha fatto), dite “sono preoccupato che se state guardando la nostra storia di controllo delle fonti per valutare i nostri meriti per gli aumenti e le promozioni, la sua fusione fa sembrare che io non abbia contribuito a nulla”.

Questo dipende molto dalla dinamica della vostra azienda. Nel mio caso (che credo sia la norma per la maggior parte delle aziende di software professionali), sarei semi-delicato a far sparire il mio nome dal codice che ho scritto… Ora non ho persone che mi fanno domande su decisioni stupide che ho preso nel mio codice mesi prima! :)

Onestamente, dati i dettagli forniti, tutti quelli che dicono report it! mi sembra una reazione eccessiva.

Il mio collega ed io abbiamo lavorato su un progetto per oltre 2 anni scambiandoci impegni avanti e indietro, e si , a volte riutilizzavamo o ottimizzavamo il codice a vicenda.

Non so in che tipo di cultura lavori, ma se in qualche modo definisce il lavoro in linee di codice piuttosto che il prodotto finale e il contributo complessivo sembra piuttosto tossico e competitivo. Il mio consiglio è di non correre lungo la catena di comando alla ricerca di una qualche forma di retribuzione. Se è così importante per lei, parli con il suo manager di come determinare il merito delle cose e poi documenti in qualsiasi modo descrivano.

Il punto che più volevo affrontare era il suo rapporto con il suo collega. Secondo la mia onesta opinione, se un giorno il mio collega venisse da me ed esclamasse: “Non usate il mio codice! È il mio codice!”, e poi mi avesse messo nei guai con la direzione per qualcosa che non stavo facendo di proposito o in modo malizioso, avrei pensato che fosse un idiota autoimportante. Lo terrei a mente, perché dalla domanda non è chiaro se abbiano davvero rubato il tuo codice, o forse si stavano solo fondendo nei cambiamenti in modo strano.

L'accusa (che è una grande accusa da fare) - se non rovina completamente il tuo rapporto professionale, sicuramente abbasserebbe la loro opinione personale su di te. Non è un grosso problema se hai ragione. Sono un fan del pensiero del tipo “ti scavi la fossa da solo” - ma se ti sbagli, il danno al tuo rapporto di lavoro potrebbe essere piuttosto sostanziale. La politica dell'ufficio è una cosa complicata!

Ora, se siete assolutamente certi che stia rubando e che si prenda il merito di cose che non ha fatto, sentitevi liberi di contattare il vostro Manager e di prendere le misure appropriate per assicurarvi che sia rimproverato per quel tipo di comportamento - tuttavia, se non siete veramente sicuri, forse riconsiderate la cosa. Il plagio non è una cosa da prendere alla leggera, soprattutto quando può influenzare la vostra vita quotidiana per un periodo di tempo piuttosto lungo.

Solleva una discussione con il tuo collega e manager su ciò che accade di fatto, ma non accusarli del loro intento.

Ciò che accade di fatto è che hanno fuso il tuo codice come se fosse il loro. Questo potrebbe essere stato fatto per vendetta personale per farvi fare la figura dello sciocco, ma questa è un'accusa di dolo, che è molto più difficile da provare, e basandosi proprio su quello che avete postato non c'è nulla che indichi un intento maligno da parte del vostro collega.

Concentratevi sul fare di questo un momento di insegnamento, assumendo la sua ignoranza sui modi di usare correttamente git. Git fornisce molti modi per permettere ad uno sviluppatore di riutilizzare il codice di un altro sviluppatore, preservandone la paternità. I due strumenti principali sono il comando merge e cherry-pick.

Dite loro di essere consapevoli che preservare i metadati e la paternità della storia è importante nel progetto.

Le meta-informazioni come la paternità esistono in un sistema di controllo di versione come git non tanto per tracciare la proprietà, ma più per aiutare a comprendere come qualcosa è diventato il modo in cui è diventato.

Mentre i flussi semplici hanno la fusione di commit che hanno la paternità individuale, ci sono molti casi in cui questo non funziona, o non cattura l'intera storia nei campi a scopo fisso di un commit.

Qualcosa come refactoring o anche l'applicazione di nuove regole di spazio bianco ad un blocco di codice comporta ciò che git considera come nuova paternità, dal momento che git comprende solo i dettagli letterali, non il significato. E questo solo nei casi in cui il codice continua ad essere usato nel suo ruolo originale e nell'esatta posizione del file.

Molti altri casi, come il basare la soluzione di un nuovo problema su codice copiato dalla soluzione di un vecchio problema all'interno della base di codice di un'azienda, cerca in tutto il mondo un VCS come una vera e propria nuova paternità.

Anche se non sono certo perfetto nel farlo, quando creo un commit basato in gran parte su un lavoro già esistente (specialmente quello di qualcun altro che è stato trasferito o sostanzialmente rielaborato) cerco di menzionarne l'origine nel messaggio del commit. Questo è un po’ troppo per dare credito, ma altrettanto o più per creare una registrazione della relazione con altri codici. Così, per esempio, se si trova un bug nel nuovo uso, vale la pena di controllare se esiste anche nel luogo da cui il codice è stato copiato.

Dato questo, una buona linea d'azione potrebbe essere quella di cercare di usare un processo di revisione del codice per far sì che la fusione finale del codice contestato sia fatta sotto un messaggio più descrittivo, che descriva le sue origini reali. E fare in modo che questo argomento non sia tanto per preservare la “proprietà” del contributo, quanto per preservare la conoscenza della provenienza del codice, di quale possa essere la sua relazione con l'altro codice e per avere una lista più completa di chi cercare input in caso di difficoltà.

Non so se l'avete notato, ma quando si dispone di un sistema di controllo del codice sorgente, e due persone apportano modifiche identiche, allora si ottengono molti “conflitti di fusione” che trasformano la fusione in un'operazione lunga e soggetta a errori.

Così nella prossima riunione del team, dove si discute di ogni genere di cose, si può dire “… e in futuro, apprezzerei se nessuno prendesse modifiche incomplete dalla mia filiale e le fondesse nella filiale principale. Ho sprecato ore e ore di lavoro per risolvere i conflitti di fusione a causa di questo”. È possibile che il vostro capo vi chieda poi chi ha fatto questo tipo di sciocchezze, e ora potete fare i nomi al capo senza fare la figura di un informatore.

Unisci il suo codice specificando che l'ha scritto lui. La gestione di se stessi si fonde è una strategia viale. sembra che non sappia come funziona GIT e si sia dimenticato di mantenere la sincronizzazione con i vostri cambiamenti. Commits with all’ il codice di altre persone viene generato automaticamente da strumenti come l'albero dei sorgenti nel caso di persone che usano una strategia di fusione scadente

Ciò che è sbagliato è specificare “il mio codice” nella descrizione della comunità.

Quando vengo colpito da un bug per un giorno ( un mese sembra troppo. Non sono mai rimasto su un bug per un mese) e ho unito i cambiamenti dico specificamente che l'unione include la mia correzione del bug più il codice precedente di altri, e anche così facendo non sembra che abbia impegnato codice di altri.

Se il tuo collega sta lavorando su un ramo, dovrebbe prima unire il ramo principale nel suo. Test. Poi fondere di nuovo il suo ramo. Se inizia a copiare il codice dal vostro ramo senza fonderlo e poi inviarlo, sta facendo anche di peggio. Sta lavorando intorno al versioning che potenzialmente introduce nuovi bug.

Introdurrei una politica di impegno a seguire e costringerei tutti a rispettare la politica. Preferirei essere più preoccupato per la sua abilità GIT. Potrebbe causare havok

Sì, mi è successo una volta con un collega molto insolito. Un giorno una persona che mi ha detto che il mio codice è identico a quello dell'altro collega. Mi sono connesso a GitHub e ho notato che il codice è stranamente simile al mio, ma all'inizio mi sono accorto che forse, dato che ospitiamo più siti che condividono lo stesso file, il codice è semplicemente lo stesso dato che fa la stessa cosa.

Nel corso del tempo ho osservato che la collega ha detto che stava lavorando alla “rifattorizzazione del codice” durante gli stand up giornalieri fino all'ultimo giorno dello sprint, poi dice che il suo codice non è pronto l'ultimo giorno e ha bisogno di un giorno in più, e poi misteriosamente il giorno dopo centinaia di linee di codice sono state spinte verso l'alto su una richiesta di pull. Ho guardato il codice e ho notato che il codice è simile al mio, fino a un errore di ortografia che ho fatto. Poi mi sono reso conto che la persona stava aspettando che io spingessi su il mio ramo e che avrebbe osservato e copiato le cose da esso.

Ero furioso quanto te. Soprattutto perché la collega non è venuta da me a chiedermi quale avrei volentieri aiutato o diretto. È stato uno dei pochi motivi per cui ho deciso di lasciare l'azienda dopo averne parlato con un manager che non sembrava preoccuparsene. **Il mio consiglio è di parlarne con un dirigente, inserendo un errore di ortografia che si può dimostrare che non può essere duplicato per caso. In questo modo si può dire che non si tratta di una mera coincidenza.