Source code management/fr

Notre principal outil de gestion de code est git. Cet article explique comment l'utiliser et les règles générales qui s'appliquent dans le cas de FreeCAD. Il est fortement recommandé d'apprendre comment fonctionne git (il existe beaucoup d'informations et de tutoriels à propos de git sur internet) avant de travailler avec le code source de FreeCAD.

Il existe également de nombreux bons clients graphiques pour git, comme par exemple git-cola, qui rendent le processus de management des dépôts git plus facile. Il existe également une introduction superficielle au "Développement de FreeCad avec GitKraken"

Accès au code source
Tout le monde peut accéder et obtenir une copie du code source de FreeCAD, mais seuls les gestionnaires de projet(s) peuvent en modifier le contenu. Vous pouvez avoir une copie du code, l'étudier et le modifier comme vous le souhaitez, mais si vous voulez que vos modifications soient prises en compte dans le code source officiel, vous devez effectuer un "pull request" sur le dépôt master. Les gestionnaires pourront alors vérifier vos modifications avant de les valider. Cette façon de développer est connue sous le nom de flux de travail des dictateurs et des lieutenants où les développeurs principaux (dictateurs) et développeurs de confiance (lieutenants) filtrent le code soumis par les développeurs et les utilisateurs indépendants.

Si votre code source change de manière significative, il vous est conseillé de l'expliquer dans la section "pull requests" du forum FreeCAD.



Dépôt officiel Github
Une façon simple de commencer à travailler avec le code source de FreeCAD est d'utiliser le dépot officiel FreeCAD

Pour pouvoir contribuer et accéder au code source, vous devez avoir un compte GitHub.

Configuration de votre nom d'utilisateur git
Les utilisateurs doivent faire un commit vers leur dépôt de projet, en utilisant leur nom d'utilisateur GitHub. Si ce n'est pas déjà fait globalement, vous pouvez le régler au niveau local pour le dépôt Git actuel comme ceci :

Note sur les dépôts distants
Veuillez lire quelques informations pour vous aider à mieux comprendre la différence entre ce que origin et upstream signifient dans le contexte de git. Cette section explique comment définir les dépôts Git distants en upstream et origin. En gros:
 *   = votre fork du compte git FreeCAD alias https://github.com/GITHUB_USERNAME/FreeCAD.git
 *   = le dépôt git officiel FreeCAD alias https://github.com/FreeCAD/FreeCAD.git
 * Ceci est important à comprendre car si vous clonez  directement à partir de l', votre origine sera indiquée comme https://github.com/FreeCAD/FreeCAD.git. Si vous faites cela accidentellement, vous pouvez utiliser la commande   pour remédier à la situation.

La distinction est importante, vous devez d'abord écrire votre code dans votre propre dépôt, avant de "pousser" ces changements sur le dépôt officiel.

En s'appuyant sur ce qui a été dit précédemment, il existe 2 méthodes principales pour configurer votre environnement git:
 * 1ère méthode: Créez une branche sur GitHub et clonez votre branche localement
 * 2ème méthode: clonez le dépôt officiel de FreeCAD directement sur votre machine locale

Nous recommandons la première méthode car c'est la plus rapide.

1ère méthode: Créez une branche sur GitHub et clonez votre branche localement
Cette méthode est recommandée car elle nécessite moins d’étapes. Vous allez pour l'essentiel forker le dépôt FreeCAD sur votre propre compte GitHub puis cloner localement le dit fork de GitHub. Ensuite vous définissez votre dépôt upstream dans git. La procédure est la suivante:  Vous inscrire pour un compte GitHub si vous n'en avez pas déjà un Allez sur le dépôt FreeCAD: https://github.com/FreeCAD/FreeCAD En haut à droite de la page, recherchez et appuyez sur le bouton "Fork" (il s'agira essentiellement de copier le dépôt officiel FreeCAD sur votre dépôt personnel GitHub: https://github.com/GITHUB_USERNAME/FreeCAD.git) Sur votre machine, clonez votre fork FreeCAD nouvellement créée en ouvrant un terminal et en tapant: git clone https://github.com/GITHUB_USERNAME/FreeCAD.git  Une fois le processus de clonage terminé, définissez maintenant votre   dépôt à distance (voir "Note sur les dépôts distants"). Trouvez où sont placés vos répertoires git distants. Taper   et ca devrait ressembler à: [foo@bar FreeCAD]$ git remote -v origin	https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch) origin	https://github.com/GITHUB_USERNAME/FreeCAD.git (push)  Maintenant, configurez votre   dépôt [foo@bar FreeCAD]$ git remote add upstream https://github.com/FreeCAD/FreeCAD.git  Vérifiez de nouveau et la aussi ca devrait ressembler à: [foo@bar FreeCAD]$ git remote -v origin	https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch) origin	https://github.com/GITHUB_USERNAME/FreeCAD.git (push) upstream	https://github.com/FreeCAD/FreeCAD.git (fetch) upstream	https://github.com/FreeCAD/FreeCAD.git (push)   Nous pouvons maintenant commencer à nous développer. Rendez vous sur "Processus de développement Git"</li> </ol>


 * Once the download is complete, enter the new source directory and set the repository.


 * Confirm your remote repositories with ; the output should be similar to this


 * Now development can begin.

2ème méthode: clonez le dépôt officiel FreeCAD git sur votre ordinateur local
Cette méthode de configuration de votre environnement git nécessite quelques étapes supplémentaires, puis la première méthode. Vous clonerez le dépôt FC git directement sur votre machine locale, puis modifierez vos dépôts distants via le terminal. La procédure est la suivante: <ol> Clonez le code FreeCAD avec git: git clone https://github.com/FreeCAD/FreeCAD.git </li> Créez un compte sur un serveur git public (GitHub, GitLab, etc ... pour nos besoins, nous supposons que c'est GitHub)</li> Repérez où sont placés vos répertoires git distants: git remote -v </li> Cela retournera quelque chose qui ressemble à ce qui suit: [foo@bar FreeCAD]$ git remote -v origin https://github.com/FreeCAD/FreeCAD.git (fetch) origin https://github.com/FreeCAD/FreeCAD.git (push) </li> Comme expliqué ci-dessus "Note sur les dépôts distants" vous devez modifier ces adresses de dépôt git distantes. Donc configurez votre   distant: [foo@bar FreeCAD]$ git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git </li> Puis nous configurons notre   distant: [foo@bar FreeCAD]$ git remote add upstream https://github.com/FreeCAD/FreeCAD.git </li> Vérifiez de nouveau et la aussi ca devrait ressembler à: [foo@bar FreeCAD]$ git remote -v origin	https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch) origin	https://github.com/GITHUB_USERNAME/FreeCAD.git (push) upstream	https://github.com/FreeCAD/FreeCAD.git (fetch) upstream	https://github.com/FreeCAD/FreeCAD.git (push) </li> Nous pouvons maintenant commencer à nous développer. Rendez vous sur "Processus de développement Git"</li> </ol>


 * Once the download is complete, enter the new source directory and set the repository.


 * Then set up the repository.


 * Confirm your remote repositories with ; the output should be similar to this


 * Now development can begin.

If for some reason the remote repositories exist but point to the wrong address, you can remedy the situation by renaming the remote repository's name. For example, should point to your personal fork; if it is pointing to the original FreeCAD repository, change the name of this remote to, and manually add the  repository.

You can also show more information with the keyword.

Processus de développement Git

 * Une branche du dépôt principal est crée en ligne et clonée sur un ordinateur isolé (0); De nouvelles branches (1) sont utilisées pour appliquer des modifications et des ajouts de code localement (2); Les branches sont rechargées avec la version de code la plus récente (3), et elles sont ensuite "poussées" vers le dépôt distant (4); Puis un "Pull Request" est créé afin de pouvoir fusionner le code dans le dépôt principal (5). Ensuite, le clone personnel est mis à jour avec le nouveau code master (a); Ce master mis à jour est également "poussé" vers le dépôt distant (b) afin d'obtenir le même code à la fois sur le serveur distant et l'ordinateur isolé.

Ramifications
Une caractéristique importante de Git, est qu'il est extrêmement facile de travailler avec des branches, et, les fusionner. La meilleure pratique recommande de créer une nouvelle branche à chaque fois que vous voulez travailler sur une nouvelle fonctionnalité.

L'ajout d'une nouvelle branche est réalisée en 2 étapes : Tout d'abord vous créez la branche, puis vous commutez sur celle-ci.

ou, les deux opérations en un seule :

vous pouvez toujours vérifier, dans quelle branche vous êtes avec :

Une fois que vous avez effectué les changements et que vous les avez validés (commit), utilisez la ligne de commande avec les options suivantes pour visualiser les branches.

Soumettre
Une fois que vous avez fait un peu de travail, validez le avec :

Contrairement à SVN, vous devez informer avec précision les fichiers à envoyer (ou la totalité avec l'option -a). Votre éditeur de texte s'ouvrira, pour vous permettre d'écrire un message de validation.

Alternatively add the message in the commit itself

Rédaction de bons messages de commit
Vous devriez essayer de travailler en petites sections. Si vous ne pouvez pas résumer vos modifications en une seule phrase, il y a probablement trop longtemps, que vous avez fait un commit. Il est également important de donner une descriptions détaillée, et, utile de votre travail. Pour les messages de commit, FreeCAD a adopté un format qui est mentionné dans le livre Git Pro.

For big changes, it is important that you have helpful and useful descriptions of your work. FreeCAD has adopted a format mentioned in the Pro Git book, which consists of a short message, and then a larger descriptive paragraph.

Court sommaire des changements (50 caractères ou plus)

Si nécessaire, bien détailler les textes explicatifs. Ecrivez-en environ 72 caractères ou plus. Dans certains cas, la première ligne est considérée comme l'objet (résumé) d'un email, et, le reste du texte comme le corps. Laisser une ligne blanche pour séparer le résumé, du corps du message (sauf si vous omettez l’entièreté corps); des outils comme rebase peut se confondre si vous exécutez les deux ensemble.

Les paragraphes supplémentaires, viennent après les lignes vides. * Les puces sont très bien aussi - En général, un trait d'union ou un astérisque est utilisé pour la puce, précédé d'un  espace unique, avec des lignes blanches entre les deux, mais ici les conventions varient.

Si vous faites beaucoup de travaux connexes, il a été suggéré ici, que l'on doit faire autant de commits que possible, grand ou petit, dans le sens que vous utilisez des messages avec de courtes phrases. Lorsque vous souhaitez faire une fusion, faites un journal '''log master git .. BRANCH''', et, utilisez la sortie comme une base, pour la qualité de votre commit message. Ensuite, lorsque vous effectuez la fusion, utilisez l'option --squash, et, engagez avec le message de validation (commits) de qualité. Cela vous permettra d'être très libéral avec votre commit, et, aidez à assurer un bon niveau de détails des messages de commit sans faire trop de descriptions distinctes.

to see the individual commit messages. Then you can write a high quality message when performing a merge.

When you merge to master use the 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.

Regroupement des "commits"
Il est possible de regrouper plusieurs "commits" consécutifs dans 1 seul "commit", on appelle ça le "squashing". Ceci peut être utile dans les cas où vous avez effectué beaucoup de "petits commits" et que vous souhaitez les regrouper dans un seul "commit". Par exemple, lorsque vous changez simplement une variable, que vous corrigez des erreurs d'orthographe ou que vous ajustez la mise en forme de votre code. Vous devez faire des regroupements uniquement sur des "petits commits". Les grandes modifications effectuées sur plusieurs fichiers doivent contenir l'ensemble de l'historique des changements du commit.

Avec la commande, vous pouvez voir plusieurs "commits" consécutifs dont le plus récent est situé en haut de la liste. Dans cet exemple, plusieurs "commits" ont été effectués à partir de la "fonctionnalité A" pour réaliser l'implémentation de la "fonctionnalité B"; Nous souhaiterions maintenant regrouper tous les "commits" effectués pour la "fonctionnalité B" en un seul.

Utilisez la commande  avec l'option  pour sélectionner différents "commits" et les regrouper en un seul. Utilisez la valeur de hachage située juste devant le premier commit que vous voulez regrouper. Dans notre cas, il s'agit de celui qui correspond à la "fonctionnalité A".

un éditeur de ligne de commande comme ou  s'ouvrira pour vous montrer les "commits", mais cette fois avec le plus ancien en haut de la liste. Avant chaque "commit", le mot sera affiché. Supprimez le mot, et écrivez le mot ou juste la lettre  à la place, à l'exception de la première entrée; Ce "commit" est le plus ancien, donc tous les futurs "commits" seront regroupés dans celui-ci.

Sauvegardez le fichier et fermez l'éditeur.

L'éditeur s'ouvrira de nouveau. Vous pouvez maintenant ajouter un long message qui décrira tous les changements effectués comme s'ils étaient réunis dans un seul "commit". Sauvegardez le fichier et fermez l'éditeur une fois de plus. Ceci finira l'action de regroupement de ces "commits" avec le nouveau message que vous avez saisis.

Vous pouvez encore utiliser pour observer le nouvel historique des changements du commit. Dans ce cas, seul un simple "commit" pour la "fonctionnalité B", apparaitra au dessus du "commit" non modifié pour la "fonctionnalité A".

Publication de votre travail sur votre dépôt GitHub
Après avoir fait des modifications sur votre branche locale, et, l'engager (commit) (cela signifie s'engager localement), vous pouvez envoyer votre référentiel sur le serveur. Cela ouvre votre branche au public, et, permet aux principaux développeurs d'examiner, et, d'intégrer votre branche en "maître".

Pour plus d'informations sur ce sujet, veuillez consulter https://help.github.com/articles/pushing-to-a-remote/

The regular developer doesn't have write access to the repository https://github.com/FreeCAD/FreeCAD, therefore, you shouldn't push code to this remote server.

Rebasing from upstream
While you work on your own branch, the official FreeCAD code keeps "moving forward" with commits from other developers, and thus starts diverging from the code that you have in your personal fork. .-A origin/myNewBranch / -o---Z FreeCAD upstream/master

Therefore, when you are ready to merge your branch to the main FreeCAD repository, you must "rebase" your own copy of the repository, so that it is as close as possible to the official repository. See Git Branching - Rebasing for more information.

This will download the code from the branch of the  repository (the official FreeCAD source), and will merge it with your current branch, so that your changes will appear on top of the latest official code. If nobody modified the same files that you did, then the merge will succeed without problems. If some files were changed at the same time by different people, there may be a conflict that needs to be resolved. .-A' origin/myNewBranch / -o---Z FreeCAD upstream/master

To summarize, you need to be in the appropriate branch, rebase the upstream code, and then proceed with the push.

The operation is equivalent to a  followed by a. When the option is used, instead of doing a simple, it runs the  operation.

Fusion de la branche (pull request)
Once you have committed your changes locally, rebased your branch from the upstream repository, and pushed your branch online, you can initiate a "pull request". A pull request tells the administrators of the official FreeCAD repository that you want to merge the new code in your branch with the official code.

As soon as you push the code to your repository, GitHub will give you the option of comparing and creating a pull request against the  repository. By pressing you will open an interface that will allow you to pick which repository is the "base", target of the merge, and which is the "head", your additional code. A quick check will be done by the system telling you if there are no conflicts with the files that you modified; if you worked on files that nobody has touched, your branch will be able to merge cleanly. In addition, it will show you a text editor so you can write a message documenting your changes; it will also display the number of commits in your branch, the number of files that were modified, and a view showing you the differences between the "base" and the "head" so that everybody can immediately see your intended modifications.

Click to proceed. A message will appear indicating that some checks need to be done on the code. This is a system that compiles FreeCAD automatically and runs the unit tests. If the tests pass, the pull request will have a better chance of being merged into the main code, otherwise a report will be made indicating the errors encountered. See FreeCAD pull requests. Some checks haven’t completed yet


 * continuous-integration/travis-ci/pr Pending — The Travis CI build is in progress |Required|

If the tests succeed, you will see a message such as the following All checks have passed


 * continuous-integration/travis-ci/pr — The Travis CI build passed |Required|

This branch has no conflicts with the base branch Only those with write access to this repository can merge pull requests.

Now you must wait for the administrators to merge your branch; you will be notified when this happens.

If you wish, you may delete the branch that was just merged, or even your entire FreeCAD fork, as your own code is already included at the end of the master branch.

you may continue working on the same branch while you wait for merge approval; if you  again, a second merge commit will be queued in the same pull request, and another automated test will be done. That is, while your merges aren't yet approved by the administrators, you may keep pushing changes to your repository, and this will queue those commits in the same pull request to the  repository. Using a single pull request to queue many individual commits is often desirable for small changes. For big additions to the source code, you should create another branch, develop your features there, and then submit a separate pull request for this branch.

The pull request interface can be used whenever you want to submit code from your own repositories to another repository in GitHub. You can use it to merge code in the opposite direction as well, from other people's branches to your own, or even between your own branches. In the last case, since you own the branches, the merges can be approved by yourself immediately.

Maintien du dépôt GitHub à jour
Once you've forked FreeCAD, your personal repository exists independently from the original. When the original repository has new commits, GitHub will inform you that your personal repository is behind in number of commits:

In similar way, if you created a development branch with new code, GitHub will inform you that this branch is ahead in number of commits; that is, this branch has changes that haven't been merged into the official FreeCAD repository:

While developing, both cases are possible, as your own branch may lack commits made by other developers, but include new commits by you:

When developing code it is recommended that you rebase the branch in which you are currently working, as that will put your branch always ahead of the FreeCAD master code.

As for your original branch, it will never be automatically updated by GitHub; this is something that you must do yourself. Switch to the branch, then  from  (which performs a  and ), and then push this updated  branch to your remote  repository.

After this is done, GitHub will let you know that your are synchronized with the repository.

Now that your is up to date, you may decide to switch to it, and delete the other branch that you used previously to develop a feature.

To delete the branch in the remote repository, you can use the  action. Normally, you push a local branch; this creates a remote branch with the same name as your local branch.

However, if you use the notation, the local branch is created in the remote repository under a different name:

Therefore, you can delete the remote branch by pushing an empty local branch:

Now that you only have an up-to-date, you can create a new branch, and repeat the steps of changing files, committing, pushing, submitting a pull request, merging, and updating.

If you don't want to delete your already custom branch, you may force updating it to be equal to the updated ; then you can do whatever you want with it, including adding more commits and pushing it to the remote repository.

Hard resetting a branch like this is usually not needed. In most cases, you want to follow the sequence of creating a new branch, committing changes, pushing those changes, merging the branch, and then deleting the branch.

Résolution des problèmes de merge
https://gist.github.com/piscisaureus/3342247

Résolution des conflits de fusion

 * explications git-scm sur la manière dont les conflits sont présentés
 * Article de GitHub sur la résolution des problèmes de merge par la ligne de commande
 * Personnalisez votre outil de merge préféré lorsque vous rencontrez un conflit entre plusieurs git.

La fusion des branches locales via pourra occasionnellement générer des conflits car les fichiers peuvent être modifiés en même temps et au même emplacement. Si cela se produit, vous allez devoir réparer les fichiers, puis refaire la fusion.


 * How merge conflicts are presented with
 * Basic merge conflicts and Git Tools - Advanced Merging
 * Resolving a merge conflict using the command line
 * External merge and diff tools to use when you encounter a Git conflict.

Inspect the changes of a single file through various commits:

Création de correctifs à partir de Git
Il est parfois nécessaire de créer un patch au lieu de soumettre un PR. Le flux de travail suivant explique comment procéder: <ol>  Assurez-vous d’être dans la bonne branche (c’est-à-dire pas dans la branche principale) en vérifiant avec git branch -v</ pre> </li>  Créez le patch: we do this by using the git format-patch command which we patch against the master branch and redirect to STDOUT. Nous créons le patch dans le répertoire en dehors de la source (afin de ne pas polluer le répertoire source lui-même, ceci est facultatif car vous pouvez choisir l'emplacement où vous voulez que le patch soit créé) git format-patch master --stdout> ../patch.name.patch </li>  Une autre méthode consiste à utiliser git format-patch HEAD^ ou git format-patch HEAD~1. Le ^ ou 1 peut être changé en nombre de commits devant être couverts, à savoir: ^^^ ou ~ 3. git format-patch HEAD^ </li> Il créera un patch ou une série de patchs avec le format de nom de fichier XXXX-commit-message.patch. Un exemple: 0001-fix-ViewProjMatrix-getProjectionMatrix.patch


 * You should be developing your new code in a secondary branch of your repository, and not in the master branch. So the first step is to make sure you are in the correct branch.


 * Now use against the master branch, and use the  option to redirect the result to standard output; then redirect the standard output to a file, which for convenience is created above the source code directory.


 * Another method is

The number of circumflex carets or the number  indicate the number of commits that should be considered, that is,  or  will create three patches for three commits.

This will create a patch or series of patches with the following naming convention

where is a number from  to, and the commit message forms the majority of the file name, for example,

Application de correctifs via git
Git a la capacité de fusionner des correctifs/diffs. Pour en savoir plus à ce sujet, lisez la référence suivante: Application des patches avec Git

If you already have the patch file in your system, just apply it.

You can use to download a patch from a website, and then apply it through.


 * Conseil utile: ajoutez simplement .diff ou .patch à la fin de l'URL d'une page de validation GitHub, d'une demande d'extraction ou d'une vue de comparaison et vous obtiendrez une vue de cette page. Exemple:
 * Regular GitHub page: https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621
 * 'Diffed' GitHub page: https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.diff
 * 'Patched' GitHub page: https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch

You can point to a particular commit patch in the repository, and pipe it directly to  to apply the patch. curl https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch | git apply -

Inverser un patch dans git
Si vous avez suivi les instructions ci-dessus et que vous avez changé d'avis, vous pouvez rapidement l'inverser en utilisant: git apply -R path/file.patch ou une autre façon est d'utiliser: git checkout -f qui supprimera les modifications non validées de la branche

This will revert the changes applied, if you still have access to the original patch file.

Alternatively, this will remove non-committed changes to the branch.

Stockage temporaire dans le cache des git commits
Supposons que vous travaillez sur une branche et que vous modifiez la source en dehors du champ de votre branche actuelle. En d'autres termes, il serait préférable d'ajouter certains commits à une autre branche et de les soumettre à la place du fichier actuel. C'est ici que la commande  'git stash'  peut être très utile. La commande git stash peut vous aider à stocker (temporairement mais en toute sécurité) vos modifications locales non validées. git stash Ensuite, lorsque vous souhaitez utiliser ces commits, vous pouvez faire git stash apply ou git stash pop pop supprimera le cache <BR/> Si vous avez plusieurs caches, vous pouvez faire git stash list Pour en savoir plus sur les autres fonctions que vous pouvez utiliser, consultez https://medium.freecodecamp.org/useful-tricks-you-might-not-know-about-git-stash-e8a9490f0a1a

Say that you're working on a branch and you find yourself making some modifications to the source that are out of the scope of your current branch; in other words, those changes would be better in another branch instead of the current one. The command can be used to temporarily store those uncommitted local changes.

If in the future you want to use those commits, you can pop the commits out of the stash, and into your working branch.

Or if you decide that you don't like those saved commits anymore, you may drop the commits from the stash entirely.

You can list multiple stash commits with

To learn more, read Useful tricks you might not know about Git stash.

Check out GitHub requests locally
Checkout GitHub pull requests locally

Numéro de révision FreeCAD
Contrairement à Subversion qui incrémente le numéro de révision, Git génère une valeur de hachage SHA-1 à chaque "commit". Une valeur de hachage est une longue chaîne de caractères alphanumériques qui ressemble à ceci :

Quelle est la dernière révision de FreeCAD Dev ?
Il y a 2 façons de faire cela:
 * 1ère méthode: Dans votre répertoire git cloné, tapez:


 * 2ème méthode: Parcourez le dépôt sur GitHub et lisez le nombre de mises à jour (commits) effectuées dans la branche correspondante.

Quel est le numéro de révision d'un commit et inversement?
git rev-list --count 9948ee4 13541

Since the hash is an alphanumeric string it is not very useful to decide if a certain commit is older or newer than another hash. To find the revision number of a particular hash, again use the operation; the input can be the full hash, or a partial hash that is unique, usually the first 7 digits are enough.

Revision hash of a specific commit number
If we have the commit number, say, 15000, and we want to find the corresponding hash, we need to calculate the number of commits since this point until the last commit. First, get the latest commit number.

Then subtract the commit that we want.

Then use the operation to show all commits and hashes. The option jumps the difference in commits that we calculated so that we go directly to the hash that we are looking for.

Since the log may show you two close commits, confirm it's the right commit number. If it's off by one, just pick the next commit in the sequence (before or after) and check again.


 * quelques sujets du forum à ce sujet:
 * https://forum.freecadweb.org/viewtopic.php?f=10&t=26673
 * https://forum.freecadweb.org/viewtopic.php?t=5308
 * https://forum.freecadweb.org/viewtopic.php?f=18&t=12883&p=103207#p103203
 * https://forum.freecadweb.org/viewtopic.php?f=10&t=31118

Comment le numéro de révision dans l'aide de FreeCAD est-il généré ?
Le numéro de version qui apparait dans est définit dans le fichier, qui est créé au moment de la compilation lorsque l'outil  est exécuté. Lisez le post Extract version number from git source pour plus d'informations.

See the compile on Unix page for the full information on compiling FreeCAD.

Dépôts alternatifs
La force de Git est que tout à chacun peut cloner un projet, et commencer à modifier du code. Plusieurs contributeurs fréquents du projet FreeCAD ont leur propre dépôt Git, avec lequel ils réalisent leur travail avant que des modifications soient prêtes pour être incluses dans le code source officiel, ou avec lequel ils expérimentent simplement de nouvelles idées. Dans certains cas, vous pouvez souhaiter cloner votre code FreeCAD depuis un des ces dépôt plutôt que depuis les dépôts officiels, pour pouvoir bénéficier des changements réalisés par leur utilisateurs.

Several collaborators of the FreeCAD project have their own Git repositories where they build up their work or where they experiment new ideas before they are ready to be included in the official source code. In certain cases you might want to clone your FreeCAD sources from these other repositories to test their code.

Il est également possible de lier plusieurs dépôts distants avec un seul code local, en utilisant la commande "git remote". C'est pratique pour rester synchronisé avec la branche "master", mais gardez un œil sur le travail des différents dévelopers.

Head to the development section of the FreeCAD forum to discuss more about development of new features. See also Compiling for instructions on compiling FreeCAD.

Lecture complémentaire

 * Développer FreeCAD avec GitKraken, un guide pour utiliser l'interface graphique avec Git.
 * Git pour le paresseux, un guide très concis pour les principales commandes de.
 * Le Pro Git book, un livre open source qui vous apprend à utiliser Git; Il est disponible au format électronique et papier.