Git — git, тематические ветки


Содержание

Как посмотреть ветки в Git

Список локальных веток

Чтобы вывести список локальных веток используется команда:

Список удаленных веток

Чтобы показать удаленные (remote) ветки используется ключ -r :

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

git fetch загружает коммиты, файлы и ссылки из удаленного репозитория. Данная команда выполняется, когда вы хотите посмотреть, что изменилось в удаленном репозитории, что кто-то другой сделал в нем. При этом очень важно, что git fetch не изменяет никаких ваших локальных данных, над которыми вы работаете.

Список всех веток

Для вывода всех веток, локальных и удаленных, используется ключ -a :

Git — создание ветвей (branch)

September 04, 2014

Продолжаю совместно с вами постепенно изучать магию Git\GitHub.

Слово магия здесь применено не случайно — не иначе, как магией возможности Git\GitHub не назовешь. По крайней мере, я впечатлен этими возможностями. Другое дело, что процесс изучения Git у меня лично идет как-то тяжеловато. Ну, это не страшно — главное, не останавливаться!

В этом разделе я попытаюсь осветить для себя (и возможно, для вас, уважаемый читатель) вопрос создания ветвей (branches) в Git, перемещение между ветвями (branches), слияние (merge) ветвей. Этот вопрос очень подробно и хорошо описан на странице официальной документации — “Git Branching — Basic Branching and Merging”. Здесь я попробую самостоятельно описать данный вопрос.

Инициализация Git-репозитория

Создаю тестовую директорию , в которой будут производиться эксперименты по созданию ветвей в Git. Внутри этой директории создаю два файла — индексный файл и файл таблиц стилей. А затем инициализирую Git-репозиторий, добавляю созданные файлы под версионный контроль Git:

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

Итак, мы уже кое-что узнали. А именно — при инициализации Git-репозитория была автоматически создана ветвь (branch) по имени . И на данный момент мы находимся в этой ветви.

Конечно, на самом деле это пока мало о чем говорит, так как не с чем сравнивать. Поэтому давайте я немного отредактирую оба файла и , проиндексирую\зафиксирую их.

В браузере примерный вид странички будет выглядеть таким образом:

Git — создание новой ветви (branch)

В системе Git (как уже упоминалось ранее) имеется механизм ветвления (branches). Попробую на словах объяснить, что он из себя представляет.

Допустим, в моем текущем проекте, у которого имеются два файла, нужно внести кардинальные изменения. Причем, изменения такого рода, что они могут нарушить работу уже существующего проекта. Чтобы обезопасить себя (подстраховать), создаю точную копию существующего проекта и перехожу в нее для дальнейшей работы.

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

Строка услужливо информирует, что меня автоматически “перебросило” во вновь ветвь . Можно проверить себя, набрав в консоли:

Строка говорит сама за себя.

Отлично! Теперь давайте я внесу некоторые изменения в файлы и и мы вместе посмотрим на результат в окне браузера. Изменения будут касаться добавления блока-обертки, еще нескольких параграфов и другой легкой стилизации.

Не забуду также проиндексировать и зафиксировать внесенные изменения. Обратите внимание на вид команды — . Эта команда является сокращенным вариантом двух команд: и . Применяется, когда нужно “проскочить” этап индексирования и сразу зафиксировать изменения.

Смотрим, что у нас получилось в окне браузера — то, что и ожидалось:

Git — переключение между ветвями (branches)

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

Оп! Мы видим старую картину — Git “запечатлел” тот момент, когда мы совершили переход из ветви в ветвь . Другими словами, мы вернулись в последнее зафиксированное состояние ветви :

Если я снова вернусь в ветку и запущу команду просмотра логов Git, то коммитов окажется больше:

Мне кажется, уже сейчас должно быть понятно, что такое ветви (branches) в Git и для чего они предназначены. На самом деле это действительно очень просто.

Git — слияние ветвей (branches)

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

Фактически, я хочу сделать слияние двух веток — и . Это сделать очень просто — для этого я перехожу в ветку . То есть, я должен находиться в той ветке, в которую я вношу изменения из другой ветки. А затем произвожу само слияние:

Команда слияния проста — я просто указываю имя той ветки (branch), которую хочу слить (merge) с текущей, в которой я нахожусь на данный момент.

При слиянии ветвей зачастую может возникнуть ситуация, когда происходит конфликт между двумя ветвями. Рассмотрение вопроса решения конфликтов при слиянии не рассматривается мною, так как на данный момент еще не освоил этот вопрос до конца.

Давайте снова “заглянем” в окно браузера — что он нам интересного покажет?

Показал он то, что и следовало показать — результат объединения двух ветвей и .

Git — графическое представление ветвей (branches)

Система Git имеет в своем составе возможность графического представления ветвления в репозитории. Причем, такое представление можно сделать даже в консоли, с помощью псевдографики.

Это можно сделать, набрав в консоли команду:


На Stack Overflow я нашел примеры красивых изображений консоли с псевдографическим выводом команды :

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

Помимо псевдографики, ветви в Git можно визуализировать с помощью настоящего графического приложения. Под Mac OS X и Linux имеется достаточно большое количество таких приложений. Например, под Mac OS X это GitX, под Linux — Gitk или Gitg:

Git — удаление ветви (branch)

В разделе слияния ветвей в Git я научился процессу объединения двух ветвей в одну. Такой процесс в Git имеет название (слияние). Теперь ветвь имеет в себе все, что есть и в ветви . Поэтому ветвь можно удалить.

Выполняется это командой:

Посмотрим на вывод команды :

У меня осталась одна ветвь — .

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

Git — git, тематические ветки

git config —global user.name «[name]» — установить имя, которое будет прикрепляться к коммиту.

git config —global user.email «[email address]» — установить email, который будет прикрепляться к коммиту.

git config —global color.ui auto — включить полезную подсветку командной строки.

git config —global push.default current — обновлять удаленную ветку с таким же именем, что и локальная, при пуше изменений (если не указано иного).

git config —global core.editor [editor] — установить редактор для редактирования сообщений коммита.

git config —global diff.tool [tool] — установить программу для разрешения конфликтов при слиянии.

Создание репозиториев

git init [project-name] — создать новый локальный репозиторий с заданным именем.

git clone [url] — загрузить проект и его полную историю изменений.

Работа с изменениями

git status — полный список изменений файлов, ожидающих коммита.

git status -s — краткий вид изменений.

git diff — показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged).

git add [file] — сделать указанный файл готовым для коммита.

git add . — сделать все измененные файлы готовыми для коммита.

git add ‘*.txt’ — добавить только файлы, соответствующие указанному выражению.

git add —patch filename — позволяет выбрать какие изменения из файла добавятся в коммит.

git diff —staged — показать что было добавленно в индекс с помощью git add , но еще не было закоммиченно.

git diff HEAD — показать что изменилось с последнего коммита.

git diff HEAD^ — показать что изменилось с предпоследнего коммита.

git diff [branch] — сравнить текущую ветку с заданной.

git difftool -d — то же самое, что и diff , но показывает изменения в заданной difftool.

git difftool -d master.. — показать изменения, сделанные в текущей ветке.

git diff —stat — показать статистику какие файлы были изменены и как.

git reset [file] — убрать файлы из индекса коммита (изменения не теряются).

git commit — записать изменения в репозиторий. для написания сообщения откроется назначенный редактор.

git commit -m «[descriptive message]» — записать изменения с заданным сообщением.

git commit —amend — добавить изменения к последнему коммиту.

Работа с ветками

git branch — список всех локальных веток в текущей директории.

git branch [branch-name] — создать новую ветку.

git checkout [branch-name] — переключиться на указанную ветку и обновить рабочую директорию.


git checkout -b /
— переключиться на удаленную ветку.

git checkout [filename] — вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита.

git merge [branch] — соединить изменения в текущей ветке с изменениями из заданной.

git merge —no-ff [branch] — соединить ветки без режима “fast forwarding”.

git branch -a — посмотреть полный список локальных и удаленных веток.

git branch -d [branch] — удалить заданную ветку.

git branch -D [branch] — принудительно удалить заданную ветку, игнорируя ошибки.

git branch -m

    — переименовать ветку.

Работа с файлами

git rm [file] — удалить файл из рабочей директории и добавить в индекс информацию об удалении.

git rm —cached [file] — удалить файл из репозитория, но сохранить его локально.

git mv [file-original] [file-renamed] — изменить имя файла и добавить в индекс коммита.

Отслеживание файлов

.gitignore — текстовый файл, в котором задаются правила для исключения файлов из репозитория. Например:

git ls-files —other —ignored —exclude-standard — список всех игнорируемых файлов.

Сохранение фрагментов

git stash — положить во временное хранилище все отслеживаемые файлы.

git stash pop — восстановить последние файлы, положенные во временное хранилище.

git stash list — список всех сохраненных изменений во временном хранилище.

git stash drop — удалить последние файлы, положенные во временное хранилище.

Просмотр истории

git log — список изменения текущей ветки.

git log —follow [file] — список изменения текущего файла, включая переименования.

git log —pretty=format:»%h %s» —graph — изменение вида отображения истории изменений.

git log —author=’Name’ —after= <1.week.ago>—pretty=oneline —abbrev-commit — посмотреть над чем работал заданный пользователь последнюю неделю.

git log —no-merges master.. — посмотреть историю изменений только для текущей ветки.

git diff [file-branch]..[second-branch] — посмотреть различия между двумя заданными ветками.

git show [commit] — показать метадату и изменения в заданном коммите.

git show [branch]:[file] — посмотреть на файл в другой ветке, не переключаясь на неё.

Отмена коммитов

git reset — убрать изменения из индекса коммита, сами изменения останутся.

git reset [commit/tag] — отменить все коммиты после указанного коммита, изменения будут сохранены локально.

git reset —hard [commit] — принудительно вернутся к указанному коммиту, не сохраняя историю и изменения.

Синхронизация изменений

git fetch [bookmark] — загрузить всю историю с заданного удаленного репозитория.

git merge [bookmark]/[branch] — слить изменения локальной ветки и заданной удаленной.

git push — запушить текущую ветку в удаленную ветку.

git push [remote] [branch] — запушить ветку в указанный репозиторий и удаленную ветку.

git push [bookmark] :[branch] — в удаленном репозитории удалить заданную ветку.

git push -u origin master — если удаленная ветка не установлена как отслеживаемая, то сделать ее такой.

git pull — загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой.

git pull [remote][branch] — указать конкретную удаленную ветку для слияния.

git remote — посмотреть список доступных удаленных репозиториев.


git remote -v — посмотреть детальный список доступных удаленных репозиториев.

git remote add [remote][url] — добавить новый удаленный репозиторий.

GIT за 100 минут. Ветвление и управление ветками

Добро пожаловать на третий урок нашего миникурса git за 100 минут

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

Когда вы создаете какой-либо коммит (первый, второй – неважно), у вас создается некая последовательность коммитов, которую условно можно представить в виде линии. Чем больше коммитов вы делаете, тем длиннее эта линия становится.

Здесь необходимо понять один момент. У всех, кроме первого коммита, есть запись в базе (внутри самого git-а), где указывается «родитель», то есть, у коммита №2 – «родитель» коммит №1. У коммита №3 «родитель» коммит №2. У первого коммита родителя нет, потому что он первый. В БД gita содержатся так называемые «записи», в которых есть сам коммит, его родитель, автор, имейл и т.д; ссылка на еще одну запись в базе, где описывается структура каталога. Если у нас 3 файла, то у нас 5 записей: по одной записи на каждый файл, одна запись на дерево (на структуру нашей папки) и одна запись – коммит, в котором прописан родитель и автор. Но сейчас важно, что у каждого коммита есть «родитель» (кроме первого). Бывает так, что у коммита есть несколько родителей. Происходит это случае, когда коммит является следствием слияния нескольких веток. У вас есть несколько веток, они сливаются в один коммит. Чуть дальше мы более подробно про эту тему поговорим, а сейчас о ветках.

Цукерберг рекомендует:  Анимированные закладки на CSS3

Когда вы только установили git, запустили его, инициализировали в папки, коммиты по умолчанию создаются в ветке «master» (в вашей основной ветке), которая по умолчанию создается, когда вы инициализируете репозиторий. В этой ветке вы совершаете некие действия. Каждый раз, когда вы создаете новый коммит, так называемый заголовок, маркер [head] перемещается дальше по коммитам. [head] находится на самом последнем коммите, который у вас сейчас есть. Сначала был на первом, потом переместился на второй, потом на третий. Все это в рамках одной ветки «master».

Бывает так, что появляется необходимость провести некие изменения в сделанной вами копии. Например, нужно что-то резко пофиксить. Представим живой пример – сайт. Вы делаете сайт. Вы его выпустили. В верхней ветке мастера находится production версия, то бишь чистый код, для публикации на сайте, он уже готов и оттестирован. С каждым новым коммитом вы добавляете в ваш оттестированный рабочий код что-то новое. Потом публикуете в интернете. То есть, это ваш гарантированно рабочий сайт, production версия. Потом выясняется, что на вашем сайте есть какой-то баг, который вам надо подправить. При этом вы работаете над четвертым коммитом, то есть готовите еще одну запись, программируете, что-то дорабатываете. Тут вам звонит клиент и говорит: «У вас баг на сайте». Что вам надо делать. В простом варианте вы бы сохранили работу в том состоянии, в котором она есть. Вернулись бы к старому back-up-у в папочке (предположим, мы не используем СКВ), начали бы в нем что-нибудь делать, забыв про комит 4. И в итоге работа бы немножко тормознулась. Что позволяет сделать git? Git создает еще одну ветку. Веток может быть неограниченное количество. То есть мы пока находимся на этом коммите. Делаем ветку bugfix- фиксим баг. Git создает ответвление от текущего снапшота. То есть, после того, как вы создали ветку, ничего не произошло. У вас просто появился bugfix, который как и мастер, ссылается на снапшот. Ветка – передвижной указатель. Сейчас на третий коммит указывают две ветки: master и bugfix. Как только вы начнете делать коммиты, находясь в ветке bugfix, они пойдут отдельно, будут идти отдельной веткой. Эти изменения останутся незатронутыми. То бишь, мы создали новую ветку bugfix. Она еще находится в рамках текущего снапшота, текущего коммита. Без изменений. Вы внесли изменения. Что-то подправили на сайте, исправили какой-то баг (допустим не работает форма), закоммители, он появился в новой ветке.

Бывает такое: Вы правите баг, а ваш сотрудник работает над CSS, продолжает комментить в мастер ветке. Получается, у вас разделение. Вы пока фиксите баги на отдельной ветке, совершенно не мешая работать с production версией другому вашему сотруднику. Например, у вас есть верстальщик и программист. Вы программист. У вас появился баг. Вы сделали отдельную ветку и начали фиксить баг. При этом в production версии, в мастере продолжает вести работы верстальщик, а вы продолжаете чинить фиксы (исправлять все баги на сайте). Когда вы все сделали, оттестировали, убедились, что сайт исправлен, вы можете сделать слияние, то бишь слить две ветки в одну. Git – система очень умная, она возьмет и все соединения соединит, если у вас нет каких-либо конфликтов, которые мы рассмотрим.

Если в С5 (ветка master) и С4 (ветка bugfix) правился один и тот же кусок – например, в подвале менялся копирайт, то при слиянии у вас будет конфликт, который нужно вручную исправить. Но если правились разные места (например, CSS и PHP файлы), это все одна большая директория проекта. В конце мы просто это сольем. Файлы добавятся нужными кусками, где-то что-то запишется, добавится, что-то уберется. У вас в итоге в ветке «master» сольются все изменения, и вы сможете дальше заниматься production веткой. То бишь, ветвление в git позволяет решать какие-то сторонние задачи, что-то изменять и при этом не мешать друг другу работать.

Один из самых больших плюсов ветвления, то что вы можете создавать таких веток огромное количество, хоть с самой первой. У вас есть, например, master ветка, которая будет являться production. Вы сразу с первым коммитом создаете ветку develop, где у вас находятся все ваши разработки. Коммитете ее, коммитете. Делаете ваши разработки, периодически сливая ее с продакшеном. Сделали, оттестировали, залили в продакшен. Таким образом, у вас в ветке master всегда будет чистый, аккуратный, готовый к публикации исходный код. Притом, у вас может быть ветка develop. От нее ветка fix. От мастера еще может ответвляться ветка hotfix (срочные изменения). Таких веток может быть огромное количество. Они могут сливаться, изменяться. Представляем себе ветку на дереве. То же самое происходит и в git-е.

Давайте пройдем по всем веткам поэтапно, по всем слайдам в процессе работы. Итак, для начала нам необходимо создать несколько коммитов перед тем, как мы начнем ветвление.

Возвращаемся уже в знакомую рабочую машину. В папке «work» уже появился сайт. Там лежит новый git репозиторий, в котором кроме инициализации еще ничего не происходило. Первое, что мы сделаем – посмотрим get status, чтобы разобраться, что у нас происходит в данный момент.

Git — git, тематические ветки

Запуск git status в чистой рабочей копии выводит следующую информацию:

Вывод говорит о том, что мы находимся в ветке master . Дополнительно в этом можно убедиться с помощью специализированной команды git branch .

Для понимания значения слова «ветка» давайте посмотрим, что из себя представляет история коммитов:

Слева первый коммит, затем второй, который ссылается на первый, а в конце третий. Каждый новый коммит содержит ссылку на предыдущий. Это позволяет прослеживать связь между коммитами, а способ организации коммитов называется линейный список.

Представьте ситуацию, в которой появилось два коммита, родителем которых является один и тот же коммит:

Из картинки видно, что наш список превратился в дерево, в котором две ветки. Каждая ветка – это своё собственное развитие исходного кода. Как нетрудно догадаться, таких веток может быть сколько угодно, и порождаться они могут из любого коммита любой ветки (дерево же).

Только что инициализированный репозиторий содержит только одну ветку — master. Она используется в качестве основной и выбрана сразу. Как только вы начинаете работать с новыми репозиторием, вы работаете в ветке master, её не нужно специально выбирать. Всё остальное опционально. Вот основные причины использовать ветвление:

  • Одновременная поддержка нескольких версий. Такое всегда есть у коробочного софта. Например, версии браузеров или операционных систем.
  • Работа над задачами в ветках не блокирует возможность правок в основной ветке. Например, во время реализации сложной функциональности может потребоваться срочно внести изменение в работающий проект.

Ниже пример того, как в git работать с ветками:

Некоторые выводы из приведённого листинга:

  1. Каждая ветка имеет уникальное имя, которое задаётся при создании ветки.
  2. Команда git branch показывает не только все доступные ветки, но также и отмечает текущую символом * .

У внимательного читателя возможно возник вопрос: как Git определяет, где мы сейчас находимся? Ответ на этот вопрос можно увидеть в этой строчке:

Любой односвязный список содержит голову (HEAD). Это последний добавленный в него элемент (в списках добавление всегда идёт в начало, то есть новая голова «нанизывается» на предыдущую голову). Git работает точно так же: когда мы делаем любой коммит, он становится HEAD. Другими словами, понятие HEAD это, по сути, ссылка на некоторый коммит. А отсюда следует интересная вещь. Помните, что мы можем переключиться на любой коммит (абсолютно любой) и загрузить его снимок в рабочую копию командой git checkout идентификатор ? Так вот, после того, как мы это проделаем, HEAD начинает указывать именно на загруженный коммит. Внутри происходит изменение указателя HEAD и загрузка в рабочую копию соответствующего снимка.

Каждая ветка – это, всего лишь, точно такой же указатель на определённый коммит, а сами ветки определяются исключительно связями между коммитами. В этом легко убедиться, если изучить папку refs внутри .git :

Видно, что ветка – это файл с именем ветки и записанным в него идентификатором коммита, а HEAD – это файл, внутри которого стоит ссылка, в данном случае на new-feature . То есть это состояние ситуации, при которой мы только что переключились на ветку new-feature , и HEAD совпадёт с последним коммитом в new-feature .

Из всего сказанного следует, что коммиты не принадлежат веткам. Структура коммитов существует сама по себе безотносительно них. Ветки накладываются поверх коммитов как указатели. Это, например, означает, что изменение коммита общего для нескольких веток (а такое можно делать используя rebase) отражается на всех ветках, в которые попал этот коммит.

Слияние

Предположим, что вы реализовали фичу и теперь хотите, чтобы этот код оказался в ветке master. Делается это командой git merge , которая сливает ветки между собой. Результатом слияния, становится особенный merge commit. Его отличие от остальных коммитов в том, что этот коммит не содержит изменений, но он ссылается сразу на двух родителей, которыми выступают последние коммиты в какой-либо ветке и ветке master в момент слияния. Именно благодаря тому, что он ссылается на последний (на момент слияния) коммит из ветки, Git узнает о том, какие были выполнены изменения и как нужно изменить код мастера.

Команда git merge выполняется из той ветки, в которую мы сливаем изменения, а аргументом передаётся имя той ветки, которую мы сливаем.

Перемещение

Команда git rebase относится к продвинутым техникам Git, но именно она делает вас настоящим властелином репозиториев. Как только основы будут освоены, окунитесь в её изучение.

Perl, Python — блог программиста

Шпаргалка по git. Пошаговое руководство: как выполнить слияние веток в git, как создать новую ветку и репозиторий, как выписать ветку с github и т.п. Инструкции по git для начинающих.

Git — это распределенная система контроля версий. Это главное отличие git от svn . Каждый разработчик создает на своем компьютере отдельный, полноценный репозиторий.

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

git push — вливание локальных изменений в удаленный репозиторий. git pull — вливание изменений из удаленного репозитория в локальный. Обмен данными обычно происходит с использованием протокола SSH.


Git поддерживают несколько крупных репозиториев — GitHub , SourceForge , BitBucket и Google Code . Удобно использовать один из них в качестве основного хранилища для корпоративных проектов.

Изображение с сайта http://www.stickycomics.com/where-did-you-meet/

Ниже приведены инструкции по использованию git в различных ситуациях. Что делать, если нужно создать новый репозиторий, или выписать ветку, и т.п. Я использую подобную шпаргалку для скоростного копипаста :) Чтобы не отвлекаться, когда голова занята сложными задачами. По мере создания новых инструкций, статья будет обновляться.

Пошаговые рекомендации

Как выписать репозиторий с github

  1. Создаем новую директорию для проекта project_name , переходим в нее.
  2. Выполняем команду:

Результат: каталог с выписанной веткой master . Теперь можно создавать новые ветки, или выписывать с github существующие.

Как выписать ветку с github

С помощью команды «checkout» можно выписать уже существующую ветку с github:

Или так, что намного надежнее:

Если команда не сработала, нужно попробовать выполнить обновление:

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

Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.

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

  1. Создаем новую ветку в локальном репозитории:

Как переключиться на другую ветку в git

Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:

Как посмотреть список веток

Команда «branch» позволяет посмотреть список веток в локальном репозитории. Текущая ветка будет помечена звездочкой:

Как сделать commit

Создаем новую ветку, выполняем в ней нужные изменения.

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

Или удаляем устаревшие файлы:

Как правило, в репозитории существует две основные ветки — dev и master. Dev — общая ветка разработчиков и тестировщиков. Именно в нее добавляются все новые разработки перед очередным релизом. Master — ветка для выкладки продукта на боевые сервера.

После коммита надо влить в нашу ветку изменения из ветки dev и master:

Теперь наша ветка содержит изменения для проекта, и все последние изменения по другим задачам, которые успела внести команда.
Переключаемся на ветку dev:

Вливаем в dev изменения из ветки проекта:

Заливаем последнюю версию ветки dev на удаленный сервер:

push может не пройти, потому что удалённый origin/dev обогнал локальную его копию.

Как решить конфликт бинарных файлов

Допустим, при слиянии с другой веткой git выдал ошибку. Команда git status возвращает информацию о конфликте:

Конфликтный файл является бинарным (это могут быть архивные файлы, изображения и т.п.), и решение конфликта стандартным способом, с помощью редактирования — не возможно.


Чтобы решить такой конфликт, надо просто выбрать — какая версия файла будет использоваться: ваша или из вливаемой ветки. Чтобы использовать свой вариант файла, вводим команду:

Если мы выбираем версию из вливаемой ветки:

» ours » — от английского «наш», » theirs » — от английского «их».

Как посмотреть историю изменений

git log — просмотр логов.

Вывод данных о каждом коммите в одну строку:

Для вывода информации git log использует просмотрщик, указанный в конфиге репозитория.

Поиск по ключевому слову в комментариях к коммиту:

Команда «git show» позволяет просмотреть, какие именно изменения произошли в указанном коммите:

Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:

git annotate , выводит измененные строки и информацию о коммитах, где это произошло:

Как сделать откат

  1. git log — просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.
Цукерберг рекомендует:  Stl - C++ Обработка значений в методе

После того, как откат сделан, и выполнен очередной локальный коммит, при попытке сделать push в удаленный репозиторий, git может начать ругаться, что версия вашей ветки младше чем на github и вам надо сделать pull. Это лечится принудительным коммитом:

Как выполнить слияние с другой веткой

git merge выполняет слияние текущей и указанной ветки. Изменения добавляются в текущую ветку.

git pull забирает изменения из ветки на удаленном сервере и проводит слияние с активной веткой.

git pull отличается от git merge тем, что merge только выполняет слияние веток, а pull прежде чем выполнить слияние — закачивает изменения с удаленного сервера. merge удобно использовать для слияния веток в локальном репозитории, pull — слияния веток, когда одна из них лежит на github.

Создание нового локального репозитория

git cherry-pick

git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

    Для этого нужно выписать ветку, в которую будем вливать коммит:

Как раскрасить команды git

После создания репозитория в текущей директории появится субдиректория .git . Она содержит файл config .

Чтобы раскрасить вывод git, можно добавить в файл блок [color] :

Полезные ссылки по теме git

Шпаргалка по Git — основные команды, слияние веток, выписка веток с github : 10 комментариев

> git cherry-pick помогает применить один-единственный коммит из одной ветки к дереву другой.

можно и не один, а много коммитов перечислить через проблел

пример: git cherry-pick qw1w2e3 a4s5d5 f6g7h8j8
(последний коммит будет верхним)

У меня с гитом было так.
На первом работе использовали SVN
В ВУЗе я работаю четвертый год над проектом и исторически там SVN
Писал игрушку под андроид и надеялся делать это не один, товарищ подтолкнул к гиту, я попробовал. Потом таки писал один и проклинал гит.
Постепенно привыкал к гиту, хотел прочитать книжку по нему, но руки не доходили (ты знаешь о чем я, ведь твой блог о мотивации xD).
Устроился на новую работу, там меркуриал. Работа работой, но за 3 месяца я прочитал на работе 2 книжки (одни из них Pro GIT) и прошел курс по git.

Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают — на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD — я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.

Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита — из этого хотя бы понятно как его правильно (ну или «более оптимально») использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? — вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.

Опять же статьи описывают не все, а книга Чакона — все и сразу. Очень здоровская книга и ее перевели на русский уже.

Но пока я читал книгу, я написал вот такую же шпаргалку как у Вас примерно (но побольше только. ). Потом я забыл ее на работе (( — я ж уволился сразу как дочитал все книги xD.

проконсультируйте пжл что я делаю не правильно.
#!/bin/bash
clear
git status | grep -c «nothing to commit»
read $s
echo $s

echo выводит null

Простите, у меня сейчас нет git на серверах — т.к. для личных нужд он мне пока не был нужен, а устанавливать нет желания. Обычно я не отвечаю на вопросы, если не могу проверить ответ на практике, чтобы быть уверенной в его корректности. :(

You should remove $ in fourth line:)

Try smth like that:

#!/bin/bash
clear
git status | grep -c “nothing to commit”
read s
echo $s


Что значит выписать? Все татары кроме я.

Ну можно, наверное, перевести это как «создать копию указанной ветки на локальном компьютере» :)

Шикарная шпаргалка, спасибо!

Но сначала был курс. Я как бы понимал что делаю что-то не так, когда постоянно матерился на гит в проекте с андройдом. Я хотел научиться и нашел курс (ну многие его знают – на githowto). И вот я устроился на работу и у меня появилось 8 часов свободного времени в сутки xD – я конечно прошел курс. Дак вот курс хреновый, он запутывает и не рассказывает как правильно.

Я начал читать книжку Чакона и вот ее я всем советую. Особенно в середине книжке здорово описаны варианты использования гита – из этого хотя бы понятно как его правильно (ну или “более оптимально”) использовать в твоем проекте исходя из масштаба проекта. Потому что в гите тьма всяких фич и вот статьи на хабре рассказывают про них, а значит люди пользуются этим. Если кто-то этим пользуется, а я нет, значит я чего-то не понимаю? – вот Чакон пояснил че почем. Это реально нужно, потому что в гите гораздо больше вариантов ведения проекта чем в svn. Ну а также есть куча холиваров на хабре, например по поводу удаленных веток и эти все статьи часто запутывают.

Pro Git

Страницы

среда, 18 февраля 2015 г.

Ветвление в 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.

Цукерберг рекомендует:  Создание индикатора сложности пароля на PHP

Теперь мы можем переключится в ветку 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 сервер продолжит хранить всю информацию о коммитах до тех пор пока вы не запустите команду уборки мусора.

# 4 Git — как работают ветки

Всем привет. Мы продолжаем изучать гит и сегодня мы будем разбираться в ветками в гите. Зачем вообще нужны ветки в гите? Для того, чтобы разделять код. Например одна ветка у нас может быть основная для разработки. Если мы делаем новый функционал, то мы создаем новую ветку под него, а после окончания работы сливаем то, что мы сделали в основную ветку.

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

Давайте попробуем. По умолчанию в гите создается ветка мастер. На ней мы с вами все это время работали.

Если мы напишем

то мы увидим список всех веток, которые у нас есть. В нашем случае это только мастер. Обратите внимание на звездочку перед названием мастер. Эта звездочка показывает на какой ветке мы сейчас.

Давайте создадим новую ветку

Если мы еще раз напишем git branch, то увидим у нас 2 ветки, но мы все еще находимся на ветке мастер. Чтобы перейти на ветку, которую мы только что создали нужно написать

Теперь написав git branch мы видим что мы на ветке implement-new-logic.

Давайте добавим функцию getPerson в файл 2.js. Просто создадим функцию getPerson, которая будет склеивать имя и фамилию.

сохраним и запушим наши изменения.

Теперь если мы зайдем в наш репозиторий в браузере, то мы увидим что у нас там 2 ветки: implement-new-logic и master. Если мы перейдем на ветку implement-new-logic, то мы увидим, что на ней 5 коммитов, а в файле 2.js есть наша функция, которую мы добавили.

Если же мы перейдем обратно на мастер, для этого мы можем написать

то наши изменения, которые мы сделали так и останутся на той ветке. И пока мы их не вольем в ветку master, она не изменится.

В гите термин вливания ветки в другую ветку называется merge. Для того, что смерджить нашу ветку implement-new-logic в мастер, нам нужно сначала перейти на мастер и потом написать какую ветку мы хотим влить.

Как мы видим, у нас написало, что ветка обновилась и добавился файл 2.js. Теперь у нас ветки стали идентичные и добавленный нами функционал находится в мастер ветке. Если мы напишем

то увидим наш коммит, который мы добавляли на другой ветке. Так как мы ветку уже смерджили и она нам не нужна больше, давайте ее удалим.

Теперь написав git branch мы опять видим только мастер. Давайте запушим эти изменения.

Теперь мы запушили наши изменения. И если мы заходим и видим master ветку, то мы видим, что у нас 5 коммитов и последним идет тот, который мы добавили. Единственное отличие в том, что мы удалили ветку локально, но не удалили ее на сервере. Вы можете зайти в список веток, all branches и нажать delete this branch. И это удаляет ветку не локально уже, а на сервере.

[git] Работа с ветками

Отправить локальную ветку в удалённый репозиторий

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

Cвязать существующую локальную ветку с существующей удаленной:

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

Переключится на ветку

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

Например приступая к работе с новой фичей (или исправляя баг), ответвляемся (щас стоим на мастере)

Если ветка в удалённом репозитории не удаляется из-за того что она по умолчанию, то нужно в начале переключить удалённый репозиторий на новую ветку, для этого надо в удалённом репозитории сделать (т.е. зайти непосредственно на сервер где лежит удалённый репозиторий):

Бывает что в удалёном репозитории ветки удалены а в локальном они продолжают отслеживаться. Если сделать комманду

то в разделе Remote branches: могут находится ветки подобно этому

поэтому для удаления этих не актуальных веток нужно сделать

При просмотре git br -a иногда есть такая ветка remotes/origin/HEAD -> origin/master или чтото подобное. Она появляется обычно после того как сдалть clone . Я пока толком не разобрался для чего она нужна, её можно удалить так:

Комманда для возврата на место remotes/origin/HEAD

Переименовать текущую ветку:

Переименовать любой бранч:

Ситуация немного усложняется в случае если вы уже запушили ветку на удаленный сервер, переименовываем ее так:

  • создаем новую ветку
  • пушим ее на удаленный сервер
  • удаляем старую ветку

Например нужно слить ветку feature, в которой несколько коммитов в мастер так чтобы это был один коммит в мастере.

при этом в индекс положаться все изменения которые были сделаны (всё сольётся в кучу) но не будет закоммичено. остаётся всё закоммитить одним коммитом.


Вот реально хорошая статься как ребайсить ветки с удалёнными репозиториями: Git Rebase: руководство по использованию

Работа с индексом

Добавить всё в индекс

Добавить всё в индекс (даже deleted)

Удалить файл из индекса, оставив его при этом в вашем рабочем каталоге.

Git — создание ветвей (branch)

September 04, 2014

Продолжаю совместно с вами постепенно изучать магию Git\GitHub.

Слово магия здесь применено не случайно — не иначе, как магией возможности Git\GitHub не назовешь. По крайней мере, я впечатлен этими возможностями. Другое дело, что процесс изучения Git у меня лично идет как-то тяжеловато. Ну, это не страшно — главное, не останавливаться!

В этом разделе я попытаюсь осветить для себя (и возможно, для вас, уважаемый читатель) вопрос создания ветвей (branches) в Git, перемещение между ветвями (branches), слияние (merge) ветвей. Этот вопрос очень подробно и хорошо описан на странице официальной документации — “Git Branching — Basic Branching and Merging”. Здесь я попробую самостоятельно описать данный вопрос.

Инициализация Git-репозитория

Создаю тестовую директорию , в которой будут производиться эксперименты по созданию ветвей в Git. Внутри этой директории создаю два файла — индексный файл и файл таблиц стилей. А затем инициализирую Git-репозиторий, добавляю созданные файлы под версионный контроль Git:

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

Итак, мы уже кое-что узнали. А именно — при инициализации Git-репозитория была автоматически создана ветвь (branch) по имени . И на данный момент мы находимся в этой ветви.

Конечно, на самом деле это пока мало о чем говорит, так как не с чем сравнивать. Поэтому давайте я немного отредактирую оба файла и , проиндексирую\зафиксирую их.

В браузере примерный вид странички будет выглядеть таким образом:

Git — создание новой ветви (branch)

В системе Git (как уже упоминалось ранее) имеется механизм ветвления (branches). Попробую на словах объяснить, что он из себя представляет.

Допустим, в моем текущем проекте, у которого имеются два файла, нужно внести кардинальные изменения. Причем, изменения такого рода, что они могут нарушить работу уже существующего проекта. Чтобы обезопасить себя (подстраховать), создаю точную копию существующего проекта и перехожу в нее для дальнейшей работы.

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

Строка услужливо информирует, что меня автоматически “перебросило” во вновь ветвь . Можно проверить себя, набрав в консоли:

Строка говорит сама за себя.

Отлично! Теперь давайте я внесу некоторые изменения в файлы и и мы вместе посмотрим на результат в окне браузера. Изменения будут касаться добавления блока-обертки, еще нескольких параграфов и другой легкой стилизации.

Не забуду также проиндексировать и зафиксировать внесенные изменения. Обратите внимание на вид команды — . Эта команда является сокращенным вариантом двух команд: и . Применяется, когда нужно “проскочить” этап индексирования и сразу зафиксировать изменения.

Смотрим, что у нас получилось в окне браузера — то, что и ожидалось:

Git — переключение между ветвями (branches)

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

Оп! Мы видим старую картину — Git “запечатлел” тот момент, когда мы совершили переход из ветви в ветвь . Другими словами, мы вернулись в последнее зафиксированное состояние ветви :

Если я снова вернусь в ветку и запущу команду просмотра логов Git, то коммитов окажется больше:

Мне кажется, уже сейчас должно быть понятно, что такое ветви (branches) в Git и для чего они предназначены. На самом деле это действительно очень просто.

Git — слияние ветвей (branches)

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

Фактически, я хочу сделать слияние двух веток — и . Это сделать очень просто — для этого я перехожу в ветку . То есть, я должен находиться в той ветке, в которую я вношу изменения из другой ветки. А затем произвожу само слияние:

Команда слияния проста — я просто указываю имя той ветки (branch), которую хочу слить (merge) с текущей, в которой я нахожусь на данный момент.

При слиянии ветвей зачастую может возникнуть ситуация, когда происходит конфликт между двумя ветвями. Рассмотрение вопроса решения конфликтов при слиянии не рассматривается мною, так как на данный момент еще не освоил этот вопрос до конца.

Давайте снова “заглянем” в окно браузера — что он нам интересного покажет?

Показал он то, что и следовало показать — результат объединения двух ветвей и .

Git — графическое представление ветвей (branches)

Система Git имеет в своем составе возможность графического представления ветвления в репозитории. Причем, такое представление можно сделать даже в консоли, с помощью псевдографики.

Это можно сделать, набрав в консоли команду:

На Stack Overflow я нашел примеры красивых изображений консоли с псевдографическим выводом команды :

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

Помимо псевдографики, ветви в Git можно визуализировать с помощью настоящего графического приложения. Под Mac OS X и Linux имеется достаточно большое количество таких приложений. Например, под Mac OS X это GitX, под Linux — Gitk или Gitg:

Git — удаление ветви (branch)

В разделе слияния ветвей в Git я научился процессу объединения двух ветвей в одну. Такой процесс в Git имеет название (слияние). Теперь ветвь имеет в себе все, что есть и в ветви . Поэтому ветвь можно удалить.

Выполняется это командой:

Посмотрим на вывод команды :

У меня осталась одна ветвь — .

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих