El libro realmente es muy bueno para aprender git. Yo he leido la ultima version en ingles y esta muy bien. No estoy seguro si tengan la misma estructura en español y la version 1, pero el capitulo 5 (de la version que yo lei) explica las dudas que tienes.
Hay varias formas en la que puedes manejar tu proyecto Git (varias de ellas las explican en ese capitulo del libro). En lo particular a mi me agrada bastante
este workflow. En especial en el caso que no quieras tener a tus compañeros haciendo push al repositorio oficial.
Tu repositorio oficial es el blessed repository y lo tienes hosteado en bitbucket, ahi esta todo tu trabajo y el de las demas personas. Ahora viene un desarrollador nuevo, clona el proyecto de forma local con git clone. Ahora tiene una copia de tu proyecto con la que puede trabajar y hacer sus commits. Una vez que haya terminado su contribucion tiene que colocar el repositorio en algun lugar al que tu puedas acceder. Bitbucket deberia poder dejarte crear varios repos para tus usuarios, aunque no estoy seguro. Tecnicamente no necesitas usar BitBucket para esto, lo importante es que tu puedas alcanzar el repositorio. El punto es que cada quien tiene su repositorio local y su repositorio remoto, solo que el tuyo se va a dedicar a integrar los cambios de los repositorios de los demas.
Ahora, lo interesante de esto es que te van a enviar una notificacion (puede ser por cualquier medio) diciendote que han hecho cambios y que los quieren integrar a tu repositorio oficial. Te proveen el medio por el cual alcanzar su repositorio con los cambios y tu puedes verificar que hay de nuevo en ese repositorio (usualmente atraves de un diff). Esto es basicamente un pull request. Hay varias formas de recibir pull-requests, BitBucket y GitHub implementan notificaciones en su web y tambien envian correos.
Una vez que recibes el pull request depende de ti, rechazarlo, decirle que haga otros cambios o simplemente hacer el merge con el repositorio oficial (incluir los cambios). Lo bueno de GitHub y BitBucket es que pueden hacer el merge inclusive atraves de la web. Tambien puedes agregar el remote del repositorio al cual vas a hacer el pull, luego hacer el merge a tu master y finalmente hacer el push a tu repositorio oficial. Cosa que quizas tengas que hacer algun dia si hay algun conflicto con el merge.
En resumen, tu creas tu repositorio de forma local y lo publicas en bitbucket. Los demas integrantes de tus usuarios hacen un fork de tu proyecto (hacen una copia remota de tu repositorio al cual solo ellos pueden hacer push). Los usuarios siguen trabajando en sus repositorios y luego es tu responsabilidad integrarlos o no atraves de los pull requests que te envien. En el capitulo 6 del libro cubren GitHub y explican los pull requests. Deben ser muy similares en BitBucket.
Hola Minusfor, gracias por tu explicación, mira he estado leyendo y EFEX me recomendó algo que me gusto mucho, instalar GITLab en el servidor de desarrollo
https://about.gitlab.com/ , tengo unas dudas:
Supongamos que tengo un servidor de desarrollo con su virtualhost un dominio propio.
La idea es iniciar ahi el git remoto, con la ultima versión de las fuentes, y todos los desarrolladores clonar desde ahí.
Suponiendo que estamos todos trabajando bajo el mismo repositorio, la idea es que cada uno tenga su rama, y esta rama se podría ver de forma remota? onda ejecutarla de forma remota para que funcione en el servidor? y al ver que este todo funcionando bien, hacer el merge al servidor de desarrollo y luego del desarrollo comprobar que esta todo ok, pasarlo a producción?
Justamente estoy en la parte de la versión 1 leyendo sobre las ramas,
http://git-scm.com/book/es/v1/Ramificaciones-en-Git-Procedimientos-b%C3%A1sicos-para-ramificar-y-fusionarEstoy buscando la forma de desarrollar sin necesidad de tener un ambiente local (servidor local, base de datos lcoal), lo cual sería ideal pero necesita cierto ambiente y todos deben tener lo mismo, es medio complejo prefiero usar el servidor.
Lo que pretendo es que cada cosa que haga, se pueda testear en linea desde el servidor antes de pasarlo a la rama master. Si se pudiera testear utilizar el software php en diferentes ramas sería una solución muy buena para mi y los desarrolladores.
Espero tus comentarios, muchas gracias por tu ayuda.