Учимся работать с другими
Допустим, у вас есть проект с кучей разных идей и возможностей для дальнейшей реализации. Что-то из этого уже готово, а над чем-то еще стоит потрудиться. Вполне возможно, что вы сотрудничаете с другими пользователями, которые работают над чем-то своим. Здесь и пригодится ветвление!
Ветка — это отдельное место для реализации новых идей. Изменения в ветке не затронут основную ветку master до тех пор, пока вы сами этого не захотите. То есть с отдельной веткой вы делаете что угодно, а затем просто сливаете эти изменения с основной веткой master .
Единственная ветка, которая может изменять проект, — это master . Если вы не хотите вносить изменения сразу, то выделите их отдельной веткой, а затем сливайте с master .
Если вы работаете с другими и хотите внести собственные изменения либо работаете над проектом и хотите изменить что-то, не затрагивая master , то создавайте отдельную ветку. Сделать это можно в любое время.
Очень удобно создавать в терминале ветку с названием new_feature (новая опция) и переходить в нее по команде:
git checkout -b new_feature
Вносить изменения в ветку можно сразу после ее создания. Использование отдельных веток с подходящими названиями позволяет сразу понять, что именно изменялось и почему. Каждый новый коммит следует снабжать комментарием, описывающим суть изменений.
Теперь поговорим о переключении между ветками:
git checkout
Команда позволяет «заглянуть» в репозиторий, который в данный момент не открыт. Например, вы можете перейти в ветку master :
git checkout master
или открыть ветку new_feature :
git checkout new_feature
По завершению работы с веткой можно слить эти изменения с master , чтобы их увидели другие.
git merge new_feature
Эта команда берет все изменения в ветке new_feature и добавляет их в ветку master .
Вы можете отправить изменения в репозиторий и установить удаленную ветку (например, new_feature ) в качестве «отслеживаемой»:
git push — set-upstream origin new_feature
Допустим, вы внесли какие-то изменения. Эти изменения вас устраивают, и вы хотите создать запрос на принятие изменений (Pull request). В Pull request ваши коллеги смогут проверить внесенные изменения и обсудить их. Pull request можно создавать по любому поводу, будь то внесение конечных изменений или просьба о помощи в решении какой-либо проблемы.
Эмммм… это делается через сайт?
Да, все это делается с сайта GitHub.
Pull request создается по нажатию одноименной кнопки, о которой мы говорили ранее при редактировании README-файла. Элементарно!
А еще вы можете создать отдельную ветку на сайте через сам репозиторий. Перейдите в репозиторий и кликните по выпадающему меню в левой части экрана. Там еще написано Branch: master. Задайте имя новой ветки и выберите Create branch (либо нажмите Enter на клавиатуре). Теперь у вас есть две одинаковые ветки. Это отличное место для внесения изменений и тестирования их до слияния с master .
Если вы работаете в отдельной ветке, то изменения затронут только ее.
Если вас устраивают внесенные изменения вы и хотите слить их с основной веткой, создайте Pull request. При коллективной работе вы можете предложить свои изменения через Pull request и попросить проверить их или слить их с нужными ветками.
Pull request можно открыть сразу при создании коммита, даже если вы все еще работаете с кодом. Делается это с сайта GitHub. Допустим, вы внесли изменения в ветку и хотите слить их с master . Тогда:
- Кликните по вкладке Pull request вверху экрана.
- Нажмите зеленую кнопку New pull request.
- Перейдите в поле Example Comparisons. Выберите ветку, которую хотите сравнить с master .
- Еще раз просмотрите все изменения, убедитесь, что они готовы для коммита.
- Нажмите большую зеленую кнопку Newpull request. Напишите заголовок запроса, дайте краткое описание изменений. Нажмите Create pull request.
Если это ваш репозиторий, то слить изменения с master можно через зеленую кнопку Merge pull request. Нажмите Confirm merge. Сразу после объединения нужной ветки с master нажмите Delete branch в фиолетовом боксе.
Если вы участвуете в чужом проекте, то у участников команды (или проверяющего коммиты) могут возникнуть вопросы или замечания. Хотите внести какие-то изменения? Сейчас — самое время. Сразу по завершению изменений участники проекта смогут развертывать эти изменения напрямую из ветки и проводить конечное тестирование до слияния с master . Вы также сможете произвести развертку изменений для проверки их в рабочей среде.
После утверждения изменений необходимо произвести слияние вашего кода с веткой master . В Pull request хранится запись о ваших изменениях. Таким образом, вы всегда сможете открыть этот запрос и понять, какие изменения были сделаны и почему.
Обновление и слияние
Если вы хотите работать с самой свежей версией репозитория на локальном компьютере, то можно получать изменения с GitHub через git pull . Для обновления локального репозитория до последнего коммита выполните в рабочей директории следующую команду:
git pull
Для слияния какой-то ветки с вашей активной веткой воспользуйтесь:
git merge
Git старается автоматически сливать изменения, однако это не всегда возможно. Иногда возникают конфликты слияния. Если такое произошло, то необходимо разрешить конфликт слияния вручную. После внесения нужных изменений отметьте их в качестве «объединенных» или «слитых» через git add . Просмотреть изменения до слияния можно по команде:
git diff
Перейти к ветке master можно через:
git checkout master
После слияния последних изменений обязательно удалите эту ветку через команду:
git branch -d new_feature
Другие пользователи не увидят вашу ветку, пока она не будет отправлена на удаленный репозиторий. Для отправки ветки в репозиторий выполните следующую команду:
git push origin
Подборка полезных команд
Для начала, вот вам шпаргалка по GitHub, где перечислены все самые полезные Git-команды.
Просмотр истории коммита в репозитории:
git log
Просмотр коммитов одного пользователя:
git log — author=
Просмотр непроиндексированных изменений:
git diff
Сложно запомнить нужные команды? Получите подсказку из 21 самой популярной команды:
git help
Либо почитайте разъяснения по использованию определенных команд. Например, вот эта команда показывает, как пользоваться clone :
git help clone
Практическое задание
Давайте потренируемся, а заодно и поприветствуем всех, кто знакомится с Git и GitHub. Мы создадим Стену для записей GitHub Wall, где изучающие Git и GitHub смогут оставлять комментарии и участвовать в своих первых open-source проектах.
На своей Стене вы можете разместить любые материалы. Главное — помните о вежливости и доброжелательности. Оставьте комментарий, добавьте какую-то картинку… да что угодно. Если вам сложно придумать приветственный текст, то можете взять готовый шаблон из README-файла (ссылку см. ниже).
- Клонируйте мой репозиторий на сайте GitHub или по команде
- Создайте новую ветку, добавьте файл welcome_wall.md с какой-нибудь мотивирующей цитатой. Это можно сделать на сайте GitHub. Но куда интереснее склонировать репозиторий на свой компьютер, открыть файл в любимом текстовом редакторе и вписать там нужный комментарий. Так знания лучше усвоятся.
- Создайте Pull request.
- Добавьте комментарий, описывающий суть изменений. Нажмите зеленую кнопку для отправки Pull request.
Поздравляю — вы успешно справились!
- Top 100 наиболее популярных репозиториев на GitHub
- Как создать бесплатный сайт на GitHub Pages
- Как стать продуктивнее на GitHub
A3.4 Приложение C: Команды Git — Ветвление и слияния
За создание новых веток и слияние их воедино отвечает несколько Git команд.
git branch
Команда git branch — это своего рода «менеджер веток». Она умеет перечислять ваши ветки, создавать новые, удалять и переименовывать их.
Большая часть главы Ветвление в Git посвящена этой команде, она используется повсеместно в этой главе. Впервые команда branch была представлена в разделе Создание новой ветки главы 3, а большинство таких её возможностей как перечисление и удаление веток были разобраны в разделе Управление ветками главы 3.
В разделе Отслеживание веток главы 3 мы показали как использовать сочетание git branch -u для отслеживания веток.
Наконец, мы разобрались что происходит за кулисами этой команды в разделе Ссылки в Git главы 10.
git checkout
Команда git checkout используется для переключения веток и выгрузки их содержимого в рабочий каталог.
Мы познакомились с этой командой в разделе Переключение веток главы 3 вместе с git branch .
В разделе Отслеживание веток главы 3 мы узнали как использовать флаг —track для отслеживания веток.
В разделе Использование команды checkout в конфликтах главы 7 мы использовали эту команду с опцией —conflict=diff3 для разрешения конфликтов заново, в случае если предыдущее решение не подходило по некоторым причинам.
Мы рассмотрели детали взаимосвязи этой команды и git reset в разделе Раскрытие тайн reset главы 7.
Мы исследовали внутренние механизмы этой команды в разделе HEAD главы 10.
git merge
Команда git merge используется для слияния одной или нескольких веток в текущую. Затем она устанавливает указатель текущей ветки на результирующий коммит.
Мы познакомили вас с этой командой в разделе Основы ветвления главы 3. И хотя git merge встречается в этой книге повсеместно, практически все использования имеют вид git merge с указанием единственной ветки для слияния.
Мы узнали как делать «сплющенные» слияния (когда Git делает слияние в виде нового коммита, без сохранения всей истории работы) в конце раздела Форк публичного проекта.
В разделе Продвинутое слияние главы 7 мы глубже разобрались с процессом слияния и этой командой, включая флаги -Xignore-all-whitespace и —abort , используемый для отмены слияния в случае возникновения проблем.
Мы научились проверять криптографические подписи перед слияниями если ваш проект использует GPG в разделе Подпись коммитов главы 7.
Ну и наконец в разделе Слияние поддеревьев главы 7 мы познакомились со слиянием поддеревьев.
git mergetool
Команда git mergetool просто вызывает внешнюю программу слияний, в случае если у вас возникли проблемы слияния.
Мы вкратце упомянули о ней в разделе Основные конфликты слияния главы 3 и рассказали как настроить свою программу слияния в разделе Внешние программы слияния и сравнения главы 8.
git log
Команда git log используется для просмотра истории коммитов, начиная с самого свежего и уходя к истокам проекта. По умолчанию, она показывает лишь историю текущей ветки, но может быть настроена на вывод истории других, даже нескольких сразу, веток. Также её можно использовать для просмотра различий между ветками на уровне коммитов.
Практически во всех главах книги эта команда используется для демонстрации истории проекта.
Мы познакомились c git log и некоторыми её деталями в разделе Просмотр истории коммитов главы 2. Там мы видели использование опций -p и —stat для получения представления об изменениях в каждом коммите, а также —pretty and —oneline для настройки формата вывода этой команды — более полным и подробным или кратким.
В разделе Создание новой ветки главы 3 мы использовали опцию —decorate чтобы отобразить указатели веток на истории коммитов, а также —graph чтобы просматривать историю в виде дерева.
В разделах Небольшая команда главы 5 и Диапазоны коммитов главы 7 мы познакомили вас с синтаксисом branchA..branchB , позволяющем команде git log показывать только коммиты, присутствующие в одной ветке, но отсутствующие в другой. Мы довольно подробно рассматриваем этот вопрос в разделе Диапазоны коммитов.
В разделах История при слиянии и Три точки главы 7 мы рассмотрели синтаксис branchA…branchB и опцию —left-right позволяющие увидеть, что находится в одной или в другой ветке, но не в них обеих сразу. Также в разделе История при слиянии мы рассмотрели опцию —merge , которая может быть полезной при разрешении конфликтов, а также —cc для просмотра конфликтов слияния в истории проекта.
В разделе RefLog-сокращения главы 7 мы использовали опцию -g для вывода git reflog , используя git log .
В разделе Поиск главы 7 мы рассмотрели использование опций -S и -L для поиска событий в истории проекта, например, истории развития какой-либо фичи.
В разделе Подпись коммитов главы 7 мы показали, как использовать опцию —show-signature для отображения строки валидации подписи для каждого коммита в git log .
git stash
Команда git stash используется для временного сохранения всех незафиксированных изменений с целью очистки рабочего каталога без необходимости фиксировать незавершённую работу в текущей ветке.
Эта команда практически целиком раскрыта в разделе Припрятывание и очистка главы 7.
git tag
Команда git tag используется для задания постоянной метки на какой-либо момент в истории проекта. Обычно она используется для релизов.
Мы познакомились и разобрались с ней в разделе Работа с тегами главы 2 и использовали на практике в разделе Помечайте свои релизы главы 5.
Мы научились создавать подписанные с помощью GPG метки, используя флаг -s , и проверять их, используя флаг -v , в разделе Подпись главы 7.
Git Шпаргалка | Список часто используемых команд
Специальной команды для этого нет, нужно выполнить ряд действий:
# переключиться на коммит к которому мы хотим откатить ветку git checkout hash> # создать новую ветку от текущего коммита и переключиться на нее git checkout -b new_tmp_branch # удалить старую ветку git branch -d old_branch_name # переименовать новую ветку в старое имя git branch -m new_tmp_branch old_branch_name # при необходимости прокинуть ветку в удаленный репозиторий и назначить отслеживание локальной веткой удаленной Прятанье источник
- спрятать изменения без коммита
git stash - просмотр списка спрятанных изменениц
git stash list - достать спрятанные изменения
# восстановить последние спрятанные данные git stash apply # восстановить последние спрятанные данные, без добавления файлов в индекс git stash apply --index # восстановить выбранные спрятанные данные git stash apply stash@2> - удалить спрятанные изменения
git stash drop stash@0> Работа с ветками
- создание ветки
git branch new-branch - переключение на ветку
git checkout new-branch - создание ветки и переключение на нее в одну команду
git checkout -b new-branch - удаление ветки
git branch -d branch-name - переименование ветки
git branch -m old_name new_name - просмотр веток
git branch -v - просмотр всех веток вместе с удаленными
git branch -a - просмотр только удаленных веток
git branch -r - совместный просмотр и локальных и удаленных веток с подробной информацией
git branch -avv - просмотр веток, влитых в текущую
git branch --merged - просмотр веток, не влитых в текущую
git branch --no-merged - Слияние веток
# все вливается в текущую ветку на которой вы находитесь, поэтому перед слиянием переключитесь на нужную ветку git checkout branch1-name # льем другую ветку в текущую git merge --no-ff branch2-name # если после слияния ветка не нужна, то можно ее удалить git branch -d branch2-name Работа с метками (тегами) источник
- просмотр списка тегов
git tag - поиск по маске
git tag -l 'v1.4.*' - создание аннотированной метки
git tag -a v1.4 -m 'my version 1.4' - создание легковесной метки
git tag v1.4 - добавление метки на созданный ранее коммит
git tag -a v1.2 -m 'version 1.2' [код коммита] - проталкивание данных о метках в удаленный репозиторий
# все git push origin --tags # одну конкретную git push origin v1.5 Просмотр логов
- просмотр лога
https://git-scm.com/book/ru/v1/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git-%D0%9F%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80-%D0%B8%D1%81%D1%82%D0%BE%D1%80%D0%B8%D0%B8-%D0%BA%D0%BE%D0%BC%D0%BC%D0%B8%D1%82%D0%BE%D0%B2 git log git log -p git log --pretty=oneline --graph git log --pretty=format:"%h - %an, %ar : %s" gitk //это GUI утилита, в линукс потребуется установка через sudo apt-get install gitk - список коммитов, сделанных за последние две недели
git log --since=2.weeks // так же можно указать дату например "2008-01-15", // Опция --author позволяет фильтровать по автору, опция --grep позволяет искать по ключевым словам в сообщении - поиск по сообщениям коммитов
git log --all --grep='some text' Сравнение изменений
- сравнение текущих изменений с последним комитом
# все файлы git diff HEAD # определенный файл git diff HEAD fileName.ext - сравнение комитов между собой
git diff [commit_code_1] [commit_code_2] - просмотр объема правок перед коммитом
git count-objects -vH Работа с подмодулями
- привязка подмодуля
git submodule add path/to/submodule/folder - первичная инициализация подмодулей
git submodule init - получение/обновление содержимого подмодулей
git submodule update - просмотр списка подмодулей
git submodule status - Удаление подмодуля
mv a/submodule a/submodule_tmp git submodule deinit -f -- a/submodule rm -rf .git/modules/a/submodule git rm -f a/submodule # Note: a/submodule (no trailing slash) # or, if you want to leave it in your working tree git rm --cached a/submodule mv a/submodule_tmp a/submodule В случае получения ошибки “already exists in the index” при добавлении подмодуля:
#просмотреть наличие проиндексированных данных git ls-files —stage projectfolder # удалить данные из индекса git rm —cached projectfolder # повторно пытаемся добавить подмодуль git add submodule
Оптимизация репозитория
- Очистка логов
git reflog expire --all --expire=now - Запуск сборщика мусора
git gc --prune=now --aggressive Материалы для обучения
- Пошаговый учебник
- Видеокурс “Git для профессионалов” от http://pr-of-it.ru найдете при желании 🙂
- Статья о rebase и слиянии веток
- Обучающие видео http://monsterlessons.com/project/categories/git
- Полезные алиасы git команд https://habrahabr.ru/company/mailru/blog/318508/?utm_campaign=email_digest&utm_source=email_habrahabr&utm_medium=email_week_20170110&utm_content=link2post
- Шпаргалка по работе с Git http://eax.me/git-commands/
- Поддержание аккуратной истории в Git с помощью интерактивного rebase
установка средства сравнения
sudo aptitude install meld
0.2) создаем скрипт питона
cd ~/scriptHelpers touch diff.py
#!/usr/bin/python import sys import os os.system('meld "%s" "%s"' % (sys.argv[2], sys.argv[5])) 0.3) прописываем в настройках гита
git config –global diff.external ~/scriptHelpers/diff.py что бы отменить эту настройку используем git config –global –unset diff.external
Проверить что настройки применились git config –list
3) создание репозитория git init
добавление удаленного репозитория к текушему git remote add origin https://github.com/gdecider/tscc.git
проталкивание изменений в удаленный репозиторий git push -u origin master
клонирование репозитория в текущую папку git clone https://github.com/gdecider/tscc.git .
удаление файлов из подготовленных к коммиту git rm –cached если это папка, то добавляем флаг -r для рекурсивного удаления
git reset –hard HEAD git clean -f
Это отбросит все сделанные изменения которые вы возможно добавили в индекс git, а также все другие изменения в вашей рабочем дереве. Другими словами, результат этого — вывод команд “git diff” и “git diff –cached” будет пустым.
About MELD http://meldmerge.org/help/
1) Installing Meld on Ubuntu (http://linuxpitstop.com/install-meld-on-ubuntu-and-mint-linux/)
sudo apt-get update sudo apt-get install meld
настройки можно внести в глобальный файл настроек гита, который находится ~/.gitconfig [user] name = decider_op email = decider@ya.ru [core] editor = subl -n -w [diff] tool = meld [difftool] prompt = false [merge] tool = meld [mergetool] keepBackup = false или через команды
git config –global diff.tool meld git config –global merge.tool meld . . . и т.д.
— . то что ниже не проверено
git config –global mergetool.meld.trustExitCode false
// Fix git mergetool meld –help error git config mergetool.meld.hasOutput true
Для доступа к репозиторию нужно добавить SSH ключ в настройках аккаунта github https://help.github.com/articles/connecting-to-github-with-ssh/
0) Проверим есть ли ключ на ПК с которого нужно соединиться ls -al ~/.ssh
1) Сгенерируем ключ, если нет существующего ssh-keygen -t rsa -b 4096 -C “your_email@example.com”
На вопрос об имени файла можно оставить имя по умолчанию
На вопрос о пароле введите пароль или оставьте его пустым
2) Привязка ключа в аккаунт github Для получения содержимомо ключа выведем его на экран
Копируем то что вывелось в буфер обмена
Можно воспользоваться утилитой xcopy
В Вашем аккаунте GitHub идем в настройки, пункт SSH and GPG keys — New SSH key, вставляем скопированный ключ.
Pro Git
Удалённые ветки — это ссылки на состояние веток в ваших удалённых репозиториях . Это локальные ветки, которые нельзя перемещать; они двигаются автоматически всякий раз, когда вы осуществляете связь по сети. Удалённые ветки действуют как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
Они выглядят как (имя удал. репоз.)/(ветка). Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, проверьте ветку origin/master. Если вы с партнёром работали над одной проблемой, и он выложил ветку iss53, у вас может быть своя локальная ветка iss53; но та ветка на сервере будет указывать на коммит в origin/iss53.
Всё это, возможно, сбивает с толку, поэтому давайте рассмотрим пример. Я создал удаленный репозиторий на GitHub https://github.com/n0tb0dy/RemoreBranches
Там я сделал три коммита
Чтобы склонировать его воспользуемся ссылкой для клонирования
При клонировании удаленного репозитория Git автоматически назовёт его origin, заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master, и назовёт его локально origin/master (но вы не можете его двигать). Git также сделает вам вашу собственную ветку master, которая будет начинаться там же, где и ветка master в origin, так что вам будет с чем работать.
“origin” это не специальное название
Это подобно названию ветки master, которое дается по умолчанию при создании локального репозитория. Точно так же как ветка master создается по умолчанию при команде git init, точно также по умолчанию используется название origin при команде git clone. Если вы дадите команду git clone –o booyah, то вы получите booyah/master как вашу удаленную ветку по умолчанию.
И так возвращаемся к нашим… коммитам. На удаленном репозитории они выглядят так
После команды git clpne https://github.com/n0tb0dy/RemoreBranches.git локальный репозиторий будет выглядеть так
Клонирование Git-проекта даёт вам собственную ветку master и origin/master, указывающий на ветку master в origin.
После клонирования команда git log –oneline —decorate покажет нам тоже самое, что мы видим на диаграмме:
Еще раз напомню что HEAD указывает на ветку где вы сейчас находитесь.
Если вы сделаете что-то в своей локальной ветке master, а тем временем кто-то ещё отправит (push) изменения на github.com/n0tb0dy/RemoreBranches и обновит там ветку master, то ваши истории продолжатся по-разному . И ещё на заметку, до тех пор, пока вы не свяжетесь с сервером origin, ваш указатель origin/master не будет сдвигаться .
Продемонстрируем это, сделав непосредственно на сервере GitHub в нашем проекте пару коммитов. И так же сделаем пару коммитов локально.
А на локальном компьютере это будет выглядеть так:
Команда git log –oneline —decorate выполненная локально покажет нам тоже самое:
При выполнении локальной работы и отправке кем-то изменений на удалённый сервер каждая история продолжается по-разному.
Для синхронизации вашей работы выполняется команда git fetch origin. Эта команда ищет, какому серверу соответствует origin (в нашем случае это github.com/n0tb0dy/RemoreBranches ); извлекает оттуда все данные, которых у вас ещё нет, и обновляет ваше локальное хранилище данных; сдвигает указатель origin/master на новую позицию .
Как видим притянулись два наших изменения сделанных на GitHub в ветку origin/master и туда же сдвинулся указатель HEAD это ветки. А вот наша локальная ветка осталась без изменений и HEAD ветки master указывает на тот же коммит, что и до команды git fetch.
Команда git log —oneline —decorate —graph —all покажет нам всю картину изменений более ясно:
Визуально дерево коммитов после команды git fetch на локальном компьютере будет выглядеть так:
Команда git fetch обновляет ваши удалённые ссылки . Локальные же, после ее применения остаются без изменений.
Мы можем переключится на ветку origin/master
Но Git ругнется на это сказав что мы сейчас задеатачены и т.д. и т.п. даст кучу советов, но переключится. Соответственно в рабочем каталоге поменяется файл test.txt, в котором мы увидим изменения сделанные в двух последних коммитах, которые мы сделали непосредственно на сервере GitHub.
Если мы посмотрим сейчас статус, то увидим это:
Нам опять скажут что мы задеатачены.
Переключимся обратно на ветку master
Git нам любезно сообщает что наша ветка (master) и ветка origin/master разошлись и каждая имеет по два разных коммита, соответственно. И предлагает дать команду git pull чтобы слить изменения удаленной ветки с локальной.
Но мы можем поступить и по другому, просто дать команду git merge origin/master находясь в ветке master, чтобы слить изменения в одну ветку. Естественно у нас будет конфликт слияния.
Чтобы долго не мучится просто оставим без изменений слитый файл, который создал Git. Просто закоммитим их.
В результате получаем такую картину
А теперь все это добро запушим на сервер. Для этого используется команда git push (удал. сервер) (ветка). В нашем случае команда будет выглядеть просто git push origin master.
После того как мы запушили изменения на сервер дерево коммитов будет выглядеть так:
Если вы были внимательны, то должны были заметить разницу между этим скриншотом и скриншотом сразу после того как мы закоммитили смердженные ветки. Теперь оба HEAD указателя origin/master и master находятся на одном коммите 9f3e200 , это тот коммит в котором мы слили изменения из двух веток. А до этого указатель HEAD origin/master оставался на коммите 546a797 ветки origin/master .
Это означает что метки удаленных репозиториев обновляются только после подключения к удаленому репозиторию.
На GitHub эти изменения выглядят так:
Еще раз напомню про разницу между командами fetch и pull. Fetch не трогает ваши локальные изменения, а просто притягивает удаленные в другую ветку и позволяет их вам посмотреть и если надо слить со своей веткой. Pull же старается сразу объединить изменения сделанные на удаленном сервере со связанной локальной веткой.
Еще про отправку изменений
Когда вы хотите поделиться веткой с окружающими, вам необходимо отправить (push) её на удалённый сервер, на котором у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными серверами — вам нужно явно отправить те ветки, которыми вы хотите поделиться . Таким образом, вы можете использовать свои личные ветки для работы, которую вы не хотите показывать, и отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.
Если у вас есть ветка serverfix, над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните git push (удал. сервер) (ветка). Давайте для примера создадим ее, сделаем изменения в файлике test.txt и отправим это все на сревер GitHub.
Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится “возьми мой serverfix и сделай его удалённым serverfix”. Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы ветка называлась serverpigs на удалённом сервере, то вместо предыдущей команды выполните git push origin serverfix:serverpigs. Так ваша локальная ветка serverfix отправится в ветку serverpigs удалённого проекта.
На сервере GitHub появится наш последний коммит в своей ветке
В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix:
$ git fetch origin
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
From git@github.com:schacon/simplegit
* [new branch] serverfix -> origin/serverfix
Важно отметить, что когда при получении данных у вас появляются новые удалённые ветки, вы не получаете автоматически для них локальных редактируемых копий . Другими словами, в нашем случае вы не получите новую ветку serverfix — только указатель origin/serverfix, который вы не можете менять .
Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна своя собственная ветка serverfix , над которой вы сможете работать, то вы можете создать её на основе удалённой ветки:
$ git checkout -b serverfix origin/serverfix
Branch serverfix set up to track remote branch refs/remotes/origin/serverfix.
Switched to a new branch «serverfix»
Это даст вам локальную ветку serverfix , на которой можно работать. Она будет начинаться там, где и origin/serverfix.
Если вы хотите чтобы локальное имя ветки отличалось от удаленной то можете эту же команду дать например так:
$ git checkout -b MYserverfix origin/serverfix
Для примера создадим новую ветку CreatedOnGitHub в нашем проекте на сервере GitHub и сделаем изменения в нашем многострадальном файле test.txt и закоммитим их. А затем притянем себе в локальный Git.
Вот наша, созданная удаленно веточка и коммит в ней притянулись. Как видим в имени ветки стоит origin/CreatedOnGitHub. То есть как и говорилось выше мы не получили локальную ветку CreatedOnGitHub после выполнения команды git fetch origin.
Теперь мы можем переключится в ветку origin/CreatedOnGitHub и получить измененный файл test.txt (с изменениями которые мы сделали на сервере) в рабочем каталоге и получить редактируемую копию ветки origin/CreatedOnGitHub в локальной ветке CreatedOnGitHub простой командой git checkout CreatedOnGitHub:
То есть мы проделали ту же подобную команду (git checkout -b serverfix origin/serverfix), только гораздо проще. Хотя при этом мы создали отслеживаемую ветку (об этом читаем ниже).
Мы можем посмотреть ветки которые у нас есть
Теперь сделаем изменения в нашем файлике test.txt в ветке CreatedOnGitHub и отправим эти изменения обратно на сервер GitHub
Теперь посмотрим это на GitHub
Видим что наш Local Commit 04 бла бла бла… успешно запушен на сервер GitHub.
Отслеживание веток
Получение локальной ветки с помощью git checkout из удалённой ветки автоматически создаёт то, что называется отслеживаемой веткой . Отслеживаемые ветки — это локальные ветки, которые напрямую связаны с удалённой веткой . Если, находясь на отслеживаемой ветке, вы наберёте git push, Git уже будет знать, на какой сервер и в какую ветку отправлять изменения . Аналогично выполнение git pull на одной из таких веток сначала получает все удалённые ссылки, а затем автоматически делает слияние с соответствующей удалённой веткой.
При клонировании репозитория, как правило, автоматически создаётся ветка master, которая отслеживает origin/master, поэтому git push и git pull работают для этой ветки «из коробки» и не требуют дополнительных аргументов. Однако, вы можете настроить отслеживание и других веток удалённого репозитория.
Если вы хотите посмотреть какие отслеживаемые ветки у вас есть то можете дать команду
$ git branch –vv
Примечание: номера коммитов отображаемые командой git branch –vv , могут не соответствовать тем, что у вас есть в реальности, так как о на показывает номера коммитов которые были после последней команды fetch . Это просто надо иметь в виду. Если же вы хотите чтобы все отображаемые номера коммитов соответствовали тому что есть на сервере, то сперва надо дать команду git fetch —all.
Из этого скрина мы видим что у нас отслеживаются ветки master и CreatedOnGitHub, а ветка serverfix не отслеживается.
Это можно поправить следующей командой
$ git branch -u origin/serverfix
Поскольку локальная ветка serverfix у нас уже существует то надо использовать ключ –u, чтобы включить ее отслеживание, но для этого сперва надо перейти в эту ветку, чтобы дать эту команду. Смотрим скрин
Теперь все три наших ветки отслеживаются.
Примечание: при команде git push нам приходилось каждый раз вводить логин и пароль для публикации изменений на сервере GitHub. Этого можно избежать настроив кэш учетных записей.
Pulling
Команда git fetch просто получает обновления с сервера которых у вас еще нет и ни каким образом не изменяет вашу рабочую директорию . Эта команда просто получает данные и позволяет вам самим решать что с ними делать (объединять с вашими данными, редактировать и т.п.)
Команда git pull , в большинстве случаев, сразу же производит слияние полученных данных с вашими .
Обычно, лучше просто использовать команду git fetch и команду git merge, чтобы иметь самим возможность проконтролировать процесс слияния.
Удаление удаленных веток
Имеется конечно в виду удаление веток на удаленном сервере
Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя команду:
$ git push origin —delete serverfix
Хлоп! И ветка на удаленном сервере исчезла. Но в принципе эта команда просто удаляет указатель ветки на удаленном сервере. Git сервер продолжит хранить всю информацию о коммитах до тех пор пока вы не запустите команду уборки мусора.