#90 Bueno recuerdo que tube que bajarme algo de git-core o algo asi
usergit@miserver:~$ ls
MEMORY.git
usergit@miserver:~$ cd MEMORY.git/
usergit@miserver:~/MEMORY.git$ ls
usergit@miserver:~/MEMORY.git$
Me deja conectarme perfectamente por SSH, pero por Egit desde eclipse al definirle la conexion, me daba un error tipo "no se ha encontrado repositorio git"
Eso es el paquete para que puedas crear repositorios, pero es que un repositorio git no es más que una carpeta en el sistema de archivos, si te funciona el acceso remoto desde terminal, te tiene que funcionar git.
Para los que tenian problemas con git como servidor:
Si quereis algo facil: https://www.atlassian.com/es/software/stash
Funciona muy bien, muy escalable. Y el precio es muy ajustado para equipos de 10 personas o menos.
( 10$ pago único ). (Demo 1 mes gratis).
Luego si quieres updates a partir del primer año hay que pagar 10$/año.
Yo desde que lo tengo me he olvidado de git-o-lites y historias...
Si os parecen mucho los 10$ siempre podeis usar gitosis (https://wiki.archlinux.org/index.php/gitosis ) o gitolite ( http://gitolite.com/gitolite/ )
#94 Bueno lo tenia hecho, pero como estoy de pruebas pues ahora no estaba.
Igualmente lo he realizado y al intentar conectar desde Eclipse ->
Cannot get remote repository refs.
Reason: ssh://usergit@ipserver/MEMORY.git: fatal '/MEMORY.git' does not appear to be a git repository
Edit: Vale solventado, era que en la ruta a la carpeta le decia MEMORY.git en vez de /MEMORY.git
Alguien ha conseguido conetarse a github con certificado ssh en vez de usuario y contrseña? con bitbucket si puedo accerder por ssh sin problemas
ssh -T [email protected]
Hi xxxxxx! You've successfully authenticated, but GitHub does not provide shell access.
#96 cuando da esos problemas github por ssh es por los agentes, prueba con ssh -T -v [email protected] y tambien revisa el agent
ha vuelto a actualizar!!
Usando Git con tus compañeros de proyecto
pd: puede parecer SPAM pero obviamente no lo es, los veteranos conocereis a Pirado IV xD
¿Cuál sería la manera más adecuada de crear un nuevo proyecto a partir de otro ya existente en un repositorio de GIT?
Tengo un proyecto, y quiero empezar otro usando la base del primero. A partir del momento en que se genere la división, serán dos proyectos totalmente independientes que seguirán evolucionando por caminos distintos.
#101 Pero un fork, si no me equivoco, es terminología propia de GitHub ¿no?
¿En Git eso sería crear otro repositorio nuevo con la base del anterior?
Sí, un fork es una forma de crear un proyecto nuevo en github/bitbucket, etc usando como base uno existente, si estás usando git sin más, no existe la opción de 'fork'.
Simplemente clona el repositorio, si lo vas a usar como repositorio centralizado elimina el remote origin, y conviértelo en un bare repository, y luego clona otra vez ese repositorio en cada puesto donde vayas a trabajar con él.
#103 Estoy usando BitBucket, no sabía que tenía Fork también.
Perfecto pues utilizaré ese sistema, muchas gracias a los dos 
Vuelvo a la carga xD
Somos dos personas editando archivos de un mismo repositorio a la vez. Los dos usamos SourceTree con BitBucket.
El problema es el siguiente:
Si yo edito algo, hago commit y push mientras él está editando otra cosa (en otro fichero), cuando intenta hacer commit y push le dice que no, que está usando una versión vieja y que no puede si no hace merge primero. Si intenta hacer merge tampoco le deja, y sólo conseguimos solucionarlo si él vuelve a la versión anterior a sus cambios (eliminando lo que haya hecho), actualiza con un pull, y cuando ya está en la última versión vuelve a meter los cambios.
¿Cómo deberíamos hacerlo? ¿Necesitamos más branches? Estoy perdidísimo con esto y no encuentro información sobre la edición simultánea.
#105 o me estoy liando yo o te estás liando tú.
Normalmente origin/master se refiere a repositorio/branch. Si ambos partís del mismo estado y tú haces un cambio y haces commit (y push) entonces él cuando intente hacer lo mismo se le pedirá que antes haga un pull (o fetch o lo que sea) y haga el merge.
No sé muy bien por qué no os deja, pero así es cómo funciona la cosa normalmente. Si no estáis trabajando en lo mismo yo utilizaría branches y luego las mergearía, sino es un coñazo.
#106 Tienes toda la razón, estaba confundiendo repositorio y branch, porque en el repositorio local sólo me aparece el nombre del branch.
Entonces ¿cada uno deberíamos tener la master branch en nuestro repositorio local, y un branch separado para los cambios que hagamos, aunque no se pisen en nada? Probaré con eso a ver.
#107 Normalmente la manera de trabajar con git es hacerte una copia del repo remoto y trabajar con el desde local, luego solicitas un pull request.
Si no quieres hacerte una copia y trabajáis mas de una persona en el mismo repo, lo que tenéis que hacer es una rama por persona y luego hacéis un merge y resolvéis los conflictos que hagan falta.
A tu compañero debería funcionarle el commit, lo que no debería funcionarle es el push, me explico;
cuando tu haces primero un push el repo a cambiado, por tanto antes de que tu compañero haga otro push tiene que tener la ultima versión del repo.
Lo que tiene que hacer cuando no le deje hacer un push es hacer un pull (fetch y merge) y resolver los conflictos, luego seguidamente haga un push y se subirán los cambios al repo remoto.
Espero haberte aclarado algo 
¿En Bitbucket no se pueden clonar los repositorios privados aunque estés en el grupo de trabajo de ese repo? ¿Hay que ponerlo público por narices?
#110 ¿Cómo lo haces? Es decir, sin ser el usuario creador del repo, si no uno perteneciente al grupo de trabajo.
#112 Tengo acceso de "write", así que teóricamente debería poder. Bueh, seguiré investigando. Gracias :3
Perdon por la nigromancia, llevo ya unos cuantos meses con Git y la verdad es que me encanta (Lo uso con el Bash y me esta haciendo plantearme el cambiar a *nix, le estoy cogiendo el gusto a escribir comandos en un terminal)
Mi pregunta es la siguiente, alguien ha conseguido firmar commits con una clave GPG en windows?
Si no sabeis que es, es basicamente usar una clave PGP para "certificar" los commits, es decir de alguna formar confirmar que eres tú el que ha pusheado esa modificacion.
Es algo que en Linux es trivial (GPG viene con la mayoría de sistemas operativos tipo Debian) y una vez tienes tu clave en el keyring es:
) ha realizado un manual para git con un caso real
$ git config --global user.signingkey
$ git commit -S -m "Test commit of foo"
You need a passphrase to unlock the secret key for user:
"Mortadelegle <[email protected]>"
4096-bit RSA key, ID 08C196A5, created 2014-12-24
Y acto seguido introducir la passphrase.
Sin embargo en Windows llevo varios días intentadolo y estoy a punto de darme por vencido, para empezar git asume que tu keyring siempre va a estar en C:\Users\Tu_Usuario.gnupg, cosa que en windows no es, hay varias formas de solucionar esto, yo opte por cambiar el homedir de el programa de GPG de windows, cosa que es simplemente meter en el cmd
gpg --homedir c:\\your\\path\\Pero aquí descrubes que hay un bug que lleva más de dos años en el tracker por el cual esto no funciona y que tienes que meter esto en un archivo .reg y despues hacer doble click para editar el registro:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\GNU\GnuPG]
"HomeDir"="c:\\Users\\Tu_Usuario\\.gnupg"Pero la diversión no acaba aquí amigos!, no no no, Bill sabe que esto os encanta por lo que si habeís llegado hasta aqui sin que os funda el cerebro descubrireis que si intentais firmas cualquier commit despues de configurar git no importa como lo hagais esto os sale:
gpg: skipped "Mortadelegle <[email protected]>": bad passphrase
gpg: signing failed: bad passphrase
error: gpg failed to sign the data
fatal: failed to write commit objectAsí que si alguno tiene alguna idea se lo agradecería, seguire intentandolo hasta que se me evapore la poca materia gris que me queda (Que no es mucha)
Y #114 seguramente esta respuesta te llega muy tarde pero, te recomiendo seguir un poco la progresion de https://www.atlassian.com/git/tutorials/comparing-workflows, yo hasta ahora en el equipo que tenía estaba usando el centralized workflow pero estoy intentando hacer que cambien a un feature branch flow, a mi parecer es exactamente igual que el gitflow, solo que las ramas no son tan esctrictas (Por ejemplo tener un master y una release branch me parece redundante)
Tengo un par de dudas respecto al uso de Git.
Tengo una carpeta llamada "myapp" donde tengo mi proyecto :
Tengo 2 branches, master y feature_x (esta última es una copia de master).
Hago checkout y me paso a feature_x y empiezo a hacer cambios.
Decido volver al master para ver una cosa.
Mi pregunta es, tengo 2 "versiones" de código en diferentes branches, como veo los cambios hechos localmente en la carpeta "myapp". Es decir, hay algún comando para que la carpeta "myapp" se actualice al branch que estoy utilizando ?
git pullNo me actualiza la copia local
#116 No he entendido que quieres decir.
Quieres pasar lo que has hecho en feature_x a master?
Si es así:
git checkout master -> pasamos a master
git merge feature_x -> mergea los cambios de feature_x en master
o bien
git merge feature_x masterQue le está diciendo que haga merge de feature en master
También puedes usar rebase pero no lo recomiendo.
Si no es eso, no entiendo lo que estás haciendo xD
#117 Me refiero a que, si tengo 2 branches master y feature_x
Como hago para tener en la carpeta local los archivos de feature_x y no los de master. Archivos que modifico con el PHPStorm por ejemplo en mi carpeta local.
Si en master tengo los archivos : abc.txt , def.txt
Y en feature_x tengo : xyz.txt, eee.txt
Cuando miro la carpeta en mi copia de windows, tengo los archivos de master.
Al cambiar de branch a feature_x, como hago para ver en mi carpeta local solo los archivos de este branch ?
El resultado sería que al abrir c:/micarpeta , solo viese los archivos del feature_x y no los del master
#118 Que yo sepa phpstorm tiene integrada el control de versiones. Puedes hacerlo directamente desde allí.
http://www.jetbrains.com/help/phpstorm/2016.1/accessing-git-branches-popup-menu.html?origin=old_help
#118 Al hacer checkout, los archivos de la carpeta pasan a ser los de la revisión de la rama actual, a excepción de los ficheros modificados sin commitear. Intenta no cambiar de rama sin antes haber hecho commits de todo o haber hecho stash, pero cuidado con olvidar los stash hechos...
