Come gestire correttamente le unioni quando si esegue un GIT PULL in Visual Studio

Question

Non riesco a far funzionare correttamente GIT per TFS in Visual Studio quando si tratta di unioni. Fondamentalmente ogni operazione di unione che si verifica quando estraggo l'ultima versione del codice è un incubo.

Sono in particolare parlando di unioni che si verificano quando si tira codice altro qualcuno dallo stesso ramo (vale a dire io sono non parlando di scenari che coinvolgono più rami).

Sto anche specificatamente parlando di plug-in GIT integrato di Visual Studio, quindi per favore non suggerire di eseguire comandi da riga di comando di cui sono a conoscenza (come rebase) se c'è un'altra soluzione da all'interno dell'IDE ("non è possibile" sarebbe una risposta valida, però).

Ecco come riprodurre il problema:

• ci sono due sviluppatori, A e B, lavorando sullo stesso ramo
• sviluppatore Un spinge alcuni commit che modifica i file F1 e F2
• sviluppatore B una modifica dei file F1 e F3
• sviluppatore B impegna modifiche su F1 e F3
• sviluppatore B fa un pull: Visual Studio rileva un conflitto sul file di F1 (presumibilmente)
• sviluppatore B risolve il conflitto sulla F1

Ora qui è il problema: tutti i file F1, F2 e F3 sono nel modificata Stato per B. Perché? Lo sviluppatore B ha modificato solo i file F1 e F3. Non vedo un motivo valido per F2 nello stato modificato, perché B non lo ha modificato.

Capisco che localmente il file F2 non è la stessa di prima il tiro, ma il problema è che la B in fondo non può rivedere i suoi cambiamenti di F1 e F3 prima di spingere, il lavoro a causa di tutti gli altri (nel semplificato caso sopra, su F2) appare anche nella sua lista di modifiche.

Nei nostri scenari del mondo reale, ci sono più sviluppatori che lavorano sullo stesso ramo, e ogni Merge è un grande fallimentonella storia ramo: Visual Studio mostra fondamentalmente un gruppo di 50-o-così file modificati per ogni unione (quando lo sviluppatore ha modificato solo 1 o 2 file).

Questo problema sempre si verifica con un up-to-date di Visual Studio 2013. Visual Studio 2015 sembra abbastanza intelligente da non spettacolo F2 come modificato, ma non sempre .

Come risolvere questo comportamento? Attualmente GIT è un PITA da utilizzare all'interno di Visual Studio per questo motivo.

---

EDIT:

Ecco un esempio visivo.A sinistra, la cronologia mostrata in VS 2013: molti file modificati. A destra, la stessa storia (stesso repository, stessa macchina, stesso commit ... ecc.) Come mostrato in VS 2015. Ovviamente VS 2015 mostra qualcosa di diverso e leggermente migliore (vedo solo le mie modifiche). Nota che questo non funziona sempre in questo modo, a volte VS 2015 mostra i file che non ho modificato, proprio come fa VS 2013.

Questa domanda era su questo comportamento quando sto per spingere il risultato di una fusione, ma è esattamente la stessa cosa quando ho semplicemente visualizzare la cronologia di una fusione vecchio, come illustrato di seguito:

Le domande sono:

• è presente un bug?
• in caso contrario, questo è documentato?
• in ogni caso, come dovrei lavorare con GIT, in particolare con VS 2013, per quanto riguarda l'incoerenza come mostrato sopra?

Answer 1

Hai solo bisogno di capire come funziona git.

Quando si dice:

sviluppatore B fa un pull: Visual Studio rileva un conflitto sul file di F1 (presumibilmente)

Ecco dove ti sbagli. Git rileva i conflitti e quindi non può eseguire l'unione. (Anche se ci si sta unendo dal ramo "same", ciò che sta facendo git è creare un commit di merge su nastro anche questi rami insieme).

Quando questo accade, git ti mostra tutte le differenze portate da entrambi i rami. Puoi aggiungere git (o qualunque cosa venga chiamato in Visual Studio) tutti i file senza conflitto, faranno parte del "merge commit".

L'unica cosa che devi fare è correggere i conflitti in cui sono marcati e lasciare il resto ma così com'è e creare il commit di unione.

Riassumendo, quando un merge non riesce, si arriva a vedere sia cambia e risulta in conflitto. Concentrati solo sulla risoluzione dei conflitti e lascia che il regolare cambi come sono.

Answer 2

Ho usato Visual Studio 2013 con Git & funziona perfettamente per lo scenario che hai menzionato sopra.

Quello che potrei suggerire è di verificare se c'è qualche differenza nelle Impostazioni utente di quegli sviluppatori. È possibile che si verifichino cambiamenti nelle terminazioni di linea, spazio delle schede o Utilizzo di Ctrl + K + F (scelta rapida per la formattazione).

Quello che suggerisco di disinstallare qualsiasi plugin personalizzato, oltre al supporto VS nativo, aggiorna Visual Studio all'ultima patch.

Se i problemi persistono, provare a importare le stesse impostazioni utente su tutti gli sviluppatori in Visual Studio.Fare riferimento: How to: Share Settings Between Computers or Visual Studio Versions

Strumenti => Importa impostazioni & esportazione .. =>

successiva =>

Esportare questa impostazione & importazione a tutti gli altri utenti in modo che tutti gli utenti avendo le stesse impostazioni.

Diversi plugin come estensioni git, git tartaruga o qualsiasi altra estensione git personalizzata possono giocare con terminazioni di linea o spazi di tabulazione predefiniti che provocano modifiche rilevate in quasi tutti i file modificati da qualsiasi sviluppatore.