Estoy empezando en esto y quisiera saber si me podrías ayudar con este error…realice todos los pasos que dices pero cuando presiono push y le doy ok haciendo el proceso que tu dices me sale que:

git -c diff.mnemonicprefix=false -c core.quotepath=false push -v –tags –set-upstream origin master:master
remote: Invalid username or password. If you log in via a third party service you must ensure you have an account password set in your account profile.

fatal: Authentication failed for ‘https://[email protected]/anderson_suarez/primer_prueba.git/’
Pushing to https://[email protected]/anderson_suarez/primer_prueba.git

Completed with errors, see above.

Que puedo realizar al respecto?
De antemano de doy las gracias por compartir tus conocimientos.

Muchas gracias por tu tiempo. Revisaré la información.

Saludos.

Hola Andrés:

Bitbucket dispone de varias acciones para gestionar los permisos de las ramas. En este post de su blog puedes verlas:

http://blog.bitbucket.org/2013/09/16/take-control-with-branch-restrictions/

Puedes limitar pushes, evitar los borrados de ramas o impedir que se pueda reescribir la historia de una rama. Cada miembro tendría su rama a la que puede hacer push, tu te das permiso para hacer push en todas las ramas, impides que esas ramas se puedan borrar y con esto ya lo deberías tener.

Sólo una nota más. Yo he trabajado en un flujo parecido al que quieres hacer porque trabajaba con gente que no conocía bien la herramienta. Desafortunadamente mi experiencia no fue buena porque el flujo que escogí no fue el adecuado o yo no lo implementé correctamente. Las decisiones que tomé me llevaron a tener toda la responsabilidad, convertirme en un cuello de botella (si sólo uno puede o sabe hacer los merges es lo que pasa), un «single point of failure» (si me iba de fin de semana largo no había merges) y di lugar a que el resto del equipo se acomodase «descuidando» el repositorio y «pasando» de aprender a usar la herramienta. Lo comparto contigo para que no cometas los mismos errores que yo 😉

Hola gracias por tu respuesta, yo tengo alojado mi proyecto en bitbucket y a este le he configurado ramas para mi equipo. A estas ramas quiero asiganrle usuarios(miembros del equipo) para que solo trabajen en esas ramas, luego ya yo como administrador poder hacer los marge y demas sin tener complicaciones. Saludos.

Hola Andrés:

Para poder ayudarte necesitaría un poco más de información sobre el tipo de infraestructura que estáis utilizando. ¿Dónde tenéis alojados los repositorios remotos? ¿gitolite, github, bitbucket, gitlab, vuestro propio servidor? Cada una de estas soluciones implementa los permisos de acceso a su manera. Recuerda que git no ofrece por defecto ningún tipo de control de acceso, son estas aplicaciones las que ponen la capa de autenticación por encima de git.

Saludos.

Hola Óscar:

La pregunta no es tonta. Ese checkbox sirve para indicar si quieres que cal crear la rama remota, tu rama local se convierta en «tracking branch» de esa rama remota. Si vas a utilizar la rama para subir commits al servidor de manera regular, lo normal que sí la marques como «tracking».

Cuando una rama local es tracking branch de una rama remota, git puede decirte cosas como que vas 3 commits por detrás o dos por delante, por ejemplo, de lo que está pasando en el servidor. También sirve para que los comandos pull y push sepan a qué rama remota subir tus commits cuando los ejecutas a secas, es decir, poniendo «git pull» o «git push» nada más.

Puedes encontrar más información acerca de qué es un tracking branch en el capítulo 3 del libro de Pro git:

http://git-scm.com/book/en/Git-Branching-Remote-Branches#Tracking-Branches

(en español lo tienes aquí: http://git-scm.com/book/es/Ramificaciones-en-Git-Ramas-Remotas#Haciendo-seguimiento-a-las-ramas)

Un saludo y gracias por tus comentarios.

Muchas gracias por esta entrada ya que me esta sirviendo para meterme en el mundo de git.

Hay una cosa que no entiendo y es el significado de track en la ventana emergente que aparece al hacer el commit.
No sé si debo seleccionarlo siempre o que.
Perdón por esta pregunta tan tonta ;-P

Saludos y gracias.

Perfectamente Alonso.
Ahora ya tengo todo claro y ya me hago una idea de la dinámica y flujo de trabajo con control de versiones. Efectivamente, estaba mezclando conceptos.

Muchísimas gracias!

…vamos a ver, que creo que estás mezclando cosas ;-).

Por un lado está el trabajo diario que haces con git (para el que usas la línea de comandos, Sourcetree o cualquier otro GUI como bien dices). Como parte de tu trabajo diario, harás commits y los subirás a un servidor como bitbucket usando push de ciertas ramas.

Por otro lado, tendrás un proceso de despliegue en producción, independiente del repositorio aunque puede estar conectado con él. Dos ejemplos:
– Deploy manual: Decides una rama o etiqueta de tu repo, haces un zip y lo subes por FTP
– Deploy semi automático: te conectas por SSH a tu servidor y haces un pull de tu rama «production»

¿te he aclarado la duda (aunque sea un poco)?

Hola Alfonso,
Muchísimas gracias, ¡es justo lo que necesitaba!.

Tengo otra duda respecto a la metodología usada para cuando se finaliza un proyecto. Pongamos que hemos estado desarrollando un website utilizando bitbucket y con GUI como SourceTree. Una vez terminado el proyecto, se conecta directamente el repo de bitbucket a «producción / ftp de tu site», o se sube por ftp directamente desde tu local? o hay alguna otra forma? o bitbucket es solo para trabajar?
¡Gracias otra vez! ya se que igual son muchas preguntas a la vez, pero me parece interesante tener la perspectiva general a la hora de trabajar en un proyecto con control de versiones. Evidentemente, soy bastante nueva en esto 🙂

Hola Oihana:

Ahora mismo no recuerdo cuáles son las tres maneras de instalar sourcetree (y no tengo un windows a mano para probarlo). Te comento las dos que yo conozco:

• Usar la versión de git que distribuye sourcetree
• Instalar git por tu cuenta y decirle a sourcetree que lo use

Si no te quieres complicar y la versión que se distribuye con Sourctree te vale, la primera es la opción más rápida. Si no usas la línea de comandos no vas a echar nada de menos.

Si quieres estar a la última y usar la línea de comandos al 100%, entonces usas la segunda opción. Te instalas git por tu cuenta y luego le dices a sourcetree dónde está el ejecutable de git para que lo use.

Espero haberte ayudado.

Un saludo,

Alfonso

Muy interesante el tutorial. Actualmente estoy estudiando estas herramientas y has explicado muy bien como conectar bitbucket con sourcetree. Tengo una duda, cuando he instalado sourcetree en windows me ha preguntado para instalar git de 3 formas diferentes. Podrías orientarme en la instalación de Sourctree y qué es necesario para su correcta instalación y posterior conexión con Bitbucket?
Muchas gracias .

¡Gracias! me alegro de que te haya sido de ayuda.