Source code management/es: Difference between revisions

From FreeCAD Documentation
(Updating to match new version of source page)
(Updating to match new version of source page)
Line 1: Line 1:
<languages/>
<languages/>
Our main source code management tool is [http://en.wikipedia.org/wiki/Git_%28software%29 git]. This article explains how to use it and how some general rules apply in the case of FreeCAD. You are highly advised to learn how git works first (there are a lot of tutorials and docs available for git on the internet) before working with the FreeCAD source code.
The main source code management tool for the FreeCAD project is [http://en.wikipedia.org/wiki/Git_%28software%29 Git], which can be easily installed in most operating systems from a package manager or directly from [https://git-scm.com/ Git's website]. You are advised to become familiar with Git before working with the FreeCAD source code directly. Visit the [https://git-scm.com/doc Git documentation] page for the reference manual, as well as the [https://git-scm.com/book/en/v2 Pro Git book] to learn to use the system in a general way. The present document focuses on the use of Git for FreeCAD development. Compiling FreeCAD is described in [[Compiling|Compiling]].


There are also many good graphical clients to git, such as [http://github.com/git-cola/git-cola git-cola], that make the whole process of managing git repositories easier. FYI there also exists a cursory intro to [[Developing FreeCAD with GitKraken|Developing FreeCAD with GitKraken]].
While Git is primarily a terminal application, there are many graphical clients for it which facilitate working with branches, applying patches, and submitting pull requests to a master branch. Examples include [https://git-scm.com/docs/gitk gitk] (the first graphical interface developed), [https://wiki.gnome.org/Apps/Gitg/ gitg] (Gnome), [https://github.com/tibirna/qgit qgit] (Qt), [https://jonas.github.io/tig/ tig] (Ncurses), [http://github.com/git-cola/git-cola git-cola], and [https://www.gitkraken.com/ GitKraken] (proprietary). Please see [[Developing FreeCAD with GitKraken|Developing FreeCAD with GitKraken]] for a cursory introduction to this tool.


== Source Code Access ==
== Source code 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 [http://forum.freecadweb.org/viewforum.php?f=17 pull requests] section of the FreeCAD forum.


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 want your changes to be included in the official source code, you need to perform a "pull request" against the master repository so that your modifications can be reviewed by the managers. This style of development is known as the [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows Dictator and lieutenants workflow], as the core developers (dictators) and trusted developers (lieutenants) filter the code that is submitted by independent developers and users.
{{Note|NOTE|In all examples below, "GITHUB_USERNAME" represents your GitHub user account.}}


If your source code changes are significant, you are advised to explain them in the pull request section of the [http://forum.freecadweb.org/viewforum.php?f=17 FreeCAD forum].
=== Official GitHub Repo ===

An easy way to start with the FreeCAD source code is using the official FreeCAD repository at
[[File:FreeCAD_git_workflow.svg|600px]]
'''https://github.com/FreeCAD/FreeCAD'''
{{Caption|Generic workflow to develop code for FreeCAD; everybody can get the code from the main repository, but the main developers have the exclusive right to review and merge submissions by other developers.}}

=== Official GitHub repository ===
The FreeCAD source code is hosted in Github, {{URL|https://github.com/FreeCAD/FreeCAD}}

In order to contribute code, you need to have a [https://github.com/join GitHub account].


<div class="mw-translate-fuzzy">
<div class="mw-translate-fuzzy">
Line 18: Line 23:
Los usuarios deberían enviar a sus repositorios de proyecto utilizando sus nombres de usuario de SourceForge.net. Si no está definido globalmente, lo puedes definir localmente para el repositorio de Gir actual así:
Los usuarios deberían enviar a sus repositorios de proyecto utilizando sus nombres de usuario de SourceForge.net. Si no está definido globalmente, lo puedes definir localmente para el repositorio de Gir actual así:
</div>
</div>
{{Code|code=
git config user.name "YOUR NAME"
git config user.email "GITHUB_USERNAME@users.noreply.github.com"
git config user.name "YOUR_NAME"
git config user.email GITHUB_USERNAME@users.noreply.github.com
Ahora puedes utilizar alguna combinación de los comandos "git add" y "git commit" para crear uno o más envíos en tu repositorio local.
}}


Where {{incode|"YOUR_NAME"}} represents your full name or nickname, used to identify the author of a particular commit, and {{incode|GITHUB_USERNAME}} indicates the name of your account on GitHub.
==== A note about Remotes ====

Please read some [https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github#9257901 background] to help you understand better the difference between what '''origin''' and '''upstream''' mean in the context of git. This section explains how to set the correct upstream and origin remote git repos.
=== Remote repositories ===
Please read [https://stackoverflow.com/questions/9257533/what-is-the-difference-between-origin-and-upstream-on-github#9257901 What is the difference between origin and upstream on GitHub?] (Stackoverflow) to help you understand the difference between {{incode|origin}} and {{incode|upstream}} in the context of Git. This section explains how to set the correct repositories for development.
Essentially:
Essentially:
* '''<code>origin</code>''' = Your fork of the FreeCAD git repo AKA https://github.com/GITHUB_USERNAME/FreeCAD.git
* {{incode|origin}} is your personal fork of the official FreeCAD repository, that is, {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}
* '''<code>upstream</code>''' = The official FreeCAD git repo AKA https://github.com/FreeCAD/FreeCAD.git
* {{incode|upstream}} is the official FreeCAD repository, that is, {{URL|https://github.com/FreeCAD/FreeCAD}}

*: '''This is important to understand because if you <code>git clone</code> directly from <code>upstream</code> then <u>confusingly</u>, your origin will be listed as''' https://github.com/FreeCAD/FreeCAD.git <br/>BTW, if you do this accidentally you can use the '''<code>git remote rename</code>''' command to remedy the situation.
This distinction is important, as you should write code in your own copy of the repository first, before pushing those changes to the official repository.
So, based on the above, there are 2 main ways to setup your git environment:

* [[Source_code_management#Clone_Official_FreeCAD_git_repo_to_your_local_machine|1st Method: Fork on GitHub and clone your fork locally]]
Based on the above, there are two ways to setup your Git development environment:
* [[Source_code_management#Clone_Official_FreeCAD_git_repo_to_your_local_machine|2nd Method: Clone FreeCAD official directly to your local machine]]
* 1st Method: fork on GitHub and clone your fork locally
We recommend the 1st method for the reason mentioned above.
* 2nd Method: clone FreeCAD directly to your local machine, and adjust the remote servers

We recommend the 1st method because it's one step faster.


<div class="mw-collapsible mw-collapsed toccolours">
<div class="mw-collapsible mw-collapsed toccolours">
==== 1st Method: Fork on GitHub and clone your fork locally ====
==== 1st Method: Fork on GitHub and clone your fork locally ====

<div class="mw-collapsible-content">
<div class="mw-collapsible-content">
First you will fork the FreeCAD repository in GitHub, then clone this personal fork to your computer, and finally set the {{incode|upstream}} repository.
{{Note|Important Note|You will need to re-configure 'remote upstream' as mentioned above in "[[Source_code_management#A_note_about_Remotes|A note about Remotes]]"}}
* [https://github.com/join Log in] to your GitHub account.
This method is the recommended way since it takes less steps. You will essentially fork the FreeCAD repo on your own GitHub account and then clone said GitHub fork locally. Then you will set your '''upstream''' repo in git. The procedure is as follows:
* Go to the official FreeCAD repository: {{URL|https://github.com/FreeCAD/FreeCAD}}
<ol>
* In the top right of the page press the "Fork" button. This will create a personal copy of the FreeCAD repository under your GitHub username: {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}
<li>[https://github.com/join Sign up] for a GitHub account if you don't already have one </li>
* On your machine, clone your newly created FreeCAD fork. It will be created inside a directory {{incode|freecad-source}}.
<li>Go to the FreeCAD repo: https://github.com/FreeCAD/FreeCAD</li>
{{Code|code=
<li>In the top right of the page find and press the "Fork" button (this will essentially git clone the official FreeCAD repo to your personal GitHub repo: https://github.com/GITHUB_USERNAME/FreeCAD.git) </li>
git clone https://github.com/GITHUB_USERNAME/FreeCAD.git freecad-source
<li>On your machine, clone your newly created FreeCAD fork by opening a terminal and typing:
}}
<pre>git clone https://github.com/GITHUB_USERNAME/FreeCAD.git</pre></li>
* Once the download is complete, enter the new source directory and set the {{incode|upstream}} repository.
<li>Once the clone process is complete, now set your '''<code>upstream</code>''' remote repo (see "[[Source_code_management#A_note_about_Remotes|A note about Remotes]]"). Find out what and where your remote git repositories are set to. Type '''<code>git remote -v</code>''' and the output should look similar to:
{{Code|code=
<pre> [foo@bar FreeCAD]$ git remote -v
cd freecad-source
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch)
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push)</pre></li>
git remote add upstream https://github.com/FreeCAD/FreeCAD.git
}}
<li>Great. Now set your '''<code>upstream</code>''' repo
* Confirm your remote repositories with {{incode|git remote -v}}; the output should be similar to this
<pre>[foo@bar FreeCAD]$ git remote add upstream https://github.com/FreeCAD/FreeCAD.git</pre></li>
{{Code|code=
<li>Check your remotes again, they should look similiar to this:
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch)
<pre> [foo@bar FreeCAD]$ git remote -v
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch)
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push)
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push)
upstream https://github.com/FreeCAD/FreeCAD.git (fetch)
upstream https://github.com/FreeCAD/FreeCAD.git (fetch)
upstream https://github.com/FreeCAD/FreeCAD.git (push)
}}
upstream https://github.com/FreeCAD/FreeCAD.git (push)</pre></li>
* Now development can begin.
</li>
</div>
<li>Now we can start developing. Please refer to "[[Source_code_management#Git_Development_Process|Git Development Process]]"</li>
</ol>
</div>
</div></div>


<div class="mw-collapsible mw-collapsed toccolours">
<div class="mw-collapsible mw-collapsed toccolours">

==== 2nd Method: Clone Official FreeCAD git repo to your local machine ====
==== 2nd Method: Clone FreeCAD directly to your local machine ====

<div class="mw-collapsible-content">
<div class="mw-collapsible-content">
First you will fork the FreeCAD repository in GitHub, however, you will clone the original FreeCAD repository to your local machine, and then alter your remotes via the terminal.
{{Note|Important Note|You will need to re-configure both 'remote origin' and 'remote upstream' please refer to above "[[Source_code_management#A_note_about_Remotes|A note about Remotes]]"}}
* [https://github.com/join Log in] to your GitHub account.
This method of setuping your git environment takes a few more steps then the 1st method. You will clone the FC git repo directly to your local machine and then alter your remotes via the terminal. The procedure is as follows:
* Go to the official FreeCAD repository: {{URL|https://github.com/FreeCAD/FreeCAD}}
<ol>
* In the top right of the page press the "Fork" button. This will create a personal copy of the FreeCAD repository under your GitHub username: {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}
<li>Clone the FreeCAD code with git:
* Clone the original FreeCAD repository. It will be created inside a directory {{incode|freecad-source}}.
<pre>git clone https://github.com/FreeCAD/FreeCAD.git</pre></li>
{{Code|code=
<li>Create an account on a public git server (GitHub, GitLab, etc... for our purposes we're assuming it's GitHub)</li>
git clone https://github.com/FreeCAD/FreeCAD.git freecad-source
<li>Find out what and where your remote git repositories are set to:
}}
<pre>git remote -v</pre></li>
* Once the download is complete, enter the new source directory and set the {{incode|origin}} repository.
<li>This will return something that looks like the following:
{{Code|code=
<pre>[foo@bar FreeCAD]$ git remote -v
cd freecad-source
origin https://github.com/FreeCAD/FreeCAD.git (fetch)
origin https://github.com/FreeCAD/FreeCAD.git (push)</pre></li>
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git
}}
<li>As was explained above in "[[Source_code_management#A_note_about_Remotes|A note about Remotes]]" you need to modify these remote git repo addresses.<br />
* Then set up the {{incode|upstream}} repository.
So first set up your '''<code>origin</code>''' remote:
{{Code|code=
<pre>[foo@bar FreeCAD]$ git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git</pre></li>
git remote add upstream https://github.com/FreeCAD/FreeCAD.git
<li>Then we set up our '''<code>upstream</code>''' remote:
}}
<pre>[foo@bar FreeCAD]$ git remote add upstream https://github.com/FreeCAD/FreeCAD.git</pre></li>
<li>Check your remotes again, they should look similiar to this:
* Confirm your remote repositories with {{incode|git remote -v}}; the output should be similar to this
{{Code|code=
<pre> [foo@bar FreeCAD]$ git remote -v
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch)
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (fetch)
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push)
origin https://github.com/GITHUB_USERNAME/FreeCAD.git (push)
upstream https://github.com/FreeCAD/FreeCAD.git (fetch)
upstream https://github.com/FreeCAD/FreeCAD.git (fetch)
upstream https://github.com/FreeCAD/FreeCAD.git (push)</pre></li>
upstream https://github.com/FreeCAD/FreeCAD.git (push)
}}
<li>Now we can start developing. Please refer to "[[Source_code_management#Git_Development_Process|Git Development Process]]"</li>
* Now development can begin.
</ol>
</div></div>
</div>
</div>

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, {{incode|origin}} should point to your personal fork; if it is pointing to the original FreeCAD repository, change the name of this remote to {{incode|upstream}}, and manually add the {{incode|origin}} repository.
{{Code|code=
git remote rename origin upstream
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git
git remote -v
}}

You can also show more information with the {{incode|show}} keyword.
{{Code|code=
git remote show origin
git remote show upstream
}}


<div class="mw-translate-fuzzy">
<div class="mw-translate-fuzzy">
Line 96: Line 123:
Puedes aprender a hacer esto [http://book.git-scm.com/3_basic_branching_and_merging.html aquí].
Puedes aprender a hacer esto [http://book.git-scm.com/3_basic_branching_and_merging.html aquí].
</div>
</div>

[[File:FreeCAD_git_branches_workflow.svg|800px]]
{{Caption|Generic workflow to develop code for FreeCAD using {{incode|git}}; the main repository is forked online and cloned to an offline computer (0); new branches (1) are used to commit local changes and additions to the code (2); the branches are rebased to the latest online code (3), and then are pushed to the remote repository (4); then a pull request is created in order to merge the code into the main repository (5). Then the personal clone is updated with the new master code (a); this updated master is also pushed to the remote repository (b) in order to have the same code both online and offline.}}


=== Ramificado ===
=== Ramificado ===


Una importante característica de Git es que es extremadamente sencillo trabajar con ramas y fusionarlas. La mejor forma de trabajar recomienda crear una nueva rama siempre que quieras trabajar en una nueva característica. La creación de una rama se hace con:
Una importante característica de Git es que es extremadamente sencillo trabajar con ramas y fusionarlas. La mejor forma de trabajar recomienda crear una nueva rama siempre que quieras trabajar en una nueva característica. La creación de una rama se hace con:

git branch myNewBranch
Instead of working on the master version of the code, best practices with Git recommend creating a new branch whenever you want to work on a new feature. Branches are inexpensive, they don't copy the entire source tree, but merely create a point in time on top of which you will write code; thus branches help keep work in progress separate from the main code.
git checkout myNewBranch

Using a new branch is done in two steps, first your create the branch, and then you switch to it:
{{Code|code=
git branch myNewBranch
git checkout myNewBranch
}}
o, ambas operaciones en una:
o, ambas operaciones en una:
{{Code|code=
git checkout -b myNewBranch
git checkout -b myNewBranch
}}
siempre puedes comprobar con que rama estas:
siempre puedes comprobar con que rama estas:
{{Code|code=
git branch
git branch
git branch -vv
}}
After you've made changes and committed those changes use the {{incode|log}} operation with the following options to visualize the branches
{{Code|code=
git log --oneline --decorate --graph --all
}}


=== Envío ===
=== Envío ===


Una vez que hagas algo de trabajo, envíalo con:
Una vez que hagas algo de trabajo, envíalo con:

<pre>git commit -a</pre>
Once you are inside a new branch, edit the source files that you want with a text editor. To see which files were modified use the {{incode|status}} and {{incode|diff}} operations; when you are satisfied with the modifications, save the changes with the {{incode|commit}} operation:
{{Code|code=
git status
git diff
git commit -a
}}
A diferencia de SVN, tienes que especificar los archivos que quieres enviar (o todos con la opción -a). Tu editor de texto se abrirá para permitirte escribir un mensaje de envío.
A diferencia de SVN, tienes que especificar los archivos que quieres enviar (o todos con la opción -a). Tu editor de texto se abrirá para permitirte escribir un mensaje de envío.


Alternatively add the message in the commit itself
<div class="mw-translate-fuzzy">
{{Code|code=
=== Publicación de tu trabajo en el repositorio de sourceforge ===
git commit -a -m "Fix the bug in the clone function."

}}
Después de hacer algunos cambios en tu ramal local y enviarlos (es decir, enviarlos "localmente") puedes enviar tu repositorio al servidor. Esto abre tu ramal al público y permite que los desarrolladores principales revisen e integren tu ramal en el ''principal''.
</div>
git push <REMOTENAME> <BRANCHNAME>
git push origin my-branch
<small>For further info on this subject please read https://help.github.com/articles/pushing-to-a-remote/</small>


=== Escribiendo buenos mensajes de envío ===
=== Escribiendo buenos mensajes de envío ===
Line 126: Line 173:
Deberías tratar de trabajar en pedazos pequeños. Si no puedes resumir tus cambios en una frase, entonces posiblemente ha pasado pasado demasiado tiempo desde que hiciste un envío. También es importante que ofrezcas descripciones de tu trabajo que sean útiles y ayuden. Para los mensajes de envío, FreeCAD ha adoptado un formato mencionado en el libro Pro Git (mira [[#Otras lecturas]]).
Deberías tratar de trabajar en pedazos pequeños. Si no puedes resumir tus cambios en una frase, entonces posiblemente ha pasado pasado demasiado tiempo desde que hiciste un envío. También es importante que ofrezcas descripciones de tu trabajo que sean útiles y ayuden. Para los mensajes de envío, FreeCAD ha adoptado un formato mencionado en el libro Pro Git (mira [[#Otras lecturas]]).


For big changes, it is important that you have helpful and useful descriptions of your work. FreeCAD has adopted a format mentioned in the [https://git-scm.com/book/en/v2 Pro Git] book, which consists of a short message, and then a larger descriptive paragraph.
Resumen corto (50 caracteres o menos) de cambios

Resumen corto (50 caracteres o menos) de cambios


Texto de explicación más detallado, si es necesario. En unos 72 caracteres.
Texto de explicación más detallado, si es necesario. En unos 72 caracteres.
Line 145: Line 194:
Si estas haciendo un montón de trabajo relacionado, se sugiere [http://forum.freecadweb.org/viewtopic.php?f=10&t=2062&p=14887#p14886 aquí] que deberías hacer tantos envíos grandes o pequeños como sea necesario para que tengan sentido en lo que estés trabajando utilizado los mensajes cortos de envío. Cuando quieras fusionarlos, haz un registro master..BRANCH y utiliza el resultado para tu mensaje de envío. Cuando fusionas con el principal utiliza la opción --squash y envía con tu mensaje de envío. Esto te permitirá ser muy liberal con tus envíos y ayudar a proporcionar un buen nivel de detalle en los mensajes de envío sin demasiadas descripciones distintas.
Si estas haciendo un montón de trabajo relacionado, se sugiere [http://forum.freecadweb.org/viewtopic.php?f=10&t=2062&p=14887#p14886 aquí] que deberías hacer tantos envíos grandes o pequeños como sea necesario para que tengan sentido en lo que estés trabajando utilizado los mensajes cortos de envío. Cuando quieras fusionarlos, haz un registro master..BRANCH y utiliza el resultado para tu mensaje de envío. Cuando fusionas con el principal utiliza la opción --squash y envía con tu mensaje de envío. Esto te permitirá ser muy liberal con tus envíos y ayudar a proporcionar un buen nivel de detalle en los mensajes de envío sin demasiadas descripciones distintas.


When you merge to master use the {{incode|--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.
== Advanced git operations ==
=== Check out GitHub Requests Locally ===
https://gist.github.com/piscisaureus/3342247


<div class="mw-translate-fuzzy">
=== Resolving Merge Conflicts ===
=== Publicación de tu trabajo en el repositorio de sourceforge ===
* [https://git-scm.com/docs/git-merge#_how_conflicts_are_presented git-scm explanation on how conflicts are presented]

* [https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/ GitHub article on resolving merge conflicts via the command-line]
Después de hacer algunos cambios en tu ramal local y enviarlos (es decir, enviarlos "localmente") puedes enviar tu repositorio al servidor. Esto abre tu ramal al público y permite que los desarrolladores principales revisen e integren tu ramal en el ''principal''.
* [https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_external_merge_tools Customize your preferred merge tool] when you encounter a git conflict.
</div>

The local branches in your computer aren't automatically synchronized with the remote servers that you have specified as {{incode|origin}} or {{incode|upstream}} (see [[#Remote repositories|Remote repositories]]); you have to explicitly push the branches to the remote servers, for which you must have write access. Once you do this, the branches become public, and available for review by other developers.

For FreeCAD, you should push your local branch to the {{incode|origin}} remote repository, that is, {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}. You need to enter your username and password every time you push, unless you have set up [https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage#_credential_caching Credential caching]. Please read [https://help.github.com/articles/pushing-to-a-remote/ Pushing commits to a remote repository] for more information.
{{Code|code=
git push origin myNewBranch
}}

The regular developer doesn't have write access to the {{incode|upstream}} repository {{URL|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.
<pre>
.-----A origin/myNewBranch
/
-----o-----------Z FreeCAD upstream/master
</pre>

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 [https://git-scm.com/book/en/v2/Git-Branching-Rebasing Git Branching - Rebasing] for more information.
{{Code|code=
git checkout myNewBranch
git pull --rebase upstream master
}}

This will download the code from the {{incode|master}} branch of the {{incode|upstream}} repository (the official FreeCAD source), and will merge it with your current branch ({{incode|myNewBranch}}), 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.
<pre>
.----A' origin/myNewBranch
/
-----o-----------Z FreeCAD upstream/master
</pre>

To summarize, you need to be in the appropriate branch, rebase the upstream code, and then proceed with the push.
{{Code|code=
git checkout myNewBranch
git pull --rebase upstream master
git push origin myNewBranch
}}

The {{incode|pull}} operation is equivalent to a {{incode|fetch}} followed by a {{incode|merge}}. When the {{incode|--rebase}} option is used, instead of doing a simple {{incode|merge}}, it runs the {{incode|rebase}} operation.
{{Code|code=
git pull upstream

git fetch upstream
git merge FETCH_HEAD
}}

{{Code|code=
git pull --rebase upstream master

git fetch upstream
git rebase master
}}

=== Merging the branch (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 [https://help.github.com/articles/about-pull-requests/ 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 {{incode|origin}} repository {{URLn|https://github.com/GITHUB_USERNAME/FreeCAD}}, GitHub will give you the option of comparing and creating a pull request against the {{incode|upstream}} repository. By pressing {{Button|Compare & pull request}} 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.
{{Code|code=
base repository: FreeCAD/FreeCAD base: master <---- head repository: GITHUB_USERNAME/FreeCAD compare: myNewBranch

Able to merge. These branches can be automatically merged.
}}

Click {{Button|Create pull request}} 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 [https://travis-ci.org/FreeCAD/FreeCAD/pull_requests FreeCAD pull requests].
<pre>
Some checks haven’t completed yet

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

If the tests succeed, you will see a message such as the following
<pre>
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.
</pre>

Now you must wait for the administrators to merge your branch; you will be notified when this happens.
{{Code|code=
Pull request successfully merged and closed

You’re all set — the GITHUB_USERNAME:myNewBranch branch can be safely deleted.
If you wish, you can also delete your fork of FreeCAD/FreeCAD.
}}

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.
{{Code|code=
-----o-----------Z----A' FreeCAD upstream/master
}}

{{Emphasis|Note:}} you may continue working ({{incode|git commit -a}}) on the same branch while you wait for merge approval; if you {{incode|git push}} 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 {{incode|origin}} repository, and this will queue those commits in the same pull request to the {{incode|upstream}} 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 latter case, since you own the branches, the merges can be approved by yourself immediately.
{{Code|code=
base repository: SomeProject/Some_Software base: master <---- head repository: GITHUB_USERNAME/Some_Software compare: add_new_functions
base repository: GITHUB_USERNAME/FreeCAD base: myNewBranch <---- head repository: FreeCAD/FreeCAD compare: master
base repository: GITHUB_USERNAME/FreeCAD base: myNewBranch <---- head repository: GITHUB_USERNAME/FreeCAD compare: fix-many-bugs-branch
}}

=== Keeping the GitHub repository up to date ===

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:
{{Code|code=
This branch is 5 commits behind FreeCAD:master.
}}

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:
{{Code|code=
This branch is 3 commits ahead of FreeCAD:master.
}}

While developing, both cases are possible, as your own branch may lack commits made by other developers, but include new commits by you:
{{Code|code=
This branch is 2 commits ahead, 14 commits behind FreeCAD:master.
}}

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 {{incode|master}} branch, it will never be automatically updated by GitHub; this is something that you must do yourself. Switch to the {{incode|master}} branch, then {{incode|pull}} from {{incode|upstream}} (which performs a {{incode|fetch}} and {{incode|merge}}), and then push this updated {{incode|master}} branch to your remote {{incode|origin}} repository.
{{Code|code=
git checkout master
git pull upstream master
git push origin master
}}

After this is done, GitHub will let you know that your are synchronized with the {{incode|upstream}} repository.
{{Code|code=
This branch is even with FreeCAD:master.
}}

Now that your {{incode|master}} is up to date, you may decide to switch to it, and delete the other branch that you used previously to develop a feature.
{{Code|code=
git checkout master
git branch -d myNewBranch
}}

To delete the branch in the {{incode|origin}} remote repository, you can use the {{incode|push}} action. Normally, you push a local branch; this creates a remote branch with the same name as your local branch.
{{Code|code=
git push origin myNewBranch
}}

However, if you use the notation {{incode|local_name:remote_name}}, the local branch is created in the remote repository under a different name:
{{Code|code=
git push origin myNewBranch:someRemoteBranch
}}

Therefore, you can delete the remote branch by pushing an empty local branch:
{{Code|code=
git push origin :myNewBranch
git push origin :someRemoteBranch
}}

Now that you only have an up-to-date {{incode|master}}, you can create a new branch, and repeat the steps of changing files, committing, pushing, submitting a pull request, merging, and updating.
{{Code|code=
git checkout master
git checkout -b anotherBranch
}}

<!-- Attention editors, this is untested!

If you don't want to delete your already custom branch, you may force updating it to be equal to the updated {{incode|master}}, and then push it to the remote {{incode|origin}} repository.
{{Code|code=
git checkout myNewBranch
git reset --hard master
git push -f origin myNewBranch
}}
-->

== Advanced Git operations ==

=== Resolving merge conflicts ===

Merging local branches with {{incode|git merge}} will occasionally present conflicts, as the files may have been changed at the same time in the same place. If this happens you should fix the files, and re-merge.

* [https://git-scm.com/docs/git-merge#_how_conflicts_are_presented How merge conflicts are presented] with {{incode|git merge}}
* [https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts Basic merge conflicts] and [https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging Git Tools - Advanced Merging]
* [https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/ Resolving a merge conflict using the command line]
* [https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_external_merge_tools External merge and diff tools] to use when you encounter a Git conflict.

Inspect the changes of a single file through various commits:
{{Code|code=
git log -p -- myFile.cpp
}}

=== Creating patches from Git ===

Although Git allows you to merge different branches of code with {{incode|git merge}} (in your computer) or a pull request (remote repository), there are times when it may be desirable to create a traditional "patch", which can be sent as an attachment through email. The following workflow explains how to do this.

* 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.
{{Code|code=
git branch -v
git checkout myBranch
}}

* Now use {{incode|git format-patch}} against the master branch, and use the {{incode|--stdout}} 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.
{{Code|code=
git format-patch master --stdout > ../myCode.patch
}}

* Another method is
{{Code|code=
git format-patch HEAD^
git format-patch HEAD~1
}}
The number of circumflex carets {{incode|^}} or the number {{incode|1}} indicate the number of commits that should be considered, that is, {{incode|^^^}} or {{incode|~3}} will create three patches for three commits.
{{Code|code=
git format-patch HEAD^
}}

This will create a patch or series of patches with the following naming convention
{{Code|code=
XXXX-commit-message.patch
}}
where {{incode|XXXX}} is a number from {{incode|0000}} to {{incode|9999}}, and the commit message forms the majority of the file name, for example,
{{Code|code=
0001-fix-ViewProjMatrix-getProjectionMatrix.patch
}}


=== Applying patches via git ===
=== Applying patches via git ===
Git has the capability to merge patches/diffs. To read more about this read the following reference: https://www.drupal.org/node/1399218
git apply [patch-name].patch


Git can merge patches or diffs. To know more about this process read [https://www.drupal.org/node/1399218 Applying patches with Git].
==== Apply a patch via curl ====
A very handy and powerful feature of git and the command line is the ability to quickly test patches all through the terminal.
curl -O https://github.com/FreeCAD/FreeCAD/commit/[patch-name].patch
git apply [patch-name].patch
or alternatively, using bash pipes you can make a sweet 1-liner:
curl https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch | git apply -


If you already have the patch file in your system, just apply it.
* Useful tip: Just add .diff or .patch at the end of the URL for a GitHub commit page, Pull Request, or Compare View and it'll show you theplaintext view of that page. Example:
{{Code|code=
::Regular GitHub page: <small>https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621</small>
git apply myCode.patch
::'Diffed' GitHub page: <small>https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.diff</small>
}}
::'Patched' GitHub page: <small>https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch</small>


You can use {{incode|curl}} to download a patch from a website, and then apply it through {{incode|git}}.
=== Creating patches from git ===
{{Code|code=
There are times when one may need to create a patch instead of submitting a PR. The following workflow explains how to do this:
curl -O https://some.website.org/code/myCode.patch
<ol>
git apply myCode.patch
<li>Make sure you are in the correct branch (i.e. not the master branch) by checking with
}}
<pre>git branch -v</pre></li>
Add {{incode|.diff}} or {{incode|.patch}} at the end of the URL of a GitHub commit, pull request, or compare view so that the website shows you the plain text view of that page.
<li>Create the patch: we do this by using the '''git format-patch''' command which we patch against the master branch and redirect to STDOUT. We create the patch in the directory outside of the source build (in order not to pollute the source dir itself, this is optional as you can decide the location wherever you want the patch to be created)
* Regular commit page: {{URL|https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621}}
<pre>git format-patch master --stdout > ../patch.name.patch</pre></li>
* Diff page: {{URL|https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.diff}}
<li>Another method is to use '''git format-patch HEAD^''' or '''git format-patch HEAD~1''' The ^ or 1 can be changed to number of commits that should be covered i.e.: ^^^ or ~3.
* Patch page: {{URL|https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch}}
<pre>git format-patch HEAD^</pre></li> It will create a patch or series of patches with file name format XXXX-commit-message.patch. An example: 0001-fix-ViewProjMatrix-getProjectionMatrix.patch


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


=== Reversing a patch in git ===
=== Reversing a patch in git ===
If you've followed the instructions above and then have a change of heart about using the patch, you can quickly reverse it using:
git apply -R path/file.patch
or another way is to use:
git checkout -f
which will remove non-committed changes to the branch


When you apply a patch you modify some files. However, these modifications aren't permanent until you commit the changes. Therefore, if you want to revert a patch use the following instructions.
== Stashing git commits ==
Say you're working on a branch and you find yourself making some modification to the source that is out of the scope of your current branch in other words it would be better to add certain commits to a whole other branch and submit it instead of the current one. This is where the '''git stash''' command can be very useful. The '''git stash''' command can help you to (temporarily but safely) store your uncommitted local changes.
git stash
Then in the future when you want to use these commits you can
git stash apply
or
git stash pop
'''pop''' will delete the stash
If you have multiple stashes you can
git stash list
To read more about what other functions you can use checkout https://medium.freecodecamp.org/useful-tricks-you-might-not-know-about-git-stash-e8a9490f0a1a


This will revert the changes applied, if you still have access to the original patch file.
== What is the latest FreeCAD Dev Revision ==
{{Code|code=
There are 2 ways to do this:
git apply -R myCode.patch
* 1st method: In your cloned git directory type:
}}
git rev-list --count master
Alternatively, this will remove non-committed changes to the branch.
* 2nd method: Browse https://github.com/FreeCAD/FreeCAD and read the amount of commits FreeCAD is at.
{{Code|code=
git checkout -f
}}


=== Stashing git commits ===


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 {{incode|git stash}} command can be used to temporarily store those uncommitted local changes.
== What is the Revision number of a specific commit hash and visa ver? ==
{{Code|code=
git rev-list --count 9948ee4
git stash
13541
}}


If in the future you want to use those commits, you can apply the stash.
* some forum topics in this regard:
{{Code|code=
** https://forum.freecadweb.org/viewtopic.php?f=10&t=26673
git stash apply
** 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


Or if you decide that you don't like the commits anymore, you may delete the stash.
== How is the Revision number in FreeCAD help about generated? ==
{{Code|code=
* https://forum.freecadweb.org/viewtopic.php?f=4&t=3025
git stash pop
}}

You can list multiple stashes with
{{Code|code=
git stash list
}}

To learn more, read [https://medium.freecodecamp.org/useful-tricks-you-might-not-know-about-git-stash-e8a9490f0a1a Useful tricks you might not know about Git stash].

=== Check out GitHub requests locally ===

[https://gist.github.com/piscisaureus/3342247 Checkout GitHub pull requests locally]

== FreeCAD revision number ==

In contrast to subversion, which uses a consecutive number for its revisions, Git produces [https://en.wikipedia.org/wiki/SHA-1 SHA-1 hash values] with every commit. A hash value is a long alphanumeric string that looks like this
{{Code|code=
9b3ffef570596e184006287434fba54a4b03ccc3
}}

=== Latest revision number ===

To find the latest revision number of a particular branch use the {{incode|rev-list}} operation with the {{incode|--count}} option. Give the name of the branch, remote repository, tag, or a special pointer like {{incode|HEAD}}, to indicate the last commit in that particular object.
{{Code|code=
git rev-list --count master
git rev-list --count HEAD
git rev-list --count origin
}}

Or browse [https://github.com/FreeCAD/FreeCAD the repository on GitHub], and read the amount of commits reported in the particular branch.

=== Revision number of a specific commit hash ===

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 {{incode|rev-list}} operation; the input can be the full hash, or a partial hash that is unique, usually the first 7 digits are enough.
{{Code|code=
git rev-list --count ab1520b872821414c6ce4a15fb85d471ac2a2b03
git rev-list --count 9948ee4
}}

=== 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 ({{incode|HEAD}}). First, get the latest commit number.
{{Code|code=
git rev-list --count HEAD
17465
}}

Then subtract the commit that we want.
{{Code|code=
17465 - 15000 = 2465
}}

Then use the {{incode|log}} operation to show all commits and hashes. The {{incode|--skip}} option jumps the difference in commits that we calculated so that we go directly to the hash that we are looking for.
{{Code|code=
git log --skip=2465
commit 44c2f19e380e76b567d114a6360519d66f7a9e24
}}

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.
{{Code|code=
git rev-list --count 44c2f19e38
15000
}}

* [https://forum.freecadweb.org/viewtopic.php?f=10&t=26673 Show the commits] starting from a particular commit in GitHub: in the address bar of the browser, change the word {{incode|commit}} to {{incode|commits}} to show a list.
* [https://forum.freecadweb.org/viewtopic.php?t=5308 Finding the revision number of the commit]
* [https://forum.freecadweb.org/viewtopic.php?f=18&t=12883&p=103207#p103203 Finding the revision number of the commit]
* [https://forum.freecadweb.org/viewtopic.php?f=10&t=31118 Finding the corresponding hash value to a particular commit number]

=== Revision number in FreeCAD's interface ===

The version number that appears in {{MenuCommand|Help → About FreeCAD → Copy to clipboard}} is defined in {{incode|src/Build/Version.h}}, which is created at compile time when the {{incode|cmake}} tool is run. Read [https://forum.freecadweb.org/viewtopic.php?f=4&t=3025 Extract version number from git source] for more information.

See the [[CompileOnUnix|compile on Unix]] page for the full information on compiling FreeCAD.


== Alternative repositories ==
== 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.


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.
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.


Use the {{incode|git remote}} command to add these other repositories so that you can {{incode|pull}} their changes.
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.
{{Code|code=
git remote add Johns_repo https://github.com/John/FreeCAD.git
git remote add FreeCADhacker_repo https://github.com/FreeCADhacker123/FreeCAD.git
}}


Head to the development section of the [https://forum.freecadweb.org/viewforum.php?f=6 FreeCAD forum] to discuss more about development of new features. See also [[Compiling|Compiling]] for instructions on compiling FreeCAD.
== Using git in a Graphical User Interface ==
* [[Developing FreeCAD with GitKraken|Developing FreeCAD with GitKraken]]


== Otras lecturas ==
== Otras lecturas ==
Line 240: Line 572:
[[Category:Hubs/es]]
[[Category:Hubs/es]]
[[Category:Developer Documentation/es]]
[[Category:Developer Documentation/es]]



{{clear}}
{{clear}}

Revision as of 08:16, 9 August 2019

The main source code management tool for the FreeCAD project is Git, which can be easily installed in most operating systems from a package manager or directly from Git's website. You are advised to become familiar with Git before working with the FreeCAD source code directly. Visit the Git documentation page for the reference manual, as well as the Pro Git book to learn to use the system in a general way. The present document focuses on the use of Git for FreeCAD development. Compiling FreeCAD is described in Compiling.

While Git is primarily a terminal application, there are many graphical clients for it which facilitate working with branches, applying patches, and submitting pull requests to a master branch. Examples include gitk (the first graphical interface developed), gitg (Gnome), qgit (Qt), tig (Ncurses), git-cola, and GitKraken (proprietary). Please see Developing FreeCAD with GitKraken for a cursory introduction to this tool.

Source code 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 want your changes to be included in the official source code, you need to perform a "pull request" against the master repository so that your modifications can be reviewed by the managers. This style of development is known as the Dictator and lieutenants workflow, as the core developers (dictators) and trusted developers (lieutenants) filter the code that is submitted by independent developers and users.

If your source code changes are significant, you are advised to explain them in the pull request section of the FreeCAD forum.

Generic workflow to develop code for FreeCAD; everybody can get the code from the main repository, but the main developers have the exclusive right to review and merge submissions by other developers.

Official GitHub repository

The FreeCAD source code is hosted in Github, https://github.com/FreeCAD/FreeCAD

In order to contribute code, you need to have a GitHub account.

Configurando tu nombre de usuario en Git

Los usuarios deberían enviar a sus repositorios de proyecto utilizando sus nombres de usuario de SourceForge.net. Si no está definido globalmente, lo puedes definir localmente para el repositorio de Gir actual así:

git config user.name "YOUR_NAME"
git config user.email GITHUB_USERNAME@users.noreply.github.com

Where "YOUR_NAME" represents your full name or nickname, used to identify the author of a particular commit, and GITHUB_USERNAME indicates the name of your account on GitHub.

Remote repositories

Please read What is the difference between origin and upstream on GitHub? (Stackoverflow) to help you understand the difference between origin and upstream in the context of Git. This section explains how to set the correct repositories for development. Essentially:

  • origin is your personal fork of the official FreeCAD repository, that is, https://github.com/GITHUB_USERNAME/FreeCAD
  • upstream is the official FreeCAD repository, that is, https://github.com/FreeCAD/FreeCAD

This distinction is important, as you should write code in your own copy of the repository first, before pushing those changes to the official repository.

Based on the above, there are two ways to setup your Git development environment:

  • 1st Method: fork on GitHub and clone your fork locally
  • 2nd Method: clone FreeCAD directly to your local machine, and adjust the remote servers

We recommend the 1st method because it's one step faster.

1st Method: Fork on GitHub and clone your fork locally

First you will fork the FreeCAD repository in GitHub, then clone this personal fork to your computer, and finally set the upstream repository.

  • Log in to your GitHub account.
  • Go to the official FreeCAD repository: https://github.com/FreeCAD/FreeCAD
  • In the top right of the page press the "Fork" button. This will create a personal copy of the FreeCAD repository under your GitHub username: https://github.com/GITHUB_USERNAME/FreeCAD
  • On your machine, clone your newly created FreeCAD fork. It will be created inside a directory freecad-source.
git clone https://github.com/GITHUB_USERNAME/FreeCAD.git freecad-source
  • Once the download is complete, enter the new source directory and set the upstream repository.
cd  freecad-source
git remote add upstream https://github.com/FreeCAD/FreeCAD.git
  • Confirm your remote repositories with git remote -v; the output should be similar to this
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)
  • Now development can begin.

2nd Method: Clone FreeCAD directly to your local machine

First you will fork the FreeCAD repository in GitHub, however, you will clone the original FreeCAD repository to your local machine, and then alter your remotes via the terminal.

  • Log in to your GitHub account.
  • Go to the official FreeCAD repository: https://github.com/FreeCAD/FreeCAD
  • In the top right of the page press the "Fork" button. This will create a personal copy of the FreeCAD repository under your GitHub username: https://github.com/GITHUB_USERNAME/FreeCAD
  • Clone the original FreeCAD repository. It will be created inside a directory freecad-source.
git clone https://github.com/FreeCAD/FreeCAD.git freecad-source
  • Once the download is complete, enter the new source directory and set the origin repository.
cd freecad-source
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git
  • Then set up the upstream repository.
git remote add upstream https://github.com/FreeCAD/FreeCAD.git
  • Confirm your remote repositories with git remote -v; the output should be similar to this
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)
  • 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, origin should point to your personal fork; if it is pointing to the original FreeCAD repository, change the name of this remote to upstream, and manually add the origin repository.

git remote rename origin upstream
git remote add origin https://github.com/GITHUB_USERNAME/FreeCAD.git
git remote -v

You can also show more information with the show keyword.

git remote show origin
git remote show upstream

En desarrollo

Antes de nada nunca desarrolles en el ramal principal! Crea un ramal local para el desarrollo. Puedes aprender a hacer esto aquí.

Generic workflow to develop code for FreeCAD using git; the main repository is forked online and cloned to an offline computer (0); new branches (1) are used to commit local changes and additions to the code (2); the branches are rebased to the latest online code (3), and then are pushed to the remote repository (4); then a pull request is created in order to merge the code into the main repository (5). Then the personal clone is updated with the new master code (a); this updated master is also pushed to the remote repository (b) in order to have the same code both online and offline.

Ramificado

Una importante característica de Git es que es extremadamente sencillo trabajar con ramas y fusionarlas. La mejor forma de trabajar recomienda crear una nueva rama siempre que quieras trabajar en una nueva característica. La creación de una rama se hace con:

Instead of working on the master version of the code, best practices with Git recommend creating a new branch whenever you want to work on a new feature. Branches are inexpensive, they don't copy the entire source tree, but merely create a point in time on top of which you will write code; thus branches help keep work in progress separate from the main code.

Using a new branch is done in two steps, first your create the branch, and then you switch to it:

git branch myNewBranch
git checkout myNewBranch

o, ambas operaciones en una:

git checkout -b myNewBranch

siempre puedes comprobar con que rama estas:

git branch
git branch -vv

After you've made changes and committed those changes use the log operation with the following options to visualize the branches

git log --oneline --decorate --graph --all

Envío

Una vez que hagas algo de trabajo, envíalo con:

Once you are inside a new branch, edit the source files that you want with a text editor. To see which files were modified use the status and diff operations; when you are satisfied with the modifications, save the changes with the commit operation:

git status
git diff
git commit -a

A diferencia de SVN, tienes que especificar los archivos que quieres enviar (o todos con la opción -a). Tu editor de texto se abrirá para permitirte escribir un mensaje de envío.

Alternatively add the message in the commit itself

git commit -a -m "Fix the bug in the clone function."

Escribiendo buenos mensajes de envío

Deberías tratar de trabajar en pedazos pequeños. Si no puedes resumir tus cambios en una frase, entonces posiblemente ha pasado pasado demasiado tiempo desde que hiciste un envío. También es importante que ofrezcas descripciones de tu trabajo que sean útiles y ayuden. Para los mensajes de envío, FreeCAD ha adoptado un formato mencionado en el libro Pro Git (mira #Otras lecturas).

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.

Resumen corto (50 caracteres o menos) de cambios
Texto de explicación más detallado, si es necesario. En unos 72 caracteres.
En algunos contextos, la primera línea es tratada como el tema
de un email y el resto del texto como el cuerpo. La línea en blanco
separando el tema del cuerpo es crítica (a menos que omitas el cuerpo por
completo); las herramientas de recálculo se pueden confundir si pones los
dos juntos.

Más párrafos van después de líneas en blanco. 

 - Las listas con viñetas también están bien

 - Tipicamente un guión o asterisco se utiliza para la viñeta, precedido 
   por un espacio en blanco, con líneas en blanco en medio, pero las 
   convenciones aquí varían

Si estas haciendo un montón de trabajo relacionado, se sugiere aquí que deberías hacer tantos envíos grandes o pequeños como sea necesario para que tengan sentido en lo que estés trabajando utilizado los mensajes cortos de envío. Cuando quieras fusionarlos, haz un registro master..BRANCH y utiliza el resultado para tu mensaje de envío. Cuando fusionas con el principal utiliza la opción --squash y envía con tu mensaje de envío. Esto te permitirá ser muy liberal con tus envíos y ayudar a proporcionar un buen nivel de detalle en los mensajes de envío sin demasiadas descripciones distintas.

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.

Publicación de tu trabajo en el repositorio de sourceforge

Después de hacer algunos cambios en tu ramal local y enviarlos (es decir, enviarlos "localmente") puedes enviar tu repositorio al servidor. Esto abre tu ramal al público y permite que los desarrolladores principales revisen e integren tu ramal en el principal.

The local branches in your computer aren't automatically synchronized with the remote servers that you have specified as origin or upstream (see Remote repositories); you have to explicitly push the branches to the remote servers, for which you must have write access. Once you do this, the branches become public, and available for review by other developers.

For FreeCAD, you should push your local branch to the origin remote repository, that is, https://github.com/GITHUB_USERNAME/FreeCAD. You need to enter your username and password every time you push, unless you have set up Credential caching. Please read Pushing commits to a remote repository for more information.

git push origin myNewBranch

The regular developer doesn't have write access to the upstream 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.

git checkout myNewBranch
git pull --rebase upstream master

This will download the code from the master branch of the upstream repository (the official FreeCAD source), and will merge it with your current branch (myNewBranch), 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.

git checkout myNewBranch
git pull --rebase upstream master
git push origin myNewBranch

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

git pull upstream

git fetch upstream
git merge FETCH_HEAD
git pull --rebase upstream master

git fetch upstream
git rebase master

Merging the branch (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 origin repository https://github.com/GITHUB_USERNAME/FreeCAD, GitHub will give you the option of comparing and creating a pull request against the upstream repository. By pressing Compare & pull request 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.

base repository: FreeCAD/FreeCAD    base: master  <----  head repository: GITHUB_USERNAME/FreeCAD    compare: myNewBranch

Able to merge. These branches can be automatically merged.

Click Create pull request 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.

Pull request successfully merged and closed

Youre all set  the GITHUB_USERNAME:myNewBranch branch can be safely deleted.
If you wish, you can also delete your fork of FreeCAD/FreeCAD.

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.

-----o-----------Z----A' FreeCAD upstream/master

Note: you may continue working (git commit -a) on the same branch while you wait for merge approval; if you git push 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 origin repository, and this will queue those commits in the same pull request to the upstream 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 latter case, since you own the branches, the merges can be approved by yourself immediately.

base repository: SomeProject/Some_Software  base: master       <----  head repository: GITHUB_USERNAME/Some_Software  compare: add_new_functions
base repository: GITHUB_USERNAME/FreeCAD    base: myNewBranch  <----  head repository: FreeCAD/FreeCAD                compare: master
base repository: GITHUB_USERNAME/FreeCAD    base: myNewBranch  <----  head repository: GITHUB_USERNAME/FreeCAD        compare: fix-many-bugs-branch

Keeping the GitHub repository up to date

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:

This branch is 5 commits behind FreeCAD:master.

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:

This branch is 3 commits ahead of FreeCAD:master.

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

This branch is 2 commits ahead, 14 commits behind FreeCAD:master.

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 master branch, it will never be automatically updated by GitHub; this is something that you must do yourself. Switch to the master branch, then pull from upstream (which performs a fetch and merge), and then push this updated master branch to your remote origin repository.

git checkout master
git pull upstream master
git push origin master

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

This branch is even with FreeCAD:master.

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

git checkout master
git branch -d myNewBranch

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

git push origin myNewBranch

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

git push origin myNewBranch:someRemoteBranch

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

git push origin :myNewBranch
git push origin :someRemoteBranch

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

git checkout master
git checkout -b anotherBranch


Advanced Git operations

Resolving merge conflicts

Merging local branches with git merge will occasionally present conflicts, as the files may have been changed at the same time in the same place. If this happens you should fix the files, and re-merge.

Inspect the changes of a single file through various commits:

git log -p -- myFile.cpp

Creating patches from Git

Although Git allows you to merge different branches of code with git merge (in your computer) or a pull request (remote repository), there are times when it may be desirable to create a traditional "patch", which can be sent as an attachment through email. The following workflow explains how to do this.

  • 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.
git branch -v
git checkout myBranch
  • Now use git format-patch against the master branch, and use the --stdout 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.
git format-patch master --stdout > ../myCode.patch
  • Another method is
git format-patch HEAD^
git format-patch HEAD~1

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

git format-patch HEAD^

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

XXXX-commit-message.patch

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

0001-fix-ViewProjMatrix-getProjectionMatrix.patch

Applying patches via git

Git can merge patches or diffs. To know more about this process read Applying patches with Git.

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

git apply myCode.patch

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

curl -O https://some.website.org/code/myCode.patch
git apply myCode.patch

Add .diff or .patch at the end of the URL of a GitHub commit, pull request, or compare view so that the website shows you the plain text view of that page.

You can point curl to a particular commit patch in the repository, and pipe it directly to git to apply the patch.

curl https://github.com/FreeCAD/FreeCAD/commit/c476589652a0f67b544735740e20ff702e8d0621.patch | git apply -

Reversing a patch in git

When you apply a patch you modify some files. However, these modifications aren't permanent until you commit the changes. Therefore, if you want to revert a patch use the following instructions.

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

git apply -R myCode.patch

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

git checkout -f

Stashing git commits

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 git stash command can be used to temporarily store those uncommitted local changes.

git stash

If in the future you want to use those commits, you can apply the stash.

git stash apply

Or if you decide that you don't like the commits anymore, you may delete the stash.

git stash pop

You can list multiple stashes with

git stash list

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

Check out GitHub requests locally

Checkout GitHub pull requests locally

FreeCAD revision number

In contrast to subversion, which uses a consecutive number for its revisions, Git produces SHA-1 hash values with every commit. A hash value is a long alphanumeric string that looks like this

9b3ffef570596e184006287434fba54a4b03ccc3

Latest revision number

To find the latest revision number of a particular branch use the rev-list operation with the --count option. Give the name of the branch, remote repository, tag, or a special pointer like HEAD, to indicate the last commit in that particular object.

git rev-list --count master
git rev-list --count HEAD
git rev-list --count origin

Or browse the repository on GitHub, and read the amount of commits reported in the particular branch.

Revision number of a specific commit hash

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 rev-list operation; the input can be the full hash, or a partial hash that is unique, usually the first 7 digits are enough.

git rev-list --count ab1520b872821414c6ce4a15fb85d471ac2a2b03
git rev-list --count 9948ee4

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 (HEAD). First, get the latest commit number.

git rev-list --count HEAD
17465

Then subtract the commit that we want.

17465 - 15000 = 2465

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

git log --skip=2465
commit 44c2f19e380e76b567d114a6360519d66f7a9e24

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.

git rev-list --count 44c2f19e38
15000

Revision number in FreeCAD's interface

The version number that appears in Help → About FreeCAD → Copy to clipboard is defined in src/Build/Version.h, which is created at compile time when the cmake tool is run. Read Extract version number from git source for more information.

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

Alternative repositories

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.

Use the git remote command to add these other repositories so that you can pull their changes.

git remote add Johns_repo https://github.com/John/FreeCAD.git
git remote add FreeCADhacker_repo https://github.com/FreeCADhacker123/FreeCAD.git

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.

Otras lecturas