Cómo subir un proyecto de desarrollo de una aplicación a GitHub y hacerla pública. Cómo reemplazar ficheros de local a remoto y viceversa.
- Cuenta de GitHub y creación de repositorio.
- Subir proyecto de desarrollo de local a repositorio público GitHub.
- Subir cambios posteriores de local a remoto.
- Reemplazar un archivo local con el contenido actual en el repositorio remoto.
Cuenta de GitHub y creación de repositorio
Necesitaremos disponer de una cuenta de GitHub, si aún no la tenemos, nos daremos de alta en GitHub. Iniciaremos sesión y crearemos un nuevo repositorio, pulsando en el botón «+» de la esquina superior derecha y seleccionando «New repository»:
Introduciremos los datos para el nuevo repositorio y pulsaremos en «Create repository». En este ejemplo, únicamente especificamos el nombre del repositorio (Repository name) y la descripción (Description), el resto de valores los dejamos por defecto, sobre todo Choose visibility que dejamos a Public.
Tras la creación, el propio GitHub nos ofrecerá la URL del repositorio, que podemos copiar para, posteriormente, usarla en los comandos de subida de local a público:
Subir proyecto de desarrollo de local a repositorio público GitHub
Cuando tengamos nuestro proyecto de desarrollo completado, para hacerlo público, necesitaremos disponer de Git instalado en el equipo, en el siguiente tutorial explicamos cómo instalarlo:
Desde la línea de comandos, sea Windows (cmd ó Símbolo de sistema) o Linux (shell), accederemos a la carpeta con los ficheros de código fuente del proyecto:
|
1 |
cd .GitPythonMonitorizacion_Proxmox_Python |
Iniciaremos el repositorio Git con el comando:
|
1 |
git init |
Nos mostrará el mensaje:
Initialized empty Git repository in D:/Git/Python/Monitorizacion_Proxmox_Python/.git/
Si queremos iniciarlo en la rama main por defecto, en lugar del comando anterior, ejecutaríamos:
|
1 |
git init -b main |
Y si ya lo teníamos iniciado con git init, si queremos establecer la rama principal a «main», podemos ejecutar este otro comando:
|
1 |
git branch -m main |
O, incluso, crear la rama main desde el primer commit (si ya hubíeramos hecho commits):
|
1 |
git checkout -b main |
Estableceremos, si aún no lo hemos hecho, el usuario y el correo electrónico que hayamos usado en GitHub, con los comandos:
|
1 2 |
git config --global user.name "usuario_github" git config --global user.email "email_github" |
Asociaremos el proyecto local con el remoto, usando la URL copiada anteriormente:
|
1 |
git remote add origin https://github.com/proyectoajpdsoft/Monitorizacion_Proxmox_Pandora_FMS_Python.git |
Comprobaremos que se ha asociado correctamente, con el comando:
|
1 |
git remote -v |
Que nos devolverá algo así:
origin https://github.com/proyectoajpdsoft/Monitorizacion_Proxmox_Pandora_FMS_Python.git (fetch)
origin https://github.com/proyectoajpdsoft/Monitorizacion_Proxmox_Pandora_FMS_Python.git (push)
Es conveniente crear un archivo README.md, describiendo el proyecto, sus características, herramientas empleadas para su desarrollo, su instalación, etc.:
|
1 |
notepad README.md |
También es recomendable crear el archivo .gitignore. En él podremos establecer qué ficheros, carpetas y extensiones no se subirán al repositorio público (ficheros con contraseñas o con contenido sensible o de pruebas/test que no queramos publicar).
|
1 |
notepad .gitignore |
Mostramos un ejemplo del contenido de este fichero para ignorar (no subir) archivos temporales y demás para Python, C#, PHP:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 |
# Python __pycache__/ *.py[cod] *$py.class *.so .Python env/ venv/ .venv/ ENV/ env.bak/ venv.bak/ .pytest_cache/ .coverage *.egg-info/ dist/ build/ .ipynb_checkpoints # C# ## Ignorar archivos de compilación bin/ obj/ *.exe *.dll *.pdb *.cache *.suo *.user *.aps *.ncb *.opensdf *.sdf _ReSharper*/ *.csproj.user # PHP ## Dependencias de Composer /vendor/ composer.lock ## Entornos .env .env.local .env.test .env.production ## Logs *.log npm-debug.log* yarn-debug.log* yarn-error.log* ## Sistema .DS_Store Thumbs.db # IDE y editores .vscode/ .idea/ *.swp *.swo *~ # Archivos temporales *.tmp *.temp # Archivos de configuración local *.local.* config/local.php |
Añadiremos los archivos del proyecto al staging area. El siguiente comando realizará este proceso, excluyendo los archivos/carpetas del fichero .gitignore:
|
1 |
git add . |
Si queremos añadir sólo algunos archivos específicos, usaríamos:
|
1 |
git add proxmox.py |
Para verificar los archivos añadidos al staging area, ejecutaremos el comando:
|
1 |
git status |
Realizaremos el primer commit, con el comando:
|
1 |
git commit -m "Commit inicial: Proyecto Python de monitorización de Proxmox con Pandora FMS" |
Y los subiremos a la rama main del repositorio remoto (con este comando se publicarán los ficheros del proyecto):
|
1 |
git push -u origin main |
Es posible que nos muestre una ventana GitHub para elegir el token o bien el usuario de GitHub:
Subir cambios posteriores de local a remoto
Cuando hayamos realizado cambios y queramos volver a publicarlos, ejecutaremos el siguiente comando, para añadir los archivos cambiados al staging area:
|
1 |
git add . |
O bien, añadir solo algunos archivos:
|
1 |
git add archivo1.py archivo2.php archivo3.cs |
Con el comando siguiente podremos comprobar los archivos modificados preparados para subir, antes de subirlos:
|
1 |
git status |
Crearemos un «paquete» con los cambios realizados (commit), con:
|
1 |
git commit -m "Modificado fichero proxmox.py para contemplar estado de las máquinas virtuales" |
Y realizaremos la publicación definitiva, con:
|
1 |
git push |
Si da error el comando anterior, podremos forzar el reemplazo de lo que haya en remoto por lo que haya en local, con:
|
1 |
git push --force-with-lease origin main |
Los ficheros reemplazados, en el repositorio público GitHub, aparecerán de esta forma:
Reemplazar un archivo local con el contenido actual en el repositorio remoto
Si queremos reemplazar un archivo local con el contenido que tenga actualmente en el repositorio remoto, seguiremos los siguientes pasos.
Desde la carpeta local del proyecto, supongamos que queremos reemplazar el archivo README.md del repositorio remoto, porque hemos hecho algunos cambios en remoto y queremos actualizarlos a local. Para ello, ejecutaremos el siguiente comando (siempre en la carpeta raíz del proyecto local):
|
1 |
git fetch origin |
El comando anterior descarga todos los cambios del remoto, pero NO los aplica. A continuación, aplicaremos sólo el archivo READMEN.md de remoto (reemplazará el que haya en local):
|
1 |
git checkout origin/main -- README.md |
En el caso de querer descargar y reemplazar todos los ficheros cambiados de remoto a local (reemplazará todos los ficheros locales que hayan cambiado con respecto a los remotos), ejecutaríamos:
|
1 |
git pull origin main |
