Hola Estimados como estan?

Tengo una duda, lo que pasa es que quiero implementar GIT como protocolo versionador de fuentes para trabajar en equipo, actualmente tenemos muchos problemas que nos pisamos los fuentes porque en general soy el único desarrollador pero de repente otro colega mete mano y pronto contratarán mas gente.

Como estoy trabajando actualmente:

Actualmente trabajo con netbeans para programar en PHP, lo tengo configurado para que al guardar guarde altiro el cambio en el servidor. (En el servidor tenemos dos ambientes, produccion y desarrollo) y yo hago esto sobre desarrollo.

Que es lo que quiero:

Quiero usar bitbucket y quiero implementar GIT para cuando alguien haga cambios, automaticamente me salga una solicitud de que quieren incluir el cambio en el proyecto y yo supervisar eso y ver si es valido ese cambio o no.

Ahora como hago compatible lo que quiero hacer para trabajar sobre un ambiente del servidor cosa que si yo apruebo el push request automaticamente el servidor actualice los cambios desde bitbucket y tome los cambios del branch master.

Cuales serían sus consejos sobre crear un ambiente de trabajo compatible con GIT y multiples desarrolladores y que estos cambios se vayan al servidor cuando corresponda? La idea es que si yo voy desarrollando quiero ver los cambios antes de hacer un commit, pero digamos que la aplicación es media especial y es complicado crearse un ambiente local en el pc (y virtualizarlo es una paja enorme) pero leo sus comentarios a ver que me aconsejan ustedes.

Gracias de antemano.

Gracias por responder, estoy leyendo lo que me enviaste, y al hacer cambios automáticamente me refiero a cuando se acepte el push dentro del servidor.

De igual forma estoy leyendo http://git-scm.com/book/es/v1/ Por si les interesa, esta entretenido el tema y vale la pena aprenderlo.

Si tienen mas sugerencias bienvenida sea, saludos y gracias nuevamente  
(Está increible la información que enviaste!)

Hola gracias por tu ayuda, la empresa es Octavius Technologies, si quieres mandame un mensaje privado para ver que onda. Es de Chile por si acaso xD, saludos.

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.

No estoy seguro de como gitlab te puede ayudar en esto, si no quieres usar bitbucket o github y quieres montar algo propio entonces si. Lo mejor seria que cada quien pueda levantar el entorno necesario. Git en parte fue pensado para evitar tener que depender de un servidor a la hora de trabajar con el código. Si te interesa armar y distribuir un entorno para todos tus usuarios quizas puedas utilizar algunas herramientas como vagrant. Por otro lado tambien puedes tener tu entorno de pruebas en algun lado. Les das acceso SSH a estos usuarios, hacen git clone (o pull) para traer sus cambios de sus repositorios y corren sus cambios ahi.

Si estas usando un solo repositorio al cual todo mundo hace push si es buena idea trabajar en ramas separadas. Yo prefiero tener mas control sobre el repositorio oficial por lo que no me gusta mucho este tipo de workflow. Con mucha gente haciendo push a un solo repositorio las cosas se pueden volver un poco pesadas. En un proyecto el año pasado hicimos un desastre de un branch solo con dos personas y hasta hace poco lo pude corregir (igual no sabia mucho de git entonces).