Source code management

From FreeCAD Documentation
Revision as of 00:22, 25 December 2011 by Momentumv5 (talk | contribs) (→‎Developing: include tanderson's tip from the forum)

In future our main source code management tool will be git. This article explain how to use it and the general rules apply in case of FreeCAD.

For a while we keep up the SVN repository on sf.net. It is possible to commit changes

in SVN and Git. I will do from time to time a merge from one to the other via a gatekeeper repository.

This is only feasible as a transition. I strongly recommend the developers to switch to

git, as soon a possible!


Access

To access a Git repository, configure your Git client as follows :

 git://free-cad.git.sourceforge.net/gitroot/free-cad/free-cad  (read-only)
 ssh://USERNAME@free-cad.git.sourceforge.net/gitroot/free-cad/free-cad (read/write) 

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.

The read/write access uses your ssh password or ssh key to authorize your access. To perform write operations, your project administrator must have granted you write access to the repository. Getting Started

Note: - For all examples below, "USERNAME" represents your SourceForge.net user account.


How to clone the repository

You can simply clone your remote repository and get working:

git clone ssh://USERNAME@free-cad.git.sourceforge.net/gitroot/free-cad/free-cad
cd REPONAME

The first time you try connecting to the free-cad.git.sourceforge.net host, you should see a message similar to the following:

The authenticity of host 'free-cad.git.sourceforge.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)?

Before typing 'yes' to accept the host fingerprint, ensure the fingerprint is correct for the host. You can find a listing of SSH host keys in the SSH Host Key Fingerprints list. If you receive a host key warning, please contact the SourceForge.net team.

Setting your git username

Users should commit to their project repository using their SourceForge.net 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.sourceforge.net"

You can now use some combination of "git add" and "git commit" commands to create one or more commits in your local repository.


Developing

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

Publishing your work

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

Guidelines for publishing your work

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 #Further Reading).

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.

Further Reading

Available translations of this page: