Learning How to Git: Create Git Branch
One of the killer features in Git is the existence of the branch system. Branch allowing us to create a different state of the files and folders. If you still wondering how branching works you can check my previous story here.
(Very) Basic Concept of Git
For someone who worked on software development, most probably you will have heard about Git.
Create Git Branch
Firstly, let’s see the branches we have using git branch .
Okay, so currently we only have a branch called master . Let’s create another branch called dev . To create a new branch we can use the git checkout -b <name-of-new-branch> . The checkout command is actually pretty tricky, we will talk about it in future stories. So, because I want to create a branch called dev then my command would be git checkout -b dev .
Hooray, now if you check using git branch , we will see our new branch.
The asterisk (*) symbol represents the current branch you currently at or usually, it is also represented at the right of the current working directory path (notice the (dev) at the upper right corner).
Working on Your Branch
Now let’s say we are working on this branch and creating commit(s). After creating all of those commit(s), we can push the branch to the remote repository by using git push origin <name-of-branch> . So, because we are currently on the dev branch then we need to run git push origin dev .
Now let’s check what happened on our remote repository.
We can see that the dev branch is now one step ahead of the master branch. This means that anything happened at to dev branch doesn’t affect the master branch.
Move to Other Branch
Let’s say we have finished with our dev branch, how we can move to other branches? It’s similar to the previous command, but we omit the -b parameter. So we would have git checkout <name-of-branch> . In my case, I want to go back to master branch, so I would use git checkout master .
If you check the file or the log you will found that the commit from the other branch will not exist here.
Wrap Up
I think this already covers the introduction to git branch system. On the next story, we are going to talk about merging those branches. I hope it’s helpful and thanks for reading.
30 команд Git, необходимых для освоения интерфейса командной строки Git
Git — самая популярная в мире распределённая система контроля версий. Линус Торвальдс, разработчик ядра ОС Linux, создал этот инструмент ещё в 2005 году, а сегодня Git активно поддерживается как проект с открытым исходным кодом. Огромное количество открытых и коммерческих проектов используют Git для контроля версий.
В данной статье перечисляются самые основные команды, которые следует знать разработчику, чтобы освоить управление репозиториями GitHub на высоком уровне. Ознакомиться с ними будет полезно как новичкам, так и опытным разработчикам.
30 основных команд, которые сделают из вас мастера Git
1. Как задать имя пользователя и адрес электронной почты
Имя пользователя нужно, чтобы привязывать коммиты к вашему имени. Это не то же самое, что имя пользователя учётной записи GitHub, с помощью которого выполняется вход в профиль на GitHub. Задать или изменить имя пользователя можно с помощью команды git config . Новое имя будет автоматически отображаться в последующих коммитах, отправленных на GitHub через командную строку. Если хотите скрыть своё реальное имя, можно использовать в качестве имени пользователя Git произвольный набор символов.
Кроме того, командой git config можно изменять адрес электронной почты, привязанный к вашим коммитам Git. Новый адрес электронной почты будет автоматически отображаться во всех дальнейших коммитах, поданных на GitHub через командную строку.
2. Кэширование учётных данных
Кэшировать учётные данные можно с помощью параметра config с флагом —global . Так вы избавитесь от необходимости вручную вводить имя пользователя и пароль при создании нового коммита.
3. Инициализация репозитория
Создать пустой репозиторий Git или вновь инициализировать существующий можно параметром init . При инициализации он создаст скрытую папку. В ней содержатся все объекты и ссылки, которые Git использует и создаёт в истории работы над проектом.
4. Добавление отдельных файлов или всех файлов в область подготовленных файлов
Добавить отдельный файл в область подготовленных файлов можно параметром add с указанием имени файла. Просто замените somefile.js на актуальное имя.
Кроме того, можно добавить все файлы и папки в эту область, предоставив wildcard . вместо имени файла:
5. Проверка статуса репозитория
Просмотреть статус нужного репозитория можно по ключевому слову status : его действие распространяется на подготовленные, неподготовленные и неотслеживаемые файлы.
6. Внесение изменений однострочным сообщением или через редактор
При создании коммита в репозитории можно добавить однострочное сообщение с помощью параметра commit с флагом -m . Само сообщение вводится непосредственно после флага, в кавычках.
Также можно открыть текстовый редактор в терминале для написания полного сообщения коммита. Оно может состоять из нескольких строк текста, в котором подробно характеризуются изменения, внесённые в репозиторий.
7. Просмотр истории коммитов с изменениями
Просматривать изменения, внесённые в репозиторий, можно с помощью параметра log . Он отображает список последних коммитов в порядке выполнения. Кроме того, добавив флаг -p , вы можете подробно изучить изменения, внесённые в каждый файл.
8. Просмотр заданного коммита
Просмотреть полный список изменений, внесённых конкретным коммитом, можно с помощью параметра show , указав идентификатор или хеш коммита. Значение хеша уникально для каждого коммита, созданного в вашем репозитории.
Также можно использовать сокращённый хеш.
9. Просмотр изменений до коммита
Можно просматривать список изменений, внесённых в репозиторий, используя параметр diff . По умолчанию отображаются только изменения, не подготовленные для фиксации.
Для просмотра подготовленных изменений необходимо добавить флаг —staged .
Также можно указать имя файла как параметр и просмотреть изменения, внесённые только в этот файл.
10. Удаление отслеживаемых файлов из текущего рабочего дерева
Удалять файлы из текущего рабочего дерева можно с помощью параметра rm . При этом файлы удаляются и из индекса.
Можно также использовать маски файлов (например *.js) для удаления всех файлов, соответствующих критерию.
11. Переименование файлов
Переименовать файл или папку можно параметром mv . Для него указывается источник source и назначение destination . Источник — реально существующий файл или папка, а назначение — существующая папка.
При выполнении команды файл или папка, указанные как источник, будут перемещены в папку назначения. Индекс будет обновлён соответственно, но изменения нужно записать.
12. Отмена подготовленных и неподготовленных изменений
Восстановить файлы рабочего дерева, не подготовленные к коммиту, можно параметром checkout . Для проведения операции требуется указать путь к файлу. Если путь не указан, параметр git checkout изменит указатель HEAD, чтобы задать указанную ветку как текущую.
Восстановить подготовленный файл рабочего дерева можно параметром reset . Потребуется указать путь к файлу, чтобы убрать его из области подготовленных файлов. При этом не будет производиться откат никаких изменений или модификаций — однако файл перейдёт в категорию не подготовленных к коммиту.
Если нужно выполнить это действие для всех подготовленных файлов, путь к ним указывать не надо.
13. Изменение последнего коммита
Внести изменения в последний коммит можно параметром commit с флагом —amend . Например, вы записали изменения, внесённые в ряд файлов, и поняли, что допустили ошибку в сообщении коммита. В этом случае можете воспользоваться указанной командой, чтобы отредактировать сообщение предыдущего коммита, не изменяя его снимок.
Также можно вносить изменения в файлы, отправленные ранее. Например, вы изменили несколько файлов в ряде папок и хотите их записать как единый снимок, но забыли добавить в коммит одну из папок. Чтобы исправить такую ошибку, достаточно подготовить для фиксации остальные файлы и папки и создать коммит с флагами —amend и —no-edit .
Флаг —no-edit позволит внести в коммит поправку без изменения сообщения коммита. В этом случае итоговый коммит заменит неполный, а выглядеть это будет так, как будто мы отправили изменения ко всем файлам в нужных папках как единый снимок.
Внимание! Не изменяйте публичные коммиты.
С помощью amend прекрасно исправляются локальные коммиты, а исправления можно передать в общий репозиторий. Однако изменять коммиты, уже доступные другим пользователям, не следует. Помните, что изменённые коммиты являются совершенно новыми, а предыдущий коммит уже не будет доступен в текущей ветке. Последствия будут такими же, как при отмене изменений публичного снимка.
14. Откат последнего коммита
Откатить последний коммит можно с помощью параметра revert . Создастся новый коммит, содержащий обратные преобразования относительно предыдущего, и добавится к истории текущей ветки.
▍ Разница между revert и reset
Команда git revert отменяет изменения, записанные только одним коммитом. Она не откатывает проект к более раннему состоянию, удаляя все последующие коммиты, как это делает команда git reset .
У команды revert есть два крупных преимущества по сравнению с reset. Во-первых, она не меняет историю проекта и производит операцию, безопасную для коммитов. Во-вторых, её объектом выступает конкретный коммит, созданный в любой момент истории, а git reset всегда берёт за точку отсчёта текущий коммит. К примеру, если нужно отменить старый коммит с помощью git reset, придётся удалить все коммиты, поданные после целевого, а затем выполнить их повторно. Следовательно, команда git revert — гораздо более удобный и безопасный способ отмены изменений.
15. Откат заданного коммита
Откатить проект до заданного коммита можно с помощью параметра revert и идентификатора коммита. Создастся новый коммит — копия коммита с предоставленным идентификатором — и добавится к истории текущей ветки.
16. Создание новой ветки и переход в неё
Создать новую ветку можно с помощью параметра branch , указав имя ветки.
Но Git не переключится на неё автоматически. Для автоматического перехода нужно добавить флаг -b и параметр checkout .
17. Просмотр списка веток
Можно просматривать полный список веток, используя параметр branch . Команда отобразит все ветки, отметит текущую звёздочкой (*) и выделит её цветом.
Также можно вывести список удалённых веток с помощью флага -a .
18. Удаление ветки
Удалить ветку можно параметром branch с добавлением флага -d и указанием имени ветки. Если вы завершили работу над веткой и объединили её с основной, можно её удалить без потери истории. Однако, если выполнить команду удаления до слияния — в результате появится сообщение об ошибке. Этот защитный механизм предотвращает потерю доступа к файлам.
Для принудительного удаления ветки используется флаг -D с заглавной буквой. В этом случае ветка будет удалена независимо от текущего статуса, без предупреждений.
Вышеуказанные команды удаляют только локальную копию ветки. В удалённом репозитории она может сохраниться. Если хотите стереть удалённую ветку, выполните следующую команду:
19. Слияние двух веток
Объединить две ветки можно параметром merge с указанием имени ветки. Команда объединит указанную ветку с основной.
Если надо выполнить коммит слияния, выполните команду git merge с флагом —no-ff .
Указанная команда объединит заданную ветку с основной и произведёт коммит слияния. Это необходимо для фиксации всех слияний в вашем репозитории.
20. Отображение журнала фиксации в виде графика для текущей или всех веток
Просмотреть историю коммитов в виде графика для текущей ветки можно с помощью параметра log и флагов —graph —oneline —decorate . Опция —graph выведет график в формате ASCII, отражающий структуру ветвления истории коммитов. В связке с флагами —oneline и —decorate , этот флаг упрощает понимание того, к какой ветке относится каждый коммит.
Для просмотра истории коммитов по всем веткам используется флаг —all .
21. Прекращение слияния при конфликте
Прервать слияние в случае конфликта можно параметром merge с флагом —abort . Он позволяет остановить процесс слияния и вернуть состояние, с которого этот процесс был начат.
Также при конфликте слияния можно использовать параметр reset , чтобы восстановить конфликтующие файлы до стабильного состояния.
22. Добавление удалённого репозитория
Добавить удалённый репозиторий можно параметром remote add , указав shortname и url требуемого репозитория.
23. Просмотр удалённых URL-адресов
Просматривать удалённые URL-адреса можно параметром remote с флагом -v . Этот параметр отображает удалённые подключения к другим репозиториям.
Такая команда открывает доступ к интерфейсу управления удалёнными записями, которые хранятся в файле .git/config репозитория.
24. Получение дополнительных сведений об удалённом репозитории
Получить подробные сведения об удалённом репозитории можно с помощью параметра remote show с указанием имени репозитория — например, origin .
Эта команда отображает список веток, связанных с удалённым репозиторием, а также рабочих станций, подключённых для получения и отправки файлов.
25. Отправка изменений в удалённый репозиторий
Отправлять изменения в удалённый репозиторий можно параметром push с указанием имени репозитория и ветки.
Эта команда передаёт локальные изменения в центральный репозиторий, где с ними могут ознакомиться другие участники проекта.
26. Получение изменений из удалённого репозитория
Для загрузки изменений из удалённого репозитория используется параметр pull . Он скачивает копию текущей ветки с указанного удалённого репозитория и объединяет её с локальной копией.
Также можно просмотреть подробные сведения о загруженных файлах с помощью флага —verbose .
27. Слияние удалённого репозитория с локальным
Слияние удалённого репозитория с локальным выполняется параметром merge с указанием имени удалённого репозитория.
28. Отправка новой ветки в удалённый репозиторий
Передать новую ветку в удалённый репозиторий можно параметром push с флагом -u , указав имя репозитория и имя ветки.
29. Удаление удалённой ветки
Чтобы избавиться от удалённой ветки, используйте параметр push с флагом —delete , указав имя удалённого репозитория и имя ветки.
30. Использование перебазирования
Для доступа к этой функции используйте параметр rebase с указанием имени ветки. Перебазирование — это процесс объединения или перемещения последовательности коммитов на новый родительский снимок.
Эта команда изменит основу ветки с одного коммита на другой, как если бы вы начали ветку с другого коммита. В Git это достигается за счёт создания новых коммитов и применения их к указанному базовому коммиту. Необходимо понимать, что, хотя ветка и выглядит такой же, она состоит из совершенно новых коммитов.
▍ Спасибо за внимание!
Вы узнали 30 основных команд интерфейса командной строки Git. Теперь, при условии регулярной практики, у вас есть всё необходимое, чтобы достичь мастерства в управлении репозиториями GitHub.
Git. Урок 3.
Ветвление. Создание, переключение и удаление веток. Команды: branch, checkout, status, log, diff.
1. Что такое ветка.
2. Зачем нужны ветки.
3. Создание новых веток.
4. Просмотр списка веток.
5. Переключение между ветками.
6. Просмотр состояния ветки. Команды: git status, git log, git diff.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
6.3. Просмотр различий между коммитами. Команда git diff.
7. Удаление веток.
Дадим два определения ветки: на логическом и физическом уровнях.
1. Логический уровень.
С точки зрения логики, ветка – это последовательность коммитов. Чтобы проще было понять, что такое ветка, рассматривайте ее как некоторую временную шкалу. Коммиты в ней – снимки интересных моментов, идущие друг за другом в хронологической последовательности. Рисунок ниже поможет вам в интуитивном представлении.
На рисунке выше изображены три ветки: main , develop и feature . Каждая представляет из себя «поток» коммитов в хронологической последовательности. Важно заметить, что эти потоки не пересекаются, то есть работа в ветках идет параллельно.
2. Физический уровень
На физическом уровне, то есть с точки зрения внутренней реализации Git, ветка – это ссылка на последний коммит в этой ветке. Картинка ниже поможет вам понять, что к чему.
- HEAD – так называемый курсор Git. Главное назначение HEAD — определять, в каком состоянии находится рабочая копия (напомним, что рабочая копия – это все файлы репозитория, за исключением директории .git/ ). На какой коммит указывает HEAD – из того коммита и загружаются файлы в рабочую директорию.
- ORIG_HEAD – указатель, который появляется, когда мы вручную передвигаем HEAD на какой-нибудь НЕ последний коммит. ORIG_HEAD указывает на тот же коммит, на который указывал HEAD до передвижения назад. Нужен он, чтобы мы имели возможность вернуться на хронологически последний коммит без существенных затрат (в истории мы не будем видеть все коммиты старше нашего, а поэтому не сможем узнать хэш последнего).
- Пользовательские указатели. Пользователи сами могут создавать указатели. Например, вы можете создать указатель version-1.2.1 , который будет указывать на коммит, в котором хранится версия 1.2.1 вашего проекта. Это довольно удобно, поскольку вы можете переключаться на коммит с той или иной версией, не запоминая его хэш.
Преимущество веток в их независимости. Вы можете вносить изменения в файлы в одной ветке, например, пробовать новую функцию, и они никак не скажутся на файлах в другой ветке. Изначально в репозитории одна ветка, но позже мы рассмотрим, как создавать другие.
На самом деле, вначале, когда мы делаем свой первый коммит, Git автоматически создает основную ветку. Вы можете помнить, что ее имя по умолчанию «main» мы задавали в настройках Git в предыдущем уроке. Каждый раз, когда мы создаем новый коммит, Git автоматически перемещает указатель main на последний коммит. Тем не менее, в следующем уроке мы узнаем, как перемещать указатель ветки между коммитами самостоятельно.
Пока мы разбирались, что такое ветка, у вас мог возникнуть вопрос: зачем нужны такие сложности, ведь можно просто делать коммиты и откатывать изменения, когда нужно.
Дело в том, что Git – универсальная система контроля версий: она подходит и большим командам крупных корпораций, и индивидуальным разработчикам для их личных проектов.
Если вы работаете один – скорее всего вы будете редко использовать ветки, но если вы работаете в большой компании, без веток вам не обойтись.
Итак, чаще всего ветки используются в следующих случаях.
- Ветки нужны, чтобы несколько программистов могли вести работу над одним и тем же проектом или даже файлом одновременно, при этом не мешая друг другу.
- Кроме того, ветки используются для тестирования экспериментальных функций: чтобы не повредить основному проекту, создается новая ветка специально для экспериментов. Если эксперимент удался, изменения с экспериментальной ветки переносятся на основную, если нет – новая ветка попросту удаляется, а проект остается нетронутым.
- Помимо прочего, ветки можно использовать для разных выходящих параллельно релизов одного проекта. Например, в репозитории Python может быть две ветки: python-2 и python-3 . До закрытия python-2 релизы этих версий языка выходили независимо друг от друга, поэтому могло иметь место такое разделение на ветки.
Способ 1. Команды git branch + git checkout
Команда git branch
На самом деле, git branch – очень мощная команда, которая умеет много всего. Сейчас мы рассматриваем ее как инструмент для создания веток. Ниже мы рассмотрим еще некоторые способы ее применения.
И как мы уже сказали, в качестве второго этапа после создания новой ветки, вам нужно переключиться на нее командой git checkout .
Способ 2. Команда git checkout -b
Команда git checkout
Как и git branch , git checkout – очень многофункциональная команда. Главное ее назначение – перемещать указатель HEAD . О том, как она работает и какие еще имеет применения, мы поговорим ниже.
- В директории .git\refs\heads создается новый файл, имя которого – имя ветки, которую вы хотите создать (при условии, что такого файла не существует). Например, если мы выполним команду git branch feature , то создастся файл .git\refs\heads\feature .
- В созданный файл записывается хэш текущего коммита. С него ветка и начнется. После этого файл .git\refs\heads\feature будет выглядеть так:
40 шестнадцатеричных цифр в файле выше и есть хэш последнего коммита, на который указывает новосозданная ветка.
Важно понимать, что как только вы создали новую ветку, она указывает на тот же коммит, что и основная ветка, и HEAD . Графически ситуация выглядит так:
Как мы видим, указатели feature и HEAD передвинулись на последний коммит 6670 .
С помощью команд git branch и git checkout вы можете создать неограниченное количество веток и переключаться между ними по мере необходимости. Обычно если ветка вам больше не нужна, ее сливают с основной и удаляют. Тема слияния веток заслуживает отдельного урока, поэтому про это мы поговорим в следующий раз, а удаление веток рассмотрим чуть ниже.
Команда git branch
# Выведем локальные и удаленные ветки
$ git branch -a
* develop
feature
main
remotes/origin/HEAD -> origin/main
remotes/origin/develop
remotes/origin/feature
remotes/origin/main
# Теперь выведем только локальные ветки
$ git branch
* develop
feature
main
# А теперь только удаленные ветки
$ git branch -r
origin/HEAD -> origin/main
origin/develop
origin/feature
origin/main
В примере выше можно увидеть, что перед веткой develop стоит звездочка. Такая запись означает, что сейчас указатель HEAD находится на ветке develop . Аналогично строка origin/HEAD -> origin/main означает, что указатель HEAD удаленного репозитория находится на удаленной ветке main .
Теперь, когда мы поняли, как можно узнать имена веток в репозитории, давайте научимся переключаться между ними.
Команда git checkout
Этот маленький фокус позволит вам сэкономить время, особенно, если вы часто переключаетесь между ветками.
- Программа проверяет, существует ли указанная ветка.
- Затем программа переключает указатель HEAD на новую ветку.
- Последним шагом программа меняет рабочую копию так, чтобы она соответствовала новой ветке.
Шаг 1. Проверка существования ветки
Нужен этот этап, чтобы случайно не переключиться на ветку, которой не существует. Чтобы понять, как происходит этот процесс, нужно сделать небольшое отступление и рассказать, как вообще Git хранит информацию о существующих ветках.
Итак, мы помним, что ветка – это тоже указатель, как и HEAD . Она указывает на последний коммит в «потоке» коммитов ветви графа Git. Графически это выглядит так:
Как видно из рисунка, у нас есть две ветки: main и feature . HEAD сейчас указывает на main, поэтому сейчас рабочая копия репозитория находится в состоянии коммита 5с5с .
Все, что нужно, чтобы задать ветку – просто записать, на какой коммит она указывает. Этого достаточно, поскольку по предкам этого коммита можно восстановить весь остальной граф. Поэтому внутри Git ветка – это просто файл в директории .git\refs\heads , названный так же, как и сама ветка. Например, в случае репозитория, граф которого изображен на картинке выше, мы получим:
Шаг 2. Переключение HEAD на нужную ветку
Теперь, когда Git убедился, что ветка с нужным именем существует, необходимо как-то переключить указатель HEAD на эту самую ветку. То есть сделать так, чтобы HEAD указывал на файл ветки. Делается это очень просто: нужно в файл .git\HEAD записать путь до нужной нам ветки: refs\heads\<имя ветки> . Тогда HEAD будет указывать на новую ветку.
В нашем случае, при переключении на ветку feature , файл .git/HEAD будет выглядеть так:
Шаг 3. Изменение рабочей копии
- Любой файл, который есть в новом коммите ( 6670 ) на рисунке выше и которого нет в коммите, с которого мы переключились ( 5с5с ), будет добавлен в рабочую копию.
- Любой файл, который был в коммите, с которого мы переключились ( 5с5с ), и которого нет в новом коммите ( 6670 ), будет удален.
- Любой файл, которого нет ни в одном из этих двух коммитов, будет просто проигнорирован. То есть удален он НЕ будет.
У внимательного читателя мог возникнуть вопрос: почему файлы в рабочей копии подгружаются именно из последнего коммита ветки? Что если до переключения с данной ветки, в ней были какие-то изменения, еще не добавленные в коммит? Что с ними будет? Ответ довольно прост. Согласно трем шагам, указанным выше, Git просто проигнорирует все такие файлы. То есть они останутся в вашей рабочей копии в том же состоянии, в котором и были до этого. Как правило, такое поведение очень неудобно, поскольку позволяет легко запутаться в структуре собственного проекта. Представьте: у вас два параллельных релиза, а вы, переключаясь между ветками, случайно занесли файлы одного релиза в ветку другого.
- Либо добавить все изменения в коммит и благополучно сменить ветку
- Либо «отложить» изменения, не добавляя их в коммит, воспользовавшись командой git stash .
6.1. Просмотр состояния файлов ветки. Команда git status.
- git checkout <имя ветки> # переключаемся на нужную ветку
- git status # просматриваем статус файлов ветки
6.2. Просмотр истории коммитов ветки. Команда git log.
- либо чтобы узнать, кто внес те или иные изменения,
- либо чтобы вспомнить хэш коммита, к которому хочется откатиться,
- либо просто проследить за историей развития проекта.
Команда git log
-<число>, -n <число>
Вывести только последние несколько коммитов. Их число вы указываете в параметре к этому ключу.
—pretty=<значение>
Красивый вывод истории. Доступные значения: oneline , short , medium , full и др.
-p
Показывает изменения, сделанные в данном коммите.
—graph
Рисует ASCII-граф взаимосвязи коммитов.
—all
Выводит историю всех имеющихся коммитов на всех ветках.
# Выведем последние 7 коммитов, воспользовавшись «красивым» выводом в одну строку.
$ git log -7 —pretty=oneline
8bb113c62cffdd3cada27b4179410f110f6f1321 (HEAD -> develop, origin/develop) adding complex algebra project
603def20e5da2d512da2852011eb5be3fa156940 (origin/main, origin/HEAD) eng. hometask done
86f24ac203c9a1a609e4f303e5c896746b13a054 minor changes and files movements
0b1f66921a08d42122e0f69babd912a2cc01ec82 minor changes
8f0479b6676b7e38eb0dd409690845bd9a64f19d new hometasks were done
cb3395bb21a353ea4ee885c4d493690e3c6294cb adding code docs
0117d8a38ed557c95a7f2959c89c1f3107a1d614 discrete math hometask done
# Выведем последние 2 коммита с обычным оформлением.
$ git log -2
commit 8bb113c62cffdd3cada27b4179410f110f6f1321 (HEAD -> develop, origin/develop)
Author: smartiqa <info@smartiqa.ru>
Date: Thu Feb 11 02:04:24 2021 +0300
adding complex algebra project
commit 603def20e5da2d512da2852011eb5be3fa156940 (origin/main, origin/HEAD)
Author: smartiqa <info@smartiqa.ru>
Date: Fri Dec 4 02:00:41 2020 +0300
В описании команды git log выше сказано, что в зависимости от ситуации, она может вывести полную историю репозитория, или же только историю некоторых коммитов. Давайте разбираться, как работает Git при выводе истории.
Общее правило, которым руководствуется Git при выводе истории, такое: иди по предкам коммитов, пока они не закончатся. Иногда это бывает удобно, иногда – нет.
Давайте разберемся, что делать, если мы хотим просмотреть историю коммитов только внутри какой-то конкретной ветки. То есть историю от момента создания ветки, до последнего коммита в ней. В этом случае нужно сделать следующее:
1. Переключиться на ветку, историю коммитов которой мы хотим просмотреть.
2. Выполнить команду git log <ключи> <имя родителя текущей ветки>..<имя текущей ветки> .
Например:
Если мы попытаемся просмотреть лог ветки main , то все будет хорошо: Git просто пойдет по предкам коммитов в обратном порядке и выведет: C5 , C3 , C2 , C1 . Но если мы попробуем просмотреть лог ветки feature , то получим: C6 , C4 , C3 , C2 , C1 , что может нас запутать: после вывода всех коммитов ветки feature , Git начал выводить коммиты ветки main до ответвления feature .
- Идем в обратном порядке. С6 младше feature ? Да. C6 Старше main ? Да, поскольку это другая ветка. Выводим C6 .
- C4 младше feature ? Да. C4 Старше main ? Да, выводим C4 .
- C3 младше feature ? Да. C3 Старше main ? Нет, поскольку, main указывает на C5 , который является наследником С3 . Таким образом С3 младше main . Останавливаемся.
В любом случае, если вам сложно визуально представить свой репозиторий, просто воспользуйтесь командой git log —all —graph . С ней вы увидите, как выглядит граф вашего репозитория и поймете, что нужно делать, чтобы получить историю той или иной ветки.
How to Create a Local Branch in Git
Joel Olawanle
When you’re making changes to a Git repository, it’s a best practice to push to a different branch first. This lets you compare changes before submitting a pull request and finally merging it.
This is especially crucial when working with other developers.
Your repository’s main branch, which is regarded as the authoritative branch, is the only branch present by default. Now let’s quickly go over how to create branches in Git.
How to Create Branches in Git
In essence, there are two methods in Git for creating branches.
You can use a single command to create the branch and switch to it. Or you can create the branch first using one command and then switch to it later using another command when you wish to work with it.
Here’s the TL;DR quick version of the code:
How to Create a Git Branch and Switch to a New Branch
We can create a new branch and switch to it using the git checkout command with the -b option and <branch-name> . It looks like this:
Assume we want to create a new Git branch named «pagination» from the main branch. To accomplish this, we will use the «git checkout» command with the «-b» option and the branch name «pagination».
As you can see, we created a new branch, and the checkout command caused our branch to automatically switch from «main” to “pagination”.
Let’s now look at how to create a Git branch without switching to it.
How to Create a Git Branch Without Switching to the New Branch
This is the standard method for creating a branch using the git branch command and specifying the name of the Git branch you want to create.
For example, as we did earlier, we can create a branch for “pagination” by replacing “
” with “pagination”. Here’s what that would look like:
As we can see the branch did not change, but the new branch was created. To see a list of all available branches, you can use this command:
Finally, suppose we later wish to switch to our new Git branch or any other branch we previously created. In that case, we can make use of the git checkout command.
Conclusion
In this article, we learned how to use Git commands in our terminal to create a branch locally.
If we want to add this branch remotely, all we have to do is push it to our Git provider such as GitHub using the command below:
You can access over 200 of my articles by visiting my website. You can also use the search field to see if I’ve written a specific article.