¿Qué es un sistema de control de versiones?

Un sistema de control de versiones, o VCS, rastrea el historial de

cambios a medida que las personas y los equipos colaboran en
proyectos juntos. A medida que el proyecto evoluciona, los equipos
pueden ejecutar pruebas, corregir errores y contribuir con nuevos
códigos con la confianza de que cualquier versión se puede recuperar en
cualquier momento. Los desarrolladores pueden revisar el historial del
proyecto para descubrir:

 ¿Qué cambios se hicieron?

 ¿Quién hizo los cambios?
 ¿Cuándo se hicieron los cambios?
 ¿Por qué se necesitaban cambios?

¿Qué es un sistema de control de versiones

distribuido?
Git es un ejemplo de un sistema de control de versiones distribuido
(DVCS) comúnmente utilizado para el desarrollo de software comercial y
de código abierto. Los DVCS permiten el acceso completo a cada
archivo, rama e iteración de un proyecto, y permiten a cada usuario
acceder a un historial completo y autónomo de todos los cambios. A
diferencia de los sistemas de control de versiones centralizados que
alguna vez fueron populares, los DVCS como Git no necesitan una
conexión constante a un repositorio central. Los desarrolladores pueden
trabajar en cualquier lugar y colaborar asincrónicamente desde cualquier
zona horaria.
Sin control de versiones, los miembros del equipo están sujetos a tareas
redundantes, plazos más lentos y copias múltiples de un solo
proyecto. Para eliminar el trabajo innecesario, Git y otros VCS brindan a
cada contribuyente una visión unificada y coherente de un proyecto, lo
que muestra el trabajo que ya está en progreso. Ver un historial
transparente de cambios, quién los hizo y cómo contribuyen al desarrollo
de un proyecto ayuda a los miembros del equipo a mantenerse alineados
mientras trabajan de forma independiente.

1
 ¿Por qué git?
Según la última encuesta de desarrolladores de Stack Overflow , más del
70 por ciento de los desarrolladores usan Git, lo que lo convierte en el
VCS más utilizado del mundo. Git se usa comúnmente para el desarrollo
de software comercial y de código abierto, con beneficios
significativos para individuos, equipos y empresas.

 Git permite a los desarrolladores ver la línea de tiempo completa de

sus cambios, decisiones y progresión de cualquier proyecto en un solo
lugar. Desde el momento en que acceden al historial de un proyecto, el
desarrollador tiene todo el contexto que necesita para comprenderlo y
comenzar a contribuir.

 Los desarrolladores trabajan en cada zona horaria. Con un DVCS

como Git, la colaboración puede ocurrir en cualquier momento mientras
se mantiene la integridad del código fuente. Usando sucursales, los
desarrolladores pueden proponer cambios de forma segura al código de
producción.

 Las empresas que usan Git pueden romper las barreras de

comunicación entre los equipos y mantenerlos enfocados en hacer su
mejor trabajo. Además, Git permite alinear expertos en una empresa para
colaborar en proyectos importantes.

¿Qué es un repositorio?
Un repositorio , o proyecto Git , abarca la colección completa de archivos
y carpetas asociados con un proyecto, junto con el historial de revisión de
cada archivo. El historial de archivos aparece como instantáneas en el
tiempo llamadas confirmaciones , y las confirmaciones existen como una
relación de lista vinculada, y se pueden organizar en múltiples líneas de
desarrollo llamadas ramificaciones . Debido a que Git es un DVCS, los
repositorios son unidades independientes y cualquier persona que posea
una copia del repositorio puede acceder a toda la base de código y su
historial. Usando la línea de comando u otras interfaces fáciles de usar,
un repositorio git también permite: interacción con el historial, clonación,
creación de ramas, confirmación, fusión, comparación de cambios entre
versiones de código, y más.
Trabajar en repositorios mantiene los proyectos de desarrollo
organizados y protegidos. Se alienta a los desarrolladores a corregir
errores o crear nuevas funciones, sin temor a descarrilar los esfuerzos de

2
 desarrollo de la línea principal. Git facilita esto mediante el uso de ramas
temáticas: punteros livianos para confirmaciones en la historia que
pueden crearse y desaprobarse fácilmente cuando ya no se necesitan.
A través de plataformas como GitHub, Git también brinda más
oportunidades para la transparencia y colaboración del proyecto. Los
repositorios públicos ayudan a los equipos a trabajar juntos para crear el
mejor producto final posible.

Comandos básicos de Git

Para usar Git, los desarrolladores usan comandos específicos para
copiar, crear, cambiar y combinar código. Estos comandos se pueden
ejecutar directamente desde la línea de comandos o mediante el uso de
una aplicación como GitHub Desktop o Git Kraken. Aquí hay algunos
comandos comunes para usar Git:

 git init inicializaun nuevo repositorio de Git y comienza a rastrear

un directorio existente. Agrega una subcarpeta oculta dentro del
directorio existente que alberga la estructura de datos interna requerida
para el control de versiones.
 git clone crea una copia local de un proyecto que ya existe de
forma remota. El clon incluye todos los archivos, historial y ramas del
proyecto.
 git add Etapas de un cambio. Git rastrea los cambios en la base de
código de un desarrollador, pero es necesario organizar y tomar una
instantánea de los cambios para incluirlos en la historia del
proyecto. Este comando realiza la puesta en escena, la primera parte de
ese proceso de dos pasos. Cualquier cambio que se realice se convertirá
en parte de la próxima instantánea y en la historia del proyecto. La
puesta en escena y el compromiso por separado brindan a los
desarrolladores un control completo sobre la historia de su proyecto sin
cambiar la forma en que codifican y funcionan.
 git commit guarda la instantánea en el historial del proyecto y
completa el proceso de seguimiento de cambios. En resumen, un commit
funciona como tomar una foto. Todo lo que se haya organizado  git add se
convertirá en parte de la instantánea con  git commit .
 git status  muestra el estado de los cambios como sin seguimiento,
modificado o por etapas.
 git branch  muestra las ramas en las que se trabaja localmente.
 git merge combina líneas de desarrollo juntas. Este comando se usa
generalmente para combinar cambios realizados en dos ramas
3
 distintas. Por ejemplo, un desarrollador se fusionaría cuando quisiera
combinar cambios de una rama de características en la rama maestra
para la implementación.
 git pull actualiza la línea de desarrollo local con actualizaciones de
su contraparte remota. Los desarrolladores usan este comando si un
compañero de equipo se ha comprometido con una sucursal en un
control remoto, y les gustaría reflejar esos cambios en su entorno local.
 git push  actualiza el repositorio remoto con cualquier confirmación
realizada localmente en una rama.
Obtenga más información en una guía de referencia completa sobre los
comandos de Git .

Explore más comandos Git

Para una visión detallada de las prácticas de Git, los videos a
continuación muestran cómo aprovechar al máximo algunos comandos
de Git.

 Trabajando localmente
 git status
 Compromisos de dos pasos
 git pull y git push

Cómo encaja GitHub

GitHub es un repositorio de alojamiento de Git que proporciona a los
desarrolladores herramientas para enviar un mejor código a través de
funciones de línea de comandos, problemas (discusiones entrelazadas),
solicitudes de extracción, revisión de código o el uso de una colección de
aplicaciones gratuitas y de compra en el GitHub Marketplace. Con capas
de colaboración como el flujo de GitHub, una comunidad de 15 millones
de desarrolladores y un ecosistema con cientos de integraciones, GitHub
cambia la forma en que se construye el software.

Como funciona GitHub

GitHub integra la colaboración directamente en el proceso de
desarrollo. El trabajo se organiza en repositorios, donde los
desarrolladores pueden describir los requisitos o la dirección y establecer
expectativas para los miembros del equipo. Luego, usando el flujo de
GitHub, los desarrolladores simplemente crean una rama para trabajar en

4
 las actualizaciones, comprometen cambios para guardarlos, abren una
solicitud de extracción para proponer y discutir cambios y fusionan las
solicitudes de extracción una vez que todos están en la misma página.

El flujo de GitHub
El flujo de GitHub es un flujo de trabajo ligero, basado en sucursales,
construido alrededor de los comandos centrales de Git utilizados por
equipos de todo el mundo, incluido el nuestro.
El flujo de GitHub tiene seis pasos, cada uno con beneficios distintos
cuando se implementa:

1. Crear una rama: las ramas de tema creadas a partir de la rama de

implementación canónica (generalmente  master ) permiten a los equipos
contribuir a muchos esfuerzos paralelos. Las ramas temáticas de corta
duración, en particular, mantienen a los equipos enfocados y dan como
resultado envíos rápidos.
2. Agregue compromisos: las instantáneas de los esfuerzos de
desarrollo dentro de una sucursal crean puntos seguros y reversibles en
la historia del proyecto.
3. Abrir una solicitud de extracción: las solicitudes de
extracción publicitan los esfuerzos en curso de un proyecto y establecen
el tono para un proceso de desarrollo transparente.
4. Discuta y revise el código: los equipos participan en las
revisiones del código comentando, probando y revisando las solicitudes
de extracción abiertas. La revisión del código es el núcleo de una cultura
abierta y participativa.
5. Fusionar: al hacer clic en fusionar, GitHub realiza
automáticamente el equivalente de una operación local 'git
merge'. GitHub también mantiene todo el historial de desarrollo de
sucursales en la solicitud de extracción combinada.
6. Implementación: los equipos pueden elegir los mejores ciclos de
lanzamiento o incorporar herramientas de integración continua y operar
con la seguridad de que el código en la rama de implementación ha
pasado por un flujo de trabajo sólido.

Obtenga más información sobre el flujo de GitHub

Los desarrolladores pueden encontrar más información sobre el flujo de
GitHub en los recursos que se proporcionan a continuación.

 Guía interactiva

5
 Video de GitHub Flow

GitHub y la línea de comando

Para los desarrolladores nuevos en la línea de comandos, el equipo de
capacitación de GitHub ha reunido una serie de tutoriales sobre los
comandos de Git para guiar el camino. A veces, una serie de comandos
puede pintar una imagen de cómo usar Git:

Ejemplo: contribuir a un repositorio existente

# download a repository on GitHub.com to our machine

git clone https://github.com/me/repo.git

# change into the `repo` directory

cd repo

# create a new branch to store any new changes

git branch my-branch

# switch to that branch (line of development)

git checkout my-branch

# make changes, for example, edit `file1.md` and `file2.md` using the
text editor

# stage the changed files

git add file1.md file2.md

# take a snapshot of the staging area (anything that's been added)

git commit -m "my snapshot"

# push changes to github

git push --set-upstream origin my-branch

Ejemplo: iniciar un nuevo repositorio y publicarlo en GitHub

Primero, deberá crear un nuevo repositorio en GitHub. Puedes aprender
cómo crear un nuevo repositorio en nuestra guía Hello
World . No inicialice el repositorio con un archivo README, .gitignore o
License. Este repositorio vacío esperará su código.

# create a new directory, and initialize it with git-specific functions

git init my-repo

6
# change into the `my-repo` directory
cd my-repo

# create the first file in the project

touch README.md

# git isn't aware of the file, stage it

git add README.md

# take a snapshot of the staging area

git commit -m "add README to initial commit"

# provide the path for the repository you created on github

git remote add origin https://github.com/YOUR-USERNAME/YOUR-
REPOSITORY.git

# push changes to github

git push --set-upstream origin master

Ejemplo: contribuir a una sucursal existente en GitHub

# assumption: a project called `repo` already exists on the machine, and

a new branch has been pushed to GitHub.com since the last time changes
were made locally

# change into the `repo` directory

cd repo

# update all remote tracking branches, and the currently checked out
branch
git pull

# change into the existing branch called `feature-a`

git checkout feature-a

# make changes, for example, edit `file1.md` using the text editor

# stage the changed file

git add file1.md

# take a snapshot of the staging area

git commit -m "edit file1"

# push changes to github

7
 git push

Modelos para el desarrollo colaborativo.

Hay dos formas principales en que las personas colaboran en GitHub:

1. Repositorio compartido
2. Tenedor y tirar

Con un repositorio compartido , las personas y los equipos se designan

explícitamente como contribuyentes con acceso de lectura, escritura o
administrador. Esta estructura de permisos simple, combinada con
características como sucursales protegidas y Marketplace, ayuda a los
equipos a progresar rápidamente cuando adoptan GitHub.
Para un proyecto de código abierto, o para proyectos en los que
cualquiera puede contribuir, administrar los permisos individuales puede
ser un desafío, pero un modelo fork y pull permite que cualquiera que
pueda ver el proyecto contribuya. Una bifurcación es una copia de un
proyecto bajo la cuenta personal de un desarrollador. Cada desarrollador
tiene el control total de su tenedor y es libre de implementar una
corrección o una nueva característica. El trabajo realizado en horquillas
se mantiene separado o se devuelve al proyecto original mediante una
solicitud de extracción. Allí, los encargados del mantenimiento pueden
revisar los cambios sugeridos antes de fusionarlos. Consulte la Guía de
proyectos de Forking para obtener más información.

Aprende a tu propio ritmo

El equipo de GitHub ha creado una biblioteca de videos educativos y
guías para ayudar a los usuarios a continuar desarrollando sus
habilidades y construir un mejor software.

 Proyectos para principiantes para explorar

 Guías de video de GitHub
 Entrenamiento bajo demanda GitHub
 Guías de entrenamiento de GitHub
 Recursos de capacitación de GitHub