Git как выбрать ветку

Обновлено: 20.09.2024

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

Ветки - главная фишка git

Git стал стандартом в системах контроля версий благодаря простой и удобной работе с ветками.

Какие проблемы решают ветки

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

Было бы здорово, если бы могли разрабатывать новую фичу независимо от основного кода проекта. То есть взять и зафиксировать рабочее состояние сайта, а делать новый функционал отдельно, не боясь поломать рабочий код. И еще чтобы можно было переключаться между основным кодом (для правки баги) и кодом новой фичи (для продолжения работы над ней)

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

Схема рабочая, но слишком много суеты и неудобств:

нужно постоянно создавать архивы с рабочим кодом
сложно "переключаться" между архивами
сложно перетаскивать изменения между архивами
легко что-то напутать или потерять - все мы люди

Все эти проблемы git решает механизмом веток.

Как работают ветки

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

Когда мы начинаем работать над новым функционалом, мы создаем новую ветку на основе master. Это называется "ответвиться от мастера". После этого мы можем работать, создавать новые файлы, вносить изменения в старые, можем хоть удалить половину проекта - главное, что это будет изолировано от основного мастера. То есть в своей ветке мы можем как угодно ломать проект, основной код при этом не пострадает.

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

Так как git хранит всю историю проекта, то он хранит все коммиты всех веток и со всеми изменениями. То есть вернувшись в свою ветку мы увидим уже сделанные коммиты и можем посмотреть изменения по ним.

Когда мы заканчиваем работать над новым функционалом, то нужно наши изменения перенести в мастер, чтобы залить на боевой сайт. Это называется слить ветку в мастер, или залить в мастер, или смерджить в мастер. При этом после мерджа в мастере оказываются не только наши изменения, но и те, которые были в мастере, но не были в нашей ветке (правка баги в мастере). То есть нам даже не обязательно после правки баги в мастере переносить эти изменения в свою ветку. При мердже git наш новый код "положит" поверх того, что было в мастере, не стирая старый.

Чтобы было нагляднее и понятнее, как это работает, смотрите видео. А в тексте ниже краткое описание команд для работы с ветками.

Ветка master

Еще раз закрепим. Ветка master - это, как правило, основная ветка проекта. Она появляется сразу после клонирования или инициализации репозитория. Есть разные варианты ведения веток, но мы будем считать, что master - наша основная рабочая ветка, от которой ответвляются другие.

Как создать новую ветку

Так мы создали новую ветку news, имея в виду, что будем разрабатывать в ней блок новостей.

Как переключаться между ветками

Для этого используется команда checkout

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

Вот что при этом вы увидите

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

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

Этой командой мы выведем список всех локальных веток. Звездочка у news означает текущую ветку, в которой мы сейчас находимся.

Коммитим в новую ветку

Коммиты в ветку добавляются точно так же, как и раньше. Делаем изменения в файлах, потом git add, потом git commit -m 'commit message'.

Как запушить новую ветку

Вспомним, как мы пушили раньше

Точно так же мы пушим и новую ветку, только вместо master указываем свое название

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

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

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

Это переименует текущую ветку news в block-news. Чтобы убедиться, посмотрим список веток

Обратите внимание, если мы запушим новую ветку, то на сервере, в github, появится еще одна ветка block-news, и при этом останется старая news. Чтобы не засорять проект, старую ветку нужно удалить как локальную у себя, так и удаленную на сервере.

Как удалить ветку

Удаляется ветка командой git branch -d branch_name. Но здесь могут быть варианты. Рассмотрим, что может пойти не так

Здесь просто - мы не можем удалить ветку, потому что в ней находимся. Сначала нужно перелючиться в мастер

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

Теперь удалено без вопросов.

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

В правом нижнем углу есть пункт "Git:master". Там пишется название текущей ветки. Чтобы создать новую, нужно кликнуть на этот пункт и выбрать New Branch. Чтобы переключиться, выбрать в списке Local Branches нужную ветку и Checkout. Чтобы удалить или переименовать соотвественно Delete или Rename.

Наглядно это показывается в видеоуроке

Раздел Remote Branches мы рассмотрим в следующем уроке

Что могу посоветовать

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

Поняв магию веток, мы уже не представим свою работу без git. Любой, даже небольшой проект мы будем начинать с создания репозитория. А работа с ветками будет такой же естественной, как и собственно написание кода. Мне кажется, именно понимание веток превращает git из прикольной тулзы в незаменимый инструмент работы.

Для начала давайте разберемся с тем что такое ветка и коммит.

Коммит

Можно сказать, что коммит это основной объект в любой системе управления версиями. В нем содержится описание тех изменений, которые вносит пользователь в код приложения. В Git коммит состоит из нескольких так называемых объектов. Для простоты понимания можно считать, что коммиты это односвязный список, состоящий из объектов в которых содержаться измененные файлы, и ссылка на предыдущий коммит.

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

Git это распределенная система управления версиями. Это значит, что у каждого участника проекта есть своя копия репозитория, которая находиться в папке “.git”, которая расположена в корне проекта. Именно в этой папке хранятся все коммиты и другие объекты Git. Когда вы работаете с Git, он в свою очередь работает с этой папкой.

Завести новый репозиторий очень просто, это делается командой

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

После чего в текущей папке появляется директория .git в которой и будет содержаться копия удаленного репозитория.

Существует несколько основных областей в которых находиться код.

Рабочая директория – это файлы в корне проекта, тот код с которым вы работаете.
Локальный репозиторий — она же директория “.git”. В ней хранятся коммиты и другие объекты.
Удаленный репозиторий – тот самый репозиторий который считается общим, в который вы можете передать свои коммиты из локального репозитория, что бы остальные программисты могли их увидеть. Удаленных репозиториев может быть несколько, но обычно он бывает один.
Есть еще одна область, с пониманием которой обычно бывают проблемы. Это так называемая область подготовленных изменений (staging area). Дело в том, что перед тем как включить какие-то изменения в коммит, нужно вначале отметить что именно вы хотите включить в этот коммит. В своей рабочей директории вы можете изменить несколько файлов, но в один конкретный коммит включать не все эти изменения.

При этом можно использовать маски со звездочкой.
Потом вы делаете коммит в свой локальный репозиторий

git commit –m “Комментарий к коммиту”

Когда коммитов накопиться достаточно много, чтобы ими можно было поделиться, вы выполняете команду

После чего ваши коммиты уходят в удаленный репозиторий.

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

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

Код в рабочей области проекта образуется применением тех изменений, которые содержаться в коммитах. У каждого коммита есть свое имя, которое представляет собой результат хеш функции sha-1 от содержимого самого коммита.

Просмотреть коммиты можно при помощи команды

Формат ответа этой команды по дефолту не очень удобен. Вот такая команда выведет ответ в более читаемом виде

git log --pretty=format:"%H [%cd]: %an - %s" --graph --date=format:%c

Что бы закончить просмотр нужно нажать на клавишу q
Посмотреть, что находиться в рабочей директории и staging area можно командой

Рабочую директорию можно переключить на предыдущее состояние выполнив команду

Только перед тем как это делать выполните git status и убедитесь, что у вас нет никаких локальных и не зафиксированных изменений. Иначе Git не поймет, как ему переключаться. git status подскажет вам что можно сделать с локальными изменениями что бы можно было переключиться. Этого правила следует придерживаться и при всяких других переключениях рабочей области.

Ветка

Ветка в Git это подвижный указатель на один из коммитов. Обычно ветка указывает на последний коммит в цепочке коммитов. Ветка берет свое начало от какого-то одного коммита. Визуально это можно представить вот так.

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

git pull
git checkout –b

Просто сделать ветку, не переключаясь на нее можно командой

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

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

Ветка обычно заканчивается специальным merge коммитом, который говорит, что ветку нужно объединить с какой-то другой веткой. В merge коммите содержатся две ссылки на два коммита которые объединяются в одну ветку.

Существует другая ситуация при объединении веток, в которой merge может произойти без merge commit. Дело в том, что если в одной из веток не произошло никаких изменений, то необходимость в merge commit с двумя предками отпадает. В таком случае, при слиянии веток, Git просто сделает пометку о том, что дальше будут идти коммиты той ветки с которой эта ветка была объединена. Такая схема merge называется слияние-перемотка (fast-forward merge), визуально это можно представить вот так.

Во всех этих случаях, после того, как ветка объединяется с другой веткой, все коммиты сделанные в ней, попадают в ветку с которой она была объединена. Так же важно понимать, что merge это не двунаправленная операция. Если смержить ветку задачи в мастер ветку, то в мастер ветке появится код, который находился в ветке задачи, а в ветке задачи не появиться новый код из мастер ветки. Если нужно что бы это произошло, нужно смержить мастер ветку в ветку задачи.
Что бы смержить одну ветку в другую нужно вначале переключиться на ту ветку, в которую вы хотите смержить

Потом получить последние изменения сделанные в этой ветке выполнив

Затем выполнить команду

Так выглядит работа с ветками в общих чертах.

Другой программист мог изменить код, в том числе внести такие изменения, которые повлияют на решение задачи, для которой вы заводите новую ветку. Эти изменения могут вам пригодиться при решении своей задачи.
Из-за этих изменений вы можете получить конфликт при мерже.
Больше шанс что у вас получится merge commit. Это не так плохо, как два предыдущих пункта. Но если можно избежать лишнего коммита, то почему бы этого не сделать?

Pull запросы

Про эту кнопку и пойдет речь дальше.

Если программист достаточно опытный и ответственный, то он обычно сам сливает свой код в мастер ветку. В противном случае программист делает так называемый Pull запрос. Pull запрос это по сути дела запрос на разрешение сделать merge. Pull запрос можно сделать из web интерфейса Git, или при помощи команды git request-pull. После того как Pull запрос создан, остальные участники могут увидеть это, просмотреть тот код который программист предлагает внести в проект, и либо одобрить этот код либо нет. Merge через pull запросы имеет свои плюсы и минусы. Минус в том, что для тесной команды опытных программистов такой подход будет лишним. Это будет только тормозить работу и вносить в нее оттенки бюрократии.

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

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

Конфликты

Конфликты возникают при мердже веток если в этих ветках одна и та же строка кода была изменена по-разному. Тогда получается, что Git не может сам решить какое из изменений нужно применить и он предлагает вручную решить эту ситуацию. Это замедляет работу с кодом в проекте. Избежать этого можно разными методами. Например, можно распределять задачи так, чтобы связанные задачи не выполнялись одновременно различными программистами.
Другой способ избежать этого, это договориться о каком-то конкретном стиле кода. Тогда программисты не будут менять форматирование кода и вероятность того, что они изменят одну и ту же строчку станет ниже.

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

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

Что бы передать ветки в удаленный репозиторий нужно выполнить команду

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

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

Это обзор основных моментов при работе с Git. Если вы хотите узнать про Git больше, то я вам посоветую прочитать книгу Pro Git. Вот здесь.

В этой статье была приведена упрощенная схема представления коммитов. Но перед тем как ее написать я решил разобраться как именно хранятся коммиты на диске. Если вас тоже заинтересует этот вопрос, то вы можете прочитать об этом вот здесь.

Переключение веток аналогично переключению старых коммитов и файлов, в которых рабочий каталог обновляется в соответствии с выбранной веткой/ревизией; вместе с тем новые изменения сохраняются в истории проекта, то есть это не просто операция чтения.

Переключение веток

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

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

Иногда команду git checkout можно спутать с командой git clone . Разница между этими двумя командами заключается в том, что при клонировании (clone) выполняется извлечение кода из удаленного репозитория, тогда как при переключении (checkout) происходит переключение между версиями кода, который уже находится в локальной системе.

Использование: существующие ветки

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

В вышеприведенном примере показано, как просмотреть список доступных веток с помощью команды git branch и переключиться на конкретную ветку (в данном случае — на ветку feature_inprogress_branch ).

Новые ветки

Команда git checkout часто используется вместе с командой git branch . С помощью команды git branch можно создать новую ветку. Когда вы захотите начать работу над новой функцией, создайте новое ответвление от ветки main с помощью команды git branch new_branch . Затем переключитесь на новую ветку с помощью команды git checkout new_branch . Команда git checkout также принимает аргумент -b , который действует как вспомогательный метод, позволяя создать новую ветку и сразу переключиться на нее. Вы можете работать сразу с несколькими функциями в одном репозитории, переключаясь между ними с помощью git checkout .

В вышеприведенном примере одновременно создается ветка и сразу же выполняется переключение на нее. Опция -b — это удобный способ сообщить системе Git, чтобы она выполнила команду git branch перед выполнением команды git checkout .

По умолчанию команда git checkout -b создает ветку новая-ветка от текущего указателя HEAD . Команде git checkout можно передать необязательный параметр с указанием ветки. В приведенном выше примере передается ＜ существующая-ветка> , поэтому новая-ветка будет создана от ветки существующая-ветка , а не от текущего указателя HEAD .

Переключение веток

Переключение веток — простая операция. При выполнении следующей команды указатель HEAD будет перенесен на последний коммит ветки .

Git отслеживает историю операций переключения в журнале ссылок reflog. Чтобы просмотреть эту историю, выполните команду git reflog .

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

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

В современных версиях Git переключение на удаленную ветку не отличается от переключения на локальную ветку.

В старых версиях Git необходимо создавать новую ветку на основе удаленного репозитория ( remote ).

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

Открепленные указатели HEAD

Теперь, когда мы рассмотрели три основных варианта использования команды git checkout на ветках, важно обсудить состояние detached HEAD , или состояние открепленного указателя HEAD. Помните, что HEAD — это указатель на текущий снимок в Git. По сути дела, команда git checkout просто обновляет указатель HEAD , чтобы он ссылался на указанную ветку или коммит. Когда HEAD указывает на ветку, Git молчит, но при попытке переключиться на коммит система переходит в состояние detached HEAD (открепленный указатель HEAD).

Всегда ведите разработку на ветке, а не на открепленном указателе HEAD . Это гарантия того, что у вас всегда будет ссылка на ваши новые коммиты. Вместе с тем при просмотре предыдущего коммита состояние указателя HEAD не имеет значения: он может быть как откреплен, так и нет.

Резюме

Эта страница посвящена использованию команды git checkout при смене веток. В общем и целом при использовании команды git checkout на ветках происходит изменение ссылки в указателе HEAD . Эту команду можно использовать для создания веток, переключения между ветками и удаленными ветками. Команда git checkout — важный инструмент при стандартной работе в Git. Она представляет собой аналог команды git merge . Команды git checkout и git merge — критически важные инструменты для реализации рабочих процессов Git .

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

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

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

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

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

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

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

2. Публикуем ее на github:

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

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

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

Как сделать commit

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

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

2. Подготавливаем коммит, добавляя в него файлы командой:

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

3. Выполняем коммит:

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

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

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

5. Переключаемся на ветку dev:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

git log — просмотр логов, показывает дельту (разницу/diff), привнесенную каждым коммитом.

Копируем идентификатор коммита, до которого происходит откат.
Откатываемся до последнего успешного коммита (указываем последний коммит):

Можно откатить до последней версии ветки:

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

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

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

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

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

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

git cherry-pick

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

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

3. Выполнить команду, указать код коммита:

4. После этого обновить ветку на сервере:

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

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

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

Add colors to your ~/.gitconfig file:

Highlight whitespace in diffs

Add aliases to your ~/.gitconfig file:

[alias] st = status
ci = commit
br = branch
co = checkout
df = diff
dc = diff —cached
lg = log -p
lol = log —graph —decorate —pretty=oneline —abbrev-commit
lola = log —graph —decorate —pretty=oneline —abbrev-commit —all
ls = ls-files

git config -e [—global] edit the .git/config [or ~/.gitconfig] file in your $EDITOR

git config —global user.name ‘John Doe’
git config —global user.email [email protected]
sets your name and email for commit messages

git config core.autocrlf true
This setting tells git to convert the newlines to the system’s standard
when checking out files, and to LF newlines when committing in

git config —list
To view all options

git config apply.whitespace nowarn
To ignore whitespace

Info
—-
git reflog
Use this to recover from *major* mess ups! It’s basically a log of the
last few actions and you might have luck and find old commits that
have been lost by doing a complex merge.

git status
show files added to the staging area, files with changes, and untracked files

git show
show the changeset (diff) of a commit specified by , which can be any
SHA1 commit ID, branch name, or tag (shows the last commit (HEAD) by default)

also to show the contents of a file at a specific revision, use
git show :
this is similar to cat-file but much simpler syntax.

git show —name-only
show only the names of the files that changed, no diff information.

git blame
show who authored each line in

git blame
show who authored each line in as of (allows blame to go back in
time)

git gui blame
really nice GUI interface to git blame

git whatchanged
show only the commits which affected listing the most recent first
E.g. view all changes made to a file on a branch:
git whatchanged
| grep commit | \
colrm 1 7 | xargs -I % git show %
this could be combined with git remote show to find all changes on
all branches to a particular file.

git diff head path/to/fubar
show the diff between a file on the current branch and potentially another branch

git diff —cached [ ] shows diff for staged (git-add’ed) files (which includes uncommitted git cherry-pick’ed files)

git ls-files
list all files in the index and under version control.

git ls-remote [HEAD] show the current version on the remote repo. This can be used to check whether
a local is required by comparing the local head revision.

git add …
add , , etc… to the project

git add
add all files under directory to the project, including subdirectories

git add .
add all files under the current directory to the project
*WARNING*: including untracked files.

git rm …
remove , , etc… from the project

git rm $(git ls-files —deleted)
remove all deleted files from the project

git rm —cached …
commits absence of , , etc… from the project

Edit $GIT_DIR/.git/info/exclude. See Environment Variables below for explanation on $GIT_DIR.

Add a file .gitignore to the root of your project. This file will be checked in.

Either way you need to add patterns to exclude to these files.

git add …
git stage …
add changes in , … to the staging area (to be included in
the next commit

git add -p
git stage —patch
interactively walk through the current changes (hunks) in the working
tree, and decide which changes to add to the staging area.

git add -i
git stage —interactive
interactively add files/changes to the staging area. For a simpler
mode (no menu), try `git add —patch` (above)

git reset HEAD …
remove the specified files from the next commit

git commit … [-m ] commit , , etc…, optionally using commit message ,
otherwise opening your editor to let you type a commit message

git commit -a
commit all files changed since your last commit
(does not include new (untracked) files)

git commit -v
commit verbosely, i.e. includes the diff of the contents being committed in
the commit message screen

git commit —amend
edit the commit message of the most recent commit

git commit —amend …
redo previous commit, including changes made to , , etc…

git branch
list all local branches

git branch -r
list all remote branches

git branch -a
list all local and remote branches

create a new branch named
, referencing the same point in history as
the current branch

git branch

create a new branch named
, referencing , which may be
specified any way you like, including using a branch name or a tag name

git push :refs/heads/

git branch —track

create a tracking branch. Will push/pull changes to/from another repository.
Example: git branch —track experimental origin/experimental

git branch —set-upstream
(As of Git 1.7.0)
Make an existing branch track a remote branch
Example: git branch —set-upstream foo origin/foo

delete the branch
; if the branch you are deleting points to a
commit which is not reachable from the current branch, this command
will fail with a warning.

git branch -r -d
delete a remote-tracking branch.
Example: git branch -r -d wycats/master

even if the branch points to a commit not reachable from the current branch,
you may know that that commit is still reachable from some other branch or
tag. In that case it is safe to use this command to force git to delete the
branch.

make the current branch
, updating the working directory to reflect
the version referenced by

git checkout -b
create a new branch referencing , and check it out.

removes a branch from a remote repository.
Example: git push origin :old_branch_to_be_deleted

Checkout a file from another branch and add it to this branch. File
will still need to be added to the git branch, but it’s present.
Eg. git co remote_at_origin__tick702_antifraud_blocking …./…nt_elements_for_iframe_blocked_page.rb

Eg. git show remote_tick702 — path/to/fubar.txt
show the contents of a file that was created on another branch and that
does not exist on the current branch.

git show :
Show the contents of a file at the specific revision. Note: path has to be
absolute within the repo.

merge branch
into the current branch; this command is idempotent
and can be run as many times as needed to keep the current branch
up-to-date with changes in

git merge
—no-commit
merge branch
into the current branch, but do not autocommit the
result; allows you to make further tweaks

git merge
-s ours
merge branch
into the current branch, but drops any changes in

, using the current tree as the new tree

git cherry-pick [—edit] [-n] [-m parent-number] [-s] [-x]
selectively merge a single commit from another local branch
Example: git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

git hash-object
get the blob of some file whether it is in a repository or not

Find the commit in the repository that contains the file blob:

git mergetool
work through conflicted files by opening them in your mergetool (opendiff,
kdiff3, etc.) and choosing left/right chunks. The merged result is staged for
commit.

For binary files or if mergetool won’t do, resolve the conflict(s) manually
and then do:

Once all conflicts are resolved and staged, commit the pending merge with:

git push
update the server with your commits across all branches that are *COMMON*
between your local copy and the server. Local branches that were never
pushed to the server in the first place are not shared.

git push origin

git push origin
:refs/heads/

E.g. git push origin twitter-experiment:refs/heads/twitter-experiment
Which, in fact, is the same as git push origin
but a little
more obvious what is happening.

git checkout
re-checkout , overwriting any local changes

Fix mistakes / Undo
——————-

git reset —hard
abandon everything since your last commit; this command can be DANGEROUS.
If merging has resulted in conflicts and you’d like to just forget about
the merge, this command will do that.

git reset —soft HEAD^
forgot something in your last commit? That’s easy to fix. Undo your last
commit, but keep the changes in the staging area for editing.

git commit —amend
redo previous commit, including changes you’ve staged in the meantime.
Also used to edit commit message of previous commit.

test = $(git merge-base )
determine if merging sha1-B into sha1-A is achievable as a fast forward;
non-zero exit status is false.

git stash apply
restore the changes recorded in the stash on top of the current working tree
state

git stash pop
restore the changes from the most recent stash, and remove it from the stack
of stashed changes

git stash list
list all current stashes

git stash show -p
show the contents of a stash — accepts all diff args

git stash drop [ ] delete the stash

git stash clear
delete all current stashes

git push :refs/heads/

delete a branch in a remote repository

git push :refs/heads/
create a branch on a remote repository
Example: git push origin origin:refs/heads/new_feature_name

git push + :
replace a branch with
think twice before do this
Example: git push origin +master:my_branch

git remote show
show information about the remote server.

git checkout -b /
Eg.:
git checkout -b myfeature origin/myfeature
git checkout -b myfeature remotes/ /

Track a remote branch as a local branch. It seems that
somtimes an extra ‘remotes/’ is required, to see the exact
branch name, ‘git branch -a’.

git push
For branches that are remotely tracked (via git push) but
that complain about non-fast forward commits when doing a
git push. The pull synchronizes local and remote, and if
all goes well, the result is pushable.

git fetch
Retrieves all branches from the remote repository. After
this ‘git branch —track …’ can be used to track a branch
from the new remote.

git submodule add

add the given repository at the given path. The addition will be part of the
next commit.

git submodule update [—init] Update the registered submodules (clone missing submodules, and checkout
the commit specified by the super-repo). —init is needed the first time.

git submodule foreach
Executes the given command within each checked out submodule.

1. Delete the relevant line from the .gitmodules file.
2. Delete the relevant section from .git/config.
3. Run git rm —cached path_to_submodule (no trailing slash).
4. Commit and delete the now untracked submodule files.

Updating submodules
To update a submodule to a new commit:
1. update submodule:
cd

git pull
2. commit the new version of submodule:
cd

git format-patch HEAD^
Generate the last commit as a patch that can be applied on another
clone (or branch) using ‘git am’. Format patch can also generate a
patch for all commits using ‘git format-patch HEAD^ HEAD’
All page files will be enumerated with a prefix, e.g. 0001 is the
first patch.

git format-patch ^..
Generate a patch for a single commit. E.g.
git format-patch d8efce43099^..d8efce43099
Revision does not need to be fully specified.

Applies the patch file generated by format-patch.

git diff —no-prefix > patchfile
Generates a patch file that can be applied using patch:
patch -p0
Will checkout the code for a particular tag. After this you’ll
probably want to do: ‘git co -b ’ to define
a branch. Any changes you now make can be committed to that
branch and later merged.

git archive master | tar -x -C /somewhere/else
Will export expanded tree as tar archive at given path

git archive master | bzip2 > source-tree.tar.bz2
Will export archive as bz2

git archive —format zip —output /full/path master
Will export as zip

GIT_AUTHOR_NAME, GIT_COMMITTER_NAME
Your full name to be recorded in any newly created commits. Overrides
user.name in .git/config

GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL
Your email address to be recorded in any newly created commits. Overrides
user.email in .git/config

GIT_DIR
Location of the repository to use (for out of working directory repositories)

GIT_WORKING_TREE
Location of the Working Directory — use with GIT_DIR to specifiy the working directory root
or to work without being in the working directory at all.

Change author for all commits with given name

Читайте также:

Git как выбрать ветку

Ветки - главная фишка git

Какие проблемы решают ветки

Как работают ветки

Ветка master

Как создать новую ветку

Как переключаться между ветками

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

Коммитим в новую ветку

Как запушить новую ветку

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

Как удалить ветку

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

Что могу посоветовать

Коммит

Ветка

Популярные схемы работы с ветками в Git

Классическая схема работы с ветками

Именная ветка

Схема с dev веткой

Pull запросы

Конфликты

Переключение веток

Использование: существующие ветки

Новые ветки

Переключение веток

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

Открепленные указатели HEAD

Резюме

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

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

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

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

Как сделать commit

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

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

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

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

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

git cherry-pick

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