6.

1 GitHub - Configuración y
configuración de la cuenta
GitHub es el host más grande para los repositorios de Git, y es el punto central de
colaboración para millones de desarrolladores y proyectos. Un gran porcentaje de todos
los repositorios de Git están alojados en GitHub, y muchos proyectos de código abierto lo
usan para el alojamiento de Git, el seguimiento de problemas, la revisión de código y otras
cosas. Entonces, aunque no es una parte directa del proyecto de código abierto de Git,
hay una buena posibilidad de que desee o necesite interactuar con GitHub en algún
momento mientras usa Git profesionalmente.

Este capítulo trata sobre el uso efectivo de GitHub. Cubriremos el registro y la

administración de una cuenta, la creación y el uso de repositorios de Git, flujos de trabajo
comunes para contribuir a proyectos y aceptar contribuciones a los suyos, la interfaz
programática de GitHub y muchos pequeños consejos para facilitarle la vida en general.

Si no está interesado en usar GitHub para alojar sus propios proyectos o colaborar con
otros proyectos alojados en GitHub, puede saltar a Git Tools .

Configuración y configuración de cuenta

Lo primero que debe hacer es configurar una cuenta de usuario gratuita. Simplemente
visite https://github.com , elija un nombre de usuario que aún no se haya tomado,
proporcione una dirección de correo electrónico y una contraseña, y haga clic en el gran
botón verde "Registrarse en GitHub".
Figura 82. El formulario de registro de GitHub.
Lo siguiente que verá es la página de precios para planes actualizados, pero es seguro
ignorar esto por ahora. GitHub le enviará un correo electrónico para verificar la dirección
que proporcionó. Adelante y haz esto; Es bastante importante (como veremos más
adelante).

GitHub ofrece todas sus funciones con cuentas gratuitas, con la

limitación de que todos sus proyectos son totalmente públicos (todos
tienen acceso de lectura). Los planes pagos de GitHub también
Nota incluyen la opción de crear proyectos privados, pero no los
cubriremos en este libro.

Al hacer clic en el logotipo de Octocat en la esquina superior izquierda de la pantalla,

accederá a la página del panel. Ahora estás listo para usar GitHub.

Acceso SSH
En este momento, puede conectarse completamente con los repositorios de Git utilizando
el https://protocolo, autenticándose con el nombre de usuario y la contraseña que
acaba de configurar. Sin embargo, para simplemente clonar proyectos públicos, ni siquiera
necesita registrarse: la cuenta que acabamos de crear entra en juego cuando bifurcamos
proyectos y pasamos a nuestros tenedores un poco más tarde.
Si desea utilizar controles remotos SSH, deberá configurar una clave pública. (Si aún no
tiene una, consulte Generar su clave pública SSH ). Abra la configuración de su cuenta
utilizando el enlace en la parte superior derecha de la ventana:
Figura 83. El enlace "Configuración de la cuenta".
Luego seleccione la sección "Teclas SSH" en el lado izquierdo.

Figura 84. El enlace "Claves SSH".

Desde allí, haga clic en el botón " Add an SSH key", asigne un nombre a su clave,
pegue el contenido de su ~/.ssh/id_rsa.pubarchivo de clave pública (o lo que sea que
haya nombrado) en el área de texto y haga clic en "Agregar clave".
Asegúrese de nombrar su clave SSH como algo que pueda
recordar. Puede nombrar cada una de sus claves (por ejemplo, "Mi
computadora portátil" o "Cuenta de trabajo") para que si necesita
Nota revocar una clave más adelante, pueda determinar fácilmente cuál
está buscando.

Tu avatar
A continuación, si lo desea, puede reemplazar el avatar que se genera para usted con una
imagen de su elección. Primero vaya a la pestaña "Perfil" (arriba de la pestaña Claves
SSH) y haga clic en "Cargar nueva imagen".
Figura 85. El enlace "Perfil".
Elegiremos una copia del logotipo de Git que está en nuestro disco duro y luego tendremos
la oportunidad de recortarlo.

Figura 86. Recorta tu avatar

Ahora, en cualquier lugar donde interactúe en el sitio, las personas verán su avatar junto a
su nombre de usuario.

Si ha subido un avatar al popular servicio Gravatar (a menudo usado para cuentas de

Wordpress), ese avatar se usará de manera predeterminada y no necesita seguir este
paso.

Sus direcciones de correo electrónico

La forma en que GitHub asigna sus compromisos de Git a su usuario es por dirección de
correo electrónico. Si usa varias direcciones de correo electrónico en sus confirmaciones y
desea que GitHub las vincule correctamente, debe agregar todas las direcciones de correo
electrónico que ha utilizado a la sección de correos electrónicos de la sección de
administración.

Figura 87. Agregar direcciones de correo electrónico

En Agregar direcciones de correo electrónico podemos ver algunos de los diferentes
estados que son posibles. La dirección superior se verifica y establece como la dirección
principal, lo que significa que es donde recibirá las notificaciones y recibos. La segunda
dirección se verifica y, por lo tanto, se puede establecer como primaria si desea
cambiarla. La dirección final no está verificada, lo que significa que no puede convertirla en
su dirección principal. Si GitHub ve alguno de estos en mensajes de confirmación en
cualquier repositorio del sitio, ahora estará vinculado a su usuario.

Autenticación de dos factores

Finalmente, para mayor seguridad, definitivamente debe configurar la autenticación de dos
factores o "2FA". La autenticación de dos factores es un mecanismo de autenticación que
se está volviendo cada vez más popular recientemente para mitigar el riesgo de que su
cuenta se vea comprometida si su contraseña es robada de alguna manera. Si lo activa,
GitHub le pedirá dos métodos diferentes de autenticación, de modo que si uno de ellos se
ve comprometido, un atacante no podrá acceder a su cuenta.

Puede encontrar la configuración de autenticación de dos factores en la pestaña Seguridad

de la configuración de su cuenta.
Figura 88. 2FA en la pestaña Seguridad
Si hace clic en el botón "Configurar autenticación de dos factores", lo llevará a una página
de configuración donde puede elegir usar una aplicación de teléfono para generar su
código secundario (una "contraseña de un solo uso basada en el tiempo"), o puede hacer
que GitHub le envíe un código por SMS cada vez que necesite iniciar sesión.

Después de elegir el método que prefiera y seguir las instrucciones para configurar 2FA,
su cuenta será un poco más segura y tendrá que proporcionar un código además de su
contraseña cada vez que inicie sesión en GitHub.

6.2 GitHub - Contribuyendo a un

Proyecto
Contribuyendo a un proyecto
Ahora que nuestra cuenta está configurada, veamos algunos detalles que podrían ser
útiles para ayudarlo a contribuir a un proyecto existente.

Proyectos de bifurcación
Si desea contribuir a un proyecto existente para el que no tiene acceso push, puede
"bifurcar" el proyecto. Cuando "bifurca" un proyecto, GitHub hará una copia del proyecto
que es completamente suya; vive en tu espacio de nombres, y puedes presionarlo.

Históricamente, el término "bifurcación" ha sido algo negativo en su

contexto, lo que significa que alguien tomó un proyecto de código
abierto en una dirección diferente, a veces creando un proyecto
Nota competitivo y dividiendo a los contribuyentes. En GitHub, una
"bifurcación" es simplemente el mismo proyecto en su propio espacio
de nombres, lo que le permite realizar cambios en un proyecto
 públicamente como una forma de contribuir de una manera más
abierta.

De esta manera, los proyectos no tienen que preocuparse por agregar usuarios como
colaboradores para darles acceso push. Las personas pueden bifurcar un proyecto,
impulsarlo y contribuir con sus cambios al repositorio original creando lo que se llama una
solicitud de extracción, que cubriremos a continuación. Esto abre un hilo de discusión con
la revisión del código, y el propietario y el contribuyente pueden comunicarse sobre el
cambio hasta que el propietario esté satisfecho con él, momento en el cual el propietario
puede fusionarlo.

Para bifurcar un proyecto, visite la página del proyecto y haga clic en el botón "Bifurcación"
en la esquina superior derecha de la página.

Figura 89. El botón "Horquilla".

Después de unos segundos, será llevado a su nueva página de proyecto, con su propia
copia del código que se puede escribir.

El flujo de GitHub
GitHub está diseñado en torno a un flujo de trabajo de colaboración particular, centrado en
solicitudes de extracción. Este flujo funciona si está colaborando con un equipo muy unido
en un único repositorio compartido, o con una compañía o red de extraños distribuidos
globalmente que contribuyen a un proyecto a través de docenas de tenedores. Se centra
en el flujo de trabajo Ramas temáticas cubierto en Git Branching .

Así es como generalmente funciona:

1. Bifurca el proyecto
2. Crear una rama de tema desde master.
3. Haz algunos compromisos para mejorar el proyecto.
4. Empuje esta rama a su proyecto GitHub.
5. Abra una solicitud de extracción en GitHub.
6. Discuta y, opcionalmente, continúe comprometiéndose.
7. El propietario del proyecto fusiona o cierra la solicitud de extracción.
8. Sincronice el maestro actualizado nuevamente a su bifurcación.

Este es básicamente el flujo de trabajo de Integration Manager cubierto en Integration-

Manager Workflow , pero en lugar de usar el correo electrónico para comunicarse y revisar
los cambios, los equipos usan las herramientas basadas en la web de GitHub.

Veamos un ejemplo de proponer un cambio a un proyecto de código abierto alojado en

GitHub usando este flujo.
Crear una solicitud de extracción
Tony está buscando código para ejecutar en su microcontrolador programable Arduino y
ha encontrado un excelente archivo de programa en GitHub
en https://github.com/schacon/blink .

Figura 90. El proyecto al que queremos contribuir.

El único problema es que la tasa de parpadeo es demasiado rápida. Creemos que es

mucho mejor esperar 3 segundos en lugar de 1 entre cada cambio de estado. Así que
vamos a mejorar el programa y presentarlo nuevamente al proyecto como un cambio
propuesto.

Primero, hacemos clic en el botón Fork como se mencionó anteriormente para obtener
nuestra propia copia del proyecto. Nuestro nombre de usuario aquí es "tonychacon", por lo
que nuestra copia de este proyecto está
en https://github.com/tonychacon/blinky allí es donde podemos editarlo. Lo
clonaremos localmente, crearemos una rama de tema, haremos que el código cambie y
finalmente empuje ese cambio de nuevo a GitHub.

$ git clone https://github.com/tonychacon/blink (1)

Cloning into 'blink'...

$ cd blink

$ git checkout -b slow-blink (2)

Switched to a new branch 'slow-blink'

$ sed -i '' 's/1000/3000/' blink.ino (macOS) (3)

# If you're on a Linux system, do this instead:

# $ sed -i 's/1000/3000/' blink.ino (3)

$ git diff --word-diff (4)

diff --git a/blink.ino b/blink.ino

index 15b9911..a6cc5a5 100644

--- a/blink.ino

+++ b/blink.ino

@@ -18,7 +18,7 @@ void setup() {

// the loop routine runs over and over again forever:

void loop() {

digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage

level)

[-delay(1000);-]{+delay(3000);+} // wait for a second

digitalWrite(led, LOW); // turn the LED off by making the voltage LOW

[-delay(1000);-]{+delay(3000);+} // wait for a second

$ git commit -a -m 'three seconds is better' (5)

[slow-blink 5ca509d] three seconds is better

1 file changed, 2 insertions(+), 2 deletions(-)

$ git push origin slow-blink (6)

Username for 'https://github.com': tonychacon

Password for 'https://tonychacon@github.com':

Counting objects: 5, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.

Total 3 (delta 1), reused 0 (delta 0)

To https://github.com/tonychacon/blink

* [new branch] slow-blink -> slow-blink

1. Clone nuestro tenedor del proyecto localmente

2. Crear una rama de tema descriptivo
3. Haz nuestro cambio al código
4. Comprueba que el cambio sea bueno
5. Comprometer nuestro cambio a la rama temática
6. Empuje nuestra nueva rama temática de nuevo a nuestra bifurcación
GitHub

Ahora, si volvemos a nuestra bifurcación en GitHub, podemos ver que GitHub notó que
empujamos una nueva rama de tema y nos presenta un gran botón verde para verificar
nuestros cambios y abrir una solicitud de extracción para el proyecto original.

Alternativamente, puede ir a la página "Sucursales"

en https://github.com/<user>/<project>/branchespara ubicar su sucursal y
abrir una nueva Solicitud de extracción desde allí.
Figura 91. Botón de solicitud de extracción

Si hacemos clic en ese botón verde, veremos una pantalla que nos pide que le demos un
título y una descripción a nuestra solicitud de extracción. Casi siempre vale la pena poner
un poco de esfuerzo en esto, ya que una buena descripción ayuda al propietario del
proyecto original a determinar qué estaba tratando de hacer, si los cambios propuestos
son correctos y si aceptar los cambios mejoraría el proyecto original.

También vemos una lista de las confirmaciones en nuestra rama temática que están "por
delante" de la masterrama (en este caso, solo una) y una diferencia unificada de todos
los cambios que se realizarán si el propietario del proyecto fusiona esta rama. .
Figura 92. Página de creación de solicitud de extracción

Cuando presiona el botón Crear solicitud de extracción en esta pantalla, el propietario

del proyecto que bifurcó recibirá una notificación de que alguien está sugiriendo un cambio
y se vinculará a una página que contiene toda esta información.

Aunque las solicitudes de extracción se usan comúnmente para

proyectos públicos como este cuando el contribuyente tiene un
cambio completo listo para ser realizado, a menudo también se usa
en proyectos internos al comienzo del ciclo de desarrollo. Dado que
Nota puede seguir avanzando hacia la rama del tema incluso después
de abrir la Solicitud de extracción, a menudo se abre temprano y se
usa como una forma de iterar en el trabajo como equipo dentro de un
contexto, en lugar de abrirse al final del proceso.

Iterando en una solicitud de extracción

En este punto, el propietario del proyecto puede ver el cambio sugerido y fusionarlo,
rechazarlo o comentarlo. Digamos que le gusta la idea, pero preferiría un tiempo un poco
más largo para que la luz esté apagada que encendida.

Cuando esta conversación puede tener lugar por correo electrónico en los flujos de trabajo
presentados en Distributed Git , en GitHub esto sucede en línea. El propietario del
proyecto puede revisar la diferencia unificada y dejar un comentario haciendo clic en
cualquiera de las líneas.

Figura 93. Comentario sobre una línea de código específica en una solicitud de extracción

Una vez que el mantenedor hace este comentario, la persona que abrió la solicitud de
extracción (y, de hecho, cualquier otra persona que esté mirando el repositorio) recibirá
una notificación. Revisaremos la personalización de esto más tarde, pero si tuviera
activadas las notificaciones por correo electrónico, Tony recibiría un correo electrónico
como este:

Figura 94. Comentarios enviados como notificaciones por correo electrónico

Cualquiera también puede dejar comentarios generales sobre la solicitud de extracción. En

la página de discusión Solicitud de extracción podemos ver un ejemplo del propietario del
proyecto comentando una línea de código y luego dejando un comentario general en la
sección de discusión. Puede ver que los comentarios del código también se incluyen en la
conversación.
Figura 95. Página de discusión de Solicitud de extracción

Ahora el contribuyente puede ver lo que necesita hacer para que su cambio sea
aceptado. Afortunadamente esto es muy sencillo. En el caso de que tenga que volver a
enviar su serie por correo electrónico y volver a enviarla a la lista de correo, con GitHub
simplemente se compromete con la rama del tema nuevamente y presiona, lo que
actualizará automáticamente la Solicitud de extracción. En la solicitud de extracción
final también puede ver que el comentario de código anterior se ha contraído en la solicitud
de extracción actualizada, ya que se realizó en una línea que desde entonces se ha
modificado.

Agregar confirmaciones a una solicitud de extracción existente no activa una notificación,

por lo que una vez que Tony ha empujado sus correcciones, decide dejar un comentario
para informar al propietario del proyecto que realizó el cambio solicitado.
Figura 96. Solicitud de extracción final

Una cosa interesante a notar es que si hace clic en la pestaña "Archivos modificados" en
esta solicitud de extracción, obtendrá la diferencia "unificada", es decir, la diferencia total
agregada que se introduciría en su rama principal si este tema la rama se fusionó. En git
difftérminos, básicamente le muestra automáticamente git diff
master...<branch>la rama en la que se basa esta solicitud de
extracción. Consulte Determinación de lo que se presenta para obtener más información
sobre este tipo de diferencias.
La otra cosa que notará es que GitHub verifica si la solicitud de extracción se fusiona
limpiamente y proporciona un botón para que se fusione en el servidor. Este botón solo
aparece si tiene acceso de escritura al repositorio y es posible una fusión trivial. Si hace
clic en él, GitHub realizará una fusión “sin avance rápido”, lo que significa que incluso si la
fusión podría ser un avance rápido, seguirá creando una confirmación de fusión.
Si lo prefiere, puede simplemente bajar la rama y fusionarla localmente. Si fusiona esta
rama en la masterrama y la empuja a GitHub, la solicitud de extracción se cerrará
automáticamente.
Este es el flujo de trabajo básico que utilizan la mayoría de los proyectos de GitHub. Se
crean ramas temáticas, se abren solicitudes de extracción sobre ellas, se produce una
discusión, posiblemente se realiza más trabajo en la rama y, finalmente, la solicitud se
cierra o se fusiona.

No solo horquillas

Es importante tener en cuenta que también puede abrir una solicitud

de extracción entre dos ramas en el mismo repositorio. Si está
Nota
trabajando en una función con alguien y ambos tienen acceso de
escritura al proyecto, puede insertar una rama temática en el
repositorio y abrir una solicitud de extracción en la master rama del
mismo proyecto para iniciar la revisión y discusión del código
proceso. No es necesario bifurcar.

Solicitudes de extracción avanzadas

Ahora que hemos cubierto los conceptos básicos para contribuir a un proyecto en GitHub,
cubramos algunos consejos y trucos interesantes sobre las solicitudes de extracción para
que pueda ser más efectivo al usarlas.

Solicitudes de extracción como parches

Es importante comprender que muchos proyectos realmente no piensan en las solicitudes
de extracción como colas de parches perfectos que deberían aplicarse limpiamente en
orden, ya que la mayoría de los proyectos basados en listas de correo piensan en
contribuciones de series de parches. La mayoría de los proyectos de GitHub piensan en
las ramas de Solicitud de extracción como conversaciones iterativas en torno a un cambio
propuesto, que culmina en una diferencia unificada que se aplica mediante la fusión.

Esta es una distinción importante, porque generalmente el cambio se sugiere antes de que
el código se considere perfecto, lo cual es mucho más raro con las contribuciones de
series de parches basadas en listas de correo. Esto permite una conversación anterior con
los mantenedores para que llegar a la solución adecuada sea más un esfuerzo de la
comunidad. Cuando se propone el código con una solicitud de extracción y los encargados
de mantenimiento o la comunidad sugieren un cambio, la serie de parches generalmente
no se vuelve a lanzar, sino que la diferencia se empuja como un nuevo compromiso a la
rama, avanzando la conversación con el contexto del trabajo previo intacto.

Por ejemplo, si regresa y vuelve a mirar la solicitud de extracción final , notará que el
contribuyente no reformuló su confirmación y envió otra solicitud de extracción. En cambio,
agregaron nuevos commits y los empujaron a la rama existente. De esta manera, si
regresa y mira esta solicitud de extracción en el futuro, puede encontrar fácilmente todo el
contexto de por qué se tomaron las decisiones. Al presionar el botón "Fusionar" en el sitio,
se crea una confirmación de fusión que hace referencia a la solicitud de extracción para
que sea fácil regresar e investigar la conversación original si es necesario.

Mantenerse al día con Upstream

Si su solicitud de extracción no está actualizada o si no se fusiona limpiamente, querrá
solucionarlo para que el responsable de mantenimiento pueda fusionarlo
fácilmente. GitHub lo probará por usted y le informará en la parte inferior de cada solicitud
de extracción si la fusión es trivial o no.

Figura 97. La solicitud de extracción no se combina limpiamente

Si ve que algo como Pull Request no se fusiona limpiamente , querrá arreglar su rama
para que se vuelva verde y el responsable no tenga que hacer un trabajo adicional.

Tienes dos opciones principales para hacer esto. Puede cambiar la base de su rama
encima de la rama de destino (normalmente la masterrama del repositorio que bifurcó), o
puede fusionar la rama de destino en su rama.
La mayoría de los desarrolladores en GitHub elegirán hacer lo último, por las mismas
razones que acabamos de ver en la sección anterior. Lo que importa es el historial y la
fusión final, por lo que el rebase no te ofrece mucho más que un historial ligeramente más
limpio y, a cambio, es mucho más difícil y propenso a errores.

Si desea fusionarse en la rama de destino para hacer que su solicitud de extracción sea
fusionable, debe agregar el repositorio original como un nuevo control remoto, buscarlo,
fusionar la rama principal de ese repositorio en su rama de tema, solucionar cualquier
problema y finalmente empujarlo volver a la misma rama en la que abrió la solicitud de
extracción.

Por ejemplo, supongamos que en el ejemplo "tonychacon" que estábamos usando antes,
el autor original realizó un cambio que crearía un conflicto en la solicitud de
extracción. Veamos esos pasos.

$ git remote add upstream https://github.com/schacon/blink (1)

$ git fetch upstream (2)

remote: Counting objects: 3, done.

remote: Compressing objects: 100% (3/3), done.

Unpacking objects: 100% (3/3), done.

remote: Total 3 (delta 0), reused 0 (delta 0)

From https://github.com/schacon/blink

* [new branch] master -> upstream/master

$ git merge upstream/master (3)

Auto-merging blink.ino

CONFLICT (content): Merge conflict in blink.ino

Automatic merge failed; fix conflicts and then commit the result.

$ vim blink.ino (4)

$ git add blink.ino

$ git commit

[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \

into slower-blink

$ git push origin slow-blink (5)

Counting objects: 6, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (6/6), done.

Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.

Total 6 (delta 2), reused 0 (delta 0)

To https://github.com/tonychacon/blink

ef4725c..3c8d735 slower-blink -> slow-blink

1. Agregue el repositorio original como un control remoto llamado

"ascendente"
2. Obtenga el trabajo más nuevo desde ese control remoto
3. Combina la rama principal de ese repositorio en la rama de tu tema
4. Arregla el conflicto que ocurrió
5. Vuelva a la misma rama temática.
Una vez que haga eso, la Solicitud de extracción se actualizará automáticamente y se
volverá a verificar para ver si se fusiona limpiamente.

Figura 98. Solicitud de extracción ahora se combina limpiamente

Una de las mejores cosas de Git es que puedes hacerlo continuamente. Si tiene un
proyecto de larga duración, puede fusionarse fácilmente desde la rama de destino una y
otra vez y solo tiene que lidiar con los conflictos que han surgido desde la última vez que
se fusionó, haciendo que el proceso sea muy manejable.

Si desea cambiar la base de la sucursal para limpiarla, sin duda puede hacerlo, pero se
recomienda no forzar el empuje sobre la sucursal en la que ya está abierta la solicitud de
extracción. Si otras personas lo han derribado y han trabajado más en él, te topas con
todos los problemas descritos en The Perils of Rebasing . En su lugar, empuje la rama
rebaseada a una nueva rama en GitHub y abra una nueva solicitud de extracción que haga
referencia a la anterior, luego cierre el original.

Referencias
Su próxima pregunta puede ser "¿Cómo hago referencia a la antigua solicitud de
extracción?". Resulta que hay muchas, muchas formas de hacer referencia a otras cosas
en casi cualquier lugar donde pueda escribir en GitHub.

Comencemos con la referencia cruzada de otra solicitud de extracción o un

problema. Todas las solicitudes y problemas de extracción son números asignados y son
únicos dentro del proyecto. Por ejemplo, no puede tener Pull Request # 3 y Issue # 3. Si
desea hacer referencia a cualquier solicitud o problema de extracción de cualquier otra,
simplemente puede poner #<num>cualquier comentario o descripción. También puede ser
más específico si la solicitud Issue o Pull reside en otro lugar; escriba username#<num>si
se refiere a un problema o solicitud de extracción en una bifurcación del repositorio en el
que se encuentra, o username/repo#<num>para hacer referencia a algo en otro
repositorio.
Veamos un ejemplo. Supongamos que volvimos a basar la rama en el ejemplo anterior,
creamos una nueva solicitud de extracción para ella y ahora queremos hacer referencia a
la antigua solicitud de extracción de la nueva. También queremos hacer referencia a un
problema en la bifurcación del repositorio y un problema en un proyecto completamente
diferente. Podemos completar la descripción como referencias cruzadas en una solicitud
de extracción. .

Figura 99. Referencias cruzadas en una solicitud de extracción.

Cuando enviemos esta solicitud de extracción, veremos todo eso representado

como referencias cruzadas en una solicitud de extracción . .

Figura 100. Referencias cruzadas representadas en una solicitud de extracción.

Tenga en cuenta que la URL completa de GitHub que pusimos allí se acortó a la
información necesaria.

Ahora, si Tony regresa y cierra la solicitud de extracción original, podemos ver que al
mencionarla en la nueva, GitHub ha creado automáticamente un evento de trackback en la
línea de tiempo de la solicitud de extracción. Esto significa que cualquier persona que
visite esta Solicitud de extracción y vea que está cerrada puede vincular fácilmente a la
que la reemplazó. El enlace se parecerá a un enlace a la nueva solicitud de extracción en
la línea de tiempo cerrada de solicitud de extracción. .

Figura 101. Vuelva a vincular a la nueva solicitud de extracción en la línea de tiempo

cerrada de solicitud de extracción.

Además de los números de emisión, también puede hacer referencia a una confirmación
específica de SHA-1. Debe especificar un SHA-1 completo de 40 caracteres, pero si
GitHub lo ve en un comentario, se vinculará directamente con la
confirmación. Nuevamente, puede hacer referencia a confirmaciones en horquillas u otros
repositorios de la misma manera que lo hizo con los problemas.

Markit con sabor a GitHub

Vincular a otros problemas es solo el comienzo de cosas interesantes que puede hacer
con casi cualquier cuadro de texto en GitHub. En las descripciones, comentarios,
comentarios de código y más de Issue and Pull Request, puede usar lo que se llama
"GitHub Flavored Markdown". Markdown es como escribir en texto plano, pero que se
representa ricamente.

Vea un ejemplo de GitHub Flavored Markdown como está escrito y como se

representa. para ver un ejemplo de cómo los comentarios o el texto se pueden escribir y
luego representar con Markdown.
Figura 102. Un ejemplo de GitHub Flavored Markdown tal como está escrito y
representado.

El sabor GitHub de Markdown agrega más cosas que puedes hacer más allá de la sintaxis
básica de Markdown. Todo esto puede ser realmente útil al crear una solicitud de
extracción o comentarios o descripciones útiles.

Listas de tareas
La primera característica de Markdown específica de GitHub realmente útil, especialmente
para su uso en solicitudes de extracción, es la Lista de tareas. Una lista de tareas es una
lista de casillas de verificación de las cosas que desea hacer. Ponerlos en una solicitud de
problema o extracción normalmente indica las cosas que desea hacer antes de considerar
que el elemento está completo.

Puede crear una lista de tareas como esta:

- [X] Write the code

- [ ] Write all the tests

- [ ] Document the code

Si incluimos esto en la descripción de nuestra solicitud o problema de extracción, lo

veremos representado como listas de tareas en un comentario de Markdown.

Figura 103. Listas de tareas representadas en un comentario de Markdown.

Esto se usa a menudo en las solicitudes de extracción para indicar lo que desea hacer en
la sucursal antes de que la solicitud de extracción esté lista para fusionarse. La parte
realmente genial es que simplemente puede hacer clic en las casillas de verificación para
actualizar el comentario; no tiene que editar el Markdown directamente para marcar las
tareas.

Además, GitHub buscará listas de tareas en sus problemas y solicitudes de extracción y

las mostrará como metadatos en las páginas que las enumeran. Por ejemplo, si tiene una
solicitud de extracción con tareas y mira la página de resumen de todas las solicitudes de
extracción, puede ver qué tan lejos está. Esto ayuda a las personas a dividir las solicitudes
de extracción en subtareas y ayuda a otras personas a rastrear el progreso de la
rama. Puede ver un ejemplo de esto en el resumen de la lista de tareas en la lista Solicitud
de extracción. .
Figura 104. Resumen de la lista de tareas en la lista Solicitud de extracción.

Estos son increíblemente útiles cuando abre una solicitud de extracción anticipadamente y
la utiliza para realizar un seguimiento de su progreso en la implementación de la función.

Fragmentos de código
También puede agregar fragmentos de código a los comentarios. Esto es especialmente
útil si desea presentar algo que podría intentar hacer antes de implementarlo realmente
como una confirmación en su sucursal. Esto también se usa a menudo para agregar
código de ejemplo de lo que no funciona o lo que podría implementar esta solicitud de
extracción.

Para agregar un fragmento de código, debe “cercarlo” en backticks.

```java

for(int i=0 ; i < 5 ; i++)

System.out.println("i is : " + i);

```

Si agrega un nombre de idioma como lo hicimos allí con Java , GitHub también intentará
resaltar la sintaxis del fragmento. En el caso del ejemplo anterior, terminaría
renderizándose como el ejemplo de código vallado renderizado. .

Figura 105. Ejemplo de código vallado renderizado.

Citando
Si está respondiendo a una pequeña parte de un comentario largo, puede citar
selectivamente el otro comentario precediendo las líneas con el >carácter. De hecho, esto
es tan común y tan útil que hay un atajo de teclado para ello. Si resalta el texto en un
comentario al que desea responder directamente y presiona la rtecla, lo citará en el
cuadro de comentarios.
Las citas se parecen a esto:

> Whether 'tis Nobler in the mind to suffer

> The Slings and Arrows of outrageous Fortune,

How big are these slings and in particular, these arrows?

Una vez procesado, el comentario se verá como un ejemplo de cita procesada . .

Figura 106. Ejemplo de cita representada.

Emoji
Finalmente, también puedes usar emoji en tus comentarios. En realidad, esto se usa
ampliamente en los comentarios que ves en muchos problemas de GitHub y solicitudes de
extracción. Incluso hay un ayudante de emoji en GitHub. Si está escribiendo un comentario
y comienza con un :personaje, un autocompletador lo ayudará a encontrar lo que está
buscando.
Figura 107. Autocompletador de Emoji en acción.

Los emojis toman la forma de :<name>:cualquier parte del comentario. Por ejemplo,
podrías escribir algo como esto:

I :eyes: that :bug: and I :cold_sweat:.

:trophy: for :microscope: it.

:+1: and :sparkles: on this :ship:, it's :fire::poop:!

:clap::tada::panda_face:

Cuando se procesa, se vería algo así como comentarios de emoji pesados. .

Figura 108. Comentarios emoji pesados.

No es que esto sea increíblemente útil, pero agrega un elemento de diversión y emoción a
un medio que de otro modo es difícil transmitir emoción.

En realidad, en la actualidad hay bastantes servicios web que utilizan

caracteres emoji. Puede encontrar una excelente hoja de referencia
para encontrar emojis que expresa lo que quiere decir en:
Nota
https://www.webfx.com/tools/emoji-cheat-sheet/
Imágenes
Esto no es técnicamente una reducción de sabor de GitHub, pero es increíblemente
útil. Además de agregar enlaces de imágenes de Markdown a los comentarios, que
pueden ser difíciles de encontrar e incrustar URL, GitHub le permite arrastrar y soltar
imágenes en áreas de texto para incrustarlas.

Figura 109. Arrastre y suelte imágenes para cargarlas e incrustarlas automáticamente.

Si observa Arrastrar y soltar imágenes para cargarlas e incrustarlas automáticamente. ,

puede ver una pequeña pista "Analizado como Markdown" encima del área de texto. Al
hacer clic en eso, obtendrá una hoja de trucos completa de todo lo que puede hacer con
Markdown en GitHub.

Mantenga actualizado su repositorio público de GitHub

Una vez que haya bifurcado un repositorio de GitHub, su repositorio (su "bifurcación")
existe independientemente del original. En particular, cuando el repositorio original tiene
nuevas confirmaciones, GitHub le informa mediante un mensaje como:

This branch is 5 commits behind progit:master.

Pero su repositorio de GitHub nunca será actualizado automáticamente por GitHub; Esto
es algo que debes hacer tú mismo. Afortunadamente, esto es muy fácil de hacer.

Una posibilidad para hacer esto no requiere configuración. Por ejemplo, si

bifurcaste https://github.com/progit/progit2.git, puedes mantener
tu mastersucursal actualizada así:

$ git checkout master (1)

$ git pull https://github.com/progit/progit2.git (2)

$ git push origin master (3)

1. Si estabas en otra rama, regresa a master.

2. Obtener cambios de https://github.com/progit/progit2.gity
fusionarlos en master.
3. Empuja tu masterrama hacia origin.
Esto funciona, pero es un poco tedioso tener que deletrear la URL de búsqueda cada
vez. Puede automatizar este trabajo con un poco de configuración:

$ git remote add progit https://github.com/progit/progit2.git (1)

$ git branch --set-upstream-to=progit/master master (2)

$ git config --local remote.pushDefault origin (3)

1. Agregue el repositorio de origen y asígnele un nombre. Aquí, he elegido

llamarlo progit.
2. Establezca su masterrama para buscar desde el progitcontrol remoto.
3. Defina el repositorio de inserción predeterminado en origin.
Una vez hecho esto, el flujo de trabajo se vuelve mucho más simple:

$ git checkout master (1)

$ git pull (2)

$ git push (3)

1. Si estabas en otra rama, regresa a master.

2. Obtener cambios progity fusionar cambios en master.
3. Empuja tu masterrama hacia origin.
Este enfoque puede ser útil, pero no está exento de inconvenientes. Git felizmente hará
este trabajo por usted en silencio, pero no le advertirá si se compromete master,
retira progity luego presiona origin : todas esas operaciones son válidas con esta
configuración. Por lo tanto, debe tener cuidado de no comprometerse
directamente master, ya que esa rama pertenece efectivamente al repositorio
ascendente.

6.3 GitHub: mantenimiento de un

proyecto
Manteniendo un proyecto
Ahora que nos sentimos cómodos contribuyendo a un proyecto, veamos el otro lado: crear,
mantener y administrar su propio proyecto.
Crear un nuevo repositorio
Creemos un nuevo repositorio para compartir nuestro código de proyecto. Comience
haciendo clic en el botón "Nuevo repositorio" en el lado derecho del tablero, o desde
el +botón en la barra de herramientas superior al lado de su nombre de usuario como se
ve en el menú desplegable "Nuevo repositorio". .

Figura 110. El área "Sus repositorios".

Figura 111. El menú desplegable "Nuevo repositorio".

Esto lo lleva al formulario "nuevo repositorio":

Figura 112. El formulario "nuevo repositorio".

Todo lo que realmente tiene que hacer aquí es proporcionar un nombre de proyecto; El
resto de los campos son completamente opcionales. Por ahora, simplemente haga clic en
el botón "Crear repositorio" y auge: tiene un nuevo repositorio en GitHub,
llamado <user>/<project_name>.
Como todavía no tiene código allí, GitHub le mostrará instrucciones sobre cómo crear un
nuevo repositorio de Git o conectar un proyecto Git existente. No vamos a decir esto
aquí; Si necesita un repaso, consulte Git Basics .

Ahora que su proyecto está alojado en GitHub, puede proporcionar la URL a cualquier
persona con la que desee compartir su proyecto. Se puede acceder a todos los proyectos
en GitHub a través de HTTPS
como https://github.com/<user>/<project_name>, y a través de SSH
como git@github.com:<user>/<project_name>. Git puede buscar y empujar a
ambas URL, pero están controladas por acceso en función de las credenciales del usuario
que se conecta a ellas.
A menudo es preferible compartir la URL basada en HTTPS para un
proyecto público, ya que el usuario no tiene que tener una cuenta de
GitHub para acceder a ella para clonarla. Los usuarios deberán tener
Nota una cuenta y una clave SSH cargada para acceder a su proyecto si
les proporciona la URL SSH. El HTTPS también es exactamente la
misma URL que pegarían en un navegador para ver el proyecto allí.

Agregar colaboradores
Si está trabajando con otras personas a las que desea otorgarles acceso de compromiso,
debe agregarlas como "colaboradores". Si Ben, Jeff y Louise se registran para obtener
cuentas en GitHub y desea darles acceso push a su repositorio, puede agregarlos a su
proyecto. Hacerlo les dará acceso "push", lo que significa que tienen acceso de lectura y
escritura al proyecto y al repositorio de Git.
Haga clic en el enlace "Configuración" en la parte inferior de la barra lateral derecha.

Figura 113. El enlace de configuración del repositorio.

Luego seleccione "Colaboradores" del menú en el lado izquierdo. Luego, simplemente

escriba un nombre de usuario en el cuadro y haga clic en "Agregar colaborador". Puede
repetir esto tantas veces como desee para otorgar acceso a todas las personas que
desee. Si necesita revocar el acceso, simplemente haga clic en la "X" en el lado derecho
de su fila.

Figura 114. Depósito de colaboradores.

Gestionar solicitudes de extracción

Ahora que tiene un proyecto con algún código y tal vez incluso algunos colaboradores que
también tienen acceso push, repasemos qué hacer cuando reciba una solicitud de
extracción usted mismo.

Las solicitudes de extracción pueden provenir de una rama en una bifurcación de su

repositorio o pueden provenir de otra rama en el mismo repositorio. La única diferencia es
que los que están en una bifurcación a menudo provienen de personas en las que no
puede empujar a su sucursal y no pueden empujar a la suya, mientras que con las
solicitudes de extracción internas generalmente ambas partes pueden acceder a la
sucursal.

Para estos ejemplos, supongamos que usted es "tonychacon" y ha creado un nuevo

proyecto de código Arduino llamado "fade".

Notificaciónes de Correo Electrónico

Alguien viene y hace un cambio en su código y le envía una solicitud de
extracción. Debería recibir un correo electrónico notificándole acerca de la nueva Solicitud
de extracción y debería ser similar a la notificación por correo electrónico de una nueva
Solicitud de extracción. .

Figura 115. Notificación por correo electrónico de una nueva solicitud de extracción.

Hay algunas cosas que notar sobre este correo electrónico. Le dará un pequeño diffstat:
una lista de archivos que han cambiado en la solicitud de extracción y en qué medida. Le
da un enlace a la solicitud de extracción en GitHub. También le proporciona algunas URL
que puede usar desde la línea de comandos.

Si observa la línea que dice git pull <url> patch-1, esta es una manera simple de
fusionarse en una rama remota sin tener que agregar un control remoto. Repasamos esto
rápidamente en Checking Out Remote Branches . Si lo desea, puede crear y cambiar a
una rama de tema y luego ejecutar este comando para fusionar los cambios de Solicitud
de extracción.
Las otras URL interesantes son las URL .diffy .patch, que, como puede suponer,
proporcionan versiones unificadas de diferencias y parches de la solicitud de
extracción. Técnicamente, podría fusionarse en el trabajo de Solicitud de extracción con
algo como esto:

$ curl https://github.com/tonychacon/fade/pull/1.patch | git am

Colaborando en la solicitud de extracción

Como cubrimos en The GitHub Flow , ahora puede tener una conversación con la persona
que abrió la solicitud de extracción. Puede comentar líneas de código específicas,
comentar confirmaciones completas o comentar toda la Solicitud de extracción en sí
misma, utilizando GitHub Flavored Markdown en todas partes.

Cada vez que alguien más comente sobre la Solicitud de extracción, continuará recibiendo
notificaciones por correo electrónico para que sepa que está ocurriendo una
actividad. Cada uno tendrá un enlace a la Solicitud de extracción donde está ocurriendo la
actividad y también puede responder directamente al correo electrónico para comentar
sobre el hilo de Solicitud de extracción.

Figura 116. Las respuestas a los correos electrónicos se incluyen en el hilo.

Una vez que el código está en un lugar que le gusta y desea fusionarlo, puede desplegar
el código hacia abajo y fusionarlo localmente, ya sea con la git pull <url>
<branch>sintaxis que vimos anteriormente, o agregando la bifurcación como control
remoto y buscando y fusionando.
Si la combinación es trivial, también puede presionar el botón "Combinar" en el sitio de
GitHub. Esto hará una fusión “sin avance rápido”, creando una confirmación de fusión
incluso si fuera posible una fusión con avance rápido. Esto significa que no importa qué,
cada vez que presiona el botón de fusión, se crea una confirmación de fusión. Como
puede ver en el botón Fusionar e instrucciones para fusionar una solicitud de extracción
manualmente. , GitHub le brinda toda esta información si hace clic en el enlace de pista.
Figura 117. Botón de combinación e instrucciones para combinar una solicitud de
extracción manualmente.

Si decide que no desea fusionarlo, también puede cerrar la Solicitud de extracción y se

notificará a la persona que la abrió.

Solicitudes de referencia de extracción

Si está lidiando con muchas solicitudes de extracción y no desea agregar un montón de
controles remotos o hacer extracciones únicas cada vez, hay un buen truco que GitHub le
permite hacer. Este es un truco un poco avanzado y revisaremos los detalles un poco más
en The Refspec , pero puede ser bastante útil.

GitHub en realidad anuncia las ramas de solicitud de extracción para un repositorio como
una especie de pseudo-ramas en el servidor. Por defecto, no los obtienes cuando clonas,
pero están allí de forma oculta y puedes acceder a ellos con bastante facilidad.

Para demostrar esto, vamos a utilizar un comando de bajo nivel (a menudo denominado
comando de "plomería", sobre el que leeremos más en Plomería y porcelana )
llamado ls-remote. Este comando generalmente no se usa en las operaciones diarias
de Git, pero es útil para mostrarnos qué referencias están presentes en el servidor.
Si ejecutamos este comando contra el repositorio "blink" que estábamos usando
anteriormente, obtendremos una lista de todas las ramas y etiquetas y otras referencias en
el repositorio.

$ git ls-remote https://github.com/schacon/blink

10d539600d86723087810ec636870a504f4fee4d HEAD

10d539600d86723087810ec636870a504f4fee4d refs/heads/master

6a83107c62950be9453aac297bb0193fd743cd6e refs/pull/1/head

afe83c2d1a70674c9505cc1d8b7d380d5e076ed3 refs/pull/1/merge
3c8d735ee16296c242be7a9742ebfbc2665adec1 refs/pull/2/head

15c9f4f80973a2758462ab2066b6ad9fe8dcf03d refs/pull/2/merge

a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head

31a45fc257e8433c8d8804e3e848cf61c9d3166c refs/pull/4/merge
Por supuesto, si está en su repositorio y ejecuta git ls-remote origino cualquier
control remoto que desee verificar, le mostrará algo similar a esto.
Si el repositorio está en GitHub y tiene solicitudes de extracción que se han abierto,
obtendrá estas referencias con el prefijo refs/pull/. Estas son básicamente ramas,
pero como no están debajo refs/heads/, no las obtiene normalmente cuando clona o
recupera del servidor; el proceso de recuperación las ignora normalmente.
Hay dos referencias por solicitud de extracción: la que termina en /headpuntos con
exactamente la misma confirmación que la última confirmación en la rama Solicitud de
extracción. Así que si alguien abre una solicitud de extracción en nuestro repositorio y su
rama se nombra bug-fixy apunta a comprometerse a5a775, a continuación,
en nuestro repositorio no vamos a tener una bug-fixrama (ya que está en su tenedor),
pero nos vamos a tener pull/<pr#>/headque apunta a a5a775. Esto significa que
podemos desplegar fácilmente todas las ramas de Solicitud de extracción de una vez sin
tener que agregar un montón de controles remotos.
Ahora, podría hacer algo como buscar la referencia directamente.

$ git fetch origin refs/pull/958/head

From https://github.com/libgit2/libgit2

* branch refs/pull/958/head -> FETCH_HEAD

Esto le dice a Git: "Conéctese al origincontrol remoto y descargue la referencia
nombrada refs/pull/958/head". Git felizmente obedece y descarga todo lo que
necesita para construir esa referencia, y coloca un puntero en la confirmación que
desea .git/FETCH_HEAD. Puede seguir eso con git merge FETCH_HEADuna rama en
la que desea probarlo, pero ese mensaje de confirmación de fusión parece un poco
extraño. Además, si está revisando muchas solicitudes de extracción, esto se vuelve
tedioso.
También hay una manera de obtener todas las solicitudes de extracción y mantenerlas
actualizadas cada vez que se conecta al control remoto. Abre .git/configtu editor
favorito y busca el origincontrol remoto. Debería verse un poco así:

[remote "origin"]

url = https://github.com/libgit2/libgit2

fetch = +refs/heads/*:refs/remotes/origin/*
Esa línea que comienza con fetch =una "especificación de referencia". Es una forma de
mapear nombres en el control remoto con nombres en su .gitdirectorio local . Este en
particular le dice a Git, "las cosas en el control remoto que están
debajo refs/headsdeben ir a mi repositorio local
debajo refs/remotes/origin". Puede modificar esta sección para agregar otra
especificación de referencia:

[remote "origin"]

url = https://github.com/libgit2/libgit2.git

fetch = +refs/heads/*:refs/remotes/origin/*

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Esa última línea le dice a Git: "Todas las referencias que

parecen refs/pull/123/headdeberían almacenarse localmente
como refs/remotes/origin/pr/123". Ahora, si guarda ese archivo y hace un git
fetch:

$ git fetch

# …

* [new ref] refs/pull/1/head -> origin/pr/1

* [new ref] refs/pull/2/head -> origin/pr/2

* [new ref] refs/pull/4/head -> origin/pr/4

# …

Ahora todas las solicitudes remotas de extracción están representadas localmente con
referencias que actúan de forma muy similar a las ramas de seguimiento; son de solo
lectura y se actualizan cuando haces una búsqueda. Esto hace que sea muy fácil probar el
código desde una solicitud de extracción localmente:

$ git checkout pr/2

Checking out files: 100% (3769/3769), done.

Branch pr/2 set up to track remote branch pr/2 from origin.

Switched to a new branch 'pr/2'

Los ojos de águila entre ustedes headnotarían el final de la parte remota de la
especificación de referencia. También hay una refs/pull/#/mergereferencia en el lado
de GitHub, que representa la confirmación que se obtendría si presiona el botón "fusionar"
en el sitio. Esto puede permitirle probar la fusión incluso antes de presionar el botón.
Solicitudes de extracción en Solicitudes de extracción
No solo puede abrir Solicitudes de extracción que se dirigen a la masterrama principal o
la sucursal, sino que también puede abrir una Solicitud de extracción dirigida a cualquier
sucursal de la red. De hecho, incluso puede apuntar a otra solicitud de extracción.
Si ve una solicitud de extracción que se mueve en la dirección correcta y tiene una idea
para un cambio que depende de ella o no está seguro de que sea una buena idea, o
simplemente no tiene acceso directo a la rama de destino, puede abrir una solicitud de
extracción directamente a ella.

Cuando va a abrir una Solicitud de extracción, hay un cuadro en la parte superior de la

página que especifica de qué rama solicita la extracción y de la que solicita la
extracción. Si presiona el botón "Editar" a la derecha de ese cuadro, puede cambiar no
solo las ramas sino también qué bifurcación.

Figura 118. Cambie manualmente la bifurcación y la bifurcación de destino de Solicitud de

extracción.

Aquí puede especificar con bastante facilidad para fusionar su nueva sucursal en otra
solicitud de extracción u otra bifurcación del proyecto.

Menciones y Notificaciones
GitHub también tiene un sistema de notificaciones bastante agradable incorporado que
puede ser útil cuando tiene preguntas o necesita comentarios de personas o equipos
específicos.

En cualquier comentario, puede comenzar a escribir un @carácter y comenzará a

completarse automáticamente con los nombres y nombres de usuario de las personas que
son colaboradores o contribuyentes en el proyecto.
Figura 119. Comience a escribir @ para mencionar a alguien.

También puede mencionar a un usuario que no está en ese menú desplegable, pero a
menudo el autocompletador puede hacerlo más rápido.

Una vez que publique un comentario con una mención de usuario, ese usuario será
notificado. Esto significa que esta puede ser una forma realmente efectiva de atraer a las
personas a conversaciones en lugar de hacerlas sondear. Muy a menudo, en las
solicitudes de extracción en GitHub, las personas atraen a otras personas en sus equipos
o en su empresa para revisar un problema o una solicitud de extracción.

Si alguien se menciona en una Solicitud o Problema de extracción, se le "suscribirá" y

continuará recibiendo notificaciones cada vez que ocurra alguna actividad en él. También
estará suscrito a algo si lo abrió, si está viendo el repositorio o si comenta algo. Si ya no
desea recibir notificaciones, hay un botón "Cancelar suscripción" en la página en el que
puede hacer clic para dejar de recibir actualizaciones.
Figura 120. Darse de baja de un problema o solicitud de extracción.

La página de notificaciones
Cuando mencionamos "notificaciones" aquí con respecto a GitHub, nos referimos a una
forma específica en que GitHub intenta ponerse en contacto con usted cuando ocurren
eventos y hay algunas formas diferentes de configurarlos. Si va a la pestaña "Centro de
notificaciones" desde la página de configuración, puede ver algunas de las opciones que
tiene.

Figura 121. Opciones del centro de notificaciones.

Las dos opciones son recibir notificaciones a través de "Correo electrónico" y "Web" y
puede elegir uno, ninguno o ambos para cuando participe activamente en las cosas y para
la actividad en los repositorios que está viendo.

NOTIFICACIONES WEB
Las notificaciones web solo existen en GitHub y solo puede verificarlas en GitHub. Si tiene
esta opción seleccionada en sus preferencias y se activa una notificación para usted, verá
un pequeño punto azul sobre el icono de notificaciones en la parte superior de la pantalla
como se ve en el Centro de notificaciones. .
Figura 122. Centro de notificaciones.

Si hace clic en eso, verá una lista de todos los elementos sobre los que ha sido notificado,
agrupados por proyecto. Puede filtrar las notificaciones de un proyecto específico haciendo
clic en su nombre en la barra lateral izquierda. También puede confirmar la notificación
haciendo clic en el ícono de la marca de verificación junto a cualquier notificación, o
reconocer todas las notificaciones en un proyecto haciendo clic en la marca de verificación
en la parte superior del grupo. También hay un botón de silencio al lado de cada marca de
verificación en el que puede hacer clic para no recibir más notificaciones sobre ese
elemento.

Todas estas herramientas son muy útiles para manejar grandes cantidades de
notificaciones. Muchos usuarios avanzados de GitHub simplemente desactivarán por
completo las notificaciones por correo electrónico y administrarán todas sus notificaciones
a través de esta pantalla.

NOTIFICACIÓNES DE CORREO ELECTRÓNICO

Las notificaciones por correo electrónico son la otra forma en que puede manejar las
notificaciones a través de GitHub. Si tiene esto activado, recibirá correos electrónicos para
cada notificación. Vimos ejemplos de esto en los comentarios enviados como
notificaciones por correo electrónico y notificación por correo electrónico de una nueva
solicitud de extracción. . Los correos electrónicos también se enviarán correctamente, lo
cual es bueno si está utilizando un cliente de correo electrónico de subprocesos.

También hay una buena cantidad de metadatos incrustados en los encabezados de los
correos electrónicos que GitHub le envía, lo que puede ser realmente útil para configurar
filtros y reglas personalizados.

Por ejemplo, si miramos los encabezados de correo electrónico reales enviados a Tony en
el correo electrónico que se muestra en la notificación por correo electrónico de una nueva
solicitud de extracción. , veremos lo siguiente entre la información enviada:
To: tonychacon/fade <fade@noreply.github.com>

Message-ID: <tonychacon/fade/pull/1@github.com>

Subject: [fade] Wait longer to see the dimming effect better (#1)

X-GitHub-Recipient: tonychacon

List-ID: tonychacon/fade <fade.tonychacon.github.com>

List-Archive: https://github.com/tonychacon/fade

List-Post: <mailto:reply+i-4XXX@reply.github.com>

List-Unsubscribe: <mailto:unsub+i-XXX@reply.github.com>,...

X-GitHub-Recipient-Address: tchacon@example.com

Hay un par de cosas interesantes aquí. Si desea resaltar o redirigir correos electrónicos a
este proyecto en particular o incluso Solicitud de extracción, la información Message-IDle
brinda todos los datos en <user>/<project>/<type>/<id>formato. Si esto fuera un
problema, por ejemplo, el <type>campo habría sido "problemas" en lugar de "pull".
Los campos List-Posty List-Unsubscribesignifican que si tiene un cliente de correo
que los comprende, puede publicar fácilmente en la lista o "Cancelar suscripción" del
hilo. Eso sería esencialmente lo mismo que hacer clic en el botón "silenciar" en la versión
web de la notificación o "Cancelar suscripción" en la página de emisión o solicitud de
extracción.
También vale la pena señalar que si tiene habilitadas las notificaciones web y de correo
electrónico y lee la versión de correo electrónico de la notificación, la versión web se
marcará como leída también si tiene imágenes permitidas en su cliente de correo.

Archivos especiales
Hay un par de archivos especiales que GitHub notará si están presentes en su repositorio.

LÉAME
El primero es el READMEarchivo, que puede tener casi cualquier formato que GitHub
reconozca como prosa. Por ejemplo, podría
ser README, README.md, README.asciidoc, etc. Si GitHub ve un archivo README en
su fuente, se las puede hacer en la página de destino del proyecto.
Muchos equipos usan este archivo para almacenar toda la información relevante del
proyecto para alguien que pueda ser nuevo en el repositorio o proyecto. Esto
generalmente incluye cosas como:
 Para qué sirve el proyecto

 Cómo configurarlo e instalarlo

 Un ejemplo de cómo usarlo o ponerlo en funcionamiento

  La licencia bajo la cual se ofrece el proyecto

 Cómo contribuir a ello

Dado que GitHub representará este archivo, puede incrustar imágenes o enlaces en él
para una mayor facilidad de comprensión.

CONTRIBUYENDO
El otro archivo especial que GitHub reconoce es el CONTRIBUTINGarchivo. Si tiene un
archivo CONTRIBUTINGcon una extensión de archivo, GitHub mostrará Abrir una solicitud
de extracción cuando exista un archivo CONTRIBUYENTE. cuando alguien comienza a
abrir una solicitud de extracción.

Figura 123. Abrir una solicitud de extracción cuando existe un archivo CONTRIBUYENTE.

La idea aquí es que puede especificar cosas específicas que desea o no desea en una
solicitud de extracción enviada a su proyecto. De esta manera, las personas pueden leer
las pautas antes de abrir la solicitud de extracción.

Administración de proyecto
Por lo general, no hay muchas cosas administrativas que puede hacer con un solo
proyecto, pero hay algunos elementos que pueden ser de interés.

Cambiar la rama predeterminada

Si está utilizando una rama distinta a "maestra" como su rama predeterminada en la que
desea que las personas abran Solicitudes de extracción o las vean de manera
predeterminada, puede cambiar eso en la página de configuración de su repositorio en la
pestaña "Opciones".
Figura 124. Cambie la rama predeterminada para un proyecto.

Simplemente cambie la rama predeterminada en el menú desplegable y esa será la

predeterminada para todas las operaciones principales a partir de ese momento, incluida
qué rama se desprotege de manera predeterminada cuando alguien clona el repositorio.

Transfiriendo un proyecto
Si desea transferir un proyecto a otro usuario u organización en GitHub, hay una opción de
"Transferir propiedad" en la parte inferior de la misma pestaña "Opciones" de la página de
configuración del repositorio que le permite hacer esto.

Figura 125. Transfiera un proyecto a otro usuario u organización de GitHub.

Esto es útil si está abandonando un proyecto y alguien quiere asumirlo, o si su proyecto se

está haciendo más grande y quiere trasladarlo a una organización.

Esto no solo mueve el repositorio junto con todos sus observadores y estrellas a otro lugar,
sino que también configura una redirección desde su URL al nuevo lugar. También
redirigirá clones y recuperaciones de Git, no solo solicitudes web.

6.4 GitHub: gestión de una

organización
Administrar una organización
Además de las cuentas de usuario único, GitHub tiene lo que se llama Organizaciones. Al
igual que las cuentas personales, las cuentas organizacionales tienen un espacio de
nombres donde existen todos sus proyectos, pero muchas otras cosas son
diferentes. Estas cuentas representan un grupo de personas con propiedad compartida de
proyectos, y existen muchas herramientas para administrar subgrupos de esas
personas. Normalmente, estas cuentas se utilizan para grupos de código abierto (como
"perl" o "rails") o empresas (como "google" o "twitter").

Conceptos básicos de la organización

Una organización es bastante fácil de crear; simplemente haga clic en el icono "+" en la
esquina superior derecha de cualquier página de GitHub y seleccione "Nueva
organización" en el menú.

Figura 126. El elemento del menú "Nueva organización".

Primero deberá nombrar su organización y proporcionar una dirección de correo
electrónico para un punto de contacto principal para el grupo. Luego puede invitar a otros
usuarios a ser copropietarios de la cuenta si así lo desea.

Siga estos pasos y pronto será el propietario de una organización completamente

nueva. Al igual que las cuentas personales, las organizaciones son gratuitas si todo lo que
planea almacenar allí será de código abierto.

Como propietario de una organización, cuando bifurca un repositorio, tendrá la opción de

bifurcarlo en el espacio de nombres de su organización. Cuando crea nuevos repositorios,
puede crearlos en su cuenta personal o en cualquiera de las organizaciones de las que es
propietario. También "observa" automáticamente cualquier nuevo repositorio creado en
estas organizaciones.

Al igual que en Tu avatar , puedes subir un avatar para que tu organización lo personalice
un poco. También, al igual que las cuentas personales, tiene una página de destino para la
organización que enumera todos sus repositorios y puede ser vista por otras personas.

Ahora cubramos algunas de las cosas que son un poco diferentes con una cuenta de
organización.
Equipos
Las organizaciones se asocian con personas individuales por medio de equipos, que son
simplemente una agrupación de cuentas de usuarios individuales y depósitos dentro de la
organización y qué tipo de acceso tienen esas personas en esos depósitos.

Por ejemplo, supongamos que su empresa cuenta con tres

repositorios: frontend, backend, y deployscripts. Desearía que sus desarrolladores
de HTML / CSS / JavaScript tengan acceso a, frontendy tal vez backend, y que su
personal de Operaciones tenga acceso a backendy deployscripts. Los equipos lo
hacen fácil, sin tener que administrar a los colaboradores para cada repositorio individual.
La página Organización le muestra un panel simple de todos los repositorios, usuarios y
equipos que están bajo esta organización.

Figura 127. La página Organización.

Para administrar sus equipos, puede hacer clic en la barra lateral de equipos en el lado
derecho de la página en la página de la organización. . Esto lo llevará a una página que
puede usar para agregar miembros al equipo, agregar repositorios al equipo o administrar
la configuración y los niveles de control de acceso para el equipo. Cada equipo puede
tener acceso de solo lectura, lectura / escritura o administrativo a los repositorios. Puede
cambiar ese nivel haciendo clic en el botón "Configuración" en la página del equipo. .
Figura 128. La página del equipo.
Cuando invita a alguien a un equipo, recibirá un correo electrónico informándole que ha
sido invitado.

Además, el equipo @mentions(como @acmecorp/frontend) funciona de la misma

manera que lo hace con usuarios individuales, excepto que todos los miembros del
equipo se suscriben al hilo. Esto es útil si desea la atención de alguien en un equipo, pero
no sabe exactamente a quién preguntar.
Un usuario puede pertenecer a cualquier número de equipos, así que no se limite a solo
equipos de control de acceso. A los equipos con intereses especiales les
gusta ux, csso refactoringson útiles para ciertos tipos de preguntas, y a otros les
gusta legaly colorblindpara un tipo completamente diferente.

Registro de auditoría
Las organizaciones también dan a los propietarios acceso a toda la información sobre lo
que sucedió bajo la organización. Puede ir a la pestaña Registro de auditoría y ver qué
eventos han sucedido a nivel de organización, quién los realizó y en qué lugar del mundo
se realizaron.
Figura 129. El registro de auditoría.
También puede filtrar a tipos específicos de eventos, lugares específicos o personas
específicas.