Source code management/it

Il nostro principale strumento di gestione del codice sorgente distribuito è Git. Questo articolo spiega come usarlo e quali sono le regole generali applicabili per FreeCAD. Prima di lavorare con il codice sorgente di FreeCAD, si consiglia vivamente di imparare come funziona Git (per Git ci sono un sacco di tutorial e di documentazione disponibile su Internet)

Ci sono anche molti buoni clienti grafici per git, come git-cola, che facilitano l'intero processo di gestione del repositorio git

Accesso al codice sorgente
Tutti possono accedere e ottenere una copia del codice sorgente di FreeCAD, ma solo i gestori del progetto di FreeCAD hanno l'accesso in scrittura. È possibile ottenere una copia del codice, studiarlo e modificarlo come si vuole, ma se si apporta una modifica che si desidera vedere inclusa nel codice sorgente ufficiale, è necessario fare una richiesta di pull nella sezione pull requests del forum di FreeCAD.

Official GitHub Repo
An easy way to start with the FreeCAD source code is using the official FreeCAD repository at https://github.com/FreeCAD/FreeCAD

You can start simply by using the "fork" button on top of the above page. This will create a copy of the FreeCAD repository on your own GitHub account. The general procedure is as follows:
 * 1) Sign up for a GitHub account
 * 2) Go to the FreeCAD repo:  https://github.com/FreeCAD/FreeCAD
 * 3) Press the "Fork" button
 * 4) On your machine, clone your newly created FreeCAD fork:
 * git clone https://github.com//FreeCAD.git
 * 1) Make your specific changes to the source code
 * 2) Create a new branch
 * 3) Checkout that new branch
 * 4) Commit your changes to that new branch
 * 5) Push that new branch to your GitHub repo

You can also start normally, without using the "fork" button:
 * 1) Clone the FreeCAD code with git:
 * git clone https://github.com/FreeCAD/FreeCAD.git
 * 1) Make your specific changes to the code
 * 2) Create a new branch
 * 3) Checkout that new branch
 * 4) Commit your changes to that new branch
 * 5) Create an account on a public git server (GitHub, GitLab, etc...)
 * 6) Push your branch to that server

Important Note': If you have code you wish to see merged into the FreeCAD source code, please post a note in the Pull Requests section of the FreeCAD forum.

Access rules
We will give everyone interested in participating write access to the git repository as long as you stay away from master branch (tip).

Authentication
The read-only access does not prompt for a password.

L'accesso in lettura e scrittura richiede la password SSH o la chiave SSH per autorizzare l'accesso. Per poter eseguire le operazioni di scrittura, l'amministratore del progetto deve aver concesso l'accesso in scrittura al repository.

Note: In all examples below, "USERNAME" represents your GitHub user account.

Setting your git username
Users should commit to their project repository using their GitHub username. If that is not already set globally, you can set it locally for the current Git repository like this: git config user.name "YOUR NAME" git config user.email "USERNAME@users.noreply.github.com" È ora possibile utilizzare una combinazione di comandi "git add" e "git commit" per creare uno o più commit nel proprio repository locale.

Alternative repositories
The beauty of git is that everybody can clone a project, and start modifying the code. Several frequent collaborators of the FreeCAD project have their own git repository, where they build up their work before it is ready to be included in the official source code, or simply where they experiment new ideas. In certain cases, you might want to clone your FreeCAD code from one of these, instead of the official repos, to benefit from the changes their users did.

Be warned, though, that this is at your own risk, and only the official repository above is fully guaranteed to work and contain clean code.

È anche possibile collegare diversi repository remoti a un medesimo codice git locale utilizzando il comando "git remote". Questo è utile per mantenere la sincronia con il ramo principale del codice, ma tenere d'occhio il lavoro degli altri sviluppatori.

Git Development Process
First of all never develop on the master branch! Create a local branch for development. You can learn how to do this here.

Ramificazioni
Una caratteristica importante di Git è che è estremamente facile lavorare con i rami e poi fonderli. Le procedure ottimali raccomandano di creare un nuovo ramo ogni volta che si desidera lavorare su una nuova funzionalità. Per creare un ramo fare in questo modo: git branch myNewBranch git checkout myNewBranch oppure, eseguire entrambe le operazioni in una sola: git checkout -b myNewBranch è sempre possibile verificare in quale ramo si stà operando con: git branch

Invio
Dopo aver prodotto un po' di lavoro, si può inviarlo con: git commit -a A differenza di SVN, è necessario indicare specificare quali file sono da inviare (o tutti con l'opzione -a). Il proprio editor di testo si apre per consentire di scrivere un messaggio di commit.

Publishing your work on your GitHub repository
After done some changes on your local branch and commit it (this means commit locally) you can push your repository to the server. This opens your branch to the public and allows the main developers to review and integrate your branch into master. git push my-branch

Scrivere buoni messaggi di commit
Si dovrebbe cercare di lavorare in piccole parti. Se non è possibile riassumere le proprie modifiche in una sola frase, è probabile che sia passato troppo tempo da quando si è fatto l'ultimo commit. Inoltre è importante che le descrizioni del lavoro siano dettagliate e utili. Per i messaggi di commit, FreeCAD adotta un formato menzionato nel libro Pro Git.

Breve riepilogo delle modifiche (circa 50 caratteri) Se è necessario, testo esplicativo più dettagliato. Utilizzare circa 72 caratteri. In alcuni contesti, la prima riga è trattata come oggetto di un messaggio e il resto del testo come il corpo. E'fondamentale lasciare una riga vuota per separare il riassunto dal corpo (a meno che non si ometta per intero il corpo); se le due parti sono unite gli strumenti come rebase possono confondersi. Ulteriori paragrafi vanno dopo una riga vuota. - Anche gli elenchi puntati sono validi - Tipicamente per le voci dell'elenco si usa un trattino o un asterisco preceduto da uno spazio bianco, e sono intervallate da una riga vuota, ma queste convenzioni possono variare

Se si sta facendo diversi lavori connessi, qui viene suggerito che si dovrebbero fare altrettanti invii, grandi o piccoli, secondo come è necessario e descriverli con brevi messaggi di commit. Quando si desidera unirli, fare un log master git..BRANCH e utilizzare il risultato come base per il messaggio di commit. Poi, quando si uniscono al master usare l'opzione --squash e inviarlo con il messaggio di commit. Questo permette di essere molto liberi con il commit e contribuisce a fornire un buon livello di dettagli nei messaggi di commit senza tante descrizioni distinte.

Ulteriori letture

 * Git for the lazy
 * Git pro libro on-line