Aprovechando una entrada anterior en la que explicaba cómo gestionar las ramas en Git mediante un flujo de trabajo, he creído conveniente crear también este post. En él te mostraré para qué sirve el fichero .gitignore.
No sé si te habrá pasado, pero a lo largo de los años he visto un error muy común que muchas veces pasamos por alto y nos puede traer sorpresas desagradables. Además de la pérdida de tiempo que supone tener que arreglar algo que se podía haber evitado fácilmente.
Me refiero a recursos que añadimos a un repositorio Git y que no deberían estar ahí.
No todos los recursos son aptos para Git
Te voy a poner un ejemplo de por qué debes evitar subir a un repositorio todos los recursos relacionados con tu proyecto que se generan durante el desarrollo.
Voy a suponer que usas un IDE para programar. Normalmente, los IDEs, como pueden ser PyCharm, VSCode o Eclipse, generan un directorio que contiene ficheros de configuración de tu proyecto y de tu espacio de trabajo. Es muy común que en estos ficheros haya referencia a rutas relativas y absolutas de tu sistema. Pues bien, si subes este directorio de configuración al repositorio común y otra persona en tu equipo (o incluso tú si usas un ordenador diferente) actualiza su repositorio y usa el mismo IDE, vais a entrar en una guerra de conflictos en la que continuamente estaréis rompiendo el proyecto y arreglando estas diferencias.
Otro ejemplo: Cuando ejecutas un programa Python, el intérprete genera código precompilado en bytecode. Este código se guarda en un directorio llamado __pycache__, creándose un directorio de este tipo en cada una de las carpetas de nuestro proyecto en la que haya código Python. Sin embargo, estos recursos no forman parte del proyecto de desarrollo, por lo que deberías evitar subirlos al repositorio.
¿Para qué sirve .gitignore?
Todos los ejemplos del apartado anterior (y muchos otros) son fácilmente evitables. Para ello, Git pone a tu disposición una herramienta llamada .gitignore. En realidad, .gitignore no es más que un fichero que añadimos en la raíz de nuestro proyecto en el que indicamos, por medio de expresiones regulares, qué ficheros no hay que tener en cuenta para el control de versiones.
.gitignore para proyectos Python 🐍
Podemos editar el fichero .gitignore según nuestras necesidades, configuración del sistema o requisitos del proyecto. Aquí te dejo un ejemplo de partida de un fichero .gitignore válido para cualquier tipo de proyecto Python. Eres libre de añadir y/o quitar lo que quieras/necesites.
👇🏻👇🏻👇🏻
# Byte-compiled / optimized / DLL files __pycache__/ *.py[cod] *$py.class # C extensions *.so # Distribution / packaging .Python build/ develop-eggs/ dist/ downloads/ eggs/ .eggs/ lib/ lib64/ parts/ sdist/ var/ wheels/ share/python-wheels/ *.egg-info/ .installed.cfg *.egg MANIFEST # PyInstaller # Usually these files are written by a python script from a template # before PyInstaller builds the exe, so as to inject date/other infos into it. *.manifest *.spec # Installer logs pip-log.txt pip-delete-this-directory.txt # Unit test / coverage reports htmlcov/ .tox/ .nox/ .coverage .coverage.* .cache nosetests.xml coverage.xml *.cover .hypothesis/ .pytest_cache/ # Translations *.mo *.pot # Django stuff: *.log local_settings.py db.sqlite3 # Flask stuff: instance/ .webassets-cache # Scrapy stuff: .scrapy # Sphinx documentation docs/_build/ # PyBuilder target/ # Jupyter Notebook .ipynb_checkpoints # IPython profile_default/ ipython_config.py # pyenv .python-version # celery beat schedule file celerybeat.pid celerybeat-schedule # SageMath parsed files *.sage.py # Environments .env .venv env/ venv/ ENV/ env.bak/ venv.bak/ # Spyder project settings .spyderproject .spyproject # Rope project settings .ropeproject # mkdocs documentation /site # mypy .mypy_cache/ .dmypy.json dmypy.json # Pyre type checker .pyre/ # IDEs project files .idea .vscode rest-client.env.json # Folder view configuration files *.DS_Store Desktop.ini # Thumbnails ._* Thumbs.db
