Introducción a Git

1

¿Por qué usar un sistema de control de versiones como Git?

2

¿Qué es Git?

3

Instalando GitBash en Windows

4

Instalando Git en OSX

5

Instalando Git en Linux

6

Editores de código, archivos binarios y de texto plano

7

Introducción a la terminal y línea de comandos

Comandos básicos en Git

8

Crea un repositorio de Git y haz tu primer commit

9

Analizar cambios en los archivos de tu proyecto con Git

10

¿Qué es el staging?

11

¿Qué es branch (rama) y cómo funciona un Merge en Git?

12

Volver en el tiempo en nuestro repositorio utilizando reset y checkout

13

Git reset vs. Git rm

Flujo de trabajo básico en Git

14

Flujo de trabajo básico con un repositorio remoto

15

Introducción a las ramas o branches de Git

16

Fusión de ramas con Git merge

17

Resolución de conflictos al hacer un merge

Trabajando con repositorios remotos en GitHub

18

Cómo funcionan las llaves públicas y privadas

19

Configura tus llaves SSH en local

20

Uso de GitHub

21

Cambios en GitHub: de master a main

22

Tu primer push

23

Git tag y versiones en Github

24

Manejo de ramas en GitHub

25

Configurar múltiples colaboradores en un repositorio de GitHub

Flujos de trabajo profesionales

26

Flujo de trabajo profesional: Haciendo merge de ramas de desarrollo a master

27

Flujo de trabajo profesional con Pull requests

28

Utilizando Pull Requests en GitHub

29

Creando un Fork, contribuyendo a un repositorio

30

Haciendo deployment a un servidor

31

Hazme un pull request

32

Ignorar archivos en el repositorio con .gitignore

33

Readme.md es una excelente práctica

34

Tu sitio web público con GitHub Pages

Multiples entornos de trabajo en Git

35

Git Rebase: reorganizando el trabajo realizado

36

Cómo usar Git Stash: guarda cambios temporalmente

37

Git Clean: limpiar tu proyecto de archivos no deseados

38

Git cherry-pick: traer commits antiguos al head del branch

Comandos de Git para casos de emergencia

39

Git Reset y Reflog: úsese en caso de emergencia

40

Reconstruir commits en Git con amend

41

Buscar en archivos y commits de Git con Grep y log

Bonus sobre Git y Github

42

Comandos y recursos colaborativos en Git y GitHub

43

Tu futuro con Git y GitHub

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Creando un Fork, contribuyendo a un repositorio

29/43
Recursos

Los forks o bifurcaciones son una característica única de GitHub en la que se crea una copia exacta del estado actual de un repositorio directamente en GitHub. Este repositorio podrá servir como otro origen y se podrá clonar (como cualquier otro repositorio). En pocas palabras, lo podremos utilizar como un nuevo repositorio git cualquiera

Un fork es como una bifurcación del repositorio completo. Comparte una historia en común con el original, pero de repente se bifurca y pueden aparecer varios cambios, ya que ambos proyectos podrán ser modificados en paralelo y para estar al día un colaborador tendrá que estar actualizando su fork con la información del original.

Al hacer un fork de un poryecto en GitHub, te conviertes en dueñ@ del repositorio fork, puedes trabajar en este con todos los permisos, pero es un repositorio completamente diferente que el original, teniendo solamente alguna historia en común (como crédito al creado o creadora original).

Los forks son importantes porque es la manera en la que funciona el open source, ya que, una persona puede no ser colaborador de un proyecto, pero puede contribuír al mismo, haciendo mejor software que pueda ser utilizado por cualquiera.

Cómo se hace un fork remoto desde consola en GitHub

Al hacer un fork, GitHub sabe que se hizo el fork del proyecto, por lo que se le permite al colaborador hacer pull request desde su repositorio propio.

Cuando trabajas en un proyecto que existe en diferentes repositorios remotos (normalmente a causa de un fork), es muy probable que desees poder trabajar con ambos repositorios. Para esto, puedes generar un remoto adicional desde consola.

git remote add <nombre_del_remoto> <url_del_remoto> 
git remote upstream https://github.com/freddier/hyperblog

Al crear un remoto adicional, podremos hacer pull desde el nuevo origen. En caso de tener permisos, podremos hacer fetch y push.

git pull <remoto> <rama>
git pull upstream master

Este pull nos traerá los cambios del remoto, por lo que se estará al día en el proyecto. El flujo de trabajo cambia, en adelante se estará trabajando haciendo pull desde el upstream y push al origin para pasar a hacer pull request.

git pull upstream master
git push origin master

Aporte creado por: David Behar

Aportes 423

Preguntas 111

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Forks o Bifurcaciones

Es una característica única de GitHub en la que se crea una copia exacta del estado actual de un repositorio directamente en GitHub, éste repositorio podrá servir como otro origen y se podrá clonar (como cualquier otro repositorio), en pocas palabras, lo podremos utilizar como un git cualquiera
.
Un fork es como una bifurcación del repositorio completo, tiene una historia en común, pero de repente se bifurca y pueden variar los cambios, ya que ambos proyectos podrán ser modificados en paralelo y para estar al día un colaborador tendrá que estar actualizando su fork con la información del original.
.
Al hacer un fork de un poryecto en GitHub, te conviertes en dueñ@ del repositorio fork, puedes trabajar en éste con todos los permisos, pero es un repositorio completamente diferente que el original, teniendo alguna historia en común.
.
Los forks son importantes porque es la manera en la que funciona el open source, ya que, una persona puede no ser colaborador de un proyecto, pero puede contribuír al mismo, haciendo mejor software que pueda ser utilizado por cualquiera.
.
Al hacer un fork, GitHub sabe que se hizo el fork del proyecto, por lo que se le permite al colaborador hacer pull request desde su repositorio propio.

Trabajando con más de 1 repositorio remoto

Cuando trabajas en un proyecto que existe en diferentes repositorios remotos (normalmente a causa de un fork) es muy probable que desees poder trabajar con ambos repositorios, para ésto puedes crear un remoto adicional desde consola.

git remote add <nombre_del_remoto> <url_del_remoto> 
git remote upstream https://github.com/freddier/hyperblog

Al crear un remoto adicional podremos, hacer pull desde el nuevo origen (en caso de tener permisos podremos hacer fetch y push)

git pull <remoto> <rama>
git pull upstream master

Éste pull nos traerá los cambios del remoto, por lo que se estará al día en el proyecto, el flujo de trabajo cambia, en adelante se estará trabajando haciendo pull desde el upstream y push al origin para pasar a hacer pull request.

git pull upstream master
git push origin master

**Apuntes! **✌🏼

Pobre anita! paso de trabajar por un sueldo a ser despedida para trabajar como una colaboradora…
Señor Freddy

P.D: Excelente clase!

Solo para resaltar algo de este video, despues de hacer el clone podemos tratar de consultar las ramas que se descargaron al repositorio local con “git branch” y nos damos cuenta que solo aparece la rama master. pero y entonces… ¿que pasó con las otras ramas?

Solución: Si hacemos un “git branch --all” vamos a ver todas las ramas tanto locales como remotas y basta con cambiar de rama, por ejemplo con: “git checkout cabecera” y automaticamente se crea una copia de esta rama en el repositorio local.

Para confirmarlo haces nuevamente un “git branch” y veran que ahora si aparacen la rama master y la rama cabecera.

Adiós Anita, siempre te recordaremos…

Pero que gran explicación!!!
.
Para subir cambios al repositorio original:
.

  1. Ubicar el repositorio del proyecto open source con el cual quiero colaborar.
    • Watch → Watching
    • Star
    • Fork: Tomar una copia del estado actual del proyecto y clonarlo, y queda como un proyecto mio.
  2. Clonamos el repositorio en nuestro local.
  3. Realizamos los cambios necesarios.
  4. New Pull Request.

.

Para traer cambios del repositorio original:
.

  1. Crear una nueva fuente para traer esos cambios:

    git remote -v
    git remote add upstream [original_repository_url]
    git remote -v
    git pull upstream master

  2. Actualizar nuestro repositorio en Github

    git push origin master

*******************
****Iniciar Git****
*******************

git int

*******************
****Iniciar Git****
*******************

**********************************
*******Configuración de Git*******
**********************************

git config
git config --list
git config --list --show origin
git config --list --show-origin
git config --global
git config --global user.name "SC"
git config --global user.email "[email protected]"

**********************************
*******Configuración de Git*******
**********************************

********************************************
******Agragar a la zona de preparación******
********************************************

git add Archivo.txt

git add .

********************************************
******Agragar a la zona de preparación******
********************************************

****************************
*********Ver estado*********
****************************

git status

****************************
*********Ver estado*********
****************************

***************************************************************************
*****************Quitar de la zona de preparación**************************
***************************************************************************

git rm --cached archivo.txt (Quitar de la zona de preparación).

***************************************************************************
*****************Quitar de la zona de preparación**************************
***************************************************************************

************************************************************
**********************Realizar commint**********************
************************************************************

git commit -m "Este es el pimer commit de este archivo"
git commit -am "Este es el pimer commit de este archivo"

************************************************************
**********************Realizar commint**********************
************************************************************

*****************************************************
*******Ver el historial de cambios del archivo*******
*****************************************************

git log
git log Archivo.txt

*****************************************************
*******Ver el historial de cambios del archivo*******
*****************************************************

***************************************************************
************Muestra todos los cambios sobre un archivo*********
***************************************************************

git show Archivo.txt

***************************************************************
************Muestra todos los cambios sobre un archivo*********
***************************************************************

**************************************
**********Comparar versiones**********
**************************************

git diff commint commint

**************************************
**********Comparar versiones**********
**************************************

*****************************************************************************
************************Volver a una versión anterior************************
*****************************************************************************

git reset commit --hard (borramos todos los cambios y lo que tengamos en staging) 

git reset commit --soft (soft conservamos cambios y lo que tengamos en staging) 

git checkout (commit) Archivo.txt

git checkout (rama) Archivo.txt
*****************************************************************************
************************Volver a una versión anterior************************
*****************************************************************************

****************************************************************************
**************************Ver Cambio en bytes*******************************
****************************************************************************

git log --stat(Cambio en bytes)

****************************************************************************
**************************Ver Cambio en bytes*******************************
****************************************************************************

***************************************************************************
****************************Crear una rama*********************************
***************************************************************************

git branch (branchName)

***************************************************************************
****************************Crear una rama*********************************
***************************************************************************


***************************************************************************
**************************Cambiar de rama**********************************
***************************************************************************

git checkout (branchName)

***************************************************************************
**************************Cambiar de rama**********************************
***************************************************************************

*******************************************************************
************************Merge entre branchs************************
*******************************************************************

git merge (branchName)

**Estar en la rama master o en la que se quiere dejar el <Head>**
*******************************************************************
************************Merge entre branchs************************
*******************************************************************

****************************************************
************Traer un repositorio externo************
****************************************************

git remote add origin (url)
git remote (muestra el origen)
git remote -v(es verval)

git pull origin master --allow-unrelated-histories (Fuerza la union de las diferentes historias)

git pull origin master (Descarga cambios)

git push (origin) (master) (Sube Cambios)
****************************************************
************Traer un repositorio externo************
****************************************************

*************************************
**************Seguridad**************
*************************************

ssh-keygen -t rsa -b 4096 -C "[email protected]" (crea la llave publica y privada)
eval $(ssh-agent -s) (saber si el agente ssh esta ejecuntando)
ssh-add ~/.ssh/id_rsa (agregar la llave privada)

git remote set-url origin git@github.com:gsuscastellanosSC/hyperblog.git (cambiar url para que sea con ssh)


*************************************
**************Seguridad**************
*************************************

**********************************
***************TAGS***************
**********************************

git log --all(Muesta toda la historia)
git log --all --graph (Muestra toda la historia con la ineracción de las ramas)
git log --all --graph --decorate --oneline
alias arbolito="git log --all --graph --decorate --oneline"(forma de alias en linux)

git tag -a v0.1 -m "apendiendo tags en git" (hash del commit) (crear un tag)
git show-ref --tags

git push origin --tags (enviar los tags al repositorio remoto)
git tag -d v0.1   && $ git push origin :refs/tags/v0.1 (Borrar tags)


**********************************
***************TAGS***************
**********************************

************************
********ramas***********
************************

git show-branch --all (¿Cuales branch existen y sus historias)
gitk (igual que la anterior per con gui)
git push origin :[nombre_branch] (Elimina rama remota)


************************
********ramas***********
************************

************************
***Crear fuente nueva***
************************

git remote add upstream (url-github)
git pull upstream master (trae todos los cabios de master del origen upstream)

************************
***Crear fuente nueva***
************************

F por Anita 😭

Apuntes 😪🥴

F por Anita

Para hacer una contribución a un proyecto de Github hay que seguir los siguientes pasos:

  1. Darle al botón de Fork en Github
  2. Hacer los cambios y darle push a ellos en mi repositorio
  3. Hacer un pull request con mis cambios en alguna de las ramas del proyecto original y esperar
  4. Una vez aprueben o rechacen mis cambios seré notificado en la cuenta de github

Pero también pasa algo muy interesante y es que cuando yo he hecho un fork, el proyecto original sigue avanzando y el mio se va quedando atras, así que para traer los cambios del proyecto original eso se hace de la siguiente manera:

  1. Crear una nueva fuente para hacer pull desde el repositorio forkeado. Por ejemplo:
    git remote add upstream [email protected]:freddier/hyperblog.git
    Nota: la palabra upstream es opcional pero es lo que normalmente se usa en la industria.
  2. Verificamos que hay una nueva fuente de datos con
    git remote -v
  3. Hacer pull de upstream/master
    git pull upstream master
  4. Hacer un commit para fusionar los cambios que hemos traído
    git commit -am “Fusion”
  5. Hacer un push para mandar los cambios a nuestro repositorio original
    git push origin master
1 Segundo de silencio por Ana... Gracias```



Anita en estos momentos…

Todos los pasos del video aqui:
Sacamos a anita del proyecto (ya no tiene permisos de merge, push solo puede clonarlo).

Desde la cuenta de anita abrimos el proyecto, le damos watch(podemos ver conversaciones), estrellita (indicador de que este proyecto me gusta, me llegan avisos cuando algo cambia),y un fork es tomar una copia a nuestros repositorios (https://geeksroom.com/2014/05/que-es-un-fork-y-como-trabajar-en-github/85588/)
PARA HACER CAMBIOS DESDE LA CUENTA DE ANITA, HAY QUE TRAERNOSLO A NUESTRO PROPIO REPOSITORIO LOCAL.
Anita: $ git clone url_delRepoRemoto_de anita(el fork)
Modifico los errores ortográficos con entidades HTML y un commit ($git commit –am “Tildes con entidades y mensaje de contribución”) y $git push
PARA PODER CREAR ESE PULL REQUEST (HACER UN MERGE) ENTRE UN PROYECTO Y OTRO
Le damos en new pull request nos abre esta interfaz y nos dice (Elija dos ramas para ver qué ha cambiado y empezar un nuevo pull request. Si lo necesita, también puede comparar los diferentes forks.)
Seleccionamos de derecha a izquierda (compare:master – mi master de mi repo) a base: master del repo original. Mas abajo vemos los cambios realizados.
Luego le damos en créate pull request y lo enviamos. Ahora toca esperar a que realicen estos cambios.

VAMOS A MI CUENTA:
Vemos que anita quiere fisionar un commit de su rama master a mi rama master.
Lo único que tenemos que preocuparnos es de cuales son los cambios.
Los aprobamos los cambios y le decimos OK y le damos Merge pull request(confirmo el merge).
Y vemos los cambios que ella hizo y si le damos a commits también puedo ver los commits que anita realizo

ANITA EN ESTE MOMENTO TIENE UN FORK, LO QUE SIGNIFICA QUE SI YO HAGO CAMBIOS ANITA DEBE DE TRAERSELOS EN SU PROPIO FORK, PORQUE SE VA QUEDANDO ATRÁS.
Realizamos cambios al archivo original desde Willy (al title).
Nos traemos los cambios de anita con $git pull origin master. Nos lanza un error que dice tus cambios locales de tus siguientes archivos van a ser resuscritos por el merge (blogpost.html) no importa que este modificado el archivo.
Realizamos el commit ($ git commit -am "Cambio de titulo“) para que los fucione.(no genera ningun conflito).
Volvemos a ejecutar git pull origin master (si queremos fusionar los câmbios de la rama master com los cambios que realizamos en remoto)
$git push origin master (para enviar los cambios que yo hice)

EN ESTE MOMENTO ANITA TIENE UN PROBLEMA PORQUE HYPERBLOG (BLOG2) ESTA MAS ADELANTADO QUE EL DE ANITA. TENEMOS QUE TRAERLO
Anita: vamos al repositorio de anita desde su cuenta vemos los commits que hubieron
Podemos comparar y vemos los cambios de allá para aca para ver cambios.
Le podemos dar a créate pull request, esto me crea un pull request de Willy a anita darle merge y listo.

PARA TRAERME LOS CAMBIOS DESDE CONSOLA. CREAREMOS OTRA FUENTE PARA HACER PULL:
$ git remote add upstream url_https (esto para generar otra fuente nueva donde podemos traer datos a nuestra rama master)
$ git pull upstream master (con esto nos traemos todos los cambios de master)
$ git commit –am “Fusion” (pero no hay nada a que hacerle commit porque ya nos traemos todo)
$ git push origin master (mandamos a nuestro repositorio original)

CONCEPTOS Y FUNDAMENTOS:
Fork: Significa tenedor, es tomar una copia del estado actual del proyecto y clonarlo como un proyecto mio. (SOLO PROYECTOS PUBLICOS,Y ES UNA CARACTERISTICA UNICA DE GITHUB.)

Hay dos maneras de actualizar mi fork del repo original, por consola o por github por consola simplemente hay que crear otra fuente remota para fusionar el remoto original con el fork en local y luego subirlo a el fork en remoto.

En esta clase más allá de entender el PullRequest se ven las ventajas siendo un no-colaborador, simplemente alguien que quiera aportar.
La clonación a través de un Fork es similar a enlazar un repositorio:

  1. Hacer el Fork desde nuestro repo remoto
  2. Copiar la URL o SSH del nuestro repo bifurcado
$git clone URL o SSH (Clona el proyecto)

Para mantener actualizado este Fork es de utilidad tener un upstream que es un puntero a la rama master del proyecto principal, se logra enlazando una rama a la rama master del proyecto original:

$git remote add upstream URLdelOriginal (Enlaza con el master original)

A partir de upstream ya se pueden tener los cambios recientes en la rama master bifurcada.

Espero que les ayude.

“Adiós Anita, que la fuerza te acompañe”

segundo 20 del video y ya extraño a Anita :’(

Cuando no eres un colaborador directo, sino que es un proyecto open source, no puede hacer push o merge, porque no es tu proyecto. Lo que se puede hacer es un fork, hacer los cambios y decirles “quiero colaborar, pro favor, revisen este código”.
En los proyectos open source para que te lleguen notificaciones de cuándo se realizan cambios hay que darle clic al botón “watch” y luego darle clic a fork, fork lo que hace es tomar una copia del proyecto y clonarlo, esto solo es posible si el proyecto es público, si el proyecto es privado es imposible saber que el proyecto existe.
Una vez el proyecto ha sido forkeado, aparecerá una copia en la interfaz del usuario en github, luego, se clona por https o ssh, y se importa en el disco local con “git clone URLDelProyecto”. Luego se hace un git commit, git push origin master, pero esto se actualizará en tu repositorio, no en el repositorio oficial. Para hacer el pull request con la rama oficial, se debe crear un pull request, luego se coloca un título, un comentario y luego enviarlo.
Desde la perspectiva del propietario, es el mismo procedimiento de code review, revisa los cambios y los acepta o no.
Ahora el proyecto oficial está más adelantado que el mío, desde github es tan fácil como revisar los cambios desde su interfaz visual, hacer un pull request de los cambios y luego un merge, nada del otro mundo, desde consola es lo interesante. se crea un nuevo origen remoto con git remote add nombreRemoto URLDelProyecto, y listo, ya se puede hacer pull del repositorio remoto oficial y luego push de nuestro repositorio remoto a github.

jejej

El fork es para personas que no están como colaboradores, sin embargo pueden pedir y colaborar desde afuera, allí hace fork tomando una copia actual del proyecto, al hacer fork puedo ver todos los cambios que ha tenido el proyecto, luego para llevarlo a local, debe ir clone or dowland en el repositorio propio, y copiar la url , ir a la terminal git clone y la url, como es publica la trae completa.

Allí puedo entrar a la carpeta y codificarla , luego de los cambios hacer git add . git commit -m “mensaje” git pull para buenas prácticas y git push para subirlo a nuestro github

Allí ya esta el repositorio con los cambios que adecue desde mi terminal, y para hacer un pull request que seria como un permiso para que hicieran merge a esos cambios, debo ir a pull request y new pull request, escoje las ramas que necesito usar que seria la que clone y la que modifique, le doy clonar y hago commit , cierro con create pull request .

De esta manera envío los cambios desde afuera del proyecto

A. Para bajarme Repo
Paso 1: Hacer Fork Directamente en GitHub
Paso 2: Hacer un clone del repositorio. (Mi Fork “Con mi nombre”)
Paso 3: Modificarlo
Paso 4: Hacer push (push origin master)
Paso 5: Hacer la petición de una PullRequest (Hasta esperar aprobación)

B. Para Descargar cambios directamente del repositorio maestro (El dueño es el Admin “Quien aprueba ó no las PullRequest”)
Paso 1: git remote add “Nombre (Preferencia upstream)” + Url Repo
Paso 2: Verificar que se realizo correctamente git remote -v
Paso 3: Descargar cambios git pull upstream master
Paso 4: Mandar los cambios de upstream a nuestro origin git push origin master

Listo todo actualizado

  • Una forma de contribuir a un proyecto sin ser colaborador es haciendo un fork del mismo.
  • Con esto tendremos una copia actualizada del repositorio en nuestro perfil para poder realizar cambios.
  • El proceso para poder contribuir a un proyecto es similar a hacer un pull request
  • Al hacer el pull request GitHub nos detecta que el proyecto es un fork para así comparar las ramas del proyecto original con nuestra copia
  • NOTA: En caso de que el repo original sufra cambios, podemos agregar otra instancia del servidor remoto apuntando al original con $ git remote add, que por convención se puede nombrar upstream. Haciendo esto podremos traer actualizaciones del repo original con $ git pull upstream master, hacer nuestras modificaciones y mandarlas al fork con $ git push origin master y pedir el pull request.

Fork: crear una copia del estado actual del proyecto y clonarlo
Pull request de un tercero: a traves del fork gitHub reconoce el base repository/ base branch y el head repository/compare branch
Actualizar el fork desde consola:
git remote addd upstream url: agrega un nuevo repositorio remoto (apuntador al repositorio original el repositorio otiginal)
Nota: tambien se puede actualizar el fork desde gitHub a traves de un pull request

Noooooo. Anita🙇‍♀️😔

Ahora si ya puedo apoyar en los proyectos OpenSource

La cara de Freddy al ver que ahora tiene más de 5k solicitudes de Pull requests 😂😂

Si por alguna razón no te deja hacer el push (como me paso a mi)
has esto:

git config --global --edit

[credential]
  helper = osxkeychain
  useHttpPath = true

Diferencia entre git pull y git clone:
git pull realiza una operación de fetch + merge de la rama especificada de un determinado repositorio.

git clone realiza una copia local de la rama activa de un repositorio remoto, incluyendo un seguimiento (remote-tracking) de todas las ramas, no solo de master. Las ramas existentes se pueden visualizar con git branch --remotes.


Que esta pasando?

El comando git remote set-url origin https://github.com/USERNAME/REPOSITORY.git sirve para poder cambiar la url del reposiorio origin y el comando git remote rm origin sirve para eliminar un repositorio remoto.

  • Si no eres parte del equipo, no podrás hacer push o merge al proyecto. Tendrás que hacer Fork al repositorio, después clonar el repositorio, hacer los cambios en tu repositorio y por última hacer un pull request al dueño del repositorio.

De casualidad me equivoqué en el nombre del remoto y le puse upstrem
Aquí les dejo como cambiarlo por si por error ponen un nombre que no quieren:
$ git remote rename upstrem upstream

Fredie y Anita como usuarios de github en el mismo PC


Al hacer el ejemplo con los dos usuarios no me dejaba hacer push al fork de Anita.

Si te ha pasado prueba agregar esta configuración local en el repositorio donde tienes el fork de Anita:

git config --local --edit

se abre un editor de texto y agregas las siguientes lineas al final:

[credential]
	useHttpPath = true

y ya puedes hacer push logueandote con tus credenciales de github.

Saludos

Después de buscar por una hora en las respuestas solo una fue acertada y la quiero compartir por si alguien a estas alturas sigue con este problema o se llega a topar
el problema:

la solución:
Tenía el mismo problema y encontré esta solución en linea:
Hay una credencial en tu sistema de otra cuenta o de un proyecto anterior que debes eliminar. Si trabajas en windows 10 ve a
Panel de control\Cuentas de usuario\Administrador de credenciales\Credenciales génericas,
busca las de github y quítalas.
Cuando vuelvas a intentar el push verifica la autenticación con el browser y asegurate de estar loggeado en la cuenta con la que estas trabajando o haber salido de la cuenta previamente para ingresar las credenciales.

Recuerden, que la notificación web de los forks no están configurados por defecto, la notificación les llegará solamente correo, pero pueden cambia la configuración en el icono de su avatar (settings/notifications) habilitan las que gusten

Para hacer un pull request, primero se debe hacer un fork. NO sirve clonar el repositorio simplemente desde el proyecto, porque github no hará la bifurcación del proyecto y no tendrá referenciado el repositorio original.

Hola me encuentro algo atorado con la practica de esta clase. he ido trabajando con las 2 cuentas desde un mismo ordenador. Lo que siempre hacia era cuando era anita Cambiaba el user name y el user email para identificarlos, pero cuando quiero hacer push siendo anita me sale el error de permission denied. Me podrían decir que podría hacer ?.
lo que trato de hacer es que “anita” haga push a su propio Hyperblog, al cual le hizo un fork desde el original de “Freddy”. No deberia pedir permisos para que el propio dueño de su cuenta haga push. O estoy equivocado?

Si quieres participar en un proyecto existente, en el que no tengas permisos de escritura, puedes bifurcarlo (hacer un “fork”). Esto consiste en crear una copia completa del repositorio totalmente bajo tu control: se almacenará en tu cuenta y podrás escribir en él sin limitaciones.

Un fork permite clonar el estado actual de un proyecto a github para que posteriormente puedas descargarlo, realizar los cambios correspondientes y posteriormente hacer un pull request para su aprobación

uff entendí el concepto, sin embargo se me ha hecho más complicado, a repasar.

Hacer un Fork es tomar una copia del estado actual del proyecto remoto público y clonarlo como un proyecto propio.
Es una característica de Github.

Primero se debe clonar el repositorio remoto
$git clone http://url

Si mi proyecto clonado local está desactualizado porque le faltan nuevos commit del propietario del proyecto lo que se puede hacer para obtener estos cambios es lo siguiente:

Se crea una nueva fuente de datos remota:

$git remote add nombre_fuente url_publica_https
$git remote add upstream https://github.com/…

Se valida que exista la nueva fuente remota:
$git remote -v

Se realiza un pull de la fuente remota a mi master local
$git pull upstream master

Actualizo mi repositorio remoto de github subiendo los cambios que tengo en mi master local
$git push origin master

¿Qué es un fork?
La palabra fork se traduce al castellano, dentro del contexto que nos ocupa, como bifurcación. Cuando hacemos un fork de un repositorio, se hace una copia exacta en crudo (en inglés «bare») del repositorio original que podemos utilizar como un repositorio git cualquiera. Después de hacer fork tendremos dos repositorios git idénticos pero con distinta URL. Justo después de hacer el fork, estos dos repositorios tienen exactamente la misma historia, son una copia idéntica. Finalizado el proceso, tendremos dos repositorios independientes que pueden cada uno evolucionar de forma totalmente autónoma. De hecho, los cambios que se hacen el repositorio original NO se transmiten automáticamente a la copia (fork). Esto tampoco ocurre a la inversa: las modificaciones que se hagan en la copia (fork) NO se transmiten automáticamente al repositorio original.

Pobre Anita tan emocionada que estaba en su nuevo trabajo. Paso de colaborador pagado a contribuyente sin paga. 😅

Ahora si se pone un poco complejo

📌 Fork permite realizar una copia exacta del repositorio original para trabajar sobre ella.

Datos✍🏻

📌 Fork

Es hacer una copia de un proyecto público a tu cuenta en GitHub.

Notas 📒

✏️ Hacer aportes a un repositorio que no es tuyo

Pasos:

  1. Realizar una bifurcación (fork) del proyecto de interés.
  2. Clonarlo localmente en nuestra computadora. git clone [URL]
  3. Realizar las mejoras en nuestro repositorio local.
  4. Actualizar nuestro repositorio remoto con los cambios. git push origin main
  5. Solicitar que nuestros cambios sean agregados al repositorio original. pull request
  6. Esperar que sean aceptados.

✏️ Traer cambios del repositorio original

Hasta el momento se tienen dos formas:
La primera es:

  1. Crear un pull request entre mi repositorio y el repositorio original.
  2. Hacer el merge.
  3. Actualizar nuestro repositorio local. git pull origin main

La segunda forma es:

  1. Agregar el repositorio remoto original del proyecto (upstream) a nuestro repositorio local. git remote add upstream [URL]
  2. Traer los cambios con git pull upstream main
  3. Actualizar nuestro repositorio remoto. git push origin main

Una bifurcación (fork en inglés) , en el ámbito del desarrollo de software, es la creación de un proyecto en una dirección distinta de la principal u oficial tomando el código fuente del proyecto ya existente. Comúnmente se utiliza el término inglés. Como resultado de la bifurcación se pueden llegar a generar proyectos diferentes que cubren necesidades distintas aunque similares.

Los cambios que se hacen en el repositorio original no se transmiten automáticamente a la copia (fork). Esto tampoco ocurre a la inversa. Las modificaciones que se hagan en la copia (fork) no se transmiten automáticamente al repositorio original.

fork clonar repositorios
git clone ruta publica del proyecto
git diff
git commit -am "mensaje"
git push origin master
pull request
comparar los forks

git remote add upstream (link)
asi añadimos la fuente nueva rama para traer de github
git pull upstream master
git commit -am "fusion"
git push origin master

colaborador -> puede hacer merge, push,
watch -> notificaciones de la actividad realizada en dicho repositorio remoto (RR).
start -> indicador de me gusta.
fork -> tomar una copia del estado actual del proyecto publico pero en un repositorio local, debido a que no es un colaborador, caracteristica github.

Pasos para contribuir o realizar una copia de un proyecto publico en github:

  1. Presionar fork, para tener el RR a contribuir a nuestro propio RR.
  2. Copiar link en clone, elegir entre HTTPS o SSH del RR a contribuir.
  3. En la carpeta deseada se clona el repositorio:
        git clone url
  1. Realizar cambios y enviar estos al RR.
  2. Crear un Pull requests, dependiedno de la rama trabajada se pueden realizar comparaciones.
  3. Esperar revisión de los cambios y la realizacion del ‘git merge pull requests’.

Pasos para realizar una copia de un proyecto publico en github desde terminal:

  1. crea otra fuente de donde se puede traer la fuente de datos desde el RR a contribuir:
        git remote add nuevaRamaRemota link

NOTA: nuevaRamaRemota es usualmente llamada upstream (fuente de origen del RR a contribuir).
  1. Traer todo los cambios de RR a la rama main al repositorio local:
        git pull nuevaRamaRemota main
  1. Fusionar repositorio, por si hay cambios
        git commit -am "comentario"
  1. enviar cambios en el repositorio remoto propio:
	git push origin main

NOTA: los envios de cambio deben ser solo desdes las ramas del repositorio local propio a nuestro RR.

git branch ->

Flag ->
    	 --all -> muestra las ramas locales y remotas del repositorio.

Nunca te olvidaremos Anita :,v

Habría diferencia entre añadir un remoto con el SSH url en vez del HTTPS url ?

Watch: Funciona para tener un seguimiendo sobre el proyecto, en el caso que salgan conversaciones nuevas o alguna otra cosa

Start: Funciona para darle favorito al proyecto por si sale una actualizacion te avisaran

Fork: Es una opcion para hacer una copia del proyecto publico a tu repositorio de GitHub, directamente esta es una cualidad que solamente encontramos en GitHub y no en Git. De esta forma podremos utilizar practicamente el proyecto como si fuera de nosotros haciendo todos cambios sin efectar al proyecto principal y sin tener una conexion alterna o directa a el.


Bueno esta confuso, tal vez es la falta de practica.

Para colaborar en un proyecto es util un pull request.

Primero creamos un FORK de el proyecto principal a nuestro perfil(github), despues lo traemos a nuestro repo local(git clone URL_del_fork).

Despues de haver echo cambio en nuestro FORK podemos enviar los cambio al proyecto principal mediante un pull request y seran implementados si el dueño los decide implementar.

saviendo que habran cambios en el proyecto principal nuestro FORK se quedara desactualizado.

Para tener actualizado nuestro FORK y nuestro repositorio en la PC, podemos crear un nuevo apuntador remoto al repocitorio del creador(git remote add upstream URL_del_creador).
Despues podemos traer actualizaciones a la PC(git pull upstrear master), y lo podemos enviar a nuesro FORK en github (git push origin master).

Sin el gorro no distingo quién es Anita y quién es Freddy 😦

Es un dolor de cabeza entender todo esto, pero estoy mucho mejor de cuando empece Cx. No puedo esperar para crear mis blogs y contenido

Hola buenas tengo una duda para los respectivos cambios siempre tengo que estar pendiente del repositorio o eso se notificaria que eso no quedo 100% claro

Crear un nuevo origen para actualizar mi repositorio local forkeado con los últimos cambios del repositorio original

Proceso para colaborar en un repositorio donde no soy colaborador.

  1. Busco el repositorio y uso la opción ‘fork’
  2. Con el repositorio en mi bandeja, lo clono en mi máquina (clone with HTTPS o SSH).
  3. Con el repositorio en mi entorno local, hago los cambios, hago commit y hago push
  4. El push queda en el respositorio remoto de mi cuenta.
  5. Con ese push hecho, puedo generar un pull request al dueño del repositorio original (del cual hice fork)
  6. En el pull request puedo especificar en qué consiste la mejora

Una vez el dueño del repositorio ingrese a GitHub, va a poder:

  1. Ver que hay un ‘contributor’ que generó un pull request
  2. Validar el pull request y aceptarlo o rechazarlo
  3. Si lo acepta, luego tendría que hacer el merge pull request

El dueño puede seguir trabajando, lo que genera que el contributor empiece a rezagarse. GitHub le va a decir al contributor que está N commits detrás del owner. El contributor puede solicitar un pull request a su repositorio y siendo dueño de su repositorio darle merge (opción GitHub-first). Esto mismo se puede hacer también por consola (Terminal-first):

# Siendo el colaborator, origin es mi repositorio remoto, no el remoto del owner
# verifico la conexion a origin
$ git remote -v
origin https://github.com/contributor_user/hyperblog.git (fetch)
origin https://github.com/contributor_user/hyperblog.git (push)

# como quiero traer la ultima actualizacion del repositorio del owner, debo copiar la URL para clone en el repositorio de owner.
# upstream es una manera generica de llamar al repositorio del owner
$ git remote add upstream [url clone del owner]

# verifico conexiones
$ git remote -v
origin https://github.com/contributor_user/hyperblog.git (fetch)
origin https://github.com/contributor_user/hyperblog.git (push)
upstream https://github.com/owner_user/hyperblog.git (fetch)
upstream https://github.com/owner_user/hyperblog.git (push)

# actualizo repositorio local:
$ git pull upstream master

# ahora, mi repositorio local esta mas adelantado que mi repositorio remoto debido al pull. Actualizo el remoto:
$ git push origin master

Es la tercera vez que miro este video, pues tuve que regresar para hacer el reto del video 31, para hacerle el Pull Request a Freddier.
No entendía que al hacer un FORK, se crea un proyecto en mi GitHub y que a partir de éste se debe realizar el “clone” en mi Git para aportar y entonces subirlo a GitHub (proyecto forked) y ahora si se puede aplicar el Pull Request.

Entonces basicamente es posible copiar un proyecto que nos guste, realizarle modificaciones a gusto y en tal caso logremos mejorarlo realizar una Solicitud para unir nuestros cambios con el repositorio al que le realizamos la copia.

Luego si existe la posibilidad de que el repositorio original este actualizado entonces podemos actualizar el nuestro ya sea por Github o por la terminal de nuestro repositorio locar añadiendo la URL del repositorio Originial.

A un “git remote add <URL>” y de esta forma aunque no podamos realizar un git push porque no estamos autorizados, si que podememos realizar un git pull

F por anita 💔

chingon! despues de agarrar pericia en proyectos con amigos, me gustaria contribuir con desconocidos

Me agradaba Anita

Incluso puedes agregar varios origenes remotos que apunten ya sea a gitlab, github o un git server privado, siempre y cuando tengas tus llaves configuradas correctamente.

Si por algua razón desean cambiar, corregir o actualizar la url del remote:
git remote set-url upstream aquí_nueva_url

Saludos!

FORK: Copia del estado actual del proyecto y clonarlo, esto nos permite mandar un pull request del proyecto si es necesario, incluso si no eres parte de él (sólo un contribuyente).

Un fork es un clonado del estado actual del proyecto.
Si no se es colaborador del proyecto, lo que se puede hacer es un fork, es decir, copiar el proyecto. Si le hacemos modificaciones, podemos enviar un pull request para que revisen si les interesan los cambios o no.

el fork no resulta ser unico de gitHub actualmente tambien se puede hacer fork en bitbucket

Para agregar una nueva fuente de datos:

  • git remote add (cualquierPalabraDescribaOrigenDatos) link_del_repositorio

Hay un modo de que el alias “Arbolito” quede guardado para siempre?
Cada vez que vuelvo a iniciar Git me toca volver a crear el alias, o simplemente no se puede?

Recuerden que actualmente la opción de Collaborators, se llama Manage access. Me pidió la contraseña al entrar allí.

Fork: Es tomar una copia del estado actual del proyecto y clonarlo. Se usa para poder contribuir a un proyecto sin ser colaborador.

🦄FUNCIONAMIENTO DE FORK✨

Al trabajar en un proyecto Open Source, nosotros no tenemos los permisos de realizar un merge o un commit directamente en la rama main del proyecto. Por lo que si queremos realizar una colaboración por nuestra cuenta necesitamos realizar un fork, es decir, realizar un clon del repositorio original en GitHub pero en nuestra cuenta personal.
.
Una vez realizado el fork en GitHub, para poder editarlo de manera cómoda debemos clonarlo en nuestro repositorio local (sí, el clon local de un clon remoto).
Cuando hayamos realizado los cambios debemos hacer un push de dichos cambios a nuestro clon remoto y posterior, realizar un Pull Request hacia proyecto original y esperar la aprobación/desaprobación, solicitud de cambios de la persona encargada de los commits del proyecto y así poder realizar nuestra contribución.
.
Los proyectos no se detienen, así que siempre hay nuevas versiones y commits, por lo que nuestros clones estarán desactualizados de dichas versiones.
Una solución para este problema es actualizarlo directamente desde la opción que nos ofrece GitHub, es decir:

  • Actualizar el repositorio clon remoto desde la herramienta que nos ofrece GitHub.

  • Realizar un pull a nuestro clon local.

  • Y continuar con las contribuciones.

Pero existe otra solución más practica desde la terminal que consiste en crear otra fuente para realizar pull, es decir:

  • Crear una nueva versión/fuente de datos local que esté conectada directamente con el repositorio remoto original, para que pueda actualizarse constantemente.
git remote add [nombreDeLaNuevaFuente] [linkDelRepositorioRemotoOriginal]
  • Con esta nueva fuente tenemos la capacidad de realizar un pull a nuestro clon local desde la nueva fuente para estar constantemente actualizados.
Nota: Un versión local solo puede estar conectada a un repositorio remoto, por eso es importante crear otra fuente para traer cambios de un repositorio y enviarlos a otro.

Tuve un error, era que en ves de clonar el protocolo http copie el SHH, y por eso me sali un error de permiso denegado, y por eso me toco hacer el merge desde github. Aprendí del error que es lo importante

Clase 29. Creando un Fork, contribuyendo a un repositorio

¿Qué es?

Es una característica única de GitHub en la que se crea una copia exacta del estado actual de un repositorio en GitHub, éste repositorio podrá servir como otro origen y se podrá clonar (como cualquier otro repositorio), en pocas palabras, lo podremos utilizar como un git cualquiera.
Al hacer fork los archivos se quedan en GitHub, no en GIT. Para llevarlos a nuestro repositorio local hacemos una clonación.

¿Cómo se hace?

La clonación a través de un fork es similar a enlazar un repositorio:

  1. Hacer el Fork desde nuestro repo remoto

  2. Copiar la URL o SSH del nuestro repo bifurcado

    $git clone url-o-ssh

  • Una vez hecho esto podemos acceder a los archivos desde nuestro repositorio local. Si hacemos unos cambios en los archivos y hacemos un commit, al ejecutar git status Git nos dirá que estamos por delante de la rama original de internet. Para actualizarla hacemos un git push y enviaremos los cambios a GitHub.
  • Estando en GitHub podemos hacer un new pull request donde podemos comparar los diferentes forks o las ramas de mi repositorio con las del original. Hay que recordar un pull request indica que es lo que cambiara en los archivos si se hace un merge.
  • Este pull request se envía al dueño del repositorio original que es quien tomara la decisión de aceptar o no los cambios y hacer un merge entre las ramas.

Si el dueño del repositorio hace cambios en los archivos nosotros tendremos un fork desactualizado. GitHub nos ayuda con eso y nos dice que estamos desactualizados, también nos ayuda a comparar esos cambios. Para mantener actualizado este fork es de utilidad tener una rama fuente que apunte a la rama master del proyecto principal. Normalmente a esa rama se le llama upstream y lo hacemos de la siguiente manera:

git remote add upstream url-del-original

Una vez hecho esto ejecutamos un git pull upstream master para traernos esos cambios que están en la rama upstream a nuestra rama master y ahora si estamos listos para mandar esos cambios a GitHub con git push.

Esto se puede hacer de la manera inversa, es decir, que GitHub se traiga los cambios del repositorio original al nuestro, y después traernos esos cambios a nuestro repositorio local. Ambas son validas y funcionales depende de ti cual usa

Pobre Anita :c

Para mantener un fork actualizado con el proyecto original es necesario:

  • Agregar un origen remoto con el URL original
    $git remote add upstream “URLoriginal”

  • traer cambios del upstream al master local
    $git pull upstream master

  • subir los cambios a nuestro fork
    $git push origin master

Cada vez mas claro 😄

Por fin aprendo como funcionan los proyectos open source en GitHub, a ver si puedo apoyar en alguno… 😃

En un entorno profesional de desarrollo.
¿Se utilizaría un Fork?

Esta era la clase que más esperaba (:

Se entendió perfecto!!

Noooo Anita :C

Explicación

git pull upstream master para traer los cambios a nuestra rama master

Anita estaba muy emocionada por su empleo, y freddy tuvo que despedirla 😦

Que complicado se puede colocar todo, pero sigue siendo muy interesante toda la información.

Me gustó más la versión de consola, es más fácil i rápido, lo único que haces es agregar la URL (llamada upstream) que apunta al proyecto original y usarla para descargarte todos los cambios, por eso la consola es más rápida jaja

RESUMEN

  • Cuando alguien deja de ser colaborador de un proyecto en GitHub, lo que puede hacer es copiar el proyecto y decir que quiero hacer un cambio, por favor fusiónenlo.
  • Pasos para colaborar en un proyecto de GitHub
    • Darle Watch y Star para indicar que el proyecto te gusta.
    • Podemos hacer un Fork, es tomar una copia del estado actual del proyecto y clonarlo. Esto solo se puede hacer con proyectos públicos.
    • Traemos el proyecto a nuestro disco con git clone [url].
    • Podemos hacer los cambios necesarios en local.
    • Una vez hecho los cambios, podemos enviar los cambios a nuestro repo remoto con git push. No es necesario colocar origin master
    • Luego debemos crear el Pull Request, donde podemos hacer las comparaciones entre las diferentes ramas.
    • Una vez hecho el PR, nos queda esperar a que el administrador quiera aceptar los cambios y haga el merge o también puedo cerrar el PR y rendirme.
  • Ahora el admin vera el PR y sus cambios, y podrá aceptar los cambios para hacer el merge o rechazarlos y hacer comentarios.
  • Una vez el proyecto original va cambiando, el Fork va quedando atrás, por lo tanto siempre tengo que traerme los cambios para estar actualizado.
  • Para actualizarlo tenemos dos opciones:
    1. Por GitHub: Puedo hacer una comparación de los cambios, y GitHub nos da la opción de hacer un PR desde del admin hacia mi, y simplemente hacer el merge.
    2. Por Consola:
      • Creamos una rama remota que nos traiga los cambios del repo original git remote add [rama] [url-proyecto], la rama suele llamarse upstream.
      • Verificamos si se ha creado correctamente la rama con git remote -v donde debemos tener las dos ramas: origin y upstream.
      • Hacemos un git pull upstream mainpara traernos todos los cambios de main.
      • Por ultimo hacemos un git mull origin master para mandarlo a nuestro repo remoto.
  • Ambas formas son 100% validas, podemos usar la 1era y luego migrar a consola.

Es una característica única de GitHub en la que se crea una copia exacta del estado actual de un repositorio directamente en GitHub, éste repositorio podrá servir como otro origen y se podrá clonar (como cualquier otro repositorio), en pocas palabras, lo podremos utilizar como un git cualquiera
.
Un fork es como una bifurcación del repositorio completo, tiene una historia en común, pero de repente se bifurca y pueden variar los cambios, ya que ambos proyectos podrán ser modificados en paralelo y para estar al día un colaborador tendrá que estar actualizando su fork con la información del original.
.
Al hacer un fork de un poryecto en GitHub, te conviertes en dueñ@ del repositorio fork, puedes trabajar en éste con todos los permisos, pero es un repositorio completamente diferente que el original, teniendo alguna historia en común.
.
Los forks son importantes porque es la manera en la que funciona el open source, ya que, una persona puede no ser colaborador de un proyecto, pero puede contribuír al mismo, haciendo mejor software que pueda ser utilizado por cualquiera.
.
Al hacer un fork, GitHub sabe que se hizo el fork del proyecto, por lo que se le permite al colaborador hacer pull request desde su repositorio propio.

/ clase 29 --> Creando un Fork(Contribución open source) /

watch --> Notifica cambios en el proyecto.
star -->  Da a entender que te gusta el proyecto.

git clone [url] --> Clona un repositorio.

git diff --> Muestra los cambios.

FORK (bifurcaciones): Pull request de alguien que no es colaborador.

Gracias por todo Anita. Que la fuerza te acompañe!

Al fin pude entender el Fork. Muchísimas gracias!!!

Esta presentando una falla a la hora de cargar el video

Yo no estoy haciendo lo que hace freddy con anita no sé si debo hacerlo

puedes encontrar los contribuidores,forks, etc dando clic en insights.