Git para Administradores

Nota: Esta es una traducción de una página de la documentación en idioma Inglés (Docs), que se considera particularmente importante, y que en su versión original se actualiza frecuentemente. Por ello, se le recomienda que revise la página original en idioma inglés: Git for Administrators.

Nota: Pendiente de Traducir. ¡Anímese a traducir esta página!.     ( y otras páginas pendientes)

Esta página describe como mantener una copia de Moodle en su servidor de producción, que pueda ser actualizada fácilmente usando Git. Si Usted tiene personalizaciones del código del núcleo (core) de Moodle, se le recomienda que siga las instrucciones en Quick Git start guide for Moodle development].

Para obtener el mayor provecho de Git, vale la pena el esfuerzo para entender sus conceptos básicos - vea también la sección inferior. La curva de aprendizaje puede ser difícil, especialmente si Usted está acostumbrado a usar CVS o Subversion.

Obtención de Git (Windows, OSX, Linux y otros)

El soporte para Git estaba, hasta hace muy poco tiempo, principalmente confinado a Linux, pero actualmente hay archivos para los sistemas operativos más populares:

• Lista de descargas del sitio Git - http://git-scm.com/download

Una vez que haya descargado e instalado el Git relevante para su sistema operativo, las instrucciones (comandos) git de éste documento deberían de trabajar con su sistema operativo.

Nombres de las ramas de Moodle

Las principales versiones de Moodle tienen cada una su propia rama en Git. Por ejemplo, MOODLE_38_STABLE (3.8), MOODLE_404_STABLE (4.4). El desarrollo generalmente se hace en la rama 'master'. Toda la vida de esa versión se conservará en esa rama. Cada versión de Moodle liberada es designada al añadir una etiqueta (tag), como por ejemplo v3.9.0-beta, v3.9.0-rc1, v3.9.0.

Desde la versión 4.0, los códigos de versión utilizan 3 dígitos: 400, 401, 402, ...

Importante: Aun y cuando el nombre de la rama incluya la palabra STABLE ('ESTABLE') en su nombre, esto no significa que el código en esa rama sea realmente estable. Poco tiempo después de que se haya creado la rama, contendrá versiones 'beta' y RC, o 'release candidate' (candidato-a-liberación), de la nueva versión de Moodle. Es importante revisar que el estado actual de la rama cumpla con las necesidades de usted. Generalmente, la forma más fácil es examinar los contenidos actuales del fichero version.php - substituya la rama en esta URL, https://github.com/moodle/moodle/blob/MOODLE_404_STABLE/version.php

NO USE versiones alfa, beta ni candidatos-a-liberación (alpha, beta, release-candidates o RC) ni tampoco código de la rama maestra (master) para sitios en producción, ya que podrían tener problemas significativos.

Obtención del código de Git

Aquí se discute la versión de Git para línea de comando. Los clientes gráficos son poco menos que envoltorios alrededor de la versión para línea de comando, por lo que Usted debería de poder deducir los parámetros correctos muy fácilmente.

Para inicializar su repositorio local, use los siguientes comandos en el terminal de su servidor:

$ cd /ruta/hacia/su/webroot
$ git clone https://github.com/moodle/moodle.git                  (1)
$ cd moodle
$ git branch -a                                                   (2)
$ git branch --track MOODLE_404_STABLE origin/MOODLE_404_STABLE   (3)
$ git checkout MOODLE_404_STABLE                                  (4)

El detalle del proceso es el siguiente:

• El comando (1) inicializa el nuevo repositorio local como una copia del repositorio remoto moodle.git desde GitHub. Se recomienda utilizar este repositorio de GitHub ya que es el repositorio público de Moodle, y una copia espejo del utilizado en desarrollo. El repositorio remoto se llama por defecto origin. Este comando creará un nuevo directorio local llamado moodle, en donde se descargan todos los archivos. Esta operación puede tomar un tiempo, porque de hecho está obteniendo toda la historia completa de todas las versiones de Moodle.

• El comando (2) lista todas las ramas disponibles. Ahí se puede comprobar si la rama que queremos instalar en el repositorio local existe en el remoto de Moodle
• El comando (3) selecciona la rama local, en este caso MOODLE_404_STABLE, y la configura para que sincronice con la rama MOODLE_404_STABLE del repositorio remoto.
• El comando (4) cambia hacia la rama local recientemente creada. Al finalizar, se puede comprobar la version utilizada en nuestro repositorio local abriendo el archivo version.php

Clonar utilizando GitHub CLI

También se puede utilizar GitHub CLI para clonar el repositorio remoto. Para ello, utilice el siguiente comando en lugar de git clone:

$ gh repo clone moodle/moodle

Actualización de su instalación

El equipo de desarrolladores de Moodle realiza la integración y prueba de problemas resueltos todos los días Lunes y Martes. En miércoles, Usted puede instalar todos los parches al actualizar su código. Revise la bitácora shortlog para ver si el repositorio oficial ya ha sido actualizado o no.

Para actualizar su código a la versión más reciente (en la rama MOODLE_404_STABLE) todo lo que tiene que hacer es:

$ cd /ruta/hacia/su/moodle/
$ git pull

Nota: la ruta hacia moodle usualmente es /var/www/html o /var/www/html/moodle en servidores Linux

Si éste es un sitio de producción Usted debería de considerar las instrucciones acerca de la Actualización_de_moodle, como por ejemplo, hacer respaldos.

Instalar un plugin opcional desde el repositorio Git

Nota: Pendiente de Traducir. ¡Anímese a traducir esta página!.     ( y otras páginas pendientes)

This is one way to handle adding plugins from other Git repositories into your Moodle repository. Another way is to use Git Submodules. However, at the time of writing, this is one of Git's rougher features and should be regarded as an advanced option.

For example, let us say we want to install the Módulo certificado from its Git repository into our Moodle 3.6.

$ cd /path/to/your/moodle/
$ cd mod                                                          (1)
$ git clone https://github.com/markn86/moodle-mod_certificate.git certificate     (2)
$ cd certificate
$ git checkout -b MOODLE_404_STABLE origin/MOODLE_404_STABLE        (3)
$ git branch -d master                                            (4)

The command (1) changes the current directory into the mod folder of your local Moodle clone. The command (2) creates a new subdirectory certificate and makes a local clone of vanilla Certificate repository. The command (3) creates a new local branch that will track the remote branch with a Certificate version for Moodle 3.6. The command (4) deletes the master that was created automatically by git-clone in (2) as we do not want it in this production checkout.

Note: you should check first the compatibility of a module with your Moodle branch by asking directly to the Maintainer before cloning the repo or - if you want to guess it - by issuing the command below before running the command (3), in order to verify what is available among the branches:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/MOODLE_20_STABLE
  remotes/origin/MOODLE_21_STABLE
  remotes/origin/MOODLE_22_STABLE
  remotes/origin/MOODLE_23_STABLE
  remotes/origin/MOODLE_24_STABLE
  remotes/origin/MOODLE_25_STABLE
  remotes/origin/MOODLE_26_STABLE
  remotes/origin/MOODLE_27_STABLE
  remotes/origin/MOODLE_28_STABLE
  remotes/origin/MOODLE_29_STABLE
  remotes/origin/MOODLE_30_STABLE
 remotes/origin/MOODLE_31_STABLE
  remotes/origin/master

This will avoid an error message when you issue the command (3) against a nonexistent branch, e.g.:

§ git checkout -b MOODLE_31_STABLE origin/MOODLE_31_STABLE
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/MOODLE_31_STABLE' which can not be resolved as commit?

Note: To fix above error, use: "git fetch origin MOODLE_31_STABLE:LOCAL_MOODLE_31_STABLE"

Now it is wise to add the new directory mod/certificate/ to the list of ignored files of the main Moodle clone, otherwise a status of the main clone will keep reminding you that the new code has not been checked in.

$ cd /path/to/your/moodle/
$ echo /mod/certificate/ >> .git/info/exclude

To update your Moodle installation now, you must visit both Git repositories and pull changes from upstream.

$ cd /path/to/your/moodle/
$ git pull
$ cd mod/certificate
$ git pull

Writing a shell script with these lines in the root of Moodle installation is a very good idea. Otherwise it is easy to forget what Git repositories are there within the main Moodle repository.

Installing and maintaining contributed extensions using Git submodules

As it was said in the previous section, this is for advanced users only. Therefore it is necessary, that you have some experience with Git and its commands. A step-by-step explanation will be provided, but in order to follow these steps it is helpful to understand, what these commands do.

Advanced options and commands can be found at [Git book]. If you have any questions about Git submodules, please visit the site above first.

Installing a new extension into an existing Moodle

As an example we use the Módulo certificado from the previous section.

$ cd /path/to/your/moodle
$ git submodule add https://github.com/markn86/moodle-mod_certificate.git mod/certificate

Note, that Git is reporting two new files in the repository:

$ git status
# On branch MOODLE_29_STABLE
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	new file:   .gitmodules
#	new file:   mod/certificate
#

The file .gitmodules contains the local path and url of all your submodules. It has to be committed, if you intend to clone the repository later (see the page development environment with Git submodules). Before commiting, make sure to check the configuration of the plugin's Git repository, since the automatically generated settings may be not sufficient. For future updates it is helpful, to track the remote branch, which corresponds to the Moodle version of your repository.

$ cd mod/certificate
$ git branch -avv
* master                          345f5b1 [origin/master] Replaced deprecated function
  remotes/origin/HEAD             -> origin/master
  remotes/origin/MOODLE_20_STABLE 1aa1040 Added option to print 'grade category' grade
  remotes/origin/MOODLE_21_STABLE 1aa1040 Added option to print 'grade category' grade
  remotes/origin/MOODLE_22_STABLE 1aa1040 Added option to print 'grade category' grade
  remotes/origin/MOODLE_23_STABLE fe047de Check that the function exists rather than relying on the Moodle version
  remotes/origin/MOODLE_24_STABLE 1051f7d CONTRIB-4892 Fixed the email to others functionality
  remotes/origin/MOODLE_25_STABLE cdb221a CONTRIB-4946: Removed character from language file breaking AMOS
  remotes/origin/MOODLE_26_STABLE 696802a Increased version
  remotes/origin/MOODLE_27_STABLE d3c0379 Increased version
  remotes/origin/MOODLE_28_STABLE fa8df83 Increased version
  remotes/origin/MOODLE_29_STABLE 3f03740 Replaced deprecated function
  remotes/origin/master           345f5b1 Replaced deprecated function

Git created the branch master which tracks origin/master automatically, because the remote repository has checked out master. Therefore, create a new branch, which tracks the appropriate remote branch. Of course, this is only possible, if the remote repository offers those branches.

$ git checkout -b MOODLE_29_STABLE origin/MOODLE_29_STABLE
Branch MOODLE_29_STABLE set up to track remote branch MOODLE_29_STABLE from origin.
Switched to a new branch 'MOODLE_29_STABLE'
$ git branch -D master
Deleted branch master (was 345f5b1).

It is not necessary to delete the master branch, but it's useless to keep it. In fact, these settings don't need to be touched afterwards.

The final step is to commit the changes to the main repository.

$ cd /path/to/your/moodle
$ git commit -a -m "New extension mod_certificate installed"

It has to be ensured, that the commit includes only the changes for the new Git submodule (since -a commits all non-staged changes).

Maintaining Git submodules

Maintaining a set of submodules is extremely easy. Consider a Moodle repository with several submodules installed. Keep in mind, that the extension mod_mylittleextension is a fake plugin, created for a test scenario in this example. It is not an official Moodle module. For updating all your submodules at once, type in:

$ cd /path/to/your/moodle
$ git submodule foreach git pull
Entering 'block/coursefeedback'
Already up-to-date.
Entering 'mod/certificate'
Already up-to-date.
Entering 'mod/mylittleextension'
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
From /local/repositories/mle
   89d9eae..64c122d  master     -> origin/master
Updating 89d9eae..64c122d
Fast-forward
 index.html  |    9 +++++++++
 version.php |    6 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)
 create mode 100644 index.html
$ git status
# On branch MOODLE_29_STABLE
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   mod/mylittleextension (new commits)
#

The command git submodule foreach [another command] walks through all submodule repositiories and executes what is specified by [another command]. In this case it is git pull. Therefore the module mylittleextension was updated and the main repository isn't clean anymore until changes are committed:

$ git commit -a -m "Plugin updates"

Maintaining plugins with Git submodules has also another application than simplifying the update process. In a greater scale it can be used to maintain a Moodle project, where multiple developers need to have an exact copy of your moodle without organizing external plugins manually. You can read more about this topic at the page Moodle development environment with Git submodules.

Vea también

Moodle Docs

• Windows installation using Git
• Git para Mac
• Moodle versions
• For fixing a Tracker Issue (MDL) / Forking Moodle / CONTRIButing code ... User:Sam_Hemelryk/My_Moodle_Git_workflow
• Case study Git + Moodle from Technical University Berlin

Documentación Moodle antigua

• Git FAQ
• For some screenshots see User:Frank_Ralf/Git (still work in progress)

Moodle forum discussions

• Github and Moodle deployment for production
• GIT help needed
• Clear git guide for Admins (not developers)

External resources

• Deploying Moodle from git - Blog post from a production experience
• Git Reference
• Pro Git book

[[1]] [[2]] [for Administrators]