Git как создать ветку в удаленном репозитории

Как создать копию ветки с удаленного репозитория?

хорошая дока по git вызывается командой git help и потом например git help checkout а где второй вопрос ?

15 фев 2013 в 11:08
пока что не придумал, но скоро будет
15 фев 2013 в 11:10
кто отмодерировал вопрос ? вы русский язык знаете ?
15 фев 2013 в 15:43

4 ответа 4

Сортировка: Сброс на вариант по умолчанию

Современные версии Git позволяют делать это гораздо проще:

git checkout branchname 

1. Есть удалённая ветка origin/branchname
2. Но нет локальной ветки с именем branchname

Допустим, есть удаленная ветка feature , которой у вас ещё нет локально.

$ git branch --all * master remotes/origin/HEAD -> origin/master remotes/origin/feature remotes/origin/master 

$ git checkout feature Branch feature set up to track remote branch feature from origin. Switched to a new branch 'feature' 

$ git branch --all * feature master remotes/origin/HEAD -> origin/master remotes/origin/feature remotes/origin/master 

Новая ветка действительно отслеживает удалённую:

git branch -vv * feature ed185c8 [origin/feature] extract environment master 4db6d3b [origin/master] stylecheck-driven syntax improvements 

Отслеживать
ответ дан 6 июл 2016 в 4:33
Nick Volynkin ♦ Nick Volynkin
34k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака

Эта команда создаст локальную копию удаленной ветки

git checkout -b remote_branch origin/remote_branch 

Отслеживать
ответ дан 15 фев 2013 в 11:05
AlexDenisov AlexDenisov
6,452 1 1 золотой знак 21 21 серебряный знак 29 29 бронзовых знаков
Разве она не копирует ветку существующего репозитория просто удаленным вариантом?
15 фев 2013 в 11:16
По-моему этого вопрощающий и хотел добиться, или я неправильно понял вопрос?
15 фев 2013 в 11:26

Дело в том что если руководствоваться вашей командой — то клонируется с этого же оригина ветка с удаленного командой git checkout branch если же самому приходиться ветку создавать — то ее нужно создать уже на удаленном хосте а с удаленного так или иначе нужно брать ветку вариантом ниже. ибо оригин — это есть тот что есть репо вообще. может и я вопрос не правильно понял.

2.5 Основы Git — Работа с удалёнными репозиториями

Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.

Примечание
Удалённый репозиторий может находиться на вашем локальном компьютере.

Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.

Просмотр удалённых репозиториев

Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote . Она выведет названия доступных удалённых репозиториев. Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:

$ git clone https://github.com/schacon/ticgit Cloning into 'ticgit'. remote: Reusing existing pack: 1857, done. remote: Total 1857 (delta 0), reused 0 (delta 0) Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done. Resolving deltas: 100% (772/772), done. Checking connectivity. done. $ cd ticgit $ git remote origin

Вы можете также указать ключ -v , чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:

$ git remote -v origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push)

Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:

$ cd grit $ git remote -v bakkdoor https://github.com/bakkdoor/grit (fetch) bakkdoor https://github.com/bakkdoor/grit (push) cho45 https://github.com/cho45/grit (fetch) cho45 https://github.com/cho45/grit (push) defunkt https://github.com/defunkt/grit (fetch) defunkt https://github.com/defunkt/grit (push) koke git://github.com/koke/grit.git (fetch) koke git://github.com/koke/grit.git (push) origin git@github.com:mojombo/grit.git (fetch) origin git@github.com:mojombo/grit.git (push)

Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.

Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.

Добавление удалённых репозиториев

В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add :

$ git remote origin $ git remote add pb https://github.com/paulboone/ticgit $ git remote -v origin https://github.com/schacon/ticgit (fetch) origin https://github.com/schacon/ticgit (push) pb https://github.com/paulboone/ticgit (fetch) pb https://github.com/paulboone/ticgit (push)

Теперь вместо указания полного пути вы можете использовать pb . Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :

$ git fetch pb remote: Counting objects: 43, done. remote: Compressing objects: 100% (36/36), done. remote: Total 43 (delta 10), reused 31 (delta 5) Unpacking objects: 100% (43/43), done. From https://github.com/paulboone/ticgit * [new branch] master -> pb/master * [new branch] ticgit -> pb/ticgit

Ветка master из репозитория Пола сейчас доступна вам под именем pb/master . Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола. Более подробно работа с ветками рассмотрена в главе Ветвление в Git.

Получение изменений из удалённого репозитория — Fetch и Pull

Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:

$ git fetch [remote-name]

Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.

Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей. Этот способ может для вас оказаться более простым или более удобным. К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий. Название веток может быть другим и зависит от ветки по умолчанию на сервере. Выполнение git pull , как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

Примечание

Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.

Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): git config —global pull.rebase «false»

Если хотите использовать перебазирование при получении изменений: git config —global pull.rebase «true»

Отправка изменений в удалённый репозиторий (Push)

Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push . Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:

$ git push origin master

Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён. Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push . Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.

Просмотр удалённого репозитория

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show . Выполнив эту команду с некоторым именем, например, origin , вы получите следующий результат:

$ git remote show origin * remote origin Fetch URL: https://github.com/schacon/ticgit Push URL: https://github.com/schacon/ticgit HEAD branch: master Remote branches: master tracked dev-branch tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (up to date)

Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master , выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.

Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :

$ git remote show origin * remote origin URL: https://github.com/my-org/complex-project Fetch URL: https://github.com/my-org/complex-project Push URL: https://github.com/my-org/complex-project HEAD branch: master Remote branches: master tracked dev-branch tracked markdown-strip tracked issue-43 new (next fetch will store in remotes/origin) issue-45 new (next fetch will store in remotes/origin) refs/remotes/origin/issue-11 stale (use 'git remote prune' to remove) Local branches configured for 'git pull': dev-branch merges with remote dev-branch master merges with remote master Local refs configured for 'git push': dev-branch pushes to dev-branch (up to date) markdown-strip pushes to markdown-strip (up to date) master pushes to master (up to date)

Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull .

Удаление и переименование удалённых репозиториев

Для переименования удалённого репозитория можно выполнить git remote rename . Например, если вы хотите переименовать pb в paul , вы можете это сделать при помощи git remote rename :

$ git remote rename pb paul $ git remote origin paul

Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории. То, к чему вы обращались как pb/master , теперь стало paul/master .

Если по какой-то причине вы хотите удалить удалённый репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :

$ git remote remove paul $ git remote origin

При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.

Шпаргалка по командам git
Что делать, когда под руками нет SourceTree

У нас есть задача (issue), которую мы планируем сделать. В центральном репозитории создаём ветку для решения задачи. Например, для задачи с номером 234 создаём ветку features/issue-234.

Примечание: префикс features/ влияет на отображение > веток в таких графических клиентах, как Git Extensions и Sourcetree. Ветки, в чьих именах встреыется символ / выглядят как файлы в каталогах. Так, ветка features/issue-234 выглядит как ветка issue-234 в каталоге features.

Так удобно группировать ветки.

Шаг 2

Теперь в удалённом репозитории есть ветка, где мы будем работать над задачей. Нам нужна такая же ветка в локальном репозитории. Локальную ветку надо создать и связать с удалённой.

Сначала скачиваем из удалённого репозитория изменения, включая новые ветки

git fetch 

Чтобы убедиться, что удалённая ветка доступна локально, выполняем команду

git branch -a 

Создаём локальную ветку, которая указывает на удалённую ветку

git checkout -b features/issue-234 origin/features/issue-234 

git checkout -t origin/features/issue-234 

Шаг 3

Далее работаем над задачей в локальной ветке, время от времени фиксируя изменения.

Прежде, чем фиксировать, смотрим, что успели сделать.

git status 

• Untracked — git не отслеживает изменения в этих файлах и не хранит их.
• Changes not staged for commit — git отлеживает и хранит эти файлы. Сейчас эти файлы изменены, но git не будет сохранять эти изменения при фиксации.
• Changes to be committed — файлы изменены и git сохранит эти изменения при следующей фиксации.

Помечаем для фиксации файлы file₁..fileₙ.

git add file₁ . fileₙ 

Помечаем для фиксации все файлы в текущем каталоге и его подкаталогах. Помеченными окажутся в том числе все новые файлы.

git add . 

Фиксируем все файлы, помеченные для фиксации. Git попросит ввести комментарий.

git commit 

Команда git commit -a работает также, как git add . и git commit вместе, за тем исключением, что новые файлы не будут зафиксированы.

Команда git commit -m «Комментарий к коммиту» фиксирует изменения с указанным комментарием, не запуская внешний редактор.

Отправляем изменения в центральный репозиторий.

git push 

Откат изменений

Если вы изменили файлы, но ещё не фиксировали изменения, вы можете изменить отдельные файлы:

git checkout -- file₁ . fileₙ 

Либо вы можете отказить изменения во всех файлах в каталоге и его подкаталогах:

git checkout -- . 

Если вы зафиксировали изменения, но ещё не отправили их в удалённый репозиторий, откатите последнюю фиксацию:

git reset --hard 

Если комит был отправлен в удалённый репозиторий, считается корректным не удалять его, а создать парный к нему отменяющий коммит.

git revert

Если вы случайно добаили к списку отслеживаемых файлов что-то, что не надо отслеживать, например, временные файлы *.tmp или результаты компиляции *.obj, вы можете удалить их из репозитория:

git rm --cached file₁ . fileₙ 

Без флага —cached git удалит файлы и в репозитории, и на диске. Эта же команда используется, если вы обновили .gitignore и хотите удалить из репозитория файлы, которые соответствуют новым правилам .gitignore:

git rm --cached . git add . 

Первая команда удалит из репозитория всех файлы (оставив их на диске), а вторая снова добавит их в репозиторий. При добавлении git проверит файлы на соответствие шаблонам .gitignore.

Удалить с диска новые файлы

git clean -f -d 

Шаг 4

Решив задачу мы должны слить все изменения в основную ветку — master или main. Это делается через pull request в центральном репозитории. Ставим галочку удалить исходную ветку после слияния, чтобы не пришлось удалять эти ветку вручную.

Теперь надо избавиться от локальной ветки, где мы работали. Сначала переключимся на основную ветку.

git checkout master 

«Затягиваем» в неё изменения из центрального репозитория.

git fetch 

После изменения можно слить с текущей веткой:

git merge 

После слияния в истории репозитория остаются «следы» — коммиты сначла расходятся, потом снова сходятся. Можно избавиться от следов, склеив все коммиты в одну ветку:

git rebase 

git fetch git merge 

Команда git remote add origin для работы с удаленными репозиториями

Как создать удаленный репозиторий, подключиться к нему и какие команды Git использовать.

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Введение

В этой инструкции мы научим вас создавать удаленный репозиторий, подключаться к нему различными методами и покажем, какие команды Git использовать.

Немного теории

Совместной разработка в Git предполагает, что у разработчиков, работающих над каким-то проектом, есть своя копия репозитория, соответственно и своя локальная история в зависимости от модели ветвления. Так как разработчикам обычно нужно поделиться серией коммитов, а не каким-то одним, в Git есть возможность делиться целыми ветками между репозиториями.

Удаленный репозиторий – это репозиторий, размещенный в локальной или интернет сети. Удаленный репозиторий используется для того, чтобы делиться и обмениваться кодом между разработчиками в рамках сети. Его также можно использовать, если вы разрабатываете проект на нескольких устройствах.

Ветки слежения – это ссылки на определенное положение веток удаленного репозитория. Перемещение веток слежения происходит автоматически при выполнении команд, которые будут показаны дальше.

Имена веток слежения имеют вид / . Если один из разработчиков произвел отправку на удаленный сервер ветки develop, когда у второго разработчика есть своя локальная ветка develop, то удаленная ветка будет называться origin/develop и соответственно быть веткой слежения. При разработке orgin по умолчанию называется удаленный сервер.

git remote add origin

git remote add origin https://github.com/ИМЯПОЛЬЗОВАТЕЛЯ/РЕПОЗИТОРИЙ.git

git remote add origin git@github.com:ИМЯПОЛЬЗОВАТЕЛЯ/РЕПОЗИТОРИЙ.git

ssh-keygen -t ed25519 -C "ПОЧТА_GitHub_АККАУНТА" ssh-keygen -t rsa -b 4096 -C "ПОЧТА_GitHub_АККАУНТА"

git remote

git ls-remote

git remote show

git push --set-upstream origin develop

git fetch [remote-name]

git pull 

git fetch; git merge

git clone [url]

git clone https://github.com/ИМЯПОЛЬЗОВАТЕЛЯ/РЕПОЗИТОРИЙ.git

git clone git@github.com:ИМЯПОЛЬЗОВАТЕЛЯ/РЕПОЗИТОРИЙ.git

git clone --single-branch [url]

git clone -o ticgit

git remote rm