🕷️ Crawler Inspector

URL Lookup

Direct Parameter Lookup

Raw Queries and Responses

1. Shard Calculation

Query:

Response:

Calculated Shard: 54 (from laksa177)

2. Crawled Status Check

Query:

curl -X POST \
  'http://laksa054.int.ahrefs:8124/' \
  -H 'Content-Type: text/plain' \
  -H 'X-ClickHouse-Database: crawler3' \
  -H 'Authorization: Basic YXBpOg==' \
  -d 'SELECT getAhrefsURLFromUnparsed(src_unparsed) AS found_url, ifNull(toUnixTimestamp(download_stamp), 0) AS crawl_time, ifNull(toUnixTimestamp(props_url_first_seen), 0) AS first_indexed_time, download_http_code AS http_code, src_unparsed AS src_unparsed, src_root_hash AS src_root_hash, history_drop_reason AS history_drop_reason, meta_title AS meta_title, meta_descriptions AS meta_descriptions, attrs_boilerpipe_text AS attrs_boilerpipe_text, attrs_markdown AS attrs_markdown, attrs_readable_markdown AS attrs_readable_markdown, meta_canonical AS meta_canonical FROM crawler3.page_info_local FINAL PREWHERE (src_root_hash, src_unparsed) IN ((getAhrefsRootHashFromUnparsed(getAhrefsUnparsedNoserviceFromURL(\'https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas\')), getAhrefsUnparsedNoserviceFromURL(\'https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas\'))) FORMAT JSONEachRow'

Response:

{"found_url":"https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Ramas-Remotas","crawl_time":1775432550,"first_indexed_time":1425957630,"http_code":200,"src_unparsed":"com,git-scm!\/book\/es\/v2\/Ramificaciones-en-Git-Ramas-Remotas s443","src_root_hash":"7104038400628677254","history_drop_reason":null,"meta_title":"Git - Ramas Remotas","meta_descriptions":[],"attrs_boilerpipe_text":"Las ramas remotas son referencias al estado de las ramas en tus repositorios remotos.\nSon ramas locales que no puedes mover; se mueven automáticamente cuando estableces comunicaciones en la red.\nLas ramas remotas funcionan como marcadores, para recordarte en qué estado se encontraban tus repositorios remotos la última vez que conectaste con ellos.\nSuelen referenciarse como\n(remoto)\/(rama)\n.\nPor ejemplo, si quieres saber cómo estaba la rama\nmaster\nen el remoto\norigin\n, puedes revisar la rama\norigin\/master\n.\nO si estás trabajando en un problema con un compañero y este envía (push) una rama\niss53\n, tú tendrás tu propia rama de trabajo local\niss53\n; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama\norigin\/iss53\n.\nEsto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo.\nSupongamos que tienes un servidor Git en tu red, en\ngit.ourcompany.com\n.\nSi haces un clon desde ahí, Git automáticamente lo denominará\norigin\n, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama\nmaster\ny denominará la copia local\norigin\/master\n.\nGit te proporcionará también tu propia rama\nmaster\n, apuntando al mismo lugar que la rama\nmaster\nde\norigin\n; de manera que tengas donde trabajar.\nNota\n“origin” no es especial\nAsí como la rama “master” no tiene ningún significado especial en Git, tampoco lo tiene “origin”. “master” es un nombre muy usado solo porque es el nombre por defecto que Git le da a la rama inicial cuando ejecutas\ngit init\n. De la misma manera, “origin” es el nombre por defecto que Git le da a un remoto cuando ejecutas\ngit clone\n. Si en cambio ejecutases\ngit clone -o booyah\n, tendrías una rama\nbooyah\/master\ncomo rama remota por defecto.\nFigura 30. Servidor y repositorio local luego de ser clonado\nSi haces algún trabajo en tu rama\nmaster\nlocal, y al mismo tiempo, alguien más lleva (push) su trabajo al servidor\ngit.ourcompany.com\n, actualizando la rama\nmaster\nde allí, te encontrarás con que ambos registros avanzan de forma diferente.\nAdemás, mientras no tengas contacto con el servidor, tu apuntador a tu rama\norigin\/master\nno se moverá.\nFigura 31. El trabajo remoto y el local pueden diverger\nPara sincronizarte, puedes utilizar el comando\ngit fetch origin\n.\nEste comando localiza en qué servidor está el origen (en este caso\ngit.ourcompany.com\n), recupera cualquier dato presente allí que tú no tengas, y actualiza tu base de datos local, moviendo tu rama\norigin\/master\npara que apunte a la posición más reciente.\nFigura 32.\ngit fetch\nactualiza las referencias de tu remoto\nPara ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos, supongamos que tienes otro servidor Git; utilizado por uno de tus equipos sprint, solamente para desarrollo.\nEste servidor se encuentra en\ngit.team1.ourcompany.com\n.\nPuedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando\ngit remote add\n, tal y como vimos en\n[ch02-git-basics]\n.\nPuedes denominar\nteamone\na este remoto al asignarle este nombre a la URL.\nFigura 33. Añadiendo otro servidor como remoto\nAhora, puedes usar el comando\ngit fetch teamone\npara recuperar todo el contenido del remoto\nteamone\nque tú no tenías.\nDebido a que dicho servidor es un subconjunto de los datos del servidor\norigin\nque tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada\nteamone\/master\npara apuntar a la confirmación (commit) que\nteamone\ntiene en su rama\nmaster\n.\nFigura 34. Seguimiento de la rama remota a través de\nteamone\/master\nPublicar\nCuando quieres compartir una rama con el resto del mundo, debes llevarla (push) a un remoto donde tengas permisos de escritura.\nTus ramas locales no se sincronizan automáticamente con los remotos en los que escribes, sino que tienes que enviar (push) expresamente las ramas que desees compartir.\nDe esta forma, puedes usar ramas privadas para el trabajo que no deseas compartir, llevando a un remoto tan solo aquellas partes que deseas aportar a los demás.\nSi tienes una rama llamada\nserverfix\n, con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama.\nCon el comando\ngit push (remoto) (rama)\n:\n$ git push origin serverfix\nCounting objects: 24, done.\nDelta compression using up to 8 threads.\nCompressing objects: 100% (15\/15), done.\nWriting objects: 100% (24\/24), 1.91 KiB | 0 bytes\/s, done.\nTotal 24 (delta 2), reused 0 (delta 0)\nTo https:\/\/github.com\/schacon\/simplegit\n * [new branch]      serverfix -> serverfix\nEsto es un atajo.\nGit expande automáticamente el nombre de rama\nserverfix\na\nrefs\/heads\/serverfix:refs\/heads\/serverfix\n, que significa: “coge mi rama local\nserverfix\ny actualiza con ella la rama\nserverfix\ndel remoto”.\nVolveremos más tarde sobre el tema de\nrefs\/heads\/\n, viéndolo en detalle en\n[ch10-git-internals]\n; por ahora, puedes ignorarlo.\nTambién puedes hacer\ngit push origin serverfix:serverfix\n, que hace lo mismo; es decir: “coge mi\nserverfix\ny hazlo el\nserverfix\nremoto”.\nPuedes utilizar este último formato para llevar una rama local a una rama remota con un nombre distinto.\nSi no quieres que se llame\nserverfix\nen el remoto, puedes lanzar, por ejemplo,\ngit push origin serverfix:awesomebranch\n; para llevar tu rama\nserverfix\nlocal a la rama\nawesomebranch\nen el proyecto remoto.\nNota\nNo escribas tu contraseña todo el tiempo\nSi utilizas una dirección URL con HTTPS para enviar datos, el servidor Git te preguntará tu usuario y contraseña para autenticarte. Por defecto, te pedirá esta información a través del terminal, para determinar si estás autorizado a enviar datos.\nSi no quieres escribir tu contraseña cada vez que haces un envío, puedes establecer un “cache de credenciales”. La manera más sencilla de hacerlo es estableciéndolo en memoria por unos minutos, lo que puedes lograr fácilmente al ejecutar\ngit config --global credential.helper cache\nLa próxima vez que tus colaboradores recuperen desde el servidor, obtendrán bajo la rama remota\norigin\/serverfix\nuna referencia a donde esté la versión de\nserverfix\nen el servidor:\n$ git fetch origin\nremote: Counting objects: 7, done.\nremote: Compressing objects: 100% (2\/2), done.\nremote: Total 3 (delta 0), reused 3 (delta 0)\nUnpacking objects: 100% (3\/3), done.\nFrom https:\/\/github.com\/schacon\/simplegit\n * [new branch]      serverfix    -> origin\/serverfix\nEs importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia local editable de las mismas.\nEn otras palabras, en este caso, no tienes una nueva rama\nserverfix\n. Sino que únicamente tienes un puntero no editable a\norigin\/serverfix\n.\nPara integrar (merge) esto en tu rama de trabajo actual, puedes usar el comando\ngit merge origin\/serverfix\n.\nY si quieres tener tu propia rama\nserverfix\npara trabajar, puedes crearla directamente basandote en la rama remota:\n$ git checkout -b serverfix origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'\nEsto sí te da una rama local donde puedes trabajar, que comienza donde\norigin\/serverfix\nestaba en ese momento.\nHacer Seguimiento a las Ramas\nAl activar (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar una “rama de seguimiento” (tracking branch).\nLas ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota.\nSi estás en una rama de seguimiento y tecleas el comando\ngit pull\n, Git sabe de cuál servidor recuperar (fetch) y fusionar (merge) datos.\nCuando clonas un repositorio, este suele crear automáticamente una rama\nmaster\nque hace seguimiento de\norigin\/master\n.\nSin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que sigan ramas de otros remotos o no seguir la rama\nmaster\n.\nEl ejemplo más simple es el que acabas de ver al lanzar el comando\ngit checkout -b [rama] [nombreremoto]\/[rama]\n.\nEsta operación es tan común que git ofrece el parámetro\n--track\n:\n$ git checkout --track origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'\nPara preparar una rama local con un nombre distinto a la del remoto, puedes utilizar la primera versión con un nombre de rama local diferente:\n$ git checkout -b sf origin\/serverfix\nBranch sf set up to track remote branch serverfix from origin.\nSwitched to a new branch 'sf'\nAsí, tu rama local\nsf\ntraerá (pull) información automáticamente desde\norigin\/serverfix\n.\nSi ya tienes una rama local y quieres asignarla a una rama remota que acabas de traerte, o quieres cambiar la rama a la que le haces seguimiento, puedes usar en cualquier momento las opciones\n-u\no\n--set-upstream-to\ndel comando\ngit branch\n.\n$ git branch -u origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nNota\nAtajo al\nupstream\nCuando tienes asignada una rama de seguimiento, puedes hacer referencia a ella mediante\n@{upstream}\no mediante el atajo\n@{u}\n. De esta manera, si estás en la rama\nmaster\ny esta sigue a la rama\norigin\/master\n, puedes hacer algo como\ngit merge @{u}\nen vez de\ngit merge origin\/master\n.\nSi quieres ver las ramas de seguimiento que tienes asignadas, puedes usar la opción\n-vv\ncon\ngit branch\n. Esto listará tus ramas locales con más información, incluyendo a qué sigue cada rama y si tu rama local está por delante, por detrás o ambas.\n$ git branch -vv\n  iss53     7e424c3 [origin\/iss53: ahead 2] forgot the brackets\n  master    1ae2a45 [origin\/master] deploying index fix\n* serverfix f8674d9 [teamone\/server-fix-good: ahead 3, behind 1] this should do it\n  testing   5ea463a trying something new\nAquí podemos ver que nuestra rama\niss53\nsigue\norigin\/iss53\ny está “ahead” (delante) por dos, es decir, que tenemos dos confirmaciones locales que no han sido enviadas al servidor.\nTambién podemos ver que nuestra rama\nmaster\nsigue a\norigin\/master\ny está actualizada.\nLuego podemos ver que nuestra rama\nserverfix\nsigue la rama\nserver-fix-good\nde nuestro servidor\nteamone\ny que está tres cambios por delante (ahead) y uno por detrás (behind), lo que significa que existe una confirmación en el servidor que no hemos fusionado y que tenemos tres confirmaciones locales que no hemos enviado. Por último, podemos ver que nuestra rama\ntesting\nno sigue a ninguna rama remota.\nEs importante destacar que estos números se refieren a la última vez que trajiste (fetch) datos de cada servidor. Este comando no se comunica con los servidores, solo te indica lo que sabe de ellos localmente. Si quieres tener los cambios por delante y por detrás actualizados, debes traértelos (fetch) de cada servidor antes de ejecutar el comando. Puedes hacerlo de esta manera:\n$ git fetch --all; git branch -vv\nTraer y Fusionar\nA pesar de que el comando\ngit fetch\ntrae todos los cambios que no tienes del servidor, este no modifica tu directorio de trabajo.\nSimplemente obtendrá los datos y dejará que tú mismo los fusiones.\nSin embargo, existe un comando llamado\ngit pull\n, el cuál básicamente hace\ngit fetch\nseguido por\ngit merge\nen la mayoría de los casos.\nSi tienes una rama de seguimiento configurada como vimos en la última sección, bien sea asignándola explícitamente o creándola mediante los comandos\nclone\no\ncheckout\n,\ngit pull\nidentificará a qué servidor y rama remota sigue tu rama actual, traerá los datos de dicho servidor e intentará fusionar dicha rama remota.\nNormalmente es mejor usar los comandos\nfetch\ny\nmerge\nde manera explícita pues la magia de\ngit pull\npuede resultar confusa.\nEliminar Ramas Remotas\nImagina que ya has terminado con una rama remota, es decir, tanto tú como tus colaboradores habéis completado una determinada funcionalidad y la habéis incorporado (merge) a la rama\nmaster\nen el remoto (o donde quiera que tengáis la rama de código estable).\nPuedes borrar la rama remota utilizando la opción\n--delete\nde\ngit push\n.\nPor ejemplo, si quieres borrar la rama\nserverfix\ndel servidor, puedes utilizar:\n$ git push origin --delete serverfix\nTo https:\/\/github.com\/schacon\/simplegit\n - [deleted]         serverfix\nBásicamente, lo que hace es eliminar el apuntador del servidor. El servidor Git suele mantener los datos por un tiempo hasta que el recolector de basura se ejecute, de manera que si la has borrado accidentalmente, suele ser fácil recuperarla.","attrs_markdown":"[![Git](https:\/\/git-scm.com\/images\/logo@2x.png)](https:\/\/git-scm.com\/) \\--fast-version-control\n\n![](https:\/\/git-scm.com\/images\/dark-mode.svg)\n\n- [About](https:\/\/git-scm.com\/about)\n  - [Trademark](https:\/\/git-scm.com\/about\/trademark)\n- [Learn](https:\/\/git-scm.com\/learn)\n  - [Book](https:\/\/git-scm.com\/book)\n  - [Cheat Sheet](https:\/\/git-scm.com\/cheat-sheet)\n  - [Videos](https:\/\/git-scm.com\/videos)\n  - [External Links](https:\/\/git-scm.com\/doc\/ext)\n- [Tools](https:\/\/git-scm.com\/tools)\n  - [Command Line](https:\/\/git-scm.com\/tools\/command-line)\n  - [GUIs](https:\/\/git-scm.com\/tools\/guis)\n  - [Hosting](https:\/\/git-scm.com\/tools\/hosting)\n- [Reference](https:\/\/git-scm.com\/docs)\n- [Install](https:\/\/git-scm.com\/install\/linux)\n- [Community](https:\/\/git-scm.com\/community)\n***\nThis book is available in [English](https:\/\/git-scm.com\/book\/en\/v2\/Git-Branching-Remote-Branches).\n\nFull translation available in\n\n|   |\n|---|\n| [azərbaycan dili](https:\/\/git-scm.com\/book\/az\/v2\/Git%E2%80%99d%C9%99-Branch-Uzaq-Branch%E2%80%99lar), |\n| [български език](https:\/\/git-scm.com\/book\/bg\/v2\/%D0%9A%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%D0%B5-%D0%B2-Git-%D0%9E%D1%82%D0%B4%D0%B0%D0%BB%D0%B5%D1%87%D0%B5%D0%BD%D0%B8-%D0%BA%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%D0%B5), |\n| [Deutsch](https:\/\/git-scm.com\/book\/de\/v2\/Git-Branching-Remote-Branches), |\n| [Español](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Ramas-Remotas), |\n| [فارسی](https:\/\/git-scm.com\/book\/fa\/v2\/%D8%A7%D9%86%D8%B4%D8%B9%D8%A7%D8%A8%E2%80%8C%DA%AF%DB%8C%D8%B1%DB%8C-%D8%AF%D8%B1-%DA%AF%DB%8C%D8%AA-Git-Branching-%D8%B4%D8%A7%D8%AE%D9%87%E2%80%8C%D9%87%D8%A7%DB%8C-%D8%B1%D8%A7%D9%87-%D8%AF%D9%88%D8%B1-Remote-Branches), |\n| [Français](https:\/\/git-scm.com\/book\/fr\/v2\/Les-branches-avec-Git-Branches-de-suivi-%C3%A0-distance), |\n| [Ελληνικά](https:\/\/git-scm.com\/book\/gr\/v2\/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-%CE%91%CF%80%CE%BF%CE%BC%CE%B1%CE%BA%CF%81%CF%85%CF%83%CE%BC%CE%AD%CE%BD%CE%BF%CE%B9-%CE%BA%CE%BB%CE%AC%CE%B4%CE%BF%CE%B9), |\n| [日本語](https:\/\/git-scm.com\/book\/ja\/v2\/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81), |\n| [한국어](https:\/\/git-scm.com\/book\/ko\/v2\/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EB%B8%8C%EB%9E%9C%EC%B9%98), |\n| [Nederlands](https:\/\/git-scm.com\/book\/nl\/v2\/Branchen-in-Git-Branches-op-afstand-Remote-branches), |\n| [Русский](https:\/\/git-scm.com\/book\/ru\/v2\/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%A3%D0%B4%D0%B0%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%B5-%D0%B2%D0%B5%D1%82%D0%BA%D0%B8), |\n| [Slovenščina](https:\/\/git-scm.com\/book\/sl\/v2\/Veje-Git-Oddaljene-veje), |\n| [Српски](https:\/\/git-scm.com\/book\/sr\/v2\/%D0%93%D1%80%D0%B0%D0%BD%D0%B0%D1%9A%D0%B5-%D1%83-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83-%D0%93%D0%B8%D1%82-%D0%A3%D0%B4%D0%B0%D1%99%D0%B5%D0%BD%D0%B5-%D0%B3%D1%80%D0%B0%D0%BD%D0%B5), |\n| [Svenska](https:\/\/git-scm.com\/book\/sv\/v2\/Git-grenar-Fj%C3%A4rrgrenar), |\n| [Tagalog](https:\/\/git-scm.com\/book\/tl\/v2\/Pag-branch-ng-Git-Remote-na-mga-Branch), |\n| [Türkçe](https:\/\/git-scm.com\/book\/tr\/v2\/Git-Dallar%C4%B1-Uzak-Dallar). |\n| [Українська](https:\/\/git-scm.com\/book\/uk\/v2\/%D0%93%D0%B0%D0%BB%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8F-%D0%B2-git-%D0%92%D1%96%D0%B4%D0%B4%D0%B0%D0%BB%D0%B5%D0%BD%D1%96-%D0%B3%D1%96%D0%BB%D0%BA%D0%B8), |\n| [简体中文](https:\/\/git-scm.com\/book\/zh\/v2\/Git-%E5%88%86%E6%94%AF-%E8%BF%9C%E7%A8%8B%E5%88%86%E6%94%AF), |\n\nPartial translations available in\n\n|   |\n|---|\n| [Čeština](https:\/\/git-scm.com\/book\/cs\/v2\/V%C4%9Btve-v-syst%C3%A9mu-Git-Vzd%C3%A1len%C3%A9-v%C4%9Btve), |\n| [Македонски](https:\/\/git-scm.com\/book\/mk\/v2\/%D0%93%D1%80%D0%B0%D0%BD%D0%B5%D1%9A%D0%B5-%D0%B2%D0%BE-Git-%D0%94%D0%B0%D0%BB%D0%B5%D1%87%D0%B8%D0%BD%D1%81%D0%BA%D0%B8-%D0%B3%D1%80%D0%B0%D0%BD%D0%BA%D0%B8), |\n| [Polski](https:\/\/git-scm.com\/book\/pl\/v2\/Ga%C5%82%C4%99zie-Gita-Ga%C5%82%C4%99zie-zdalne), |\n| [Português (Brasil)](https:\/\/git-scm.com\/book\/pt-br\/v2\/Branches-no-Git-Branches-remotos), |\n| [Ўзбекча](https:\/\/git-scm.com\/book\/uz\/v2\/Git-%D0%B4%D0%B0-%D1%82%D0%B0%D1%80%D0%BC%D0%BE%D2%9B%D0%BB%D0%B0%D0%BD%D0%B8%D1%88-%D0%A3%D0%B7%D0%BE%D2%9B-%D0%BC%D0%B0%D1%81%D0%BE%D1%84%D0%B0%D0%B4%D0%B0%D0%B3%D0%B8-%D1%82%D0%B0%D1%80%D0%BC%D0%BE%D2%9B%D0%BB%D0%B0%D1%80), |\n| [繁體中文](https:\/\/git-scm.com\/book\/zh-tw\/v2\/%E4%BD%BF%E7%94%A8-Git-%E5%88%86%E6%94%AF-%E9%81%A0%E7%AB%AF%E5%88%86%E6%94%AF), |\n\nTranslations started for\n\n|   |\n|---|\n| [Беларуская](https:\/\/git-scm.com\/book\/be\/v2\/Git-Branching-Remote-Branches), |\n| [Indonesian](https:\/\/git-scm.com\/book\/id\/v2\/Git-Branching-Remote-Branches), |\n| [Italiano](https:\/\/git-scm.com\/book\/it\/v2\/Git-Branching-Remote-Branches), |\n| [Bahasa Melayu](https:\/\/git-scm.com\/book\/ms\/v2\/Git-Branching-Remote-Branches), |\n| [Português (Portugal)](https:\/\/git-scm.com\/book\/pt-pt\/v2\/Ramifica%C3%A7%C3%A3o-do-Git-Remote-Branches). |\n***\nThe source of this book is [hosted on GitHub.](https:\/\/github.com\/progit\/progit2-es)  \n Patches, suggestions and comments are welcome.\n\n[Chapters ▾](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Ramas-Remotas)\n\n1. ## 1\\. [Inicio - Sobre el Control de Versiones](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones)\n   1. 1\\.1 [Acerca del Control de Versiones](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones)\n   2. 1\\.2 [Una breve historia de Git](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-Una-breve-historia-de-Git)\n   3. 1\\.3 [Fundamentos de Git](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-Fundamentos-de-Git)\n   4. 1\\.4 [La Línea de Comandos](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-La-L%C3%ADnea-de-Comandos)\n   5. 1\\.5 [Instalación de Git](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-Instalaci%C3%B3n-de-Git)\n   6. 1\\.6 [Configurando Git por primera vez](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-Configurando-Git-por-primera-vez)\n   7. 1\\.7 [¿Cómo obtener ayuda?](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-%C2%BFC%C3%B3mo-obtener-ayuda%3F)\n   8. 1\\.8 [Resumen](https:\/\/git-scm.com\/book\/es\/v2\/Inicio---Sobre-el-Control-de-Versiones-Resumen)\n2. ## 2\\. [Fundamentos de Git](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Obteniendo-un-repositorio-Git)\n   1. 2\\.1 [Obteniendo un repositorio Git](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Obteniendo-un-repositorio-Git)\n   2. 2\\.2 [Guardando cambios en el Repositorio](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio)\n   3. 2\\.3 [Ver el Historial de Confirmaciones](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Ver-el-Historial-de-Confirmaciones)\n   4. 2\\.4 [Deshacer Cosas](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Deshacer-Cosas)\n   5. 2\\.5 [Trabajar con Remotos](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Trabajar-con-Remotos)\n   6. 2\\.6 [Etiquetado](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Etiquetado)\n   7. 2\\.7 [Alias de Git](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Alias-de-Git)\n   8. 2\\.8 [Resumen](https:\/\/git-scm.com\/book\/es\/v2\/Fundamentos-de-Git-Resumen)\n3. ## 3\\. [Ramificaciones en Git](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F)\n   1. 3\\.1 [¿Qué es una rama?](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F)\n   2. 3\\.2 [Procedimientos Básicos para Ramificar y Fusionar](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Procedimientos-B%C3%A1sicos-para-Ramificar-y-Fusionar)\n   3. 3\\.3 [Gestión de Ramas](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Gesti%C3%B3n-de-Ramas)\n   4. 3\\.4 [Flujos de Trabajo Ramificados](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Flujos-de-Trabajo-Ramificados)\n   5. 3\\.5 [Ramas Remotas](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Ramas-Remotas)\n   6. 3\\.6 [Reorganizar el Trabajo Realizado](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Reorganizar-el-Trabajo-Realizado)\n   7. 3\\.7 [Recapitulación](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Recapitulaci%C3%B3n)\n4. ## 4\\. [Git en el Servidor](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-Los-Protocolos)\n   1. 4\\.1 [Los Protocolos](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-Los-Protocolos)\n   2. 4\\.2 [Configurando Git en un servidor](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-Configurando-Git-en-un-servidor)\n   3. 4\\.3 [Generando tu clave pública SSH](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-Generando-tu-clave-p%C3%BAblica-SSH)\n   4. 4\\.4 [Configurando el servidor](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-Configurando-el-servidor)\n   5. 4\\.5 [El demonio Git](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-El-demonio-Git)\n   6. 4\\.6 [HTTP Inteligente](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-HTTP-Inteligente)\n   7. 4\\.7 [GitWeb](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-GitWeb)\n   8. 4\\.8 [GitLab](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-GitLab)\n   9. 4\\.9 [Git en un alojamiento externo](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-Git-en-un-alojamiento-externo)\n   10. 4\\.10 [Resumen](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-el-Servidor-Resumen)\n5. ## 5\\. [Git en entornos distribuidos](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos)\n   1. 5\\.1 [Flujos de trabajo distribuidos](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos)\n   2. 5\\.2 [Contribuyendo a un Proyecto](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-entornos-distribuidos-Contribuyendo-a-un-Proyecto)\n   3. 5\\.3 [Manteniendo un proyecto](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-entornos-distribuidos-Manteniendo-un-proyecto)\n   4. 5\\.4 [Resumen](https:\/\/git-scm.com\/book\/es\/v2\/Git-en-entornos-distribuidos-Resumen)\n\n1. ## 6\\. [GitHub](https:\/\/git-scm.com\/book\/es\/v2\/GitHub-Creaci%C3%B3n-y-configuraci%C3%B3n-de-la-cuenta)\n   1. 6\\.1 [Creación y configuración de la cuenta](https:\/\/git-scm.com\/book\/es\/v2\/GitHub-Creaci%C3%B3n-y-configuraci%C3%B3n-de-la-cuenta)\n   2. 6\\.2 [Participando en Proyectos](https:\/\/git-scm.com\/book\/es\/v2\/GitHub-Participando-en-Proyectos)\n   3. 6\\.3 [Mantenimiento de un proyecto](https:\/\/git-scm.com\/book\/es\/v2\/GitHub-Mantenimiento-de-un-proyecto)\n   4. 6\\.4 [Gestión de una organización](https:\/\/git-scm.com\/book\/es\/v2\/GitHub-Gesti%C3%B3n-de-una-organizaci%C3%B3n)\n   5. 6\\.5 [Scripting en GitHub](https:\/\/git-scm.com\/book\/es\/v2\/GitHub-Scripting-en-GitHub)\n   6. 6\\.6 [Resumen](https:\/\/git-scm.com\/book\/es\/v2\/GitHub-Resumen)\n2. ## 7\\. [Herramientas de Git](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Revisi%C3%B3n-por-selecci%C3%B3n)\n   1. 7\\.1 [Revisión por selección](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Revisi%C3%B3n-por-selecci%C3%B3n)\n   2. 7\\.2 [Organización interactiva](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Organizaci%C3%B3n-interactiva)\n   3. 7\\.3 [Guardado rápido y Limpieza](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Guardado-r%C3%A1pido-y-Limpieza)\n   4. 7\\.4 [Firmando tu trabajo](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Firmando-tu-trabajo)\n   5. 7\\.5 [Buscando](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Buscando)\n   6. 7\\.6 [Reescribiendo la Historia](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Reescribiendo-la-Historia)\n   7. 7\\.7 [Reiniciar Desmitificado](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Reiniciar-Desmitificado)\n   8. 7\\.8 [Fusión Avanzada](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Fusi%C3%B3n-Avanzada)\n   9. 7\\.9 [Rerere](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Rerere)\n   10. 7\\.10 [Haciendo debug con Git](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Haciendo-debug-con-Git)\n   11. 7\\.11 [Submódulos](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Subm%C3%B3dulos)\n   12. 7\\.12 [Agrupaciones](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Agrupaciones)\n   13. 7\\.13 [Replace](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Replace)\n   14. 7\\.14 [Almacenamiento de credenciales](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Almacenamiento-de-credenciales)\n   15. 7\\.15 [Resumen](https:\/\/git-scm.com\/book\/es\/v2\/Herramientas-de-Git-Resumen)\n3. ## 8\\. [Personalización de Git](https:\/\/git-scm.com\/book\/es\/v2\/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git)\n   1. 8\\.1 [Configuración de Git](https:\/\/git-scm.com\/book\/es\/v2\/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git)\n   2. 8\\.2 [Git Attributes](https:\/\/git-scm.com\/book\/es\/v2\/Personalizaci%C3%B3n-de-Git-Git-Attributes)\n   3. 8\\.3 [Puntos de enganche en Git](https:\/\/git-scm.com\/book\/es\/v2\/Personalizaci%C3%B3n-de-Git-Puntos-de-enganche-en-Git)\n   4. 8\\.4 [Un ejemplo de implantación de una determinada política en Git](https:\/\/git-scm.com\/book\/es\/v2\/Personalizaci%C3%B3n-de-Git-Un-ejemplo-de-implantaci%C3%B3n-de-una-determinada-pol%C3%ADtica-en-Git)\n   5. 8\\.5 [Recapitulación](https:\/\/git-scm.com\/book\/es\/v2\/Personalizaci%C3%B3n-de-Git-Recapitulaci%C3%B3n)\n4. ## 9\\. [Git y Otros Sistemas](https:\/\/git-scm.com\/book\/es\/v2\/Git-y-Otros-Sistemas-Git-como-Cliente)\n   1. 9\\.1 [Git como Cliente](https:\/\/git-scm.com\/book\/es\/v2\/Git-y-Otros-Sistemas-Git-como-Cliente)\n   2. 9\\.2 [Migración a Git](https:\/\/git-scm.com\/book\/es\/v2\/Git-y-Otros-Sistemas-Migraci%C3%B3n-a-Git)\n   3. 9\\.3 [Resumen](https:\/\/git-scm.com\/book\/es\/v2\/Git-y-Otros-Sistemas-Resumen)\n5. ## 10\\. [Los entresijos internos de Git](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Fontaner%C3%ADa-y-porcelana)\n   1. 10\\.1 [Fontanería y porcelana](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Fontaner%C3%ADa-y-porcelana)\n   2. 10\\.2 [Los objetos Git](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Los-objetos-Git)\n   3. 10\\.3 [Referencias Git](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Referencias-Git)\n   4. 10\\.4 [Archivos empaquetadores](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Archivos-empaquetadores)\n   5. 10\\.5 [Las especificaciones para hacer referencia a… (refspec)](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Las-especificaciones-para-hacer-referencia-a%E2%80%A6%E2%80%8B-refspec)\n   6. 10\\.6 [Protocolos de transferencia](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Protocolos-de-transferencia)\n   7. 10\\.7 [Mantenimiento y recuperación de datos](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Mantenimiento-y-recuperaci%C3%B3n-de-datos)\n   8. 10\\.8 [Variables de entorno](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Variables-de-entorno)\n   9. 10\\.9 [Recapitulación](https:\/\/git-scm.com\/book\/es\/v2\/Los-entresijos-internos-de-Git-Recapitulaci%C3%B3n)\n\n1. ## A1. [Apéndice A: Git en otros entornos](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Interfaces-gr%C3%A1ficas)\n   1. A1.1 [Interfaces gráficas](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Interfaces-gr%C3%A1ficas)\n   2. A1.2 [Git en Visual Studio](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Visual-Studio)\n   3. A1.3 [Git en Eclipse](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Eclipse)\n   4. A1.4 [Git con Bash](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-con-Bash)\n   5. A1.5 [Git en Zsh](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Zsh)\n   6. A1.6 [Git en Powershell](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Powershell)\n   7. A1.7 [Resumen](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Resumen)\n2. ## A2. [Apéndice B: Integrando Git en tus Aplicaciones](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Git-mediante-L%C3%ADnea-de-Comandos)\n   1. A2.1 [Git mediante Línea de Comandos](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Git-mediante-L%C3%ADnea-de-Comandos)\n   2. A2.2 [Libgit2](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Libgit2)\n   3. A2.3 [JGit](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-JGit)\n3. ## A3. [Apéndice C: Comandos de Git](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Configuraci%C3%B3n)\n   1. A3.1 [Configuración](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Configuraci%C3%B3n)\n   2. A3.2 [Obtener y Crear Proyectos](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Obtener-y-Crear-Proyectos)\n   3. A3.3 [Seguimiento Básico](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Seguimiento-B%C3%A1sico)\n   4. A3.4 [Ramificar y Fusionar](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Ramificar-y-Fusionar)\n   5. A3.5 [Compartir y Actualizar Proyectos](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Compartir-y-Actualizar-Proyectos)\n   6. A3.6 [Inspección y Comparación](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Inspecci%C3%B3n-y-Comparaci%C3%B3n)\n   7. A3.7 [Depuración](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Depuraci%C3%B3n)\n   8. A3.8 [Parcheo](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Parcheo)\n   9. A3.9 [Correo Electrónico](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Correo-Electr%C3%B3nico)\n   10. A3.10 [Sistemas Externos](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Sistemas-Externos)\n   11. A3.11 [Administración](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Administraci%C3%B3n)\n   12. A3.12 [Comandos de Fontanería](https:\/\/git-scm.com\/book\/es\/v2\/Ap%C3%A9ndice-C:-Comandos-de-Git-Comandos-de-Fontaner%C3%ADa)\n\n2nd Edition\n\n# 3\\.5 Ramificaciones en Git - Ramas Remotas\n## Ramas Remotas\nLas ramas remotas son referencias al estado de las ramas en tus repositorios remotos. Son ramas locales que no puedes mover; se mueven automáticamente cuando estableces comunicaciones en la red. Las ramas remotas funcionan como marcadores, para recordarte en qué estado se encontraban tus repositorios remotos la última vez que conectaste con ellos.\n\nSuelen referenciarse como `(remoto)\/(rama)`. Por ejemplo, si quieres saber cómo estaba la rama `master` en el remoto `origin`, puedes revisar la rama `origin\/master`. O si estás trabajando en un problema con un compañero y este envía (push) una rama `iss53`, tú tendrás tu propia rama de trabajo local `iss53`; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama `origin\/iss53`.\n\nEsto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un servidor Git en tu red, en `git.ourcompany.com`. Si haces un clon desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master` y denominará la copia local `origin\/master`. Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; de manera que tengas donde trabajar.\n\n|   |   |\n|---|---|\n| Nota | “origin” no es especial Así como la rama “master” no tiene ningún significado especial en Git, tampoco lo tiene “origin”. “master” es un nombre muy usado solo porque es el nombre por defecto que Git le da a la rama inicial cuando ejecutas `git init`. De la misma manera, “origin” es el nombre por defecto que Git le da a un remoto cuando ejecutas `git clone`. Si en cambio ejecutases `git clone -o booyah`, tendrías una rama `booyah\/master` como rama remota por defecto. |\n\n![Servidor y repositorio local luego de ser clonado.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-1.png)\n\nFigura 30. Servidor y repositorio local luego de ser clonado\n\nSi haces algún trabajo en tu rama `master` local, y al mismo tiempo, alguien más lleva (push) su trabajo al servidor `git.ourcompany.com`, actualizando la rama `master` de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama `origin\/master` no se moverá.\n\n![El trabajo remoto y el local pueden diverger.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-2.png)\n\nFigura 31. El trabajo remoto y el local pueden diverger\n\nPara sincronizarte, puedes utilizar el comando `git fetch origin`. Este comando localiza en qué servidor está el origen (en este caso `git.ourcompany.com`), recupera cualquier dato presente allí que tú no tengas, y actualiza tu base de datos local, moviendo tu rama `origin\/master` para que apunte a la posición más reciente.\n\n![\\`git fetch\\` actualiza las referencias de tu remoto.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-3.png)\n\nFigura 32. `git fetch` actualiza las referencias de tu remoto\n\nPara ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos, supongamos que tienes otro servidor Git; utilizado por uno de tus equipos sprint, solamente para desarrollo. Este servidor se encuentra en `git.team1.ourcompany.com`. Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando `git remote add`, tal y como vimos en [\\[ch02-git-basics\\]](https:\/\/git-scm.com\/book\/es\/v2\/ch00\/ch02-git-basics). Puedes denominar `teamone` a este remoto al asignarle este nombre a la URL.\n\n![Añadiendo otro servidor como remoto.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-4.png)\n\nFigura 33. Añadiendo otro servidor como remoto\n\nAhora, puedes usar el comando `git fetch teamone` para recuperar todo el contenido del remoto `teamone` que tú no tenías. Debido a que dicho servidor es un subconjunto de los datos del servidor `origin` que tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada `teamone\/master` para apuntar a la confirmación (commit) que `teamone` tiene en su rama `master`.\n\n![Seguimiento de la rama remota a través de \\`teamone\/master\\`.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-5.png)\n\nFigura 34. Seguimiento de la rama remota a través de `teamone\/master`\n\n### Publicar\nCuando quieres compartir una rama con el resto del mundo, debes llevarla (push) a un remoto donde tengas permisos de escritura. Tus ramas locales no se sincronizan automáticamente con los remotos en los que escribes, sino que tienes que enviar (push) expresamente las ramas que desees compartir. De esta forma, puedes usar ramas privadas para el trabajo que no deseas compartir, llevando a un remoto tan solo aquellas partes que deseas aportar a los demás.\n\nSi tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando `git push (remoto) (rama)`:\n```\n$ git push origin serverfix\nCounting objects: 24, done.\nDelta compression using up to 8 threads.\nCompressing objects: 100% (15\/15), done.\nWriting objects: 100% (24\/24), 1.91 KiB | 0 bytes\/s, done.\nTotal 24 (delta 2), reused 0 (delta 0)\nTo https:\/\/github.com\/schacon\/simplegit\n * [new branch]      serverfix -> serverfix\n```\nEsto es un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs\/heads\/serverfix:refs\/heads\/serverfix`, que significa: “coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto”. Volveremos más tarde sobre el tema de `refs\/heads\/`, viéndolo en detalle en [\\[ch10-git-internals\\]](https:\/\/git-scm.com\/book\/es\/v2\/ch00\/ch10-git-internals); por ahora, puedes ignorarlo. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: “coge mi `serverfix` y hazlo el `serverfix` remoto”. Puedes utilizar este último formato para llevar una rama local a una rama remota con un nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto.\n\n|   |   |\n|---|---|\n| Nota | No escribas tu contraseña todo el tiempo Si utilizas una dirección URL con HTTPS para enviar datos, el servidor Git te preguntará tu usuario y contraseña para autenticarte. Por defecto, te pedirá esta información a través del terminal, para determinar si estás autorizado a enviar datos. Si no quieres escribir tu contraseña cada vez que haces un envío, puedes establecer un “cache de credenciales”. La manera más sencilla de hacerlo es estableciéndolo en memoria por unos minutos, lo que puedes lograr fácilmente al ejecutar `git config --global credential.helper cache` Para más información sobre las distintas opciones de cache de credenciales, véase [Almacenamiento de credenciales](https:\/\/git-scm.com\/book\/es\/v2\/ch00\/r_credential_caching). |\n\nLa próxima vez que tus colaboradores recuperen desde el servidor, obtendrán bajo la rama remota `origin\/serverfix` una referencia a donde esté la versión de `serverfix` en el servidor:\n```\n$ git fetch origin\nremote: Counting objects: 7, done.\nremote: Compressing objects: 100% (2\/2), done.\nremote: Total 3 (delta 0), reused 3 (delta 0)\nUnpacking objects: 100% (3\/3), done.\nFrom https:\/\/github.com\/schacon\/simplegit\n * [new branch]      serverfix    -> origin\/serverfix\n```\nEs importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia local editable de las mismas. En otras palabras, en este caso, no tienes una nueva rama `serverfix`. Sino que únicamente tienes un puntero no editable a `origin\/serverfix`.\n\nPara integrar (merge) esto en tu rama de trabajo actual, puedes usar el comando `git merge origin\/serverfix`. Y si quieres tener tu propia rama `serverfix` para trabajar, puedes crearla directamente basandote en la rama remota:\n```\n$ git checkout -b serverfix origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'\n```\nEsto sí te da una rama local donde puedes trabajar, que comienza donde `origin\/serverfix` estaba en ese momento.\n\n### Hacer Seguimiento a las Ramas\nAl activar (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar una “rama de seguimiento” (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando `git pull`, Git sabe de cuál servidor recuperar (fetch) y fusionar (merge) datos.\n\nCuando clonas un repositorio, este suele crear automáticamente una rama `master` que hace seguimiento de `origin\/master`. Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que sigan ramas de otros remotos o no seguir la rama `master`. El ejemplo más simple es el que acabas de ver al lanzar el comando `git checkout -b [rama] [nombreremoto]\/[rama]`. Esta operación es tan común que git ofrece el parámetro `--track`:\n```\n$ git checkout --track origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'\n```\nPara preparar una rama local con un nombre distinto a la del remoto, puedes utilizar la primera versión con un nombre de rama local diferente:\n```\n$ git checkout -b sf origin\/serverfix\nBranch sf set up to track remote branch serverfix from origin.\nSwitched to a new branch 'sf'\n```\nAsí, tu rama local `sf` traerá (pull) información automáticamente desde `origin\/serverfix`.\n\nSi ya tienes una rama local y quieres asignarla a una rama remota que acabas de traerte, o quieres cambiar la rama a la que le haces seguimiento, puedes usar en cualquier momento las opciones `-u` o `--set-upstream-to` del comando `git branch`.\n```\n$ git branch -u origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\n```\n|   |   |\n|---|---|\n| Nota | Atajo al *upstream* Cuando tienes asignada una rama de seguimiento, puedes hacer referencia a ella mediante `@{upstream}` o mediante el atajo `@{u}`. De esta manera, si estás en la rama `master` y esta sigue a la rama `origin\/master`, puedes hacer algo como `git merge @{u}` en vez de `git merge origin\/master`. |\n\nSi quieres ver las ramas de seguimiento que tienes asignadas, puedes usar la opción `-vv` con `git branch`. Esto listará tus ramas locales con más información, incluyendo a qué sigue cada rama y si tu rama local está por delante, por detrás o ambas.\n```\n$ git branch -vv\n  iss53     7e424c3 [origin\/iss53: ahead 2] forgot the brackets\n  master    1ae2a45 [origin\/master] deploying index fix\n* serverfix f8674d9 [teamone\/server-fix-good: ahead 3, behind 1] this should do it\n  testing   5ea463a trying something new\n```\nAquí podemos ver que nuestra rama `iss53` sigue `origin\/iss53` y está “ahead” (delante) por dos, es decir, que tenemos dos confirmaciones locales que no han sido enviadas al servidor. También podemos ver que nuestra rama `master` sigue a `origin\/master` y está actualizada. Luego podemos ver que nuestra rama `serverfix` sigue la rama `server-fix-good` de nuestro servidor `teamone` y que está tres cambios por delante (ahead) y uno por detrás (behind), lo que significa que existe una confirmación en el servidor que no hemos fusionado y que tenemos tres confirmaciones locales que no hemos enviado. Por último, podemos ver que nuestra rama `testing` no sigue a ninguna rama remota.\n\nEs importante destacar que estos números se refieren a la última vez que trajiste (fetch) datos de cada servidor. Este comando no se comunica con los servidores, solo te indica lo que sabe de ellos localmente. Si quieres tener los cambios por delante y por detrás actualizados, debes traértelos (fetch) de cada servidor antes de ejecutar el comando. Puedes hacerlo de esta manera: `$ git fetch --all; git branch -vv`\n\n### Traer y Fusionar\nA pesar de que el comando `git fetch` trae todos los cambios que no tienes del servidor, este no modifica tu directorio de trabajo. Simplemente obtendrá los datos y dejará que tú mismo los fusiones. Sin embargo, existe un comando llamado `git pull`, el cuál básicamente hace `git fetch` seguido por `git merge` en la mayoría de los casos. Si tienes una rama de seguimiento configurada como vimos en la última sección, bien sea asignándola explícitamente o creándola mediante los comandos `clone` o `checkout`, `git pull` identificará a qué servidor y rama remota sigue tu rama actual, traerá los datos de dicho servidor e intentará fusionar dicha rama remota.\n\nNormalmente es mejor usar los comandos `fetch` y `merge` de manera explícita pues la magia de `git pull` puede resultar confusa.\n\n### Eliminar Ramas Remotas\nImagina que ya has terminado con una rama remota, es decir, tanto tú como tus colaboradores habéis completado una determinada funcionalidad y la habéis incorporado (merge) a la rama `master` en el remoto (o donde quiera que tengáis la rama de código estable). Puedes borrar la rama remota utilizando la opción `--delete` de `git push`. Por ejemplo, si quieres borrar la rama `serverfix` del servidor, puedes utilizar:\n```\n$ git push origin --delete serverfix\nTo https:\/\/github.com\/schacon\/simplegit\n - [deleted]         serverfix\n```\nBásicamente, lo que hace es eliminar el apuntador del servidor. El servidor Git suele mantener los datos por un tiempo hasta que el recolector de basura se ejecute, de manera que si la has borrado accidentalmente, suele ser fácil recuperarla.\n\n[prev](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Flujos-de-Trabajo-Ramificados) \\| [next](https:\/\/git-scm.com\/book\/es\/v2\/Ramificaciones-en-Git-Reorganizar-el-Trabajo-Realizado)\n\n[About this site](https:\/\/git-scm.com\/site)  \n Patches, suggestions, and comments are welcome.\n\nGit is a member of [Software Freedom Conservancy](https:\/\/git-scm.com\/sfc)","attrs_readable_markdown":"Las ramas remotas son referencias al estado de las ramas en tus repositorios remotos. Son ramas locales que no puedes mover; se mueven automáticamente cuando estableces comunicaciones en la red. Las ramas remotas funcionan como marcadores, para recordarte en qué estado se encontraban tus repositorios remotos la última vez que conectaste con ellos.\n\nSuelen referenciarse como `(remoto)\/(rama)`. Por ejemplo, si quieres saber cómo estaba la rama `master` en el remoto `origin`, puedes revisar la rama `origin\/master`. O si estás trabajando en un problema con un compañero y este envía (push) una rama `iss53`, tú tendrás tu propia rama de trabajo local `iss53`; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama `origin\/iss53`.\n\nEsto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un servidor Git en tu red, en `git.ourcompany.com`. Si haces un clon desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master` y denominará la copia local `origin\/master`. Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; de manera que tengas donde trabajar.\n\n|   |   |\n|---|---|\n| Nota | “origin” no es especial Así como la rama “master” no tiene ningún significado especial en Git, tampoco lo tiene “origin”. “master” es un nombre muy usado solo porque es el nombre por defecto que Git le da a la rama inicial cuando ejecutas `git init`. De la misma manera, “origin” es el nombre por defecto que Git le da a un remoto cuando ejecutas `git clone`. Si en cambio ejecutases `git clone -o booyah`, tendrías una rama `booyah\/master` como rama remota por defecto. |\n\n![Servidor y repositorio local luego de ser clonado.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-1.png)\n\nFigura 30. Servidor y repositorio local luego de ser clonado\n\nSi haces algún trabajo en tu rama `master` local, y al mismo tiempo, alguien más lleva (push) su trabajo al servidor `git.ourcompany.com`, actualizando la rama `master` de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama `origin\/master` no se moverá.\n\n![El trabajo remoto y el local pueden diverger.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-2.png)\n\nFigura 31. El trabajo remoto y el local pueden diverger\n\nPara sincronizarte, puedes utilizar el comando `git fetch origin`. Este comando localiza en qué servidor está el origen (en este caso `git.ourcompany.com`), recupera cualquier dato presente allí que tú no tengas, y actualiza tu base de datos local, moviendo tu rama `origin\/master` para que apunte a la posición más reciente.\n\n![\\`git fetch\\` actualiza las referencias de tu remoto.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-3.png)\n\nFigura 32. `git fetch` actualiza las referencias de tu remoto\n\nPara ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos, supongamos que tienes otro servidor Git; utilizado por uno de tus equipos sprint, solamente para desarrollo. Este servidor se encuentra en `git.team1.ourcompany.com`. Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando `git remote add`, tal y como vimos en [\\[ch02-git-basics\\]](https:\/\/git-scm.com\/book\/es\/v2\/ch00\/ch02-git-basics). Puedes denominar `teamone` a este remoto al asignarle este nombre a la URL.\n\n![Añadiendo otro servidor como remoto.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-4.png)\n\nFigura 33. Añadiendo otro servidor como remoto\n\nAhora, puedes usar el comando `git fetch teamone` para recuperar todo el contenido del remoto `teamone` que tú no tenías. Debido a que dicho servidor es un subconjunto de los datos del servidor `origin` que tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada `teamone\/master` para apuntar a la confirmación (commit) que `teamone` tiene en su rama `master`.\n\n![Seguimiento de la rama remota a través de \\`teamone\/master\\`.](https:\/\/git-scm.com\/book\/es\/v2\/images\/remote-branches-5.png)\n\nFigura 34. Seguimiento de la rama remota a través de `teamone\/master`\n\n### Publicar\nCuando quieres compartir una rama con el resto del mundo, debes llevarla (push) a un remoto donde tengas permisos de escritura. Tus ramas locales no se sincronizan automáticamente con los remotos en los que escribes, sino que tienes que enviar (push) expresamente las ramas que desees compartir. De esta forma, puedes usar ramas privadas para el trabajo que no deseas compartir, llevando a un remoto tan solo aquellas partes que deseas aportar a los demás.\n\nSi tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando `git push (remoto) (rama)`:\n```\n$ git push origin serverfix\nCounting objects: 24, done.\nDelta compression using up to 8 threads.\nCompressing objects: 100% (15\/15), done.\nWriting objects: 100% (24\/24), 1.91 KiB | 0 bytes\/s, done.\nTotal 24 (delta 2), reused 0 (delta 0)\nTo https:\/\/github.com\/schacon\/simplegit\n * [new branch]      serverfix -> serverfix\n```\nEsto es un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs\/heads\/serverfix:refs\/heads\/serverfix`, que significa: “coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto”. Volveremos más tarde sobre el tema de `refs\/heads\/`, viéndolo en detalle en [\\[ch10-git-internals\\]](https:\/\/git-scm.com\/book\/es\/v2\/ch00\/ch10-git-internals); por ahora, puedes ignorarlo. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: “coge mi `serverfix` y hazlo el `serverfix` remoto”. Puedes utilizar este último formato para llevar una rama local a una rama remota con un nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto.\n\n|   |   |\n|---|---|\n| Nota | No escribas tu contraseña todo el tiempo Si utilizas una dirección URL con HTTPS para enviar datos, el servidor Git te preguntará tu usuario y contraseña para autenticarte. Por defecto, te pedirá esta información a través del terminal, para determinar si estás autorizado a enviar datos. Si no quieres escribir tu contraseña cada vez que haces un envío, puedes establecer un “cache de credenciales”. La manera más sencilla de hacerlo es estableciéndolo en memoria por unos minutos, lo que puedes lograr fácilmente al ejecutar `git config --global credential.helper cache` |\n\nLa próxima vez que tus colaboradores recuperen desde el servidor, obtendrán bajo la rama remota `origin\/serverfix` una referencia a donde esté la versión de `serverfix` en el servidor:\n```\n$ git fetch origin\nremote: Counting objects: 7, done.\nremote: Compressing objects: 100% (2\/2), done.\nremote: Total 3 (delta 0), reused 3 (delta 0)\nUnpacking objects: 100% (3\/3), done.\nFrom https:\/\/github.com\/schacon\/simplegit\n * [new branch]      serverfix    -> origin\/serverfix\n```\nEs importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia local editable de las mismas. En otras palabras, en este caso, no tienes una nueva rama `serverfix`. Sino que únicamente tienes un puntero no editable a `origin\/serverfix`.\n\nPara integrar (merge) esto en tu rama de trabajo actual, puedes usar el comando `git merge origin\/serverfix`. Y si quieres tener tu propia rama `serverfix` para trabajar, puedes crearla directamente basandote en la rama remota:\n```\n$ git checkout -b serverfix origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'\n```\nEsto sí te da una rama local donde puedes trabajar, que comienza donde `origin\/serverfix` estaba en ese momento.\n\n### Hacer Seguimiento a las Ramas\nAl activar (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar una “rama de seguimiento” (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando `git pull`, Git sabe de cuál servidor recuperar (fetch) y fusionar (merge) datos.\n\nCuando clonas un repositorio, este suele crear automáticamente una rama `master` que hace seguimiento de `origin\/master`. Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que sigan ramas de otros remotos o no seguir la rama `master`. El ejemplo más simple es el que acabas de ver al lanzar el comando `git checkout -b [rama] [nombreremoto]\/[rama]`. Esta operación es tan común que git ofrece el parámetro `--track`:\n```\n$ git checkout --track origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\nSwitched to a new branch 'serverfix'\n```\nPara preparar una rama local con un nombre distinto a la del remoto, puedes utilizar la primera versión con un nombre de rama local diferente:\n```\n$ git checkout -b sf origin\/serverfix\nBranch sf set up to track remote branch serverfix from origin.\nSwitched to a new branch 'sf'\n```\nAsí, tu rama local `sf` traerá (pull) información automáticamente desde `origin\/serverfix`.\n\nSi ya tienes una rama local y quieres asignarla a una rama remota que acabas de traerte, o quieres cambiar la rama a la que le haces seguimiento, puedes usar en cualquier momento las opciones `-u` o `--set-upstream-to` del comando `git branch`.\n```\n$ git branch -u origin\/serverfix\nBranch serverfix set up to track remote branch serverfix from origin.\n```\n|   |   |\n|---|---|\n| Nota | Atajo al *upstream* Cuando tienes asignada una rama de seguimiento, puedes hacer referencia a ella mediante `@{upstream}` o mediante el atajo `@{u}`. De esta manera, si estás en la rama `master` y esta sigue a la rama `origin\/master`, puedes hacer algo como `git merge @{u}` en vez de `git merge origin\/master`. |\n\nSi quieres ver las ramas de seguimiento que tienes asignadas, puedes usar la opción `-vv` con `git branch`. Esto listará tus ramas locales con más información, incluyendo a qué sigue cada rama y si tu rama local está por delante, por detrás o ambas.\n```\n$ git branch -vv\n  iss53     7e424c3 [origin\/iss53: ahead 2] forgot the brackets\n  master    1ae2a45 [origin\/master] deploying index fix\n* serverfix f8674d9 [teamone\/server-fix-good: ahead 3, behind 1] this should do it\n  testing   5ea463a trying something new\n```\nAquí podemos ver que nuestra rama `iss53` sigue `origin\/iss53` y está “ahead” (delante) por dos, es decir, que tenemos dos confirmaciones locales que no han sido enviadas al servidor. También podemos ver que nuestra rama `master` sigue a `origin\/master` y está actualizada. Luego podemos ver que nuestra rama `serverfix` sigue la rama `server-fix-good` de nuestro servidor `teamone` y que está tres cambios por delante (ahead) y uno por detrás (behind), lo que significa que existe una confirmación en el servidor que no hemos fusionado y que tenemos tres confirmaciones locales que no hemos enviado. Por último, podemos ver que nuestra rama `testing` no sigue a ninguna rama remota.\n\nEs importante destacar que estos números se refieren a la última vez que trajiste (fetch) datos de cada servidor. Este comando no se comunica con los servidores, solo te indica lo que sabe de ellos localmente. Si quieres tener los cambios por delante y por detrás actualizados, debes traértelos (fetch) de cada servidor antes de ejecutar el comando. Puedes hacerlo de esta manera: `$ git fetch --all; git branch -vv`\n\n### Traer y Fusionar\nA pesar de que el comando `git fetch` trae todos los cambios que no tienes del servidor, este no modifica tu directorio de trabajo. Simplemente obtendrá los datos y dejará que tú mismo los fusiones. Sin embargo, existe un comando llamado `git pull`, el cuál básicamente hace `git fetch` seguido por `git merge` en la mayoría de los casos. Si tienes una rama de seguimiento configurada como vimos en la última sección, bien sea asignándola explícitamente o creándola mediante los comandos `clone` o `checkout`, `git pull` identificará a qué servidor y rama remota sigue tu rama actual, traerá los datos de dicho servidor e intentará fusionar dicha rama remota.\n\nNormalmente es mejor usar los comandos `fetch` y `merge` de manera explícita pues la magia de `git pull` puede resultar confusa.\n\n### Eliminar Ramas Remotas\nImagina que ya has terminado con una rama remota, es decir, tanto tú como tus colaboradores habéis completado una determinada funcionalidad y la habéis incorporado (merge) a la rama `master` en el remoto (o donde quiera que tengáis la rama de código estable). Puedes borrar la rama remota utilizando la opción `--delete` de `git push`. Por ejemplo, si quieres borrar la rama `serverfix` del servidor, puedes utilizar:\n```\n$ git push origin --delete serverfix\nTo https:\/\/github.com\/schacon\/simplegit\n - [deleted]         serverfix\n```\nBásicamente, lo que hace es eliminar el apuntador del servidor. El servidor Git suele mantener los datos por un tiempo hasta que el recolector de basura se ejecute, de manera que si la has borrado accidentalmente, suele ser fácil recuperarla.","meta_canonical":null}

3. Robots.txt Check

Query:

Response:

4. Spam/Ban Check

Query:

Response:

5. Seen Status Check

ℹ️ Skipped - page is already crawled

📄

INDEXABLE

✅

CRAWLED

1 day ago

🤖

ROBOTS ALLOWED

Page Info Filters

Filter	Status	Condition	Details
HTTP status	PASS	`download_http_code = 200`	HTTP 200
Age cutoff	PASS	`download_stamp > now() - 6 MONTH`	0.1 months ago
History drop	PASS	`isNull(history_drop_reason)`	No drop reason
Spam/ban	PASS	`fh_dont_index != 1 AND ml_spam_score = 0`	ml_spam_score=0
Canonical	PASS	`meta_canonical IS NULL OR = '' OR = src_unparsed`	Not set

Page Details

Property	Value
URL	https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas
Last Crawled	2026-04-05 23:42:30 (1 day ago)
First Indexed	2015-03-10 03:20:30 (11 years ago)
HTTP Status Code	200
Meta Title	Git - Ramas Remotas
Meta Description	null
Meta Canonical	null
Boilerpipe Text	Las ramas remotas son referencias al estado de las ramas en tus repositorios remotos. Son ramas locales que no puedes mover; se mueven automáticamente cuando estableces comunicaciones en la red. Las ramas remotas funcionan como marcadores, para recordarte en qué estado se encontraban tus repositorios remotos la última vez que conectaste con ellos. Suelen referenciarse como (remoto)/(rama) . Por ejemplo, si quieres saber cómo estaba la rama master en el remoto origin , puedes revisar la rama origin/master . O si estás trabajando en un problema con un compañero y este envía (push) una rama iss53 , tú tendrás tu propia rama de trabajo local iss53 ; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama origin/iss53 . Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un servidor Git en tu red, en git.ourcompany.com . Si haces un clon desde ahí, Git automáticamente lo denominará origin , traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama master y denominará la copia local origin/master . Git te proporcionará también tu propia rama master , apuntando al mismo lugar que la rama master de origin ; de manera que tengas donde trabajar. Nota “origin” no es especial Así como la rama “master” no tiene ningún significado especial en Git, tampoco lo tiene “origin”. “master” es un nombre muy usado solo porque es el nombre por defecto que Git le da a la rama inicial cuando ejecutas git init . De la misma manera, “origin” es el nombre por defecto que Git le da a un remoto cuando ejecutas git clone . Si en cambio ejecutases git clone -o booyah , tendrías una rama booyah/master como rama remota por defecto. Figura 30. Servidor y repositorio local luego de ser clonado Si haces algún trabajo en tu rama master local, y al mismo tiempo, alguien más lleva (push) su trabajo al servidor git.ourcompany.com , actualizando la rama master de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama origin/master no se moverá. Figura 31. El trabajo remoto y el local pueden diverger Para sincronizarte, puedes utilizar el comando git fetch origin . Este comando localiza en qué servidor está el origen (en este caso git.ourcompany.com ), recupera cualquier dato presente allí que tú no tengas, y actualiza tu base de datos local, moviendo tu rama origin/master para que apunte a la posición más reciente. Figura 32. git fetch actualiza las referencias de tu remoto Para ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos, supongamos que tienes otro servidor Git; utilizado por uno de tus equipos sprint, solamente para desarrollo. Este servidor se encuentra en git.team1.ourcompany.com . Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando git remote add , tal y como vimos en [ch02-git-basics] . Puedes denominar teamone a este remoto al asignarle este nombre a la URL. Figura 33. Añadiendo otro servidor como remoto Ahora, puedes usar el comando git fetch teamone para recuperar todo el contenido del remoto teamone que tú no tenías. Debido a que dicho servidor es un subconjunto de los datos del servidor origin que tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada teamone/master para apuntar a la confirmación (commit) que teamone tiene en su rama master . Figura 34. Seguimiento de la rama remota a través de teamone/master Publicar Cuando quieres compartir una rama con el resto del mundo, debes llevarla (push) a un remoto donde tengas permisos de escritura. Tus ramas locales no se sincronizan automáticamente con los remotos en los que escribes, sino que tienes que enviar (push) expresamente las ramas que desees compartir. De esta forma, puedes usar ramas privadas para el trabajo que no deseas compartir, llevando a un remoto tan solo aquellas partes que deseas aportar a los demás. Si tienes una rama llamada serverfix , con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando git push (remoto) (rama) : $ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB \| 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix Esto es un atajo. Git expande automáticamente el nombre de rama serverfix a refs/heads/serverfix:refs/heads/serverfix , que significa: “coge mi rama local serverfix y actualiza con ella la rama serverfix del remoto”. Volveremos más tarde sobre el tema de refs/heads/ , viéndolo en detalle en [ch10-git-internals] ; por ahora, puedes ignorarlo. También puedes hacer git push origin serverfix:serverfix , que hace lo mismo; es decir: “coge mi serverfix y hazlo el serverfix remoto”. Puedes utilizar este último formato para llevar una rama local a una rama remota con un nombre distinto. Si no quieres que se llame serverfix en el remoto, puedes lanzar, por ejemplo, git push origin serverfix:awesomebranch ; para llevar tu rama serverfix local a la rama awesomebranch en el proyecto remoto. Nota No escribas tu contraseña todo el tiempo Si utilizas una dirección URL con HTTPS para enviar datos, el servidor Git te preguntará tu usuario y contraseña para autenticarte. Por defecto, te pedirá esta información a través del terminal, para determinar si estás autorizado a enviar datos. Si no quieres escribir tu contraseña cada vez que haces un envío, puedes establecer un “cache de credenciales”. La manera más sencilla de hacerlo es estableciéndolo en memoria por unos minutos, lo que puedes lograr fácilmente al ejecutar git config --global credential.helper cache La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán bajo la rama remota origin/serverfix una referencia a donde esté la versión de serverfix en el servidor: $ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia local editable de las mismas. En otras palabras, en este caso, no tienes una nueva rama serverfix . Sino que únicamente tienes un puntero no editable a origin/serverfix . Para integrar (merge) esto en tu rama de trabajo actual, puedes usar el comando git merge origin/serverfix . Y si quieres tener tu propia rama serverfix para trabajar, puedes crearla directamente basandote en la rama remota: $ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' Esto sí te da una rama local donde puedes trabajar, que comienza donde origin/serverfix estaba en ese momento. Hacer Seguimiento a las Ramas Al activar (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar una “rama de seguimiento” (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando git pull , Git sabe de cuál servidor recuperar (fetch) y fusionar (merge) datos. Cuando clonas un repositorio, este suele crear automáticamente una rama master que hace seguimiento de origin/master . Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que sigan ramas de otros remotos o no seguir la rama master . El ejemplo más simple es el que acabas de ver al lanzar el comando git checkout -b [rama] [nombreremoto]/[rama] . Esta operación es tan común que git ofrece el parámetro --track : $ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' Para preparar una rama local con un nombre distinto a la del remoto, puedes utilizar la primera versión con un nombre de rama local diferente: $ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' Así, tu rama local sf traerá (pull) información automáticamente desde origin/serverfix . Si ya tienes una rama local y quieres asignarla a una rama remota que acabas de traerte, o quieres cambiar la rama a la que le haces seguimiento, puedes usar en cualquier momento las opciones -u o --set-upstream-to del comando git branch . $ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Nota Atajo al upstream Cuando tienes asignada una rama de seguimiento, puedes hacer referencia a ella mediante @{upstream} o mediante el atajo @{u} . De esta manera, si estás en la rama master y esta sigue a la rama origin/master , puedes hacer algo como git merge @{u} en vez de git merge origin/master . Si quieres ver las ramas de seguimiento que tienes asignadas, puedes usar la opción -vv con git branch . Esto listará tus ramas locales con más información, incluyendo a qué sigue cada rama y si tu rama local está por delante, por detrás o ambas. $ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets master 1ae2a45 [origin/master] deploying index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it testing 5ea463a trying something new Aquí podemos ver que nuestra rama iss53 sigue origin/iss53 y está “ahead” (delante) por dos, es decir, que tenemos dos confirmaciones locales que no han sido enviadas al servidor. También podemos ver que nuestra rama master sigue a origin/master y está actualizada. Luego podemos ver que nuestra rama serverfix sigue la rama server-fix-good de nuestro servidor teamone y que está tres cambios por delante (ahead) y uno por detrás (behind), lo que significa que existe una confirmación en el servidor que no hemos fusionado y que tenemos tres confirmaciones locales que no hemos enviado. Por último, podemos ver que nuestra rama testing no sigue a ninguna rama remota. Es importante destacar que estos números se refieren a la última vez que trajiste (fetch) datos de cada servidor. Este comando no se comunica con los servidores, solo te indica lo que sabe de ellos localmente. Si quieres tener los cambios por delante y por detrás actualizados, debes traértelos (fetch) de cada servidor antes de ejecutar el comando. Puedes hacerlo de esta manera: $ git fetch --all; git branch -vv Traer y Fusionar A pesar de que el comando git fetch trae todos los cambios que no tienes del servidor, este no modifica tu directorio de trabajo. Simplemente obtendrá los datos y dejará que tú mismo los fusiones. Sin embargo, existe un comando llamado git pull , el cuál básicamente hace git fetch seguido por git merge en la mayoría de los casos. Si tienes una rama de seguimiento configurada como vimos en la última sección, bien sea asignándola explícitamente o creándola mediante los comandos clone o checkout , git pull identificará a qué servidor y rama remota sigue tu rama actual, traerá los datos de dicho servidor e intentará fusionar dicha rama remota. Normalmente es mejor usar los comandos fetch y merge de manera explícita pues la magia de git pull puede resultar confusa. Eliminar Ramas Remotas Imagina que ya has terminado con una rama remota, es decir, tanto tú como tus colaboradores habéis completado una determinada funcionalidad y la habéis incorporado (merge) a la rama master en el remoto (o donde quiera que tengáis la rama de código estable). Puedes borrar la rama remota utilizando la opción --delete de git push . Por ejemplo, si quieres borrar la rama serverfix del servidor, puedes utilizar: $ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix Básicamente, lo que hace es eliminar el apuntador del servidor. El servidor Git suele mantener los datos por un tiempo hasta que el recolector de basura se ejecute, de manera que si la has borrado accidentalmente, suele ser fácil recuperarla.
Markdown	[![Git](https://git-scm.com/images/logo@2x.png)](https://git-scm.com/) \--fast-version-control ![](https://git-scm.com/images/dark-mode.svg) - [About](https://git-scm.com/about) - [Trademark](https://git-scm.com/about/trademark) - [Learn](https://git-scm.com/learn) - [Book](https://git-scm.com/book) - [Cheat Sheet](https://git-scm.com/cheat-sheet) - [Videos](https://git-scm.com/videos) - [External Links](https://git-scm.com/doc/ext) - [Tools](https://git-scm.com/tools) - [Command Line](https://git-scm.com/tools/command-line) - [GUIs](https://git-scm.com/tools/guis) - [Hosting](https://git-scm.com/tools/hosting) - [Reference](https://git-scm.com/docs) - [Install](https://git-scm.com/install/linux) - [Community](https://git-scm.com/community) * This book is available in [English](https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches). Full translation available in \| \| \|---\| \| [azərbaycan dili](https://git-scm.com/book/az/v2/Git%E2%80%99d%C9%99-Branch-Uzaq-Branch%E2%80%99lar), \| \| [български език](https://git-scm.com/book/bg/v2/%D0%9A%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%D0%B5-%D0%B2-Git-%D0%9E%D1%82%D0%B4%D0%B0%D0%BB%D0%B5%D1%87%D0%B5%D0%BD%D0%B8-%D0%BA%D0%BB%D0%BE%D0%BD%D0%BE%D0%B2%D0%B5), \| \| [Deutsch](https://git-scm.com/book/de/v2/Git-Branching-Remote-Branches), \| \| [Español](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas), \| \| [فارسی](https://git-scm.com/book/fa/v2/%D8%A7%D9%86%D8%B4%D8%B9%D8%A7%D8%A8%E2%80%8C%DA%AF%DB%8C%D8%B1%DB%8C-%D8%AF%D8%B1-%DA%AF%DB%8C%D8%AA-Git-Branching-%D8%B4%D8%A7%D8%AE%D9%87%E2%80%8C%D9%87%D8%A7%DB%8C-%D8%B1%D8%A7%D9%87-%D8%AF%D9%88%D8%B1-Remote-Branches), \| \| [Français](https://git-scm.com/book/fr/v2/Les-branches-avec-Git-Branches-de-suivi-%C3%A0-distance), \| \| [Ελληνικά](https://git-scm.com/book/gr/v2/%CE%94%CE%B9%CE%B1%CE%BA%CE%BB%CE%B1%CE%B4%CF%8E%CF%83%CE%B5%CE%B9%CF%82-%CF%83%CF%84%CE%BF-Git-%CE%91%CF%80%CE%BF%CE%BC%CE%B1%CE%BA%CF%81%CF%85%CF%83%CE%BC%CE%AD%CE%BD%CE%BF%CE%B9-%CE%BA%CE%BB%CE%AC%CE%B4%CE%BF%CE%B9), \| \| [日本語](https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81), \| \| [한국어](https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EB%B8%8C%EB%9E%9C%EC%B9%98), \| \| [Nederlands](https://git-scm.com/book/nl/v2/Branchen-in-Git-Branches-op-afstand-Remote-branches), \| \| [Русский](https://git-scm.com/book/ru/v2/%D0%92%D0%B5%D1%82%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2-Git-%D0%A3%D0%B4%D0%B0%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%B5-%D0%B2%D0%B5%D1%82%D0%BA%D0%B8), \| \| [Slovenščina](https://git-scm.com/book/sl/v2/Veje-Git-Oddaljene-veje), \| \| [Српски](https://git-scm.com/book/sr/v2/%D0%93%D1%80%D0%B0%D0%BD%D0%B0%D1%9A%D0%B5-%D1%83-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83-%D0%93%D0%B8%D1%82-%D0%A3%D0%B4%D0%B0%D1%99%D0%B5%D0%BD%D0%B5-%D0%B3%D1%80%D0%B0%D0%BD%D0%B5), \| \| [Svenska](https://git-scm.com/book/sv/v2/Git-grenar-Fj%C3%A4rrgrenar), \| \| [Tagalog](https://git-scm.com/book/tl/v2/Pag-branch-ng-Git-Remote-na-mga-Branch), \| \| [Türkçe](https://git-scm.com/book/tr/v2/Git-Dallar%C4%B1-Uzak-Dallar). \| \| [Українська](https://git-scm.com/book/uk/v2/%D0%93%D0%B0%D0%BB%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8F-%D0%B2-git-%D0%92%D1%96%D0%B4%D0%B4%D0%B0%D0%BB%D0%B5%D0%BD%D1%96-%D0%B3%D1%96%D0%BB%D0%BA%D0%B8), \| \| [简体中文](https://git-scm.com/book/zh/v2/Git-%E5%88%86%E6%94%AF-%E8%BF%9C%E7%A8%8B%E5%88%86%E6%94%AF), \| Partial translations available in \| \| \|---\| \| [Čeština](https://git-scm.com/book/cs/v2/V%C4%9Btve-v-syst%C3%A9mu-Git-Vzd%C3%A1len%C3%A9-v%C4%9Btve), \| \| [Македонски](https://git-scm.com/book/mk/v2/%D0%93%D1%80%D0%B0%D0%BD%D0%B5%D1%9A%D0%B5-%D0%B2%D0%BE-Git-%D0%94%D0%B0%D0%BB%D0%B5%D1%87%D0%B8%D0%BD%D1%81%D0%BA%D0%B8-%D0%B3%D1%80%D0%B0%D0%BD%D0%BA%D0%B8), \| \| [Polski](https://git-scm.com/book/pl/v2/Ga%C5%82%C4%99zie-Gita-Ga%C5%82%C4%99zie-zdalne), \| \| [Português (Brasil)](https://git-scm.com/book/pt-br/v2/Branches-no-Git-Branches-remotos), \| \| [Ўзбекча](https://git-scm.com/book/uz/v2/Git-%D0%B4%D0%B0-%D1%82%D0%B0%D1%80%D0%BC%D0%BE%D2%9B%D0%BB%D0%B0%D0%BD%D0%B8%D1%88-%D0%A3%D0%B7%D0%BE%D2%9B-%D0%BC%D0%B0%D1%81%D0%BE%D1%84%D0%B0%D0%B4%D0%B0%D0%B3%D0%B8-%D1%82%D0%B0%D1%80%D0%BC%D0%BE%D2%9B%D0%BB%D0%B0%D1%80), \| \| [繁體中文](https://git-scm.com/book/zh-tw/v2/%E4%BD%BF%E7%94%A8-Git-%E5%88%86%E6%94%AF-%E9%81%A0%E7%AB%AF%E5%88%86%E6%94%AF), \| Translations started for \| \| \|---\| \| [Беларуская](https://git-scm.com/book/be/v2/Git-Branching-Remote-Branches), \| \| [Indonesian](https://git-scm.com/book/id/v2/Git-Branching-Remote-Branches), \| \| [Italiano](https://git-scm.com/book/it/v2/Git-Branching-Remote-Branches), \| \| [Bahasa Melayu](https://git-scm.com/book/ms/v2/Git-Branching-Remote-Branches), \| \| [Português (Portugal)](https://git-scm.com/book/pt-pt/v2/Ramifica%C3%A7%C3%A3o-do-Git-Remote-Branches). \| * The source of this book is [hosted on GitHub.](https://github.com/progit/progit2-es) Patches, suggestions and comments are welcome. [Chapters ▾](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas) 1. ## 1\. [Inicio - Sobre el Control de Versiones](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones) 1. 1\.1 [Acerca del Control de Versiones](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Acerca-del-Control-de-Versiones) 2. 1\.2 [Una breve historia de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Una-breve-historia-de-Git) 3. 1\.3 [Fundamentos de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Fundamentos-de-Git) 4. 1\.4 [La Línea de Comandos](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-La-L%C3%ADnea-de-Comandos) 5. 1\.5 [Instalación de Git](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Instalaci%C3%B3n-de-Git) 6. 1\.6 [Configurando Git por primera vez](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Configurando-Git-por-primera-vez) 7. 1\.7 [¿Cómo obtener ayuda?](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-%C2%BFC%C3%B3mo-obtener-ayuda%3F) 8. 1\.8 [Resumen](https://git-scm.com/book/es/v2/Inicio---Sobre-el-Control-de-Versiones-Resumen) 2. ## 2\. [Fundamentos de Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Obteniendo-un-repositorio-Git) 1. 2\.1 [Obteniendo un repositorio Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Obteniendo-un-repositorio-Git) 2. 2\.2 [Guardando cambios en el Repositorio](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio) 3. 2\.3 [Ver el Historial de Confirmaciones](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Ver-el-Historial-de-Confirmaciones) 4. 2\.4 [Deshacer Cosas](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Deshacer-Cosas) 5. 2\.5 [Trabajar con Remotos](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Trabajar-con-Remotos) 6. 2\.6 [Etiquetado](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Etiquetado) 7. 2\.7 [Alias de Git](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Alias-de-Git) 8. 2\.8 [Resumen](https://git-scm.com/book/es/v2/Fundamentos-de-Git-Resumen) 3. ## 3\. [Ramificaciones en Git](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F) 1. 3\.1 [¿Qué es una rama?](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-%C2%BFQu%C3%A9-es-una-rama%3F) 2. 3\.2 [Procedimientos Básicos para Ramificar y Fusionar](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Procedimientos-B%C3%A1sicos-para-Ramificar-y-Fusionar) 3. 3\.3 [Gestión de Ramas](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Gesti%C3%B3n-de-Ramas) 4. 3\.4 [Flujos de Trabajo Ramificados](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Flujos-de-Trabajo-Ramificados) 5. 3\.5 [Ramas Remotas](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas) 6. 3\.6 [Reorganizar el Trabajo Realizado](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Reorganizar-el-Trabajo-Realizado) 7. 3\.7 [Recapitulación](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Recapitulaci%C3%B3n) 4. ## 4\. [Git en el Servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Los-Protocolos) 1. 4\.1 [Los Protocolos](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Los-Protocolos) 2. 4\.2 [Configurando Git en un servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Configurando-Git-en-un-servidor) 3. 4\.3 [Generando tu clave pública SSH](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Generando-tu-clave-p%C3%BAblica-SSH) 4. 4\.4 [Configurando el servidor](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Configurando-el-servidor) 5. 4\.5 [El demonio Git](https://git-scm.com/book/es/v2/Git-en-el-Servidor-El-demonio-Git) 6. 4\.6 [HTTP Inteligente](https://git-scm.com/book/es/v2/Git-en-el-Servidor-HTTP-Inteligente) 7. 4\.7 [GitWeb](https://git-scm.com/book/es/v2/Git-en-el-Servidor-GitWeb) 8. 4\.8 [GitLab](https://git-scm.com/book/es/v2/Git-en-el-Servidor-GitLab) 9. 4\.9 [Git en un alojamiento externo](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Git-en-un-alojamiento-externo) 10. 4\.10 [Resumen](https://git-scm.com/book/es/v2/Git-en-el-Servidor-Resumen) 5. ## 5\. [Git en entornos distribuidos](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos) 1. 5\.1 [Flujos de trabajo distribuidos](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Flujos-de-trabajo-distribuidos) 2. 5\.2 [Contribuyendo a un Proyecto](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Contribuyendo-a-un-Proyecto) 3. 5\.3 [Manteniendo un proyecto](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Manteniendo-un-proyecto) 4. 5\.4 [Resumen](https://git-scm.com/book/es/v2/Git-en-entornos-distribuidos-Resumen) 1. ## 6\. [GitHub](https://git-scm.com/book/es/v2/GitHub-Creaci%C3%B3n-y-configuraci%C3%B3n-de-la-cuenta) 1. 6\.1 [Creación y configuración de la cuenta](https://git-scm.com/book/es/v2/GitHub-Creaci%C3%B3n-y-configuraci%C3%B3n-de-la-cuenta) 2. 6\.2 [Participando en Proyectos](https://git-scm.com/book/es/v2/GitHub-Participando-en-Proyectos) 3. 6\.3 [Mantenimiento de un proyecto](https://git-scm.com/book/es/v2/GitHub-Mantenimiento-de-un-proyecto) 4. 6\.4 [Gestión de una organización](https://git-scm.com/book/es/v2/GitHub-Gesti%C3%B3n-de-una-organizaci%C3%B3n) 5. 6\.5 [Scripting en GitHub](https://git-scm.com/book/es/v2/GitHub-Scripting-en-GitHub) 6. 6\.6 [Resumen](https://git-scm.com/book/es/v2/GitHub-Resumen) 2. ## 7\. [Herramientas de Git](https://git-scm.com/book/es/v2/Herramientas-de-Git-Revisi%C3%B3n-por-selecci%C3%B3n) 1. 7\.1 [Revisión por selección](https://git-scm.com/book/es/v2/Herramientas-de-Git-Revisi%C3%B3n-por-selecci%C3%B3n) 2. 7\.2 [Organización interactiva](https://git-scm.com/book/es/v2/Herramientas-de-Git-Organizaci%C3%B3n-interactiva) 3. 7\.3 [Guardado rápido y Limpieza](https://git-scm.com/book/es/v2/Herramientas-de-Git-Guardado-r%C3%A1pido-y-Limpieza) 4. 7\.4 [Firmando tu trabajo](https://git-scm.com/book/es/v2/Herramientas-de-Git-Firmando-tu-trabajo) 5. 7\.5 [Buscando](https://git-scm.com/book/es/v2/Herramientas-de-Git-Buscando) 6. 7\.6 [Reescribiendo la Historia](https://git-scm.com/book/es/v2/Herramientas-de-Git-Reescribiendo-la-Historia) 7. 7\.7 [Reiniciar Desmitificado](https://git-scm.com/book/es/v2/Herramientas-de-Git-Reiniciar-Desmitificado) 8. 7\.8 [Fusión Avanzada](https://git-scm.com/book/es/v2/Herramientas-de-Git-Fusi%C3%B3n-Avanzada) 9. 7\.9 [Rerere](https://git-scm.com/book/es/v2/Herramientas-de-Git-Rerere) 10. 7\.10 [Haciendo debug con Git](https://git-scm.com/book/es/v2/Herramientas-de-Git-Haciendo-debug-con-Git) 11. 7\.11 [Submódulos](https://git-scm.com/book/es/v2/Herramientas-de-Git-Subm%C3%B3dulos) 12. 7\.12 [Agrupaciones](https://git-scm.com/book/es/v2/Herramientas-de-Git-Agrupaciones) 13. 7\.13 [Replace](https://git-scm.com/book/es/v2/Herramientas-de-Git-Replace) 14. 7\.14 [Almacenamiento de credenciales](https://git-scm.com/book/es/v2/Herramientas-de-Git-Almacenamiento-de-credenciales) 15. 7\.15 [Resumen](https://git-scm.com/book/es/v2/Herramientas-de-Git-Resumen) 3. ## 8\. [Personalización de Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git) 1. 8\.1 [Configuración de Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Configuraci%C3%B3n-de-Git) 2. 8\.2 [Git Attributes](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Git-Attributes) 3. 8\.3 [Puntos de enganche en Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Puntos-de-enganche-en-Git) 4. 8\.4 [Un ejemplo de implantación de una determinada política en Git](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Un-ejemplo-de-implantaci%C3%B3n-de-una-determinada-pol%C3%ADtica-en-Git) 5. 8\.5 [Recapitulación](https://git-scm.com/book/es/v2/Personalizaci%C3%B3n-de-Git-Recapitulaci%C3%B3n) 4. ## 9\. [Git y Otros Sistemas](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Git-como-Cliente) 1. 9\.1 [Git como Cliente](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Git-como-Cliente) 2. 9\.2 [Migración a Git](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Migraci%C3%B3n-a-Git) 3. 9\.3 [Resumen](https://git-scm.com/book/es/v2/Git-y-Otros-Sistemas-Resumen) 5. ## 10\. [Los entresijos internos de Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Fontaner%C3%ADa-y-porcelana) 1. 10\.1 [Fontanería y porcelana](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Fontaner%C3%ADa-y-porcelana) 2. 10\.2 [Los objetos Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Los-objetos-Git) 3. 10\.3 [Referencias Git](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Referencias-Git) 4. 10\.4 [Archivos empaquetadores](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Archivos-empaquetadores) 5. 10\.5 [Las especificaciones para hacer referencia a… (refspec)](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Las-especificaciones-para-hacer-referencia-a%E2%80%A6%E2%80%8B-refspec) 6. 10\.6 [Protocolos de transferencia](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Protocolos-de-transferencia) 7. 10\.7 [Mantenimiento y recuperación de datos](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Mantenimiento-y-recuperaci%C3%B3n-de-datos) 8. 10\.8 [Variables de entorno](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Variables-de-entorno) 9. 10\.9 [Recapitulación](https://git-scm.com/book/es/v2/Los-entresijos-internos-de-Git-Recapitulaci%C3%B3n) 1. ## A1. [Apéndice A: Git en otros entornos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Interfaces-gr%C3%A1ficas) 1. A1.1 [Interfaces gráficas](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Interfaces-gr%C3%A1ficas) 2. A1.2 [Git en Visual Studio](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Visual-Studio) 3. A1.3 [Git en Eclipse](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Eclipse) 4. A1.4 [Git con Bash](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-con-Bash) 5. A1.5 [Git en Zsh](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Zsh) 6. A1.6 [Git en Powershell](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Git-en-Powershell) 7. A1.7 [Resumen](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-A:-Git-en-otros-entornos-Resumen) 2. ## A2. [Apéndice B: Integrando Git en tus Aplicaciones](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Git-mediante-L%C3%ADnea-de-Comandos) 1. A2.1 [Git mediante Línea de Comandos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Git-mediante-L%C3%ADnea-de-Comandos) 2. A2.2 [Libgit2](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-Libgit2) 3. A2.3 [JGit](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-B:-Integrando-Git-en-tus-Aplicaciones-JGit) 3. ## A3. [Apéndice C: Comandos de Git](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Configuraci%C3%B3n) 1. A3.1 [Configuración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Configuraci%C3%B3n) 2. A3.2 [Obtener y Crear Proyectos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Obtener-y-Crear-Proyectos) 3. A3.3 [Seguimiento Básico](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Seguimiento-B%C3%A1sico) 4. A3.4 [Ramificar y Fusionar](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Ramificar-y-Fusionar) 5. A3.5 [Compartir y Actualizar Proyectos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Compartir-y-Actualizar-Proyectos) 6. A3.6 [Inspección y Comparación](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Inspecci%C3%B3n-y-Comparaci%C3%B3n) 7. A3.7 [Depuración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Depuraci%C3%B3n) 8. A3.8 [Parcheo](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Parcheo) 9. A3.9 [Correo Electrónico](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Correo-Electr%C3%B3nico) 10. A3.10 [Sistemas Externos](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Sistemas-Externos) 11. A3.11 [Administración](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Administraci%C3%B3n) 12. A3.12 [Comandos de Fontanería](https://git-scm.com/book/es/v2/Ap%C3%A9ndice-C:-Comandos-de-Git-Comandos-de-Fontaner%C3%ADa) 2nd Edition # 3\.5 Ramificaciones en Git - Ramas Remotas ## Ramas Remotas Las ramas remotas son referencias al estado de las ramas en tus repositorios remotos. Son ramas locales que no puedes mover; se mueven automáticamente cuando estableces comunicaciones en la red. Las ramas remotas funcionan como marcadores, para recordarte en qué estado se encontraban tus repositorios remotos la última vez que conectaste con ellos. Suelen referenciarse como `(remoto)/(rama)`. Por ejemplo, si quieres saber cómo estaba la rama `master` en el remoto `origin`, puedes revisar la rama `origin/master`. O si estás trabajando en un problema con un compañero y este envía (push) una rama `iss53`, tú tendrás tu propia rama de trabajo local `iss53`; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama `origin/iss53`. Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un servidor Git en tu red, en `git.ourcompany.com`. Si haces un clon desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master` y denominará la copia local `origin/master`. Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; de manera que tengas donde trabajar. \| \| \| \|---\|---\| \| Nota \| “origin” no es especial Así como la rama “master” no tiene ningún significado especial en Git, tampoco lo tiene “origin”. “master” es un nombre muy usado solo porque es el nombre por defecto que Git le da a la rama inicial cuando ejecutas `git init`. De la misma manera, “origin” es el nombre por defecto que Git le da a un remoto cuando ejecutas `git clone`. Si en cambio ejecutases `git clone -o booyah`, tendrías una rama `booyah/master` como rama remota por defecto. \| ![Servidor y repositorio local luego de ser clonado.](https://git-scm.com/book/es/v2/images/remote-branches-1.png) Figura 30. Servidor y repositorio local luego de ser clonado Si haces algún trabajo en tu rama `master` local, y al mismo tiempo, alguien más lleva (push) su trabajo al servidor `git.ourcompany.com`, actualizando la rama `master` de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama `origin/master` no se moverá. ![El trabajo remoto y el local pueden diverger.](https://git-scm.com/book/es/v2/images/remote-branches-2.png) Figura 31. El trabajo remoto y el local pueden diverger Para sincronizarte, puedes utilizar el comando `git fetch origin`. Este comando localiza en qué servidor está el origen (en este caso `git.ourcompany.com`), recupera cualquier dato presente allí que tú no tengas, y actualiza tu base de datos local, moviendo tu rama `origin/master` para que apunte a la posición más reciente. ![\`git fetch\` actualiza las referencias de tu remoto.](https://git-scm.com/book/es/v2/images/remote-branches-3.png) Figura 32. `git fetch` actualiza las referencias de tu remoto Para ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos, supongamos que tienes otro servidor Git; utilizado por uno de tus equipos sprint, solamente para desarrollo. Este servidor se encuentra en `git.team1.ourcompany.com`. Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando `git remote add`, tal y como vimos en [\[ch02-git-basics\]](https://git-scm.com/book/es/v2/ch00/ch02-git-basics). Puedes denominar `teamone` a este remoto al asignarle este nombre a la URL. ![Añadiendo otro servidor como remoto.](https://git-scm.com/book/es/v2/images/remote-branches-4.png) Figura 33. Añadiendo otro servidor como remoto Ahora, puedes usar el comando `git fetch teamone` para recuperar todo el contenido del remoto `teamone` que tú no tenías. Debido a que dicho servidor es un subconjunto de los datos del servidor `origin` que tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada `teamone/master` para apuntar a la confirmación (commit) que `teamone` tiene en su rama `master`. ![Seguimiento de la rama remota a través de \`teamone/master\`.](https://git-scm.com/book/es/v2/images/remote-branches-5.png) Figura 34. Seguimiento de la rama remota a través de `teamone/master` ### Publicar Cuando quieres compartir una rama con el resto del mundo, debes llevarla (push) a un remoto donde tengas permisos de escritura. Tus ramas locales no se sincronizan automáticamente con los remotos en los que escribes, sino que tienes que enviar (push) expresamente las ramas que desees compartir. De esta forma, puedes usar ramas privadas para el trabajo que no deseas compartir, llevando a un remoto tan solo aquellas partes que deseas aportar a los demás. Si tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando `git push (remoto) (rama)`: ``` $ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB \| 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix ``` Esto es un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: “coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto”. Volveremos más tarde sobre el tema de `refs/heads/`, viéndolo en detalle en [\[ch10-git-internals\]](https://git-scm.com/book/es/v2/ch00/ch10-git-internals); por ahora, puedes ignorarlo. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: “coge mi `serverfix` y hazlo el `serverfix` remoto”. Puedes utilizar este último formato para llevar una rama local a una rama remota con un nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto. \| \| \| \|---\|---\| \| Nota \| No escribas tu contraseña todo el tiempo Si utilizas una dirección URL con HTTPS para enviar datos, el servidor Git te preguntará tu usuario y contraseña para autenticarte. Por defecto, te pedirá esta información a través del terminal, para determinar si estás autorizado a enviar datos. Si no quieres escribir tu contraseña cada vez que haces un envío, puedes establecer un “cache de credenciales”. La manera más sencilla de hacerlo es estableciéndolo en memoria por unos minutos, lo que puedes lograr fácilmente al ejecutar `git config --global credential.helper cache` Para más información sobre las distintas opciones de cache de credenciales, véase [Almacenamiento de credenciales](https://git-scm.com/book/es/v2/ch00/r_credential_caching). \| La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán bajo la rama remota `origin/serverfix` una referencia a donde esté la versión de `serverfix` en el servidor: ``` $ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix ``` Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia local editable de las mismas. En otras palabras, en este caso, no tienes una nueva rama `serverfix`. Sino que únicamente tienes un puntero no editable a `origin/serverfix`. Para integrar (merge) esto en tu rama de trabajo actual, puedes usar el comando `git merge origin/serverfix`. Y si quieres tener tu propia rama `serverfix` para trabajar, puedes crearla directamente basandote en la rama remota: ``` $ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ``` Esto sí te da una rama local donde puedes trabajar, que comienza donde `origin/serverfix` estaba en ese momento. ### Hacer Seguimiento a las Ramas Al activar (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar una “rama de seguimiento” (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando `git pull`, Git sabe de cuál servidor recuperar (fetch) y fusionar (merge) datos. Cuando clonas un repositorio, este suele crear automáticamente una rama `master` que hace seguimiento de `origin/master`. Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que sigan ramas de otros remotos o no seguir la rama `master`. El ejemplo más simple es el que acabas de ver al lanzar el comando `git checkout -b [rama] [nombreremoto]/[rama]`. Esta operación es tan común que git ofrece el parámetro `--track`: ``` $ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ``` Para preparar una rama local con un nombre distinto a la del remoto, puedes utilizar la primera versión con un nombre de rama local diferente: ``` $ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' ``` Así, tu rama local `sf` traerá (pull) información automáticamente desde `origin/serverfix`. Si ya tienes una rama local y quieres asignarla a una rama remota que acabas de traerte, o quieres cambiar la rama a la que le haces seguimiento, puedes usar en cualquier momento las opciones `-u` o `--set-upstream-to` del comando `git branch`. ``` $ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. ``` \| \| \| \|---\|---\| \| Nota \| Atajo al upstream Cuando tienes asignada una rama de seguimiento, puedes hacer referencia a ella mediante `@{upstream}` o mediante el atajo `@{u}`. De esta manera, si estás en la rama `master` y esta sigue a la rama `origin/master`, puedes hacer algo como `git merge @{u}` en vez de `git merge origin/master`. \| Si quieres ver las ramas de seguimiento que tienes asignadas, puedes usar la opción `-vv` con `git branch`. Esto listará tus ramas locales con más información, incluyendo a qué sigue cada rama y si tu rama local está por delante, por detrás o ambas. ``` $ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets master 1ae2a45 [origin/master] deploying index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it testing 5ea463a trying something new ``` Aquí podemos ver que nuestra rama `iss53` sigue `origin/iss53` y está “ahead” (delante) por dos, es decir, que tenemos dos confirmaciones locales que no han sido enviadas al servidor. También podemos ver que nuestra rama `master` sigue a `origin/master` y está actualizada. Luego podemos ver que nuestra rama `serverfix` sigue la rama `server-fix-good` de nuestro servidor `teamone` y que está tres cambios por delante (ahead) y uno por detrás (behind), lo que significa que existe una confirmación en el servidor que no hemos fusionado y que tenemos tres confirmaciones locales que no hemos enviado. Por último, podemos ver que nuestra rama `testing` no sigue a ninguna rama remota. Es importante destacar que estos números se refieren a la última vez que trajiste (fetch) datos de cada servidor. Este comando no se comunica con los servidores, solo te indica lo que sabe de ellos localmente. Si quieres tener los cambios por delante y por detrás actualizados, debes traértelos (fetch) de cada servidor antes de ejecutar el comando. Puedes hacerlo de esta manera: `$ git fetch --all; git branch -vv` ### Traer y Fusionar A pesar de que el comando `git fetch` trae todos los cambios que no tienes del servidor, este no modifica tu directorio de trabajo. Simplemente obtendrá los datos y dejará que tú mismo los fusiones. Sin embargo, existe un comando llamado `git pull`, el cuál básicamente hace `git fetch` seguido por `git merge` en la mayoría de los casos. Si tienes una rama de seguimiento configurada como vimos en la última sección, bien sea asignándola explícitamente o creándola mediante los comandos `clone` o `checkout`, `git pull` identificará a qué servidor y rama remota sigue tu rama actual, traerá los datos de dicho servidor e intentará fusionar dicha rama remota. Normalmente es mejor usar los comandos `fetch` y `merge` de manera explícita pues la magia de `git pull` puede resultar confusa. ### Eliminar Ramas Remotas Imagina que ya has terminado con una rama remota, es decir, tanto tú como tus colaboradores habéis completado una determinada funcionalidad y la habéis incorporado (merge) a la rama `master` en el remoto (o donde quiera que tengáis la rama de código estable). Puedes borrar la rama remota utilizando la opción `--delete` de `git push`. Por ejemplo, si quieres borrar la rama `serverfix` del servidor, puedes utilizar: ``` $ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix ``` Básicamente, lo que hace es eliminar el apuntador del servidor. El servidor Git suele mantener los datos por un tiempo hasta que el recolector de basura se ejecute, de manera que si la has borrado accidentalmente, suele ser fácil recuperarla. [prev](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Flujos-de-Trabajo-Ramificados) \\| [next](https://git-scm.com/book/es/v2/Ramificaciones-en-Git-Reorganizar-el-Trabajo-Realizado) [About this site](https://git-scm.com/site) Patches, suggestions, and comments are welcome. Git is a member of [Software Freedom Conservancy](https://git-scm.com/sfc)
Readable Markdown	Las ramas remotas son referencias al estado de las ramas en tus repositorios remotos. Son ramas locales que no puedes mover; se mueven automáticamente cuando estableces comunicaciones en la red. Las ramas remotas funcionan como marcadores, para recordarte en qué estado se encontraban tus repositorios remotos la última vez que conectaste con ellos. Suelen referenciarse como `(remoto)/(rama)`. Por ejemplo, si quieres saber cómo estaba la rama `master` en el remoto `origin`, puedes revisar la rama `origin/master`. O si estás trabajando en un problema con un compañero y este envía (push) una rama `iss53`, tú tendrás tu propia rama de trabajo local `iss53`; pero la rama en el servidor apuntará a la última confirmación (commit) en la rama `origin/iss53`. Esto puede ser un tanto confuso, pero intentemos aclararlo con un ejemplo. Supongamos que tienes un servidor Git en tu red, en `git.ourcompany.com`. Si haces un clon desde ahí, Git automáticamente lo denominará `origin`, traerá (pull) sus datos, creará un apuntador hacia donde esté en ese momento su rama `master` y denominará la copia local `origin/master`. Git te proporcionará también tu propia rama `master`, apuntando al mismo lugar que la rama `master` de `origin`; de manera que tengas donde trabajar. \| \| \| \|---\|---\| \| Nota \| “origin” no es especial Así como la rama “master” no tiene ningún significado especial en Git, tampoco lo tiene “origin”. “master” es un nombre muy usado solo porque es el nombre por defecto que Git le da a la rama inicial cuando ejecutas `git init`. De la misma manera, “origin” es el nombre por defecto que Git le da a un remoto cuando ejecutas `git clone`. Si en cambio ejecutases `git clone -o booyah`, tendrías una rama `booyah/master` como rama remota por defecto. \| ![Servidor y repositorio local luego de ser clonado.](https://git-scm.com/book/es/v2/images/remote-branches-1.png) Figura 30. Servidor y repositorio local luego de ser clonado Si haces algún trabajo en tu rama `master` local, y al mismo tiempo, alguien más lleva (push) su trabajo al servidor `git.ourcompany.com`, actualizando la rama `master` de allí, te encontrarás con que ambos registros avanzan de forma diferente. Además, mientras no tengas contacto con el servidor, tu apuntador a tu rama `origin/master` no se moverá. ![El trabajo remoto y el local pueden diverger.](https://git-scm.com/book/es/v2/images/remote-branches-2.png) Figura 31. El trabajo remoto y el local pueden diverger Para sincronizarte, puedes utilizar el comando `git fetch origin`. Este comando localiza en qué servidor está el origen (en este caso `git.ourcompany.com`), recupera cualquier dato presente allí que tú no tengas, y actualiza tu base de datos local, moviendo tu rama `origin/master` para que apunte a la posición más reciente. ![\`git fetch\` actualiza las referencias de tu remoto.](https://git-scm.com/book/es/v2/images/remote-branches-3.png) Figura 32. `git fetch` actualiza las referencias de tu remoto Para ilustrar mejor el caso de tener múltiples servidores y cómo van las ramas remotas para esos proyectos remotos, supongamos que tienes otro servidor Git; utilizado por uno de tus equipos sprint, solamente para desarrollo. Este servidor se encuentra en `git.team1.ourcompany.com`. Puedes incluirlo como una nueva referencia remota a tu proyecto actual, mediante el comando `git remote add`, tal y como vimos en [\[ch02-git-basics\]](https://git-scm.com/book/es/v2/ch00/ch02-git-basics). Puedes denominar `teamone` a este remoto al asignarle este nombre a la URL. ![Añadiendo otro servidor como remoto.](https://git-scm.com/book/es/v2/images/remote-branches-4.png) Figura 33. Añadiendo otro servidor como remoto Ahora, puedes usar el comando `git fetch teamone` para recuperar todo el contenido del remoto `teamone` que tú no tenías. Debido a que dicho servidor es un subconjunto de los datos del servidor `origin` que tienes actualmente, Git no recupera (fetch) ningún dato; simplemente prepara una rama remota llamada `teamone/master` para apuntar a la confirmación (commit) que `teamone` tiene en su rama `master`. ![Seguimiento de la rama remota a través de \`teamone/master\`.](https://git-scm.com/book/es/v2/images/remote-branches-5.png) Figura 34. Seguimiento de la rama remota a través de `teamone/master` ### Publicar Cuando quieres compartir una rama con el resto del mundo, debes llevarla (push) a un remoto donde tengas permisos de escritura. Tus ramas locales no se sincronizan automáticamente con los remotos en los que escribes, sino que tienes que enviar (push) expresamente las ramas que desees compartir. De esta forma, puedes usar ramas privadas para el trabajo que no deseas compartir, llevando a un remoto tan solo aquellas partes que deseas aportar a los demás. Si tienes una rama llamada `serverfix`, con la que vas a trabajar en colaboración; puedes llevarla al remoto de la misma forma que llevaste tu primera rama. Con el comando `git push (remoto) (rama)`: ``` $ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB \| 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix ``` Esto es un atajo. Git expande automáticamente el nombre de rama `serverfix` a `refs/heads/serverfix:refs/heads/serverfix`, que significa: “coge mi rama local `serverfix` y actualiza con ella la rama `serverfix` del remoto”. Volveremos más tarde sobre el tema de `refs/heads/`, viéndolo en detalle en [\[ch10-git-internals\]](https://git-scm.com/book/es/v2/ch00/ch10-git-internals); por ahora, puedes ignorarlo. También puedes hacer `git push origin serverfix:serverfix`, que hace lo mismo; es decir: “coge mi `serverfix` y hazlo el `serverfix` remoto”. Puedes utilizar este último formato para llevar una rama local a una rama remota con un nombre distinto. Si no quieres que se llame `serverfix` en el remoto, puedes lanzar, por ejemplo, `git push origin serverfix:awesomebranch`; para llevar tu rama `serverfix` local a la rama `awesomebranch` en el proyecto remoto. \| \| \| \|---\|---\| \| Nota \| No escribas tu contraseña todo el tiempo Si utilizas una dirección URL con HTTPS para enviar datos, el servidor Git te preguntará tu usuario y contraseña para autenticarte. Por defecto, te pedirá esta información a través del terminal, para determinar si estás autorizado a enviar datos. Si no quieres escribir tu contraseña cada vez que haces un envío, puedes establecer un “cache de credenciales”. La manera más sencilla de hacerlo es estableciéndolo en memoria por unos minutos, lo que puedes lograr fácilmente al ejecutar `git config --global credential.helper cache` \| La próxima vez que tus colaboradores recuperen desde el servidor, obtendrán bajo la rama remota `origin/serverfix` una referencia a donde esté la versión de `serverfix` en el servidor: ``` $ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix ``` Es importante destacar que cuando recuperas (fetch) nuevas ramas remotas, no obtienes automáticamente una copia local editable de las mismas. En otras palabras, en este caso, no tienes una nueva rama `serverfix`. Sino que únicamente tienes un puntero no editable a `origin/serverfix`. Para integrar (merge) esto en tu rama de trabajo actual, puedes usar el comando `git merge origin/serverfix`. Y si quieres tener tu propia rama `serverfix` para trabajar, puedes crearla directamente basandote en la rama remota: ``` $ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ``` Esto sí te da una rama local donde puedes trabajar, que comienza donde `origin/serverfix` estaba en ese momento. ### Hacer Seguimiento a las Ramas Al activar (checkout) una rama local a partir de una rama remota, se crea automáticamente lo que podríamos denominar una “rama de seguimiento” (tracking branch). Las ramas de seguimiento son ramas locales que tienen una relación directa con alguna rama remota. Si estás en una rama de seguimiento y tecleas el comando `git pull`, Git sabe de cuál servidor recuperar (fetch) y fusionar (merge) datos. Cuando clonas un repositorio, este suele crear automáticamente una rama `master` que hace seguimiento de `origin/master`. Sin embargo, puedes preparar otras ramas de seguimiento si deseas tener unas que sigan ramas de otros remotos o no seguir la rama `master`. El ejemplo más simple es el que acabas de ver al lanzar el comando `git checkout -b [rama] [nombreremoto]/[rama]`. Esta operación es tan común que git ofrece el parámetro `--track`: ``` $ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' ``` Para preparar una rama local con un nombre distinto a la del remoto, puedes utilizar la primera versión con un nombre de rama local diferente: ``` $ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' ``` Así, tu rama local `sf` traerá (pull) información automáticamente desde `origin/serverfix`. Si ya tienes una rama local y quieres asignarla a una rama remota que acabas de traerte, o quieres cambiar la rama a la que le haces seguimiento, puedes usar en cualquier momento las opciones `-u` o `--set-upstream-to` del comando `git branch`. ``` $ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. ``` \| \| \| \|---\|---\| \| Nota \| Atajo al upstream Cuando tienes asignada una rama de seguimiento, puedes hacer referencia a ella mediante `@{upstream}` o mediante el atajo `@{u}`. De esta manera, si estás en la rama `master` y esta sigue a la rama `origin/master`, puedes hacer algo como `git merge @{u}` en vez de `git merge origin/master`. \| Si quieres ver las ramas de seguimiento que tienes asignadas, puedes usar la opción `-vv` con `git branch`. Esto listará tus ramas locales con más información, incluyendo a qué sigue cada rama y si tu rama local está por delante, por detrás o ambas. ``` $ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] forgot the brackets master 1ae2a45 [origin/master] deploying index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] this should do it testing 5ea463a trying something new ``` Aquí podemos ver que nuestra rama `iss53` sigue `origin/iss53` y está “ahead” (delante) por dos, es decir, que tenemos dos confirmaciones locales que no han sido enviadas al servidor. También podemos ver que nuestra rama `master` sigue a `origin/master` y está actualizada. Luego podemos ver que nuestra rama `serverfix` sigue la rama `server-fix-good` de nuestro servidor `teamone` y que está tres cambios por delante (ahead) y uno por detrás (behind), lo que significa que existe una confirmación en el servidor que no hemos fusionado y que tenemos tres confirmaciones locales que no hemos enviado. Por último, podemos ver que nuestra rama `testing` no sigue a ninguna rama remota. Es importante destacar que estos números se refieren a la última vez que trajiste (fetch) datos de cada servidor. Este comando no se comunica con los servidores, solo te indica lo que sabe de ellos localmente. Si quieres tener los cambios por delante y por detrás actualizados, debes traértelos (fetch) de cada servidor antes de ejecutar el comando. Puedes hacerlo de esta manera: `$ git fetch --all; git branch -vv` ### Traer y Fusionar A pesar de que el comando `git fetch` trae todos los cambios que no tienes del servidor, este no modifica tu directorio de trabajo. Simplemente obtendrá los datos y dejará que tú mismo los fusiones. Sin embargo, existe un comando llamado `git pull`, el cuál básicamente hace `git fetch` seguido por `git merge` en la mayoría de los casos. Si tienes una rama de seguimiento configurada como vimos en la última sección, bien sea asignándola explícitamente o creándola mediante los comandos `clone` o `checkout`, `git pull` identificará a qué servidor y rama remota sigue tu rama actual, traerá los datos de dicho servidor e intentará fusionar dicha rama remota. Normalmente es mejor usar los comandos `fetch` y `merge` de manera explícita pues la magia de `git pull` puede resultar confusa. ### Eliminar Ramas Remotas Imagina que ya has terminado con una rama remota, es decir, tanto tú como tus colaboradores habéis completado una determinada funcionalidad y la habéis incorporado (merge) a la rama `master` en el remoto (o donde quiera que tengáis la rama de código estable). Puedes borrar la rama remota utilizando la opción `--delete` de `git push`. Por ejemplo, si quieres borrar la rama `serverfix` del servidor, puedes utilizar: ``` $ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix ``` Básicamente, lo que hace es eliminar el apuntador del servidor. El servidor Git suele mantener los datos por un tiempo hasta que el recolector de basura se ejecute, de manera que si la has borrado accidentalmente, suele ser fácil recuperarla.
Shard	54 (laksa)
Root Hash	7104038400628677254
Unparsed URL	com,git-scm!/book/es/v2/Ramificaciones-en-Git-Ramas-Remotas s443