Dove deve essere memorizzata la descrizione dei rami in un VCS?

Question

Dove deve essere memorizzata la descrizione dei rami in un VCS?

#1 da (4 voti)
#2 da (3 voti)
#3 da (2 voti)

4

Se mantieni molti rami nel tuo sistema di controllo delle versioni preferito, è essenziale capire quale ramo per cui è rientrato.

In SVN puoi mettere README allo stesso livello delle dirs di trunk / branches / features. Che ne dici di DVCS?

Puoi mantenere ChangeLog . Ma con questo approccio è difficile ottenere una visione di breif che sia fatta in tutti i rami (se si mantengono diversi changelog di release di lunga durata tra di loro possono essere leggermente diversi).

Nel progetto open source le informazioni sui rami di solito si trovano sul wiki del progetto, quindi salvate separatamente da VCS. Penso che questa sia una brutta cosa. Quando cloni il progetto, hai bisogno anche di una persona per i wiki.

git version-control svn mercurial

posta gavenkoa 08.07.2011 - 16:23

fonte

3 risposte

Leggi altre domande sui tag git version-control svn mercurial

Sinonimi per gli operatori Come funziona un interprete? [chiuso]

score 4 · Answer 1

In git, puoi utilizzare git notes per questo scopo, ma non è molto elegante:

Nel tuo ramo fai git notes add -m "this branch is for blah blah"

Quindi scrivi un post-commit nel repository con il seguente:

#!/bin/sh
git notes show HEAD~1
git notes copy HEAD~1 HEAD
git notes remove HEAD~1

Utilizza git notes show per vedere a cosa serve il ramo.

Si noti che la nota può essere trasferita al repository remoto come qualsiasi ref, ma come ho detto prima, questo non è elegante, ma funziona, e questo è quello che uso.

Dai anche un'occhiata a questa risposta a una domanda simile (per git) - collegamento Questa risposta menziona l'utilizzo della configurazione per la memorizzazione di tali informazioni, che non verrebbero propagate ai repository remoti su push, ecc. Quindi questo potrebbe non essere quello che stai guardando.

score 3 · Answer 2

Cerco solo di dare nomi descrittivi ai rami. Cerco anche di non averne così tante che non riesco a ricordare a cosa servono.

Un buon nome descrittivo è probabilmente sufficiente. Uso le barre per categorizzare i rami. per es.

feat/close-button
feat/keyboard-shortcuts
bug/238/rl-alg-leak

btw, in Git, se ti ritrovi a dover passare da molte attività non correlate potrebbe essere meglio mettere da parte le tue modifiche, invece di creare un ramo per ognuna di esse. Quando si archivia, è anche possibile fornire una descrizione di ciò su cui si sta lavorando:

git stash save "trying out this thing..."

Penso che qualsiasi soluzione che si basa sulla registrazione extra-scm di ciascun ramo non sia ottimale. Ho lavorato con pagine wiki e README per questo scopo in passato, e dover aggiornarli diventa un problema. I rami Git di solito sono di breve durata, comunque. Quindi non ha molto senso catalogarli.

score 2 · Answer 3

ogni ramo abbastanza importante da essere spinto al nostro repository centrale è previsto (ma non al momento richiesto, da fiat di hg update_hooks ) per avere una versione corrispondente nel nostro tracker di problemi. La maggior parte dei rami ha nomi semplici ma descrittivi, ma l'autorizzazione definitiva su ciò che il ramo è per viene dall'insieme di problemi impostati per essere corretti nella versione con lo stesso nome del ramo.