git pull —rebase
Рассмотрим команду pull с параметром rebase:
git pull --rebase
На результат слияния параметр —rebase не влияет, единственное, что он делает — меняет вид истории коммитов.
До команды pull
Допустим, мы разветвились с удаленным репозиторием на коммите D:
До pull
Наши локальные коммиты с момента разветвления — это нижние E, F, G, а в удаленном репозитории с тех пор появились коммиты A, B, C. Нам надо их накатить сверху на наши коммиты E, F, G, что собственно и делает команда pull.
Обычный pull
Но тут возможны нюансы. По умолчанию делается дополнительный коммит H, который и включает все изменения из удаленной ветки:
git pull
pull —rebase
Если же мы выполним:
git pull --rebase
то история локальных коммитов будет выглядеть по другому (при том же результате слияния файлов):
git pull —rebase
При просмотре истории коммитов мы просто увидим ряд коммитов из основной ветки A, B, C, идущих за нашими локальными E, F, G. Кому-то такой вид выглядит чище, хотя разницы в итоговом содержимом файлов нет.
Как работать с ветками в PhpStorm
В правом нижнем углу есть пункт «Git:master». Там пишется название текущей ветки. Чтобы создать новую, нужно кликнуть на этот пункт и выбрать New Branch.
Чтобы переключиться, выбрать в списке Local Branches нужную ветку и Checkout. Чтобы удалить или переименовать соотвественно Delete или Rename.
Наглядно это показывается в видеоуроке
Раздел Remote Branches мы рассмотрим в следующем уроке
Что могу посоветовать
- научитесь легко оперировать ветками
- создавайте больше веток
- называйте ветки по общим правилам
- пушьте ветки почаще, их легко потом удалить
Поняв магию веток, мы уже не представим свою работу без git. Любой, даже небольшой проект мы будем начинать с создания репозитория.
А работа с ветками будет такой же естественной, как и собственно написание кода. Мне кажется, именно понимание веток превращает git из прикольной тулзы в незаменимый инструмент работы.
И напоследок Киану. Просветление. Назад возврата нет
В следующем уроке мы узнаем, как работать с ветками на сервере
Спасибо за внимание и до встречи!
Следующий урок ⇨
Урок 8. Работа с ветками на сервере, git fetch
⇦ Предыдущий урок
Урок 6. git push и git pull
Как переименовать ветку
Иногда оказывается, что первоначально созданное имя ветки не самое лучшее. Его можно изменить.
Локальную
Если еще не выполнена команда push, то достаточно переименовать локальную ветку.
Чтобы переименовать локальную ветку, выполним команду:
$ git branch -m <old-name> <new-name>
Например, переименуем ветку testing в ветку test:
$ git branch –m testing test
Чтобы переименовать текущую ветку, выполним команду:
$ git branch -m <new-name>
Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:
$ git branch –m subbranch
Удаленную
Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:
$ git push origin :old-name new-name
здесь origin — имя удаленного репозитория (обычно удаленный репозиторий так называется),old-name — имя ветки локальной ветки,new-name — новое имя ветки в удаленном репозитории.
Например, надо переименовать ветку testing в test:
$ git push origin :testing test
Какие проблемы решают ветки
Представим рабочую ситуацию. Мы сидим и разрабатываем функционал новой большой фичи, например, добавляем на сайт раздел новостей.
Уже добавили новые файлы, поменяли стили, поправили разметку, но до завершения еще далеко.
Внезапно прилетает задача — срочно поправить багу в верстке шапки. Мы не можем чинить багу прямо сейчас, в текущем состоянии проекта.
У нас много изменений, но работа над большой фичей не завершена — поэтому мешать код новой фичи и код с починкой срочной баги нельзя. Как быть?
Было бы здорово, если бы могли разрабатывать новую фичу независимо от основного кода проекта.
То есть взять и зафиксировать рабочее состояние сайта, а делать новый функционал отдельно, не боясь поломать рабочий код.
И еще чтобы можно было переключаться между основным кодом (для правки баги) и кодом новой фичи (для продолжения работы над ней)
Когда я не пользовался git, то решал эту проблему созданием архивов проекта. Довел сайт до какого-то рабочего состояния — сделал архив.
Реализовал новую фичу — сделал еще один архив. Нужно переключиться на старый код для правки баги —
сохранил текущую работу в новый «временный» архив, выбрал старый «стабильный» архив, распаковал, починил там багу, вернулся обратно во «временный» архив.
Схема рабочая, но слишком много суеты и неудобств:
- нужно постоянно создавать архивы с рабочим кодом
- сложно «переключаться» между архивами
- сложно перетаскивать изменения между архивами
- легко что-то напутать или потерять — все мы люди
Все эти проблемы git решает механизмом веток.
Создание новой ветви в командной строке
Программа Git в командной строке предлагает максимальную мощность и гибкость, но есть чему поучиться. Если вам удобно копаться в man-страницах и активно использовать Git, это отличный вариант.
Используйте команду git branch <branchname>, чтобы создать новую ветку с заданным именем:
Это ответвление от текущей ветви, поэтому убедитесь, что вы переключились на ту, от которой хотите перейти, прежде чем выполнять эту команду.
Вы можете перечислить все ветки и подтвердить, что новая была создана, с помощью git branch без каких-либо аргументов:
Вы можете увидеть дополнительную информацию, в том числе, какую ветвь отслеживает другая, используя флаг -vv :
Если вы попытаетесь создать ветку до первой фиксации, вы получите сообщение об ошибке, например:
Если вы попытаетесь создать ветку с уже существующим именем, вы получите сообщение об ошибке, например:
Команда git branch создает новую ветку, указывающую на тот же коммит, над которым вы сейчас работаете. Однако ваша рабочая копия по-прежнему будет указывать на основную ветку. Чтобы переключиться на новую ветку, которую вы только что создали, используйте git checkout :
Термин « проверка» может сбивать с толку, если вы привыкли к другим системам контроля версий; в Git проверка относится к переключению текущей активной ветки. Поскольку вы обычно хотите переключиться на новую ветку после ее создания, для всего процесса есть ярлык:
Эта команда означает «создать новую ветку под названием« dev »и немедленно переключиться на нее». Это эквивалент:
Фактически, вы даже можете использовать git checkout для создания ветки из любой другой, а не только из той, которая в данный момент проверена. Например, чтобы создать новую ветку с именем another , из ветки с именем dev :
Как создать подветку ветки
Обычно мы ответвляемся от основной ветки master, но не всегда. Иногда требуется сделать ответвление от созданной ветки — так сказать, ответвление второго порядка.
Предыдущая команда, с помощью которой мы создавали ветку:
$ git branch testing
создает ответвление от основной ветки master.
Если нам надо ответвиться не от основной ветки, а от вновь созданной testing, то выполним поочередно команды:
$ git checkout testing $ git checkout -b subbranch_of_testing testing
Первая команда переключит нас на ветку testing.
Вторая команда создаст ветку с именем subbranch_of_testing, ответвляющуюся от testing, и переключит нас на нее.
Как понятно из имени, subbranch_of_testing – это подветка ветки testing.
Как использовать команду Git Merge?
Чтобы объединить изменения, полученные в предыдущем разделе, выполните следующую команду:
git merge
Если вы видите такой же результат, значит, вы успешно объединили изменения в своем локальном репозитории. На приведенном выше изображении третья строка показывает написанное Fast-forward (перемотка вперед). Это происходит потому, что это fast-forward merge (быстрое слияние), выполняемое git. Давайте посмотрим, что это такое.
Fast-Forward Merge
Fast-Forward Merge (быстрое слияние) в Git означает, что существует линейный путь от ветви, который отклоняется от ветви, к которой вы сливаетесь. Линейный путь означает, что не было никаких коммитов к главной ветви с тех пор, как ветвь объекта перешла в точку слияния.
На приведенном выше рисунке показано, что ветвь была отклонена, сделала три коммита, и за это время в главной ветви не было коммитов (зеленые точки). После трех коммитов я объединю ветвь функции в главную ветвь, что приведет к быстрой перемотке вперед.
Как использовать команду Git Fetch?
Прежде чем использовать эту команду, давайте внесем некоторые изменения в наш удаленный репозиторий, чтобы мы могли извлечь их через локальный репозиторий.
Выполните следующие действия в своей учетной записи GitHub:
- Во-первых, откройте свою учетную запись GitHub и перейдите в репозиторий.
- Во-вторых, откройте Readme.md файл.
- В-третьих, нажмите значок редактирования, чтобы отредактировать файл.
- В-четвертых, отредактируйте описание файла.
- После этого прокрутите вниз, зафиксируйте изменения и нажмите кнопку commit changes (зафиксировать изменения).
- Изменения будут отражены в файле README.md.
Теперь, когда у нас есть некоторые изменения в удаленном репозитории, мы должны получить их в нашей локальной рабочей копии репозитория.
- Откройте Git bash и перейдите в свой рабочий каталог.
- Проверьте наличие чистого рабочего репозитория (никаких зафиксированных изменений).
- Наконец, выполните команду в Git Bash: git fetch
Последние две строки означают:
https://<repo_url> : URL-адрес репозитория.
e7b37f6..47b2bf6 : первый хэш-это хэш последней объединенной фиксации в локальном репозитории, а 47b2bf6-это новый хэш-код фиксации/изменения из удаленного репозитория.
Пользователь также может проверить коммиты и недавние действия с помощью команды git log.
Если на вашем экране отображается аналогичный вывод, как показано на рисунке выше, вы успешно извлекли изменения из удаленного хранилища.
Частые вопросы
Что отличает git fetch и git pull?
Команда git fetch и команда git pull отличаются друг от друга по работе. Git fetch извлекает изменения, в то время как git pull объединяет их после извлечения. Таким образом, в некотором смысле git fetch является частью git pull, поскольку он сначала извлекает изменения, а затем выполняет git merge.
Могу ли я отменить изменения, внесенные git merge?
Да, в Git слияние изменений может повернуть вспять с помощью следующих действий. Определите коммит, к которому вы хотите вернуться с помощью команды git reflog. Выполните жесткий сброс вместе с хэшем фиксации с помощью git reset –hard <hash>.
git pull force
Насильно выполнить git pull нельзя. Она не перезапишет локальные изменения, если есть конфликт. Конфликт все равно придется разрешать.
Если же требуется получить данные из удаленной ветки, перезаписав локальные изменения, то делается это в два этапа. Сначала обновить локальную копию удаленного репозитория:
git fetch --all
Далее, допустим надо перезаписать содержимое текущей ветки данными из ветки master репозитория origin:
git reset --hard origin/master
Если надо перезаписать содержимое текущей ветки данными из другой ветки dev репозитория origin:
git reset --hard origin/dev
Но будьте внимательны с опцией —hard, она действительно затирает коммиты текущей ветки безвозвратно. Если надо их сохранить, то перед выполнением команды создайте новую ветку — в нее все сохранится:
git branch new-branch-to-save-current-commits git fetch --all git reset --hard origin/dev
Что еще интересно: коммиты reset —hard затирает, а если в папке были просто неотслеживаемые файлы, то они не будут затронуты.
Как работают ветки
Представим код проекта в виде дерева. Посередине ствол — это рабочее состояние проекта, тот код, который выложен на боевом сервере.
Этот ствол в терминах git называется основной веткой разработки — веткой master. Эта ветка есть всегда в любом проекте.
Как только мы клонировали или создали новый репозиторий, мы попали в ветку master. Все, что мы делали на предыдущих уроках, мы делали в мастере.
Когда мы начинаем работать над новым функционалом, мы создаем новую ветку на основе master. Это называется «ответвиться от мастера».
После этого мы можем работать, создавать новые файлы, вносить изменения в старые, можем хоть удалить половину проекта — главное, что это будет изолировано от основного мастера.
То есть в своей ветке мы можем как угодно ломать проект, основной код при этом не пострадает.
Кроме того мы в любой момент можем переключиться в мастер, например, для правки баги, не боясь потерять изменения в своей ветке с новым функционалом.
Починим багу в мастере, выложим правку на боевой сайт и так же легко вернемся к своей ветке и продолжим работать в ней.
Так как git хранит всю историю проекта, то он хранит все коммиты всех веток и со всеми изменениями. То есть вернувшись в свою ветку мы увидим уже сделанные коммиты и можем посмотреть изменения по ним.
Когда мы заканчиваем работать над новым функционалом, то нужно наши изменения перенести в мастер, чтобы залить на боевой сайт.
Это называется слить ветку в мастер, или залить в мастер, или смерджить в мастер.
При этом после мерджа в мастере оказываются не только наши изменения, но и те, которые были в мастере, но не были в нашей ветке (правка баги в мастере).
То есть нам даже не обязательно после правки баги в мастере переносить эти изменения в свою ветку. При мердже git наш новый код «положит» поверх того, что было в мастере, не стирая старый.
Чтобы было нагляднее и понятнее, как это работает, смотрите видео. А в тексте ниже краткое описание команд для работы с ветками.
