Dovresti inviargli un'e-mail dicendo qualcosa sulla falsariga di:

Vedo che hai spinto il codice dal mio ramo al ramo principale. Tieni presente che la cronologia delle revisioni è importante in questo tipo di prodotti, quindi dovresti evitare di tagliare e incollare il codice nel ramo principale, come hai fatto tu; piuttosto, il codice dovrebbe essere inviato dal ramo su cui è stato sviluppato.

e metti in cc il tuo manager. Ciò renderà il tuo manager consapevole del problema senza accusare direttamente il tuo collega di cattiva condotta e lo inquadra come preoccupazione per l'integrità del progetto piuttosto che come merito personale.

Lo segnalerei sicuramente al tuo manager con la prova che l'hai scritto per primo.

Non è illegale come in un tribunale, ma è sbagliato e il tuo manager dovrebbe saperlo. Digli che se lo fa di nuovo lo segnalerai di nuovo.

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

Puoi inviare un'email a chiunque abbia accettato il tiro con il tuo " preoccupazioni "sul tuo codice ancora in fase di sviluppo che appare su master. Non devi nemmeno fare accuse; lascia che "capiscano" cosa è successo da soli. Supponi che il tuo codice dovrebbe essere buono, ma non hai finito di testare e modificare e sei perplesso / preoccupato di come è diventato master senza che tu invii una richiesta pull.

Questo rimuove la maggior parte del dramma, ma preserva una buona possibilità per il tuo collega di essere rimproverato, una volta che hanno capito come il codice è arrivato in modo inappropriato sul master. Vedo che alcune persone con una mentalità tecnologica vengono sconvolte dal conflitto, rendendole meno entusiaste di scavare in esso, ma quasi sicuramente vorranno capire cosa è successo se affrontato come un "WTF" invece di un'accusa apparentemente oltraggiosa.

Se le cose saranno come affermato, l'indagine sarà breve e conclusiva. In ogni caso sembra che tu sia un lavoratore migliore, quindi il tempo setaccia il grano dalla pula; sii magnanimo e non "schiacciare" la politica in ufficio.

Woah Betty, analizziamolo:

Un collega ha rubato del tutto il codice e afferma di aver scritto tutto

^ È abbastanza serio. Se va in giro a dire alla gente "questo è il lavoro che ho fatto", allora di sicuro dì al tuo manager "Ehi, vorrei solo indicarti questa pagina GitHub per mostrare che sono l'autore di tutto questo lavoro, mentre Bob ha fatto solo questa fusione. Lo sto facendo notare perché non voglio che tu abbia l'impressione che non abbia svolto la mia parte di lavoro, e allo stesso tempo mi dà fastidio che Bob stia cercando di prendere credito per il lavoro che non ha svolto. "

Ma

Oggi, Bob unisce del codice nel nostro ramo principale.

Bob sta davvero "affermando" di aver scritto tutto? O ha semplicemente unito un ramo in master e nessuno sa / si preoccupa del nome accanto a quel commit di unione? Nella mia azienda, a meno che la direzione non stia esaminando un disastro, nessuno guarderebbe chi ha creato quale commit.

Oltre a git, c'è qualche altro strumento di gestione del progetto che il tuo manager usa per vedere quanto lavoro stanno facendo tutti? In tal caso, un nome su un commit non significa nulla. In caso contrario, la gestione è abbastanza scarsa che non credo che nessuno guarderebbe la cronologia di Git in ogni caso.

Avevi il 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 and I nei commit git contenenti il ​​tuo codice. Git commit non dovrebbe essere uno strumento di gestione o uno strumento per assegnare crediti per il lavoro svolto. Il software o il sistema di gestione del progetto utilizzato dovrebbe gestire chi ottiene il merito per cosa. Se entrambi foste assegnati alla stessa attività, la direzione probabilmente si aspetta che utilizziate le idee e il codice degli altri. Dovreste essere entrambi onestamente sullo stesso ramo se si tratta di un compito comune.

Il vero problema sono le vostre preoccupazioni per le sue capacità e / o l'etica del lavoro. Dovrebbe essere affrontato separatamente da questo particolare incidente.

Dovresti prima parlare con il tuo collega. Al momento, sembra che sia successo solo una volta. Ho spesso eseguito il commit del codice dei miei colleghi e ho lasciato che i colleghi impegnassero il mio codice. Se ti riguarda, sentiti libero di dirgli che la cronologia di git è importante e che vorresti che il tuo nome fosse allegato a qualsiasi codice che è stato inserito. Insisti sul fatto che se c'è un bug nel codice, non vuoi che venga incolpato ingiustamente.

Se continua a comportarsi male nel suo lavoro, parla con la direzione delle sue prestazioni (non dei commit) . Puoi dire che i suoi commit spesso usano il tuo codice, ma non renderlo il punto, perché non c'è davvero nulla di intrinsecamente sbagliato in questo di per sé. Devi solo chiarire che non dovrebbero usare i commit per valutare la sua abilità o etica del lavoro perché è il tuo codice.

Segnalalo alla direzione. Leggi anche il manuale dei dipendenti della tua azienda, probabilmente hanno una politica sul comportamento non etico e qual è anche il loro processo per segnalarlo.

Quando segnali anche questo, assicurati che sia per iscritto / un'email , come se avessi bisogno di farvi riferimento in seguito, dovresti aver ben documentato che ciò è accaduto e che è stato presentato un reclamo.

Il tuo obiettivo è assicurarti di ottenere credito per il codice che hai scritto?

L'idea che il codice sia "tuo" in genere non è un buon modo per pensare al lavoro che svolgi per l'azienda. Il codice che scrivi non ti appartiene; appartiene all'azienda. Non dovrebbe fare differenza se il codice è stato eseguito il commit dal tuo ramo o dal ramo di Bob. Tu e Bob avete l'obiettivo comune di completare tutte le attività necessarie per il prodotto.

È una cosa se il tuo manager crede che tu non stia facendo il tuo peso, ma Bob sì, ma la tua domanda lo fa sembrare più come se ti sentissi derubato.

Alcuni commenti hanno affrontato questo problema; ma le risposte (soprattutto la risposta accettata) sembrano andare in una direzione molto diversa. La giusta linea di condotta dipende dai tuoi obiettivi reali; ma a meno che il tuo manager non stia esaminando i log di commit per assicurarti che tu e Bob stiate lavorando a sufficienza, non sentirò il bisogno di fare nulla per questa situazione.

Sembra la cosa peggiore Bob ha fatto qui per non seguire le migliori pratiche su come utilizzare il controllo del codice sorgente. L'unione delle modifiche avrebbe consentito una cronologia delle revisioni migliore rispetto a copiare / incollare le modifiche. È ragionevole spiegarglielo e spiegarne le ragioni. Ma dalle informazioni che abbiamo nella domanda; questo non è un problema in cui è necessario scrivere formalmente qualcosa e assicurarsi di copiare il proprio manager. Menzionaglielo casualmente.

Sembra un'unione che è andata a male; Non pretendo di capire abbastanza bene git da sapere esattamente perché ciò si verifica, ma a volte Visual Studio crea commit sul proprio repository locale quando si utilizza l'IDE per risolvere i conflitti di unione. Nella cronologia questo sembra aver preso tutte le modifiche al repository remoto, applicandole al proprio repository, eseguendone il commit e quindi applicando quel commit al repository remoto.

La spiegazione razionale qui è che Bob ha fatto clic sul processo di unione senza comprenderlo realmente e ha generato una cronologia del controllo del codice sorgente fuorviante. Lavorando su questo assunto, interrogalo con lui con l'intenzione di istruirlo su come fondersi correttamente, dando il beneficio del dubbio sul fatto che il problema sia un errore.

In primo luogo, identifica qual è il problema . Non è del tutto chiaro dalla tua domanda così come è stata posta.

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 pulizia e probabilmente non è un segno di comportamento dannoso da parte del tuo collega. Se un collega è bloccato su un bug per un mese, questo tipo suggerisce che potrebbe essere un po 'arrugginito riguardo all'uso dei suoi strumenti, incluso il controllo della versione.

Il tuo nome dovrebbe essere visualizzato tutto il codice che hai scritto. Non è una questione di orgoglio o di ricevere crediti che ti sono dovuti: hai bisogno di quella storia intatta in modo che le persone sappiano chi ha scritto quale riga di codice e con chi parlare quando incontrano bug o strane decisioni di progettazione in futuro. Se il tuo nome non compare più, allora il tuo collega è colui che può rispondere alle domande sul tuo codice e prendersi la colpa dei tuoi bug!

Usa il tuo IDE o uno strumento di controllo del codice sorgente 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 su tutte le righe di codice in quel commit . Ciò va a rotoli se non ha unito correttamente i rami per far sì che ciò accada, e questo è qualcosa che deve fare correttamente.

Se lavori in un'organizzazione in cui "quanto codice ho scritto" è una metrica, track e lo usano per scopi promozionali, quindi dovresti portarlo alla direzione. Non dire "mi ha rubato" (non sai che l'ha fatto), dì "Sono preoccupato che se stai esaminando la nostra cronologia del controllo del codice sorgente per valutare il nostro merito per aumenti e promozioni, la sua unione fa sembrare come se non avessi contribuito con niente ".

Dipende molto dalla dinamica della tua azienda. Nel mio caso (che penso sia la norma per la maggior parte delle società di software professionali), sarei quasi felice che il mio nome scompaia dal codice che ho scritto ... Ora non ho persone che mi fanno domande su decisioni stupide che io fatto nel mio codice mesi prima! :)

Onestamente, dati i dettagli forniti, tutti quelli che dicono segnalalo! mi sembrano solo una reazione eccessiva.

Io e il mio collega abbiamo lavorato a un progetto per oltre 2 anni scambiando i commit avanti e indietro e sì , a volte riusciamo o ottimizziamo 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 in prodotto finale e contributo complessivo, sembra piuttosto tossico e competitivo. Il mio consiglio è di non eseguire la catena di comando alla ricerca di qualche forma di punizione. Se è un grosso problema per te, parla con il tuo manager su come determinare il merito delle cose e poi documentale in qualunque modo descrivano.

Il punto che più volevo affrontare era il tuo rapporto con il tuo collega. A mio parere onesto, se un giorno un mio collega fosse venuto da me ed avesse esclamato: "Non usare il mio codice! È il mio codice!", E poi mi ha messo nei guai con la gestione per qualcosa che non ero " Per fare intenzionalmente o maliziosamente, penserei che fosse un idiota importante. Lo terrò a mente, perché dalla domanda non è chiaro se hanno davvero rubato il tuo codice, o forse stavano solo fondendo le modifiche in un modo strano.

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

Ora, se sei assolutamente sicuro che stia rubando e prendendosi il merito di cose che non ha fatto, sentiti libero di contattare il tuo manager e prendere le misure appropriate per assicurarti che venga rimproverato per quel tipo di comportamento, tuttavia , se non sei proprio sicuro , forse riconsiderare. Il plagio non è qualcosa da rivendicare alla leggera, soprattutto quando può influenzare la tua vita quotidiana per un periodo piuttosto lungo.

Le meta-informazioni come la paternità esistono in un sistema di controllo della versione come git non tanto per tenere traccia della proprietà ma più per aiutare la comprensione di come qualcosa sia diventato il in questo modo.

Mentre i flussi semplici hanno unioni di commit con 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 il refactoring o anche l'applicazione di nuove regole di spazi bianchi a un blocco di codice coinvolge ciò che git considera essere una nuova paternità, poiché git comprende solo i dettagli letterali, non il significato. E questo solo nei casi in cui il codice continua a essere utilizzato nel suo ruolo originale e nella posizione esatta del file.

Molti altri casi, come basare la soluzione a un nuovo problema sul codice copiato dalla soluzione di un vecchio problema all'interno del codice di un'azienda, cerca tutto il mondo in un VCS come un autentico, nuovo autore.

Anche se tutt'altro che perfetto in questo, quando creo un commit basato in gran parte sul lavoro esistente (specialmente qualcun altro è stato trasferito o sostanzialmente rielaborato) cerco di menzionare la sua origine nel messaggio di commit. Questo è un po 'un merito, ma altrettanto o più per creare una registrazione della relazione con un altro codice . Quindi, ad esempio, se viene rilevato un bug nel nuovo utilizzo, vale la pena controllare se esiste anche nel luogo da cui è stato copiato il codice.

Detto questo, una buona linea di condotta potrebbe essere quella di provare a utilizzare un processo di revisione del codice per fare in modo che l'unione finale del codice contestato venga eseguita in un messaggio più descrittivo, che ne descriva le origini effettive. E per rendere questo argomento non tanto per preservare la "proprietà" del contributo, ma per preservare conoscenza da dove proviene il codice, quale può essere la sua relazione con un altro codice e per avere un elenco più completo di a chi chiedere input in caso di difficoltà .

Solleva una discussione con il tuo collega e manager su ciò che accade di fatto, ma non accusarlo delle loro intenzioni.

Ciò che accade di fatto è che hanno unito il tuo codice come se fosse il loro. Questo potrebbe essere stato fatto per vendetta personale per farti sembrare uno sciocco, ma è un'accusa di intenti, che è molto più difficile da dimostrare e, in base a ciò che hai pubblicato, non c'è nulla che indichi un intento dannoso da parte del tuo collega .

Concentrati sul rendere questo un momento di insegnamento, assumendo la sua ignoranza sui modi in cui usa git correttamente. Git offre molti modi per consentire a uno sviluppatore di riutilizzare il codice di un altro sviluppatore preservandone la paternità. I due strumenti principali qui sono il comando merge e cherry-pick.

Dì loro di essere consapevoli che preservare i metadati e la paternità della cronologia è importante nel progetto.

Non so se l'hai notato, ma quando hai un sistema di controllo del codice sorgente e due persone apportano modifiche identiche, otterrai molti "conflitti di unione" che trasformano la fusione in un errore che richiede tempo operazione incline.

Quindi alla prossima riunione del team, dove si discute di tutti i tipi di cose, puoi dire "... e in futuro, apprezzerei se nessuno prendesse modifiche incomplete dal mio ramo e le unisse in il ramo principale. Ho sprecato ore e ore di lavoro per risolvere i conflitti di unione a causa di questo ". È del tutto possibile che il tuo capo ti chieda chi ha fatto quel tipo di sciocchezze, e ora puoi nominare i nomi al capo senza sembrare un informatore.

Sì, una volta mi è successo con un collega molto insolito. Un giorno una persona addetta al QA mi ha detto che il mio codice è esattamente lo stesso di questo altro collega. Ho effettuato l'accesso a GitHub e ho notato che il codice è stranamente simile al mio, ma all'inizio mi sono detto che forse poiché ospitiamo più siti che condividono lo stesso file, il codice è semplicemente lo stesso poiché fa la stessa cosa.

Nel tempo ho osservato che la collega diceva che stava lavorando al "refactoring del codice" durante gli standup giornalieri fino all'ultimo giorno dello sprint, poi dice che il suo codice non è pronto l'ultimo giorno e ha bisogno di un giorno aggiuntivo, e poi misteriosamente il giorno successivo centinaia di righe di codice sono state inviate su una richiesta pull. Ho guardato il codice e ho notato che il codice è simile al mio, a causa di un errore di ortografia che ho fatto. Poi ho capito che la persona stava aspettando finché non avessi spinto il mio ramo e lei avrebbe osservato e copiato le cose da esso.

Ero furioso come te. Soprattutto perché il collega non è venuto da me per chiedere cosa avrei aiutato o diretto volentieri. È stato uno dei pochi motivi per cui ho deciso di lasciare l'azienda dopo averne parlato con un manager a cui sembrava non importare. Il mio consiglio è di portarlo a un manager, inserire un errore di ortografia che puoi provare non può essere duplicato per caso. In questo modo puoi dire che non è possibile che sia una semplice coincidenza.

Unisci il suo codice specificando che lo ha scritto. Gestire le proprie fusioni è una strategia di viale. sembra che non sappia come funziona GIT e si sia dimenticato di sincronizzarsi con le tue modifiche. I commit con tutto il codice di altre persone vengono generati automaticamente da strumenti come l'albero dei sorgenti nel caso in cui le persone utilizzino una strategia di fusione scadente

Ciò che non va è 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 unisco le modifiche, dico specificamente che l'unione include la mia correzione del bug più il codice precedente di altri, e anche farlo Non sembra che abbia eseguito il commit del codice da altri.

Se il tuo collega sta lavorando su un ramo, dovrebbe prima unire il ramo principale al suo. Test. Quindi unisci il suo ramo indietro. In questo modo manterrai la cronologia delle tue modifiche.

Se inizia a copiare il codice dal tuo ramo senza unirlo e poi inviare, sta facendo anche peggio. Sta lavorando sul controllo delle versioni che potenzialmente introduce nuovi bug.

Vorrei introdurre una politica di commit da seguire e costringere tutti a rispettare la politica. Preferirei essere più preoccupato dalla sua abilità GIT. Potrebbe causare il caos