Git на практике
Существует замечательная книга Pro Git, в которой подробно описаны все команды и возможности гита. Но после ее прочтения у многих остается непонимание того, как это все использовать на практике. В частности, у программистов разного уровня часто возникают вопросы о том, как работать с ветками в Git, когда их заводить и как мержить между собой. Порой мне попадались очень «оригинальные» и неоправданно усложненные схемы работы с гитом. В то время как в сообществе программистов уже сформировалась схема работы с гитом и ветками в нем. В этой статье я хочу дать краткий обзор основных моментов при работе с Git, и описать «классическую» схему работы с ветками. Многое из того что описано в этой статье будет справедливо и для других систем управления версиями.
Эта статья может быть полезна для программистов, которые только начинают осваивать Git, или какую-то другую систему управления версиями. Для опытных программистов эта статья покажется очень простой и банальной.
Для начала давайте разберемся с тем что такое ветка и коммит.
Коммит
Можно сказать, что коммит это основной объект в любой системе управления версиями. В нем содержится описание тех изменений, которые вносит пользователь в код приложения. В Git коммит состоит из нескольких так называемых объектов. Для простоты понимания можно считать, что коммиты это односвязный список, состоящий из объектов в которых содержаться измененные файлы, и ссылка на предыдущий коммит.
У коммита есть и другие свойства. Например, дата коммита, автор, комментарий к коммиту и т.п.
В качестве комментария обычно указывают те изменения, которые вносит этот коммит в код, или название задачи которую он решает.
Git это распределенная система управления версиями. Это значит, что у каждого участника проекта есть своя копия репозитория, которая находиться в папке “.git”, которая расположена в корне проекта. Именно в этой папке хранятся все коммиты и другие объекты Git. Когда вы работаете с Git, он в свою очередь работает с этой папкой.
Завести новый репозиторий очень просто, это делается командой
Таким образом у вас получиться новый пустой репозиторий. Если вы хотите присоединиться к разработке уже имеющегося проекта, то вам нужно будет скопировать этот репозиторий в свою локальную папку с удаленного репозитория. Делается это так:
git clone <url удаленного репозитория>
После чего в текущей папке появляется директория .git в которой и будет содержаться копия удаленного репозитория.
Существует несколько основных областей в которых находиться код.
- Рабочая директория – это файлы в корне проекта, тот код с которым вы работаете.
- Локальный репозиторий — она же директория “.git”. В ней хранятся коммиты и другие объекты.
- Удаленный репозиторий – тот самый репозиторий который считается общим, в который вы можете передать свои коммиты из локального репозитория, что бы остальные программисты могли их увидеть. Удаленных репозиториев может быть несколько, но обычно он бывает один.
- Есть еще одна область, с пониманием которой обычно бывают проблемы. Это так называемая область подготовленных изменений (staging area). Дело в том, что перед тем как включить какие-то изменения в коммит, нужно вначале отметить что именно вы хотите включить в этот коммит. В своей рабочей директории вы можете изменить несколько файлов, но в один конкретный коммит включать не все эти изменения.
git add <имя/файла>
При этом можно использовать маски со звездочкой.
Потом вы делаете коммит в свой локальный репозиторий
git commit –m “Комментарий к коммиту”
Когда коммитов накопиться достаточно много, чтобы ими можно было поделиться, вы выполняете команду
После чего ваши коммиты уходят в удаленный репозиторий.
Если нужно получить изменения из удаленного репозитория, то нужно выполнить команду
После этого, в вашем локальном репозитории появятся те изменения, которые были отправлены другими программистами.
Код в рабочей области проекта образуется применением тех изменений, которые содержаться в коммитах. У каждого коммита есть свое имя, которое представляет собой результат хеш функции sha-1 от содержимого самого коммита.
Просмотреть коммиты можно при помощи команды
Формат ответа этой команды по дефолту не очень удобен. Вот такая команда выведет ответ в более читаемом виде
git log —pretty=format:»%H [%cd]: %an — %s» —graph —date=format:%c
Что бы закончить просмотр нужно нажать на клавишу q
Посмотреть, что находиться в рабочей директории и staging area можно командой
Рабочую директорию можно переключить на предыдущее состояние выполнив команду
git checkout <hash коммита>
Только перед тем как это делать выполните git status и убедитесь, что у вас нет никаких локальных и не зафиксированных изменений. Иначе Git не поймет, как ему переключаться. git status подскажет вам что можно сделать с локальными изменениями что бы можно было переключиться. Этого правила следует придерживаться и при всяких других переключениях рабочей области.
Ветка
Ветка в Git это подвижный указатель на один из коммитов. Обычно ветка указывает на последний коммит в цепочке коммитов. Ветка берет свое начало от какого-то одного коммита. Визуально это можно представить вот так.
Сделать новую ветку и переключиться на нее можно выполнив команды
git pull
git checkout –b <имя новой ветки>
Просто сделать ветку, не переключаясь на нее можно командой
git branch <имя ветки>
переключиться на ветку
git checkout <имя ветки>
Важно понимать, что ветка берет свое начало не от ветки, а от последнего коммита который находиться в той ветке, в которой вы находились.
Ветка обычно заканчивается специальным merge коммитом, который говорит, что ветку нужно объединить с какой-то другой веткой. В merge коммите содержатся две ссылки на два коммита которые объединяются в одну ветку.
Существует другая ситуация при объединении веток, в которой merge может произойти без merge commit. Дело в том, что если в одной из веток не произошло никаких изменений, то необходимость в merge commit с двумя предками отпадает. В таком случае, при слиянии веток, Git просто сделает пометку о том, что дальше будут идти коммиты той ветки с которой эта ветка была объединена. Такая схема merge называется слияние-перемотка (fast-forward merge), визуально это можно представить вот так.
Во всех этих случаях, после того, как ветка объединяется с другой веткой, все коммиты сделанные в ней, попадают в ветку с которой она была объединена. Так же важно понимать, что merge это не двунаправленная операция. Если смержить ветку задачи в мастер ветку, то в мастер ветке появится код, который находился в ветке задачи, а в ветке задачи не появиться новый код из мастер ветки. Если нужно что бы это произошло, нужно смержить мастер ветку в ветку задачи.
Что бы смержить одну ветку в другую нужно вначале переключиться на ту ветку, в которую вы хотите смержить
git checkout <имя ветки>
Потом получить последние изменения сделанные в этой ветке выполнив
Затем выполнить команду
git merge <имя ветки>
Так выглядит работа с ветками в общих чертах.
- Другой программист мог изменить код, в том числе внести такие изменения, которые повлияют на решение задачи, для которой вы заводите новую ветку. Эти изменения могут вам пригодиться при решении своей задачи.
- Из-за этих изменений вы можете получить конфликт при мерже.
- Больше шанс что у вас получится merge commit. Это не так плохо, как два предыдущих пункта. Но если можно избежать лишнего коммита, то почему бы этого не сделать?
Популярные схемы работы с ветками в Git
Теперь можно описать популярные схемы работы с ветками в гите.
Ветки нужны для того, чтобы программисты могли вести совместную работу над проектом и не мешать друг другу при этом. При создании проекта, Git создает базовую ветку. Она называется master веткой. Она считается центральной веткой, т.е. в ней содержится основной код приложения.
Классическая схема работы с ветками
Обычно перед тем как взяться за решение какой-то задачи, программист заводит новую ветку от последнего рабочего коммита мастер ветки и решает задачу в этой новой ветке. В ходе решения он делает ряд коммитов, после этого тестирует код непосредственно в ветке задачи. А после того как задача решена, делают merge обратно в мастер ветку. Такую схему работы часто используют с юнит тестами и автоматизированным деплоем. Если юнит тесты будут покрывать весь код, то можно настроить деплой так, что вначале будут прогоняться все тесты в ветке задачи. А после этого, если они прошли успешно, будет происходить merge и деплой. При такой схеме можно добиться полной автоматизации при тестировании и деплои.
Именная ветка
Неопытные программисты заводят себе именную ветку и работают всегда в ней. Они решают по одной задачи за раз, и когда заканчивают решение одной из задач, делают новый Pull запрос через Web интерфейсе (об этом чуть ниже). Недостаток этого подхода в том, что так можно решать только одну задачу и нельзя быстро переключиться на решение другой задачи. Еще один недостаток в том, что ветки так со временем будут все сильнее расходиться и код в ветке программиста рано или поздно устареет относительно мастер ветки и его придется обновить. Для этого можно либо смержить мастер ветку в ветку программиста, либо завести новую ветку для этого программиста от последнего рабочего состояния в мастер ветке. Правда к тому времени, как это произойдет программист уже может освоить гит в достаточной мере что бы перейти на “классическую” схему работы. Таким образом эта схема имеет место быть для неопытных пользователей Git.
Схема с dev веткой
Другая схема очень похожа на классическую, только в ней помимо мастер ветки есть еще девелоперская ветка, которая деплоится на тестовый сервер. Такую ветку обычно называют dev. Схема работы при этом такая. Программист перед выполнением новой задачи заводит для нее ветку от последнего рабочего состояния в мастер ветке. Когда он заканчивает работу над задачей, то мержит ветку задачи в dev ветку самостоятельно. После этого, совместными усилиями задача тестируется на тестовом сервере вместе с остальными задачами. Если есть ошибки, то задачу дорабатывают в той же ветке и повторно мержат с dev веткой. Когда тестирование задачи заканчивается, то ВЕТКУ ЗАДАЧИ мержат с мастер веткой. Важно заметить, что в этой схеме работы с мастер веткой нужно мержить ветку задачи, а не dev ветку. Ведь в dev ветке будут содержаться изменения, сделанные не только в этой задаче, но и в других и не все эти изменения могут оказаться рабочими. Мастер ветка и dev ветка со временем будут расходиться, поэтому при такой схеме работы периодически заводят новую dev ветку от последнего рабочего состояния мастер ветки. Недостатком этого подхода является избыточность, по сравнению с классической схемой. Такую схему работы с ветками часто используют если в проекте нет автоматизированных тестов и все тестирование происходит вручную на сервере разработки.
Так же следует отметить что эти схемы работы можно комбинировать между собой, если в этом есть какая-то необходимость.
Pull запросы
С этим понятием имеется путаница. Дело в том, что в Git есть две совершенно разные вещи, которые можно назвать Pull запросом. Одна из них, это консольная команда git pull. Другая это кнопка в web интерфейсе репозитория. На github.com она выглядит вот так
Про эту кнопку и пойдет речь дальше.
Если программист достаточно опытный и ответственный, то он обычно сам сливает свой код в мастер ветку. В противном случае программист делает так называемый Pull запрос. Pull запрос это по сути дела запрос на разрешение сделать merge. Pull запрос можно сделать из web интерфейса Git, или при помощи команды git request-pull. После того как Pull запрос создан, остальные участники могут увидеть это, просмотреть тот код который программист предлагает внести в проект, и либо одобрить этот код либо нет. Merge через pull запросы имеет свои плюсы и минусы. Минус в том, что для тесной команды опытных программистов такой подход будет лишним. Это будет только тормозить работу и вносить в нее оттенки бюрократии.
С другой стороны, если в проекте есть не опытные программисты, которые могут сломать код, то Pull запросы могут помочь избежать ошибок, и быстрее обучить этих программистов наблюдая за тем какие изменения они предлагают внести в код.
Так же Pull запросы подходят для широкого сообщества программистов, работающих с открытым исходным кодом. В этом случае нельзя заранее сказать что-то о компетенции таких разработчиков и о том, что они хотят изменить в коде.
Конфликты
Конфликты возникают при мердже веток если в этих ветках одна и та же строка кода была изменена по-разному. Тогда получается, что Git не может сам решить какое из изменений нужно применить и он предлагает вручную решить эту ситуацию. Это замедляет работу с кодом в проекте. Избежать этого можно разными методами. Например, можно распределять задачи так, чтобы связанные задачи не выполнялись одновременно различными программистами.
Другой способ избежать этого, это договориться о каком-то конкретном стиле кода. Тогда программисты не будут менять форматирование кода и вероятность того, что они изменят одну и ту же строчку станет ниже.
Еще один хороший совет, который поможет вам избежать конфликтов при работе в команде, это вносить минимум изменений в код при решении задач. Чем меньше строчек вы поменяли, тем меньше вероятность что вы измените ту же самую строку что и другой программист в другой задаче.
После того, как в мастер ветке достигается состояние, которое можно считать стабильным оно отмечается тегом с версией этого состояния. Это и есть то что называют версией программы.
Делается это вот так
Что бы передать ветки в удаленный репозиторий нужно выполнить команду
Теги удобны еще и тем, что можно легко переключиться на то состояние кода которое отмечено тегом. Делается это с помощью все той же команды
git checkout <имя тега>
Различные системы деплоя и автоматизированной сборки используют теги для идентификации того состояния, которое нужно задеплоить или собрать. Так сделано потому, что если мы будем собирать или деплоить код последней версии, то есть риск, что какой-то другой программист в этот момент внесет какие-то изменения в мастер ветку, и мы соберем не то что хотели. К тому же так будет проще переключаться между рабочими и проверенными состояниями проектов.
Если вы будете придерживаться этих правил и “классической” схемы работы с ветками, то вам будет проще интегрировать ваш Git с другими системами. Например, с системой непрерывной интеграции или с репозиторием пакетов, таким как packagist.org. Обычно сторонние решения и всякие расширения рассчитаны именно на такую схему работы с гитом, и если вы сразу начнете делать все правильно, то это может стать большим плюсом для вас в дальнейшем.
Это обзор основных моментов при работе с Git. Если вы хотите узнать про Git больше, то я вам посоветую прочитать книгу Pro Git. Вот здесь.
В этой статье была приведена упрощенная схема представления коммитов. Но перед тем как ее написать я решил разобраться как именно хранятся коммиты на диске. Если вас тоже заинтересует этот вопрос, то вы можете прочитать об этом вот здесь.
Работа с ветками в GIT
Чтобы исправить баг или сделать новую фитчу в проекте, обычно создают новую ветку. Зачем? Чтобы избежать путаницы. Если бы все делалось в основной ветке, в проекте было бы сложно разобраться, особенно если над ним одновременно работает много людей.
Поэтому только по окончании работы над задачей изменения в ветке сливают в основную ветку master.
Создание ветки
Чтобы создать новую ветку testing локально, выполним команду:
На момент выполнения команды вы находились в какой-то ветке, допустим в master. Состояние этой ветки будет скопировано в ветку testing, и в testing можно будет редактировать файлы и делать снимки, не трогая пока основную ветку master.
Переключение на ветку
Предыдущая команда создаст ветку, но не переключит нас на нее, мы все еще останемся работать в старой ветке. Чтобы перейти на ветку testing и начать работать в ней, выполним команду:
Имейте в виду, что GIT не позволит перейти на другую ветку, если в текущей ветке — в которой мы находимся — есть изменения, которые не зафиксированы (commit) либо не спрятаны (stash). Это нормально, ведь при смене ветке в текущем каталоге сменятся файлы, и git-у надо знать, как быть с текущими изменениями.
Создание и переключение единой командой
Чтобы не выполнять предыдущие команды по очереди, можно написать их одной строкой:
Эта команда создаст ветку testing и сразу переключит нас на нее. Обычно именно это и требуется сделать.
Как переключиться на чью-то ветку из удаленного репозитория
Важно понимать, что GIT не позволит вам работать над чужой веткой. Принцип такой — вы создаете локальную копию чужой ветки, и над ней уже работаете.
Но для начала надо обновить локальный репозиторий — скопировать в него все ветки, которые есть в удаленном репозитории:
Теперь можно посмотреть, какие ветки есть в удаленном репозитории:
Допустим, там есть ветка dev1. Переключимся на нее, создав локальную ветку с таким же именем:
Вообще-то можно было написать проще:
- Эта команда сработает только в том случае, если удаленный репозиторий у вас единственный. Если их два, например origin и upstream, то непонятно, на чью ветку переключаться.
- Она создаст локальную ветку с точно таким же именем dev1. А в полной версии можно было создать локальную ветку и с другим именем mydev1:
Как создать подветку ветки
Обычно мы ответвляемся от основной ветки master, но не всегда. Иногда требуется сделать ответвление от созданной ветки — так сказать, ответвление второго порядка.
Предыдущая команда, с помощью которой мы создавали ветку:
создает ответвление от основной ветки master.
Если нам надо ответвиться не от основной ветки, а от вновь созданной testing, то выполним поочередно команды:
Первая команда переключит нас на ветку testing.
Вторая команда создаст ветку с именем subbranch_of_testing, ответвляющуюся от testing, и переключит нас на нее.
Как понятно из имени, subbranch_of_testing – это подветка ветки testing.
Как посмотреть ветки
Чтобы увидеть все созданные локально ветки, выполним команду:
Появится список веток. Текущая ветка будет выделена звездочкой.
Как переименовать ветку
Иногда оказывается, что первоначально созданное имя ветки не самое лучшее. Его можно изменить.
Локальную
Если еще не выполнена команда push, то достаточно переименовать локальную ветку.
Чтобы переименовать локальную ветку, выполним команду:
Например, переименуем ветку testing в ветку test:
Чтобы переименовать текущую ветку, выполним команду:
Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:
Удаленную
Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:
здесь origin — имя удаленного репозитория (обычно удаленный репозиторий так называется),
old-name — имя ветки локальной ветки,
new-name — новое имя ветки в удаленном репозитории.
Например, надо переименовать ветку testing в test:
Удаление локальной ветки
Чтобы удалить локальную ветку, выполните одну из команд:
Флаги:
-D сокращение для —delete –force удаляет ветку независимо от того, слиты ли ее изменения
-d сокращение для —delete
Например, удалим локальную ветку test:
Вообще-то локальную ветку обычно удаляют после того, как слили ее (выполнили merge) в ветку master, смотрите последний раздел в статье о слиянии веток.
Удаление ветки из удаленного репозитория
Чтобы удалить удаленную ветку, можно использовать две записи.
Либо через двоеточие, как мы уже делали при переименовании ветки:
Например, удалим ветку test из удаленного репозитория origin:
Либо с флагом —delete, так понятнее:
здесь origin — имя удаленного репозитория
Как слить ветки
Обычно сливают некоторую ветку (например, ветку-багфикс) в ветку master. Для этого сначала перейдем в ветку master (в ту ветку, в которую вливаем изменения):
А затем выполним слияние. Допустим, в ветку master надо слить ветку test :
Слияние веток не всегда происходит гладко, иногда требуется разрешить конфликты вручную. Для этого надо отредактировать конфликтые файлы, выполнить их commit.
В этой статье мы рассмотрели работу с ветками GIT и составили небольшую шпаргалку по использованию веток.
Добавить комментарий Отменить ответ
Прошу прощения: на комментарии временно не отвечаю.
Шпаргалка по Git
Результат: каталог с выписанной веткой master . Теперь можно создавать новые ветки, или выписывать с github существующие.
Как выписать ветку с github
С помощью команды «checkout» можно выписать уже существующую ветку с github:
Или так, что намного надежнее:
Если команда не сработала, нужно попробовать выполнить обновление:
Если вышеприведенные команды не сработали, выдали ошибку, и времени разбираться с ней нет, можно попробовать получить нужную ветку следующим способом:
Т.е. сначала мы создаем новую ветку, а затем вливаем в нее изменения из ветки на github.
Как создать новую ветку в локальном репозитории
- Создаем новую ветку в локальном репозитории:
2. Публикуем ее на github:
Как переключиться на другую ветку в git
Если вы случайно удалили какой-то файл, можно извлечь его из хранилища:
Как посмотреть список веток
Команда «branch» позволяет посмотреть список веток в локальном репозитории. Текущая ветка будет помечена звездочкой:
Как сделать 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 show» позволяет просмотреть, какие именно изменения произошли в указанном коммите:
Можно посмотреть построчную информацию о последнем коммите, имя автора и хэш коммита:
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] :
git clone <repo>
clone the repository specified by <repo>; this is similar to «checkout» in
some other version control systems such as Subversion and CVS
Add colors to your
[color] ui = auto
[color «branch»] current = yellow reverse
local = yellow
remote = green
[color «diff»] meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color «status»] added = yellow
changed = green
untracked = cyan
Highlight whitespace in diffs
[color] ui = true
[color «diff»] whitespace = red reverse
[core] whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
Add aliases to your
[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
# Show files ignored by git:
ign = ls-files -o -i —exclude-standard
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 branch.autosetupmerge true
tells git-branch and git-checkout to setup new branches so that git-pull(1)
will appropriately merge from that remote branch. Recommended. Without this,
you will have to add —track to your branch command or manually merge remote
tracking branches with «fetch» and then «merge».
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
You can add «—global» after «git config» to any of these commands to make it
apply to all git repos (writes to
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 diff
show a diff of the changes made since your last commit
to diff one file: «git diff — <filename>»
to show a diff between staging area and HEAD: `git diff —cached`
git status
show files added to the staging area, files with changes, and untracked files
git log
show recent commits, most recent on top. Useful options:
—color with color
—graph with an ASCII-art commit graph on the left
—decorate with branch and tag names on appropriate commits
—stat with stats (files changed, insertions, and deletions)
-p with full diffs
—author=foo only by a certain author
—after=»MMM DD YYYY» ex. («Jun 20 2008″) only commits after a certain date
—before=»MMM DD YYYY» only commits that occur before a certain date
—merge only the commits involved in the current merge conflicts
git log <ref>..<ref>
show commits between the specified range. Useful for seeing changes from remotes:
git log HEAD..origin/master # after git remote update
git show <rev>
show the changeset (diff) of a commit specified by <rev>, 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 <rev>:<filename>
this is similar to cat-file but much simpler syntax.
git show —name-only <rev>
show only the names of the files that changed, no diff information.
git blame <file>
show who authored each line in <file>
git blame <file> <rev>
show who authored each line in <file> as of <rev> (allows blame to go back in
time)
git gui blame
really nice GUI interface to git blame
git whatchanged <file>
show only the commits which affected <file> listing the most recent first
E.g. view all changes made to a file on a branch:
git whatchanged <branch> <file> | grep commit | \
colrm 1 7 | xargs -I % git show % <file>
this could be combined with git remote show <remote> to find all changes on
all branches to a particular file.
git diff <commit> head path/to/fubar
show the diff between a file on the current branch and potentially another branch
git diff —cached [<file>] 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 <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 <file1> <file2> …
add <file1>, <file2>, etc… to the project
git add <dir>
add all files under directory <dir> to the project, including subdirectories
git add .
add all files under the current directory to the project
*WARNING*: including untracked files.
git rm <file1> <file2> …
remove <file1>, <file2>, etc… from the project
git rm $(git ls-files —deleted)
remove all deleted files from the project
git rm —cached <file1> <file2> …
commits absence of <file1>, <file2>, 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 <file1> <file2> …
git stage <file1> <file2> …
add changes in <file1>, <file2> … 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 <file1> <file2> …
remove the specified files from the next commit
git commit <file1> <file2> … [-m <msg>] commit <file1>, <file2>, etc…, optionally using commit message <msg>,
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 <file1> <file2> …
redo previous commit, including changes made to <file1>, <file2>, etc…
git branch
list all local branches
git branch -r
list all remote branches
git branch -a
list all local and remote branches
git branch <branch>
create a new branch named <branch>, referencing the same point in history as
the current branch
git branch <branch> <start-point>
create a new branch named <branch>, referencing <start-point>, which may be
specified any way you like, including using a branch name or a tag name
git push <repo> <start-point>:refs/heads/<branch>
create a new remote branch named <branch>, referencing <start-point> on the
remote. Repo is the name of the remote.
Example: git push origin origin:refs/heads/branch-1
Example: git push origin origin/branch-1:refs/heads/branch-2
Example: git push origin branch-1 ## shortcut
git branch —track <branch> <remote-branch>
create a tracking branch. Will push/pull changes to/from another repository.
Example: git branch —track experimental origin/experimental
git branch —set-upstream <branch> <remote-branch> (As of Git 1.7.0)
Make an existing branch track a remote branch
Example: git branch —set-upstream foo origin/foo
git branch -d <branch>
delete the branch <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 <remote-branch>
delete a remote-tracking branch.
Example: git branch -r -d wycats/master
git branch -D <branch>
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.
git checkout <branch>
make the current branch <branch>, updating the working directory to reflect
the version referenced by <branch>
git checkout -b <new> <start-point>
create a new branch <new> referencing <start-point>, and check it out.
git push <repository> :<branch>
removes a branch from a remote repository.
Example: git push origin :old_branch_to_be_deleted
git co <branch> <path to new file>
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
git show <branch> — <path to file that does not exist>
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 <rev>:<repo path to file>
Show the contents of a file at the specific revision. Note: path has to be
absolute within the repo.
git merge <branch>
merge branch <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 <branch>
git merge <branch> —no-commit
merge branch <branch> into the current branch, but do not autocommit the
result; allows you to make further tweaks
git merge <branch> -s ours
merge branch <branch> into the current branch, but drops any changes in
<branch>, using the current tree as the new tree
git cherry-pick [—edit] [-n] [-m parent-number] [-s] [-x] <commit>
selectively merge a single commit from another local branch
Example: git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544
git hash-object <file-path>
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:
obj_blob=»$1″
git log —pretty=format:’%T %h %s’ \
| while read tree commit subject ; do
if git ls-tree -r $tree | grep -q «$obj_blob» ; then
echo $commit «$subject»
fi
done
Squashing
———
WARNING: «git rebase» changes history. Be careful. Google it.
git rebase —interactive HEAD
10
(then change all but the first «pick» to «squash»)
squash the last 10 commits into one big commit
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 fetch <remote>
update the remote-tracking branches for <remote> (defaults to «origin»).
Does not initiate a merge into the current branch (see «git pull» below).
git pull
fetch changes from the server, and merge them into the current branch.
Note: .git/config must have a [branch «some_name»] section for the current
branch, to know which remote-tracking branch to merge into the current
branch. Git 1.5.3 and above adds this automatically.
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 <branch>
update the server with your commits made to <branch> since your last push.
This is always *required* for new branches that you wish to share. After
the first explicit push, «git push» by itself is sufficient.
git push origin <branch>:refs/heads/<branch>
E.g. git push origin twitter-experiment:refs/heads/twitter-experiment
Which, in fact, is the same as git push origin <branch> but a little
more obvious what is happening.
git revert <rev>
reverse commit specified by <rev> and commit the result. This does *not* do
the same thing as similarly named commands in other VCS’s such as «svn
revert» or «bzr revert», see below
git checkout <file>
re-checkout <file>, overwriting any local changes
git checkout .
re-checkout all files, overwriting any local changes. This is most similar
to «svn revert» if you’re used to Subversion commands
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 —hard ORIG_HEAD or git reset —hard origin/master
undo your most recent *successful* merge *and* any changes that occurred
after. Useful for forgetting about the merge you just did. If there are
conflicts (the merge was not successful), use «git reset —hard» (above)
instead.
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 <sha1-A> = $(git merge-base <sha1-A> <sha1-B>)
determine if merging sha1-B into sha1-A is achievable as a fast forward;
non-zero exit status is false.
git stash
git stash save <optional-name>
save your local modifications to a new stash (so you can for example
«git svn rebase» or «git pull»)
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 <stash-name> -p
show the contents of a stash — accepts all diff args
git stash drop [<stash-name>] delete the stash
git stash clear
delete all current stashes
git remote add <remote> <remote_URL>
adds a remote repository to your git config. Can be then fetched locally.
Example:
git remote add coreteam git://github.com/wycats/merb-plugins.git
git fetch coreteam
git push <remote> :refs/heads/<branch>
delete a branch in a remote repository
git push <remote> <remote>:refs/heads/<remote_branch>
create a branch on a remote repository
Example: git push origin origin:refs/heads/new_feature_name
git push <repository> +<remote>:<new_remote>
replace a <remote> branch with <new_remote>
think twice before do this
Example: git push origin +master:my_branch
git remote prune <remote>
prune deleted remote-tracking branches from «git branch -r» listing
git remote add -t master -m master origin git://example.com/git.git/
add a remote and track its master
git remote show <remote>
show information about the remote server.
git checkout -b <local branch> <remote>/<remote branch>
Eg.:
git checkout -b myfeature origin/myfeature
git checkout -b myfeature remotes/<remote>/<branch>
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 pull <remote> <branch>
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 <remote>
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 <remote_repository> <path/to/submodule>
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 <command>
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 <path to submodule>
git pull
2. commit the new version of submodule:
cd <path to toplevel>
git commit -m «update submodule version»
3. check that the submodule has the correct version
git submodule status
If the update in the submodule is not committed in the
main repository, it is lost and doing git submodule
update will revert to the previous version.
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 <Revision>^..<Revision>
Generate a patch for a single commit. E.g.
git format-patch d8efce43099^..d8efce43099
Revision does not need to be fully specified.
git am <patch file>
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 < patchfile
Useful for sharing changes without generating a git commit.
git tag -l
Will list all tags defined in the repository.
git co <tag_name>
Will checkout the code for a particular tag. After this you’ll
probably want to do: ‘git co -b <some branch name>’ 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 instaweb —httpd=webrick [—start | —stop | —restart]
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.