Cerca
Heus ací els resultats de la cerca.
Noms de pàgina coincidents:
Resultats de text complet:
- ramas
- = ramas A diferencia de otros sistemas de control de versiones, las ramas permiten trabajar a partir de... git branch testing </code> <callout type="info" icon="true">OJO! Aquí sólo hemos creado la rama, pero ... ach master ... > git checkout -b testing </code> Con esta forma hacemos dos pasos en uno : Crear la ra... tu repositorio remoto, tendrás que hacer un push con algún commit en la nueva rama. == Cambiar de Ram
- Casos prácticos
- s muchos git-hooks existentes. Para ello , podéis consultar este repo , donde está el ejemplo que vamos a seguir. Os recomendamos que consultéis estos enlaces para profundizar en el tema ... tos-de-enganche-en-Git]] == Hosting de tu página con Github Pages (Jekyll) En este caso veremos cómo a... de Proyecto : Podemos abrir una rama gh-pages que contenga la web estática que queramos. * Para más i
- configurando GIT
- = configurando GIT Git provee de un comando para establecer ciertos parámetros de configuración. Los más comunues suelen ser: * user... excludesfile * merge.tool La información de la configuración de git se puede almacenar en tres localizaciones distintas: * /etc/gitconfig * ~/.gitconfig * .git/config (Configuració
- iniciando un repositorio
- rio, nos estamos refiriendo a comenzar a trabajar con un repositorio. La creación de un repositorio si... nos olvide, porque al principio puede ser un poco confuso. Una vez hemos creado un repositorio en local... <code bash>git init</code> <callout type="info" icon="true">Este comando lo deberemos lanzar desde el directorio donde queramos hacer un control de versiones.</callout> Una vez ejecutado gi
- cómo ve GIT los ficheros
- s por los que pasa un fichero cuando está bajo un control de versiones git. === 1.Git Directory Cuando... n esa carpeta. A diferencia de otros sistemas de control de versiones, En git se realizan snapshots de todo el contenido de la carpeta en la que se esté haciendo control de versiones, pero de una manera eficiente (exp
- gitflow
- a tener una metodología: * no se hacen commits contra **develop**, siempre se abre una rama **feature** que se acaba mergeando con ella * se hacen **release**, que se mergean con **develop** y **master** (aquí se tagea) * los **hotfix** se realizan y al acabar se mergean con **develop** y **master** ramas: * develop *
- resolución de conflictos
- = resolución de conflictos == conflictos - creamos repo - creamos fichero - commit + push - creamos rama - volve... + push - volvemos a master - fusionamos rama con master - CONFLICTO! == repositorio centralizado * ''master'' : rama producción * ''development'
- clonar repositorios, cambios, commits y sincronización en github y bitbucket
- y sincronización en github y bitbucket * ''git config --global user.name "Miguel Angel Torres"'' * ''git config --global user.email "<email>"'' * ''git config --list'' * ''git clone https://ntkog@bitbucket.o
- introducción
- ue multitud de desarrolladores pudieran colaborar con la misma base de código. Anteriormente se trabajaba con parches de código que se pasaban en una lista de ... bución y que hacía todo el proceso muy complejo y con una alta probabilidad de error. Antes de desarro
- trabajando con ramas
- = trabajando con ramas * HEAD * ''git log --stat'' * ''git log --stat --oneline'' * crear r... s la rama al respositorio remoto * y se trabaja con normalidad * también se puede usar ''git chec
- hacer forks y Pull request
- l propietario recibe y decide si aplica == otros conceptos * pair programming acronymous * ''grunt
- hosting GIT
- Gratuíto para repositorios públicos y privados ( Con un límite de inivitación de usarios en el caso de
- instalación
- r/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" brew in