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.

There are also many good graphical clients to git, such as git-cola, that make the whole process of managing git repositories easier.

Access
Everybody can access and get a copy of the FreeCAD source code, but only the FreeCAD project managers have write access to it. You can get a copy of the code, study it and modify it as you wish, but if you make a change that you wish to see included in the official source code, you need to ask for a pull request on the pull requests section of the FreeCAD forum.

The procedure below show how to get a copy of the FreeCAD source code, from one of our two official repositories:

From Github
An easy way to start with the FreeCAD source code is using github. While the official FreeCAD Git repository is currently hosted on Sourceforge (see below), we also maintain an automatic mirror of the master branch on this github repository: https://github.com/FreeCAD/FreeCAD_sf_master 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) Create yourself a github account
 * 2) Go to https://github.com/FreeCAD/FreeCAD_sf_master
 * 3) Pres the "fork" button
 * 4) On your machine, clone your newly created freecad fork
 * 5) Do your changes to the code
 * 6) Create a new branch
 * 7) Checkout to that new branch
 * 8) Commit your changes to that new branch
 * 9) 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
 * 2) Do your changes to the code
 * 3) create a new branch
 * 4) Checkout to that new branch
 * 5) Commit your changes to that new branch
 * 6) Create yourself an account on a public git server (github, gitorious, sourceforge or any other)
 * 7) Push your branch to that server

important Note: As our github repository is only a mirror, we don't watch it very carefully. Therefore, please don't use it for pull requests. 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 instead.

From Sourceforge
To access a Git repository on sf.net, configure your Git client as follows :

git://git.code.sf.net/p/free-cad/code (read-only) ssh://USERNAME@git.code.sf.net/p/free-cad/code (read/write)

Regole di accesso
Daremo a chiunque sia interessato a partecipare l'accesso in scrittura al repository git con la condizione di stare lontani dal ramo principale (consiglio).

Autenticazione
L'accesso in sola lettura non richiede una 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.

Nota: In tutti gli esempi riportati in seguito, "USERNAME" rappresenta il proprio account in SourceForge.net.

Come clonare il repository
Si può clonare facilmente il repository remoto e iniziare a lavorare con: git clone ssh://USERNAME@git.code.sf.net/p/free-cad/code REPONAME cd REPONAME La prima volta che si tenta il collegamento all'host di free-cad.git.sourceforge.net, si dovrebbe ricevere un messaggio simile al seguente: The authenticity of host 'git.code.sf.net (216.34.181.91)' can't be established. RSA key fingerprint is 86:7b:1b:12:85:35:8a:b7:98:b6:d2:97:5e:96:58:1d. Are you sure you want to continue connecting (yes/no)? Prima di digitare 'yes' per accettare la firma digitale di accoglienza, accertarsi che la firma digitale per l'host sia corretta. È possibile trovare un elenco di chiavi di host SSH nella lista delle chiavi SSH, di firme host. Se si riceve un messaggio di avviso di chiave host, si prega di contattare il team di SourceForge.net.

Impostare il proprio nome utente in Git
Gli utenti devono connettersi al proprio repository del progetto utilizzando il proprio nome utente di SourceForge.net. Se il nome utente non è già impostato a livello globale, è possibile impostarlo a livello locale per il repository Git attuale in questo modo: git config user.name "YOUR NAME" git config user.email "USERNAME@users.sourceforge.net" È ora possibile utilizzare una combinazione di comandi "git add" e "git commit" per creare uno o più commit nel proprio repository locale.

From 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 two official repositories above are fully guaranteed to work and contain clean code.

It is also possible to attach several remote repositories to a same local FreeCAD git code, using the "git remote" command. This is useful to keep in sync with the master code branch, but keep an eye on the work of different developers.

Sviluppo
Prima di tutto non sviluppare mai sul ramo master! Creare sempre un ramo locale di sviluppo. Per imparare come farlo, consultare questa pagina.

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

Committing
Once you did some work, you commit them with: git commit -a Unlike SVN, you need to specifically tell which files to commit (or all with the -a option). Your text editor will open to allow you to write a commit message.

Publishing your work on the sourceforge 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

Publishing on another repository
Git also allows you to merge branches from more than one repository. If you don't have write access to the sourceforge hosted FreeCAD Git repository, you can also setup an account on any other free Git host such as github or gitorious and tell other people to get your changes from there.

Writing good commit messages
You should try to work in small chunks. If you cannot summarize your changes in one sentence, then it has probably been too long since you have made a commit. It is also important that you have helpful and useful descriptions of your work. For commit messages, FreeCAD has adopted a format mentioned in book Pro Git (see ).

Short (50 chars or less) summary of changes More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, preceded by a   single space, with blank lines in between, but conventions vary here

If you are doing a lot of related work, it has been suggested here that one should make as many commits large or small as makes sense for what you are working on using the short one sentence commit messages. When you want to merge, do a git log master..BRANCH and use the output as a basis for your quality commit message. Then when you merge to master use the --squash option and commit with your quality commit message. This will allow you to be very liberal with your commits and help to provide a good level of detail in commit messages without so many distinct descriptions.