diferencia entre tenedor y rama en github

Si bifurco un proyecto que está alojado en github. ¿Bifurco todas las ramas? ¿Cómo sé en qué rama se basa mi bifurcación? En otras palabras, ¿qué rama se descargará a mi PC?

Todas las ramas en GitHub se copiarán en una bifurcación. (Obviamente, esto no incluye ramas que nunca se enviaron a GitHub en primer lugar).

Pero una bifurcación es una operación de GitHub a GitHub; nada se copia a su PC. No es lo mismo que un clon de Git . Si quiere preguntar "¿qué se copia cuando clono un proyecto?", Consulte el manual correspondiente git-clone(1).

Piénsalo de esta manera:

El repositorio [sitory] corresponde al trabajo colaborativo del equipo en una o varias ramas. Todos los contribuyentes tienen su propia copia.

Cada tenedor del repositorio principal corresponde al trabajo de un contribuyente. Una bifurcación es realmente una construcción Github (no Git) para almacenar un clon del repositorio en su cuenta de usuario. Como clon, contendrá todas las ramas en el repositorio principal en el momento en que hizo el tenedor.

Cada rama dentro de la bifurcación y / o en el repositorio principal puede corresponder a varios tipos de cosas, dependiendo de cómo desee trabajar. Cada rama podría referirse a una versión del proyecto, pero también puede corresponder a diferentes canales de desarrollo, como revisiones o trabajos experimentales.

La solicitud de extracción (en el ecosistema de GitHub) corresponde a la tarea. Cada vez que quiero contribuir con una tarea final aislada al repositorio principal, creo una solicitud de extracción correspondiente a las confirmaciones realizadas en esa tarea. Estas confirmaciones se extraen de mi bifurcación o de mi rama al repositorio principal .

Una confirmación es un conjunto de cambios en el código. Esta es una de las cosas más interesantes de Git. No transfieres archivos, transfieres registros de cambios.

Fork es un clon en el lado de GitHub (clona todo).
Cuando clona un repositorio, obtiene toda la historia de dicho repositorio, con todas sus ramas.

Aunque en teoría puede cambiar la rama predeterminada de un repositorio remoto , un clon de un repositorio de GitHub busca principalmente la rama maestra. Es decir, para cambiar la rama "predeterminada" que obtendrá un clon de GitHub, debe cambiar el nombre de la rama maestra.

Si bifurcas un proyecto, estás haciendo una copia de todo el proyecto en tu cuenta de git hub. no estás haciendo nada con tu PC

Para hacer una copia en su PC, debe clonarla y extraer todas las cosas y obtendrá todas las ramas y el código de ese proyecto

Si crea una bifurcación de un proyecto desde el sitio web de Github, obtendrá todas las ramas del proyecto ascendente.

Si clona desde su bifurcación recién acuñada a su PC local, tendrá el origincontrol remoto en su PC apuntando a la rama maestra de su bifurcación en Github.

Esto se puede explicar muy bien. Tienes un repositorio central en GitHub. Cada vez que tomas un clon en tu computadora personal para hacer algunos cambios, este clon local del repositorio principal se llama fork.

La rama es algo diferente y se incluye en el tenedor / repositorio. En realidad, la rama es su trabajo en diferentes etapas de desarrollo. Se crean cuando sea necesario para guardar un conjunto de funcionalidades, dar acceso a diferentes usuarios, mostrar el sitio al cliente, etc.

Me gustaría compartir un ejemplo de la vida real de cuando usamos Branches y cuando usamos Forks

Tenemos GitLab en nuestra tienda y, a veces, tenemos que trabajar en paquetes de un proyecto de Laravel. Normalmente creamos una rama y enviamos cambios a la rama que hemos estado probando en nuestro entorno de desarrollo de VM local cuando trabajamos con el proyecto real de Laravel.

Digamos que nuestro proyecto se encuentra en

https://github.com/yardpenalty/mainproject.git

Uso de sucursal:

Digamos que la rama se llama It_doesnt_matter

Una vez que tenemos nuestra sucursal de la manera que deseamos para la producción, hacemos nuestro último empuje hacia esta sucursal y creamos una solicitud de fusión que luego pasa a UAT para la prueba. Una vez que la prueba ha pasado por el control de calidad, los cambios se fusionan en la producción.

La fusión de la It_doesnt_matter rama ahora se transfiere al proyecto maestro

a https://github.com/yardpenalty/mainproject.git

Digamos que el proyecto del paquete se encuentra en

https://github.com/yardpenalty/mypackage.git

Tenga en cuenta que el proyecto principal usa este paquete en producción, por lo que no podemos hacer cambios simplemente empujándolos a este paquete (entre otras razones). Digamos que un desarrollador web tiene que editar este paquete para hacer cambios en la producción.

Una rama simple tampoco funcionará porque no podemos ver nuestros cambios sin publicar el paquete, etc.

Uso de la horquilla: ahora es cuando tenemos que hacer un poco de truco con nuestro paquete para crear un clon del paquete de producción a través de una horquilla. Los archivos composer.json se pueden actualizar para apuntar a la bifurcación que ahora se encuentra en una ruta de usuario o grupo

Entonces crearemos un tenedor en https://github.com/yardpenalty/mypackage.git

y llámalo https://github.com/yardpenalty/yards/mypackage.git

Ahora podemos actualizar nuestro archivo composer.json para apuntar a este paquete en nuestros "repositorios": [matriz como tal y ¡listo!

 {
            "type": "github",
            "url": "https://github.com/yardpenalty/yard/mypackage.git"
 }

]