Si dovrebbe utilizzare Git per la documentazione e la gestione dei progetti? Il codice dovrebbe essere in un repository separato?

Archiviamo sempre la documentazione in SVN. In effetti, tutto il nostro manuale utente è scritto in LaTeX e memorizzato in SVN. Abbiamo scelto LaTeX in modo specifico perché è un linguaggio basato su testo e facile da mostrare diff. Riga per riga.

Conserviamo anche alcuni file in formato non testuale, come file .doc di Microsoft Office, fogli di lavoro, file .zip, ecc. quando necessario ... ma alcuni dei vantaggi di un RCS vanno persi quando non è possibile vedere il differenziale incrementale.

La chiave è assicurarsi che la tua documentazione sia ben organizzata, in modo che le persone possano trovare (e aggiornare) la documentazione (e la fonte) quando ne hanno bisogno.

Beh, dipende dal formato che usi per la documentazione. Se è qualcosa di basato sul testo, va tutto bene.

Git può anche memorizzare contenuti binari e tenere traccia delle revisioni, ma l'output diff non ha senso.

È anche possibile archiviare la documentazione nel codice stesso come perldoc pod, java ha anche qualche formato / annotazione per questo.

Non riesco a immaginare perché pensi che potrebbe esserci un problema nell'usare git, o qualsiasi altro sistema di controllo della versione, per la documentazione. Proprio come il codice sorgente, la documentazione dovrebbe avere una cronologia completa e la possibilità di ripristinare una versione precedente se ciò diventa necessario. Un sistema di controllo della versione è perfetto per questo.

È chiaro che l'utilizzo di un qualche tipo di sistema di controllo della versione per l'archiviazione di documenti è un vantaggio. La parte più interessante della domanda è se è una buona idea conservare i documenti nella posizione SAME come codice sorgente? Il possibile problema qui è che potrebbe essere difficile impostare diversi privilegi di accesso per il codice e la documentazione in quel caso. E in molti casi aziendali le persone avranno bisogno di accedere ai documenti ma non al codice sorgente, come il marketing oi dipartimenti BA.

Nella società che lavoro inseriamo la documentazione in SVN. Tuttavia, dopo alcuni conflitti e la necessità di condividerlo, abbiamo deciso di spostarlo su Mediawiki.

All'inizio era trac, dopo che è stato spostato su Mediawiki perché era più facile da usare ...

Il problema principale con SVN era la causa della condivisione che avevamo il sistema di autorizzazione per SVN.

• Avere più di un semplice codice sorgente in un repository è una cosa molto buona.

  Raggruppa tutte le risorse insieme e trasforma il progetto in un'entità coesiva e centralizzata piuttosto che in una serie sparsa di file. Collaboratori / dipendenti sanno dove trovare tutto, piuttosto che inviare "Dove posso cambiare la documentazione per le x di caratteristiche?" .

  Avrai voglia di mantenere le cose organizzate. Avere un sistema per separare src da images da docs . Puoi sempre aggiungere .gitignore a una directory per mantenere pulito il repository e la cronologia. Poiché le commit Git sono basate su file, * puoi disaccoppiare le modifiche di origine dalle modifiche alla documentazione con la stessa intensità che desideri.

• Come altri hanno già detto, Git è ottimo per la versione della documentazione purché basata sul testo.

• Sono completamente d'accordo; la documentazione deve essere versionata accanto al codice.

La mia credibilità deriva dall'essere un utente GitHub e contribuire a un progetto ed esplorare molti altri. Nella mia esperienza, un progetto completo e unificato è facile da distinguere da quello a metà mancante. Cerco di contenere tutti i miei progetti all'interno di singole directory ogni volta che è possibile.

Sono venuto qui con una domanda simile. Veniamo da un ambiente SVN, dove fondamentalmente è un gioco da ragazzi per mantenere tutti i materiali relativi a un progetto nello stesso repository. A causa della natura di SVN, puoi facilmente controllare le parti del repository, quindi se hai solo bisogno del codice sorgente (ad esempio, una distribuzione del sito web), non c'è problema.

Con Git, le cose sono diverse. Un checkout è sempre a livello di root, quindi se vuoi mettere tutto nello stesso repository, finirai sempre con la stessa struttura di directory. Un approccio che ho trovato è quello di mettere tutto in rami separati, cioè i branch di codice (che normalmente sono i normali rami master, develop, ecc.) E un ramo doc, che ha una propria struttura di directory separata. Non sono ancora sicuro che sia la migliore idea, ma è un suggerimento che elude il problema che immagino sia alla base della tua domanda.

Uso un wiki per documenti interni ... ottenere la revisione PLUS accesso prominente / facile modifica. Quando la documentazione non è sincronizzata, aggiornala subito dopo. Per la documentazione per l'utente finale, prendi in considerazione uno strumento professionale come Madcap Flare Usano un dialetto XML per la condivisione , componendo e trasformando la documentazione.

Nel codice, i pensieri sono in genere separati riga per riga. Tendo a scrivere la documentazione con gli involucri della linea morbida. Quando eseguo il commit di questi file, le righe sono lunghe un intero paragrafo. Non è molto utile leggere in git diff . Questo è il problema che stavo cercando di risolvere quando ho cercato su Google e ho trovato questa pagina. Grazie a Arne Hartherz per avermi introdotto a git diff --word-diff . Potresti gradire git diff --color-words ancora meglio.