Очень часто появляется необходимость создать в локальном клоне проекта новую ветку , закинуть в нее уже созданные или измененные файлы, протолкнуть новую ветку в удаленный репозиторий, например в , чтобы коллега-программист мог стянуть ветку и посмотреть изменения или результат.
Создаем и проталкиваем новую ветку
Есть два равнозначных способа создать и переключиться на новую ветку. Первый односрочный:
Root@user: git checkout -b new_feature
Второй, аналогичный первому, но в две строки:
Root@user: git branch new_feature root@user: git checkout new_feature
Готово. Новая ветка создана в локальном репозитории и в нее включены все локальные изменения. И мы переключились на новую локальную ветку . Можем создать коммит и протолкнуть новую ветку в удаленный репозиторий:
Root@user: git commit -m "new feature" root@user: git push origin new_feature
Где origin — название вашего удаленного репозиторий (origin — значение по умолчанию при клоне проекта), new_feature — название вашей новой ветки.
Затягиваем новую ветку из удаленного репозитория
Созданная нами ветка уже находится в удаленном репозитории и теперь нам нужно изолированно ее затянуть из репы. Если сделать просто pull , то новая ветка не подтянется. Если сделать просто git pull origin new_feature, то ветка сольется с веткой master. Поэтому делаем следующую последовательность:
Root@user: git fetch root@user: git checkout -b new_feature root@user: git pull origin new_feature
На первой строке с помощью команды git fetch смотрим есть ли новые ветки, при этом загрузка удаленных изменений не происходит. Второй строкой создает локальную ветку с наким же названием и переключаемся на нее. В конец, на третьей строке, затягиваем удаленные изменения в новую ветку. Система предложить сделать merge-commit.
Чтобы иметь возможность совместной работы над каким-либо Git-проектом, необходимо знать, как управлять удалёнными репозиториями. Удалённые репозитории — это модификации проекта, которые хранятся в интернете или ещё где-то в сети. Их может быть несколько, каждый из которых, как правило, доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя управление удалёнными репозиториями и помещение (push ) и получение (pull ) данных в и из них тогда, когда нужно обменяться результатами работы. Управление удалёнными репозиториями включает умение добавлять удалённые репозитории, удалять те из них, которые больше не действуют, умение управлять различными удалёнными ветками и определять их как отслеживаемые (tracked) или нет и прочее. Данный раздел охватывает все перечисленные навыки по управлению удалёнными репозиториями.
Чтобы разобрать примеры этой главы я создал удаленный репозитарий TestRemote на GitHub, а затем склонировал его себе.
Отображение удалённых репозиториев
Чтобы просмотреть, какие удалённые серверы у вас уже настроены, следует выполнить команду git remote . Она перечисляет список имён-сокращений для всех уже указанных удалённых дескрипторов. Если вы склонировали ваш репозиторий, у вас должен отобразиться, по крайней мере, origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали:
Чтобы посмотреть, какому URL соответствует сокращённое имя в Git, можно указать команде опцию -v :
Добавление удалённых репозиториев
Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] :
Теперь вы можете использовать в командной строке имя tr вместо полного URL.
Например, я сделал некоторые изменения файла README.md и теперь загрузим их себе в локальный репозиторий командой git fetch :
Теперь ветка изменений с сервера доступна локально как tr/mater. Вы можете слить (merge) её в одну из своих веток или перейти на эту ветку, если хотите её проверить.
Тут надо отметить, что между командами git pull и git fetch есть разница, но об этом чуть позже.
На данный момент, если мы посмотрим содержимое файла README.md в рабочем каталоге, то оно будет точно такое же, как было до команды git fetch. Это потому, что мы в данный момент находимся в ветке master локального репозитария, которая не была изменена.
Чтобы посмотреть все существующие ветки можно дать команду git branch с ключом –a , который покажет все ветки репозитория.
Здесь активная ветка обозначена звёздочкой. А так же мы видим ветку которую мы притянули командой git fetch – это ветка remotes/tr/master. Собственно об этом нам команда git fetch и сообщила после выполнения.
Переключится на ветку можно командой git checkout <имя ветки>
И так мы переключились на ветку которую стянули командой git fetch, о чем нам выдалось сообщение и рассказали какие файлы были обновлены. Это файл README.md. Теперь в рабочем каталоге мы можем посмотреть измененное содержимое этого файла (мы его меняли непосредственно на GitHub).
Мы так же можем переключится обратно на нашу ветку master
Теперь будем разбираться с разницей между fetch и pull .
Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
$ git fetch [имя удал. сервера]
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет . После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта. Теперь эти ветки в любой момент могут быть просмотрены или слиты (объединены).
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем origin . Таким образом, git fetch origin извлекает все наработки, отправленные (push ) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch ) . Важно отметить, что команда fetch забирает данные в ваш локальный репозиторий, но не сливает (не объединяет) их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент . Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Если у вас есть ветка, настроенная на отслеживание удалённой ветки, то вы можете использовать команду git pull . Она автоматически извлекает и затем сливает (объединяет) данные из удалённой ветки в вашу текущую ветку . Этот способ может для вас оказаться более простым или более удобным. К тому же по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере , с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master). Выполнение git pull , как правило, извлекает (fetch ) данные с сервера , с которого вы изначально склонировали, и автоматически пытается слить (объеденить) (merge ) их с кодом, над которым вы в данный момент работаете .
$ git push origin master
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а затем команду push выполняете вы, то ваш push точно будет отклонён. Вам придётся сначала вытянуть (pull ) их изменения и объединить с вашими. Только после этого вам будет позволено выполнить push .
Я выполнил команды pull и объединил изменения для файла README.md и затем залил их на сервер GitHub. Скрин привожу просто для информации чтобы было видно как это делается.
Более подробно как отправлять (push ) данные на удалённый сервер мы рассмотрим чуть позже.
Инспекция удалённого репозитория
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show [удал. сервер] . Если вы выполните эту команду с некоторым именем, например, origin, вы получите что-то подобное:
Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master , выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных . Она также выдаёт список всех полученных ею ссылок.
Данная команда так же показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере.
Удаление и переименование удалённых репозиториев
Для переименования ссылок в новых версиях Git"а можно вылолнить git remote rename , это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать tr в tstrmt, вы можете сделать это следующим образом:
Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как tr/master, стало tstrmt/master.
Если по какой-то причине вы хотите удалить ссылку (вы сменили сервер или больше не используете определённое зеркало, или, возможно, контрибьютор перестал быть активным), вы можете использовать git remote rm :
// echo get_the_post_thumbnail(get_the_ID(), "relatedthumbnail"); // вывожу свой размер миниатюры?>
Иногда при работе с локально и удаленной веткой нам требуется их удалять. Например эта ветка отдельной функциональности которая уже слита в develop или master. Или это ветка для устранения багов. Давайте посмотрим как можно легко и быстро удалять локальные (local) и удаленные (remote) ветки.
Быстрый ответ — финальное резюме
$ git push -dЗамечу, что в большинстве случаев удаленный репозиторий записан как origin .
Удаляем локальную ветку
Чтобы удалить локальную ветку используем одну из следующих команд:
$ git branch -d branch_name $ git branch -D branch_name
Пояснение: ключ -d это ярлык команды --delete , которая удаляет ветку, только если последняя полностью смержена в ее upstream ветку. Можно также использовать команду -D , которая является алиасом команды --delete --force , которая удаляет ветку «невзирая на ее мерж статус» (независимо объединяли вы ее с вышестоящей upsream веткой ли нет).
Удаление удаленной remote ветки
В Git версии v1.7.0 , вы можете удалить remote ветку используя
$ git push
что возможно легче запомнить, чем команду
$ git push
которая была добавлена в Git v1.5.0 «чтобы удалить удаленную remote ветку или тег tag.»
Начиная с Git v2.8.0 вы также можете использовать git push с опцией -d как ярлык вместо --delete .
Более того, версия гита которая у вас установлена будет определять какой синтаксис использовать, более легкий или более сложный.
Удалить удаленную remote ветку
Цитата из 3-ей главы книги Pro Git Скотта Чакона:
Удаление Удалённых Веток
Полагаю вы завершили с работой в удаленной ветке, вы и ваши сотрудники закончили с новой фичей и смержили ее в вашу mster ветку на удаленном репозитории. Вы можете удалить удаленную ветку используя довольно тупой синтаксис git push : . Если вы хотите удалить вашу bugfix ветку с фиксом багов на сервере, вы запускаете следующую команду:
$ git push origin:serverfix To :schacon/simplegit.git - serverfix
Бабах! И не больше такой ветки на вашем сервере. Наверное вам захочется поставить закладку на эту страницу, потому что вам еще понадобится эта команда, и вы скорее всего забудете как она пишется. Способ чтобы запомнить эту команду, вспомнить прошлую git push : синтаксис которой мы рассматривали немного ранее. Если вы оставите , тогда вы буквально скажите следующее “Возьми ничего с моей стороны и сделай это .”
Я использовал git push origin:bugfix и это отлично работает.
После, вам следует выполнить эту команду на других машинах разработчиков:
Git fetch --all --prune
чтобы распространить изменения.
Я клонировал его в локальную копию, используя Eclipse EGit.
Затем я создал ветвь в исходном репозитории git на сервере.
Как скопировать ветку в мою локальную копию с помощью Eclipse EGit?
Когда я открываю Git Repositories внутри EGit, я вижу:
Local -- master - Remote Tracking -- origin/development -- origin/master
Как я могу получить происхождение / развитие в моем местном использовании с помощью EGit?
Я знаю, что могу создать новый клон, но я не хочу этого делать, поскольку считаю, что должен быть способ получить только новую ветку.
Второй вопрос – где команда pull внутри EGit? Мне удалось найти команду fetch, но когда я запустил ее, она говорит, что ничего не нужно. RefSpec:
Refs/heads/*:refs/remotes/origin/*
Третий вопрос – есть ли способ обработать команды git из командной строки внутри Eclipse в моей системе Windows? Я думал о попытке сделать вывод из командной строки, но я не могу найти его в своей локальной системе.
Ваша выборка обновлена, потому что у вас уже есть все, скопированные в локальный репозиторий. Притяжение объединит origin/development в мастера, чего вы не хотите. Вы хотите создать новую ветку с origin/development в качестве отправной точки. Я не знаю, как это сделать с помощью egit, но в командной строке вы выполните:
Git checkout -b development origin/development
Я также искал несколько часов, чтобы узнать, как получить удаленную ветвь в Eclipse EGit …
Решение изложено в этом Bugreport . И это очень просто, если вы знаете, как это сделать – не нужно использовать версию командной строки git, которая, даже если она работает в 99% всех случаев, может быть рискованной, поскольку у меня уже были проблемы, которые она мешала Eclipse и EGit.
Просто выполните следующие действия:
- Сначала убедитесь, что вы открыли представление EGit Repository view . Если вы еще не открыли его, перейдите в «Window → Show View → Other …» и оттуда выберите «Git → Git Repositories».
- В представлении « Repository view выберите «Филиалы → Удаленное отслеживание». Вы должны увидеть там свои удаленные ветви (пример: origin/new_feature).
- Щелкните правой кнопкой мыши на удаленной ветке, которую вы хотите иметь с локальными ветвями. Выберите «Создать ветвь» …
- Значения по умолчанию должны быть в порядке. Обычно вы ничего здесь не должны менять. Обратите внимание, что вы не должны изменять стратегию «Потянуть» на что-то другое, чем «Объединить», если вы не знаете, что делаете. В противном случае вытягивание изменений в восходящем потоке может привести к потере данных.
- Нажмите «ОК», и вы закончите 🙂
Я столкнулся с той же проблемой, и вот как я ее решил:
- щелкните правой кнопкой мыши (удаленный) Branch, Check Out, проверьте как новое локальное ветвь
Open Git Perspective
Сначала у вас должна быть ветка, которую вы хотите проверить, в вашем репозитории под удаленным отслеживанием . Моя проблема заключалась в том, что я не мог видеть удаленную ветку здесь, поэтому, чтобы решить эту проблему – выполните Pull on the repository, и эта команда должна предоставить вам все ветки под удаленным отслеживанием
Чтобы иметь возможность совместной работы над каким-либо Git-проектом, необходимо знать, как управлять удалёнными репозиториями. Удалённые репозитории — это модификации проекта, которые хранятся в интернете или ещё где-то в сети. Их может быть несколько, каждый из которых, как правило, доступен для вас либо только на чтение, либо на чтение и запись. Совместная работа включает в себя управление удалёнными репозиториями и помещение (push ) и получение (pull ) данных в и из них тогда, когда нужно обменяться результатами работы. Управление удалёнными репозиториями включает умение добавлять удалённые репозитории, удалять те из них, которые больше не действуют, умение управлять различными удалёнными ветками и определять их как отслеживаемые (tracked) или нет и прочее. Данный раздел охватывает все перечисленные навыки по управлению удалёнными репозиториями.
Чтобы разобрать примеры этой главы я создал удаленный репозитарий TestRemote на GitHub, а затем склонировал его себе.
Отображение удалённых репозиториев
Чтобы просмотреть, какие удалённые серверы у вас уже настроены, следует выполнить команду git remote . Она перечисляет список имён-сокращений для всех уже указанных удалённых дескрипторов. Если вы склонировали ваш репозиторий, у вас должен отобразиться, по крайней мере, origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали:
Чтобы посмотреть, какому URL соответствует сокращённое имя в Git, можно указать команде опцию -v :
Добавление удалённых репозиториев
Чтобы добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться, выполните git remote add [сокращение] :
Теперь вы можете использовать в командной строке имя tr вместо полного URL.
Например, я сделал некоторые изменения файла README.md и теперь загрузим их себе в локальный репозиторий командой git fetch :
Теперь ветка изменений с сервера доступна локально как tr/mater. Вы можете слить (merge) её в одну из своих веток или перейти на эту ветку, если хотите её проверить.
Тут надо отметить, что между командами git pull и git fetch есть разница, но об этом чуть позже.
На данный момент, если мы посмотрим содержимое файла README.md в рабочем каталоге, то оно будет точно такое же, как было до команды git fetch. Это потому, что мы в данный момент находимся в ветке master локального репозитария, которая не была изменена.
Чтобы посмотреть все существующие ветки можно дать команду git branch с ключом –a , который покажет все ветки репозитория.
Здесь активная ветка обозначена звёздочкой. А так же мы видим ветку которую мы притянули командой git fetch – это ветка remotes/tr/master. Собственно об этом нам команда git fetch и сообщила после выполнения.
Переключится на ветку можно командой git checkout <имя ветки>
И так мы переключились на ветку которую стянули командой git fetch, о чем нам выдалось сообщение и рассказали какие файлы были обновлены. Это файл README.md. Теперь в рабочем каталоге мы можем посмотреть измененное содержимое этого файла (мы его меняли непосредственно на GitHub).
Мы так же можем переключится обратно на нашу ветку master
Теперь будем разбираться с разницей между fetch и pull .
Fetch и Pull
Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:
$ git fetch [имя удал. сервера]
Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет . После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта. Теперь эти ветки в любой момент могут быть просмотрены или слиты (объединены).
Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем origin . Таким образом, git fetch origin извлекает все наработки, отправленные (push ) на этот сервер после того, как вы склонировали его (или получили изменения с помощью fetch ) . Важно отметить, что команда fetch забирает данные в ваш локальный репозиторий, но не сливает (не объединяет) их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент . Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Если у вас есть ветка, настроенная на отслеживание удалённой ветки, то вы можете использовать команду git pull . Она автоматически извлекает и затем сливает (объединяет) данные из удалённой ветки в вашу текущую ветку . Этот способ может для вас оказаться более простым или более удобным. К тому же по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере , с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master). Выполнение git pull , как правило, извлекает (fetch ) данные с сервера , с которого вы изначально склонировали, и автоматически пытается слить (объеденить) (merge ) их с кодом, над которым вы в данный момент работаете .
$ git push origin master
Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а затем команду push выполняете вы, то ваш push точно будет отклонён. Вам придётся сначала вытянуть (pull ) их изменения и объединить с вашими. Только после этого вам будет позволено выполнить push .
Я выполнил команды pull и объединил изменения для файла README.md и затем залил их на сервер GitHub. Скрин привожу просто для информации чтобы было видно как это делается.
Более подробно как отправлять (push ) данные на удалённый сервер мы рассмотрим чуть позже.
Инспекция удалённого репозитория
Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show [удал. сервер] . Если вы выполните эту команду с некоторым именем, например, origin, вы получите что-то подобное:
Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master , выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных . Она также выдаёт список всех полученных ею ссылок.
Данная команда так же показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере.
Удаление и переименование удалённых репозиториев
Для переименования ссылок в новых версиях Git"а можно вылолнить git remote rename , это изменит сокращённое имя, используемое для удалённого репозитория. Например, если вы хотите переименовать tr в tstrmt, вы можете сделать это следующим образом:
Стоит упомянуть, что это также меняет для вас имена удалённых веток. То, к чему вы обращались как tr/master, стало tstrmt/master.
Если по какой-то причине вы хотите удалить ссылку (вы сменили сервер или больше не используете определённое зеркало, или, возможно, контрибьютор перестал быть активным), вы можете использовать git remote rm :
