что делает команда git commit с флагом am
Русские Блоги
Чтобы понять разницу, вы должны сначала понять цикл изменения статуса файла git, как показано на рисунке ниже.
Все файлы в рабочем каталоге имеют не что иное, как эти два состояния: отслеживаются или не отслеживаются. Отслеживаемые файлы относятся к файлам, которые изначально были включены в систему управления версиями. Они записываются в последний моментальный снимок. После определенного периода работы их статус может быть не обновлен, изменен или помещен во временное хранилище.
Давайте рассмотрим пример, чтобы проиллюстрировать
Когда файл, такой как «a.txt», добавляется в папку проекта, он находится в состоянии отсутствия отслеживания. Неотслеживаемые файлы не могут быть отправлены
Следующий, Используйте git add a.txt, чтобы отслеживать
Затем добавьте content’a ‘в a.txt
Переписывание истории
Введение
В данном обучающем материале описаны различные способы перезаписи и изменения истории в Git. В Git используются несколько способов регистрации изменений. Мы обсудим плюсы и минусы различных способов и покажем примеры работы с ними. В данном обучающем материале описаны некоторые типовые причины перезаписи состояний кода и разъясняется, как избегать ошибок при таких операциях.
Основная задача Git — гарантировать, что вы не потеряете внесенные изменений. Но эта система также предназначена для предоставления вам полного контроля над процессом разработки. В числе прочего вы сами определяете то, как выглядит история вашего проекта. Такая свобода создает и вероятность потери коммитов. Git предоставляет команды для перезаписи истории, но предупреждает, что использование таких команд может привести к потере данных.
Изменение комментария к последнему коммиту Git
Допустим, при выполнении коммита вы допустили ошибку в комментарии к нему. Выполнение этой команды в отсутствие проиндексированных файлов позволяет отредактировать комментарий к предыдущему коммиту без изменения состояния кода.
Изменение файлов после коммита
Не используйте amend для публичных коммитов
Измененные коммиты по сути являются новыми коммитами. При этом предыдущий коммит не останется в текущей ветке. Последствия этой операции аналогичны сбросу (reset) публичного состояния кода. Не изменяйте коммит, после которого уже начали работу другие разработчики. Эта ситуация только запутает разработчиков, и разрешить ее будет непросто.
Обзор
Изменение старых или нескольких коммитов
Для изменения старых или нескольких коммитов используйте команду git rebase для объединения нескольких коммитов в новый базовый коммит. В стандартном режиме команда git rebase позволяет в буквальном смысле перезаписать историю: она автоматически применяет коммиты в текущей рабочей ветке к указателю head переданной ветки. Поскольку новые коммиты заменяют старые, команду git rebase запрещено применять к коммитам, которые стали доступны публично. Иначе история проекта исчезнет.
Изменение файлов после коммита
Несколько комментариев
Каждый стандартный коммит в Git будет содержать комментарий, поясняющий, что было изменено в коммите. Комментарии дают наглядное представление об истории проекта. Во время операции rebase можно выполнить несколько команд для изменения комментариев к коммитам.
Склеивайте коммиты для поддержания чистой истории
Команда склеивания ( s ) позволяет в полной мере понять смысл rebase. Склеивание позволяет указать коммиты, которые нужно объединить в предыдущие коммиты. Таким образом создается «чистая история». Во время перемещения Git будет исполнять указанную команду rebase для каждого коммита. В случае склеенных коммитов Git откроет выбранный текстовый редактор и предложит объединить комментарии к указанным коммитам. Этот процесс можно показать следующим образом:
Обратите внимание, что идентификаторы коммитов, измененных с помощью команды rebase, отличаются от идентификаторов каждого из начальных коммитов. Коммиты с маркером pick получат новый идентификатор, если предыдущие коммиты были переписаны.
Современные решения для хостинга Git (например, Bitbucket) предлагают возможности «автосклеивания» при слиянии. Эти возможности позволяют автоматически выполнять rebase и склеивать коммиты ветки при использовании интерфейса решений для хостинга. Дополнительную информацию см. в разделе «Склеивание коммитов при слиянии ветки Git в Bitbucket».
Обзор
Команда git rebase позволяет изменять историю, а интерактивное выполнение rebase «подчищает» за вами следы. Теперь вы можете совершать и исправлять ошибки, оттачивая свою работу и сохраняя чистую, линейную историю проекта.
Страховка: git reflog
Справочные журналы (reflog) — это механизм, который используется в Git для регистрации обновлений, применяемых к концам веток и другим ссылкам на коммиты. Reflog позволяет вернуться к коммитам, даже если на них нет ссылок из какой-либо ветки или метки. После перезаписи истории reflog содержит информацию о старом состоянии веток и позволяет при необходимости вернуться к этому состоянию. Каждый раз при обновлении конца ветки любым способом (переключение веток, загрузка новых изменений, перезапись истории или просто добавление новых коммитов) в reflog добавляется новая запись. В данном разделе мы рассматриваем команду git reflog и стандартные примеры ее использования.
Использование
Отображается reflog локального репозитория.
Отображается reflog с относительными датами (например, 2 недели назад).
Пример
В приведенной выше команде reflog показан переход из главной ветки в ветку 2.2 и обратно. Отсюда можно выполнить жесткий сброс к старому коммиту. Последнее действие указано в верхней строчке с пометкой HEAD@ <0>.
Если вы случайно переместитесь назад, reflog будет содержать главный коммит, указывающий на (0254ea7) до случайного удаления вами 2 коммитов.
При использовании команды git reset можно вернуть главную ветку к более раннему коммиту. Это страховка на случай непреднамеренного изменения истории.
Необходимо отметить, что reflog только предоставляет страховку на тот случай, когда изменения попали в коммит в локальном репозитории, и что в нем отслеживаются только перемещения концов веток репозитория. Кроме того, записи reflog имеют определенный срок хранения. По умолчанию этот срок составляет 90 дней.
Резюме
В данной статье мы рассмотрели несколько способов изменения истории Git и отмены изменений в Git. Мы вкратце рассмотрели процесс git rebase. Вот основные заключения.
Узнайте больше об описанных командах на соответствующих страницах:
Git для начинающих. Урок 4.
Коммиты и история коммитов
Работа с файлами
Видеоурок. Часть 1. Практика, основы работы с коммитами и историей коммитов
Видеоурок. Часть 2. Практика, дополнительные приемы и фишки
Видеоурок. Часть 3. Общие наблюдения и советы. Как делать «хорошие» коммиты
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Что такое коммит
По-научному это сохранение состояния, фиксация или слепок изменений.
Как сделать коммит
Представим, что мы добавляем блок учеников на сайт. Добавляем новую разметку в index.html и новые стили в main.css. Чтобы сохранить изменения, нужно их закоммитить. Но предварительно сообщить git, какие именно файлы мы хотим положить в коммит. Команда git add добавляет (или подготавливает) файлы к коммиту. Можно добавить файлы по отдельности, вот так
Добавлять все файлы сразу удобно, но стоит всегда внимательно проверять, точно ли мы хотим добавить в коммит все измененные файлы. Если ошиблись и какой-то файл добавлять в коммит не нужно, то можно исключить этот файл из подготовленных.
Создаем сам коммит
Состояние файлов в git. Измененные и подготовленные файлы
Подготовленные файлы отличаются от измененных тем, что они «подготовлены» к коммиту, то есть будут добавлены в следующий коммит.
git add filename добавляет или подготавливает файл к коммиту.
git reset filename удаляет файл из подготовленных к коммиту.
Содержимое файлов при этом не меняется. Один файл может одновременно находиться и в измененных, и в подготовленных. Это происходит, если мы добавили файл, но не закоммитили и продолжили делать в нем измения.
Из чего состоит коммит
Каждый коммит имеет
Как добавить файлы и сделать коммит одной командой
Отслеживаемые и неотслеживаемые файлы
История коммитов, git log
Все коммиты можно посмотреть в истории коммитов. История хранит все данные обо всех коммитах проекта. Показывается история командой
История включает в себя все сведения о коммитах: хэш, автор, дата и список изменений. Список изменений смотреть командой git show по хэшу коммита
Если мы сделали коммит, но хотим поправить его commit message
Эта команда перезапишет сообщение последнего коммита. Это перезаписывание истории, операция опасная. Лучше делать ее только до того, как отправили коммит на сервер (push разберем через урок)
Откат коммитов, git revert
Если мы сделали неверный коммит и хотим откатить изменения, сделанные в нем, то поможет команда git revert
Работа с файлами
При работе с файлами нужно учесть, что новые файлы git отправляет в неотслеживаемые. Поэтому при добавлении нового файла стоит сначала его закоммитить, а потом вносить изменения, чтобы они были доступны через git diff
При обычном переименовании файла в файловом менеджере или командой mv git сначала показывает 2 файла: старый удаленный и новый неотслеживаемый. Чтобы git понял, что этот файл именно переименованный, нужно сначала добавить эти файлы в подготовленные к коммиту
Тогда при команде git status файл будет отображаться именно как переименованный
Можно избежать этого промежуточного состояния, если переименовать файл в командной строке таким образом
Тогда файл будет сразу отображаться, как переименованный. То же самое с удалением файла
Командная строка vs IDE
Работа в PhpStorm продемонстрирована в первых двух частях видео.
Как и в прошлом уроке мы видим, что некоторые вещи удобнее делать в IDE. Например, процесс добавления файлов (git add) в PhpStorm при создании коммита почти не привлекает внимания. Но важно понимать, что такое git add и зачем он нужен. И что любая IDE под капотом все равно выполняет базовые команды git. Просто для нас предоставляется удобная обертка, чтобы мы больше сосредоточились на самом проекте, а не на git.
Наблюдения и советы при работе с коммитами
В каждой команде свои правила и соглашения. Но я приведу общие советы и размышления, которые помогут в любом проекте
Используйте удобные инструменты в IDE, но не забывайте командную строку. В ней вы лучше будете понимать, как устроен git, как он работает
Хорошие и плохие коммиты
С точки зрения git коммиты не бывают плохими и хорошими. Но есть удачные и неудачные подписи к коммитам с точки зрения наших коллег. Несколько примеров
Добавлен файл VipClient
Работа с vip-клиентами вынесена в отдельный класс
По первому коммиту можно предположить, что в VipClient мы скорее всего работаем с ВИПами. Во втором коммите это точно понятно, плюс дополнительная информация, что это отдельный класс.
Поправлены стили в main.css
Рефакторинг стилей в main.css
Первый коммит говорит о правке стилей, но непоянтно, что именно поправлено. Бага? Новые значения? Изменен цвет текста по рекомендации дизайнера? Второй коммит ясно указывает, что это рефакторинг
Маленький фикс
Исправлена опечатка в заголовке title страницы «О компании»
Коммит «маленький фикс» даже приблизительно не говорит, в чем он заключается. Второй коммит дает полное представление
Немного о философии коммитов
Концепция коммитов заставляет если не менять подход к разработке, то по-другому к ней относиться. С git нам приходится не просто писать код, а планировать его написание. Планировать задачи, над которыми мы работаем. Декомпозировать задачи, то есть разбивать их на небольшие части.
Мы больше думаем о том, что мы работаем не одни, а в команде. История коммитов общая для всего проекта. Чем лучше мы научимся формировать и подписывать коммиты, тем легче будет ориентироваться в истории нам самим и нашим коллегам.
В любом проекте важны не только код и его структура, но и история коммитов и хорошие commit message.
На этом все. В следующем уроке мы будем больше работать с историей коммитов и посмотрим различные варианты использования команды git log
Работаем с Git, основные команды для начинающих
Кто вносил изменения в код можно определить по имени пользователя git. Для этого сообщим git свое имя и email-адрес. Для этого введите:
После инициализации каталога будет выведено соответствующее сообщение:
$ git add
Для этого понадобится выполнить команду:
$ git status
Чтобы зарегистрировать добавление вышеприведенных файлов необходимо выполнить следующую команду:
–a означает: добавить все изменения в индекс до передачи.
-m : сообщение.
Подтверждение с описанием выполненных действий.
Мы сделали «снимок кода». Теперь мы можем редактировать файлы и регистрировать наши изменения.
$ git stash
$ git stash list
Чтобы просмотреть все сохраненные, но не зарегистрированные изменения понадобится следующая команда:
На изображении у нас одно незарегистрированное изменение. В самом файле эти изменения не будут отображены.
$ git stash pop
Восстановить же изменения поможет следующая команда:
$ git merge
Ветвление
Ветка позволяет отделить работу, например, над каким-то компонентом от основного кода сайта.
$ git checkout –b
Чтобы создать новую ветку выполните команду:
git init (инициализируем git реп-й)
Чтобы проинициализировать Git репозиторий введите команду:
git status (Проверяем статус)
Комнада, выводяюща статус репозитория, чтобы увидеть в каком состоянии находится наш проект:
git add (добавляем файл)
Чтобы сообщить Git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью:
Сейчас git отслеживает наш файл test.txt. Давайте выполним
снова, чтобы понять, что изменилось!
git commit (фиксируем изменения)
Чтобы сохранить изменения на данном этапе мы выполним команду создания коммита и передадим ей в качестве аргумента сообщение, описывающие изменения, сделанные в этом коммите.
Используем маску
К счастью, у нас есть возможность добавить все файлы, используя шаблон. Не забывайте про кавычки!
git commit –a –m ”new comment here”
Коммитится только то, что проиндексировано. Индексирование происходит функцией add (она и добавляет файлы и индексирует их).
Коммит идет не сразу: файлы, которые находятся под присмотром ГИТ необходимо проиндексировать (то есть если нам нужно сделать коммит для 1-файла, то мы помещаем его в индекс и закоммитится только он). С помощью ключа –a мы индексируем ВСЕ файлы и, соответственно, сразу выполняем коммит (например,
—amend
Эта команда берет область индексирования (add) и включает в коммит всю обнаруженную там информаци. Например,
Второй коммит заменит результат первого и в итоге останется 1 коммит
Работаем с GitHub
Зарегистрируйтесь на GitHub. Создайте репозиторий.
Чтобы разместить наш локальный репозиторий на GitHub, мы должны добавить удаленный репозиторий.
Эта команда принимает имя удаленного репозитория и его URL. В нашем случае это https://github.com/try-git/try_git.git
Выполняем команду с указанными аргументами:
git remote add origin https://github.com/try-git/try_git.git
Плюсы и минусы bitbucket.org и GitHub
На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.
Процесс разработки:
Эта команда показывает имя удаленного репо, если такой имеется в наличии.
Ключ –v показывает путь к удаленному репо.
Подробно о любой команде можно узнать:
Коммитим и пушим на GitHub (global настройки matching и simple)
Если мы выполнима для настройки глобального конфига следующую команду:
То по команде git push произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.
В данном случае протолкнется лишь текущая ветка.
git remote (прсматриваем уд. реп.)
Команда git remote позволяет просмотреть удаленные репозитории
git remote add (добавляем уд. реп.)
Добавление удаленных репозиториев под короким именем:
git remote add [сокращенное имя] [url]
В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master
Иниц. пустой реп.
Добавляем реп.
извлекаем все данные (.git)
и стягиваем ветку master из реп. kuku
git remote show (получаем инфо. об уд. реп.)
Команда git remote show [имя удал. реп.] позволяет просмотреть дополнительную информацию о конкретном удал. реп.
git fetch (извлечение данных из уд. реп.)
Извлечение данных из уд. реп. выполняется командой:
После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта
git push (проталкиваем изменения)
где origin – это куда отправляем (удаленный репозитарий), а
master это то, что отправляем (в нашем случае master ).
git pull (стягиваем изменения)
Давайте представим, что прошло какое-то время. Мы пригласили других людей в наш проект, они забрали наши изменения в свои локальные репозитории и внесли свои изменения, запушили их. Мы можем проверить изменения на GitHub и спуллить их с помощью команды:
git pull origin master
Забираем изменения из ветки ( master ) на удаленном сервере ( origin ) и проводим слияние с активной веткой.
git diff, git diff HEAD
Команда git diff показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.
Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды
git reset (Откатываем изменения/удаляем файлы из промежуточной области)
git reset octofamily/octodog.txt
git log (информация о последних коммитах)
Иногда просто хочется вернуться назад и забыть все изменения до определенного момента, потому что все они были неправильными. В таком случае Для просмотра изменений (истории коммитов) используется команда
покажет список последних коммитов и их хеши SHA1.
На самом верху мы видим самый последний коммит. Функция log очень богатая – позволяет смотреть, что было до и что было после, у git хорошая помощь (faq), чтобы просмотреть все возможности log можно воспользоваться командой:
Например, мы можем выводить историю в более удобном формате:
Ограничиваем коммиты по времени:
—stat используется для получения краткой статистики по каждому коммиту.
—graph добавляет графику с историей ветвлений и слияний
git checkout (Отмена изменений)
Файла был удален из промежуточной области. Но сам файл все еще находится в проекте! Файлы могут быть возвращены в состояние последнего коммита с помощью команды:
Для указания коммита достаточно первых нескольких символов его хеша ( 82f5 ), но можете скопировать и весь хеш.
git checkout (получаем уд. ветку)
Для получения собственной копии [имя_ветки] (из уд. реп.) можно воспользоваться командой :
(?) или просто git checkout [имя_ветки] ; но тут главное, чтобы [имя_ветки] присутствовала в уд. реп.
git branch (создаем ветку)
Когда разработчики работают над новой фичей или багом, они обычно создают копию (или ветку) кода проекта, в которую они могут коммитить независимо. Когда разработка завершена, изменения из этой копии (ветки) нужно влить (вмержить) обратно в основную ветку проекта.
Давайте создадим новую ветку и назовем ее clean_up :
git branch clean_up
Данная команда не обращается к серверу, а а берет локальные данные из кэша.
Для получений актуальной информации как на удаленном так и на локальном серверах можно использовать команду:
git rm (удаляем файлы)
merge (смержим в текущую ветку другую)
git merge clean_up
git clone
$ mkdir epicgame & cd epicgame
$ git init
$ git remote add
$ git clone
rejected
Конфликты
Сообщение о конфликте:
В статусе ( git st ) появляется блок:
То есть в самом файле:
Это указатель на тот commit, с которым мы сейчас работаем. Нужно выбрать или оставить свои изменения ( // Fry comment ) или оставить строку пользователя Bender ( // Bender comment ).
Разные полезные команды:
Добавляем пользователя:
(задаем email глобально)
(данные о гите и о пользователе; хранятся в c:\users\name_user\.gitconfig )
Игнорирование файлов:
В самом файле указываем игнорирование, например:
$ git rm
СВОЙ РЕДАКТОР ДЛЯ КОММЕНТАРИЕВ
Без ключа –m откроется редактор vim ( 😡 – означает сохранить и выйти).
Поменяем редактрор по умолчанию (vim), он будет открываться в том случае, если мы не прописываем комментарий в командной строке.
Изменения можно проверить в C:\Users\name_user\.gitconfig
ВЕТКИ ($ git checkout –b new_branch)
Создаем ветку new_f и тут же переходим в нее.
С использованием –v показывает ветки с последними коммитами.
merge
Указываем какой утилитой будем разрешать конфликты
Далее в случае наличия CONFLICT прописываем (этим мы запускаем утилиту):
Подробное руководство по Git
Основные сообщения в консоли:
Снимки состояний как основа
Большинство систем хранят информацию как список изменений, связанных с файлами (Subversion).
GIT же делает снимок файлов в конкретный момент времени и сохраняется ссылка на этот снимок. Для увелечения эффективности на неизмененные файлы делается ссылка на их раннее сохраненные версии.
Контрольная сумма
3 состояния для файлов
Файлы в GIT могут находиться в 3 состояниях:
Как строится процесс работы в Git
Настройки
Данную информацию следует указать обязательно, так как она будет включаться во все ваши коммиты:
Узнаем подробности о том, как работает команда, например, log :
Пример файла .git/config
Псевдонимы (алиасы) в GIT
Команда git config позволяет создавать псевдонимы:
.gitignore
Игнорируем имена файлов:
Звезда означает фрагмент в имени:
Указываем диапозон (для игнорирования файлов):
Игнорируем от корня проекта:
При этом данные конструкции работают одинаково:
** используются, чтобы обозначить произвольное количество фрагментов пути:
! используется, когда требуется игнорировать все кроме чего-либо конкретного:
Жизненный цикл состояния файлов
Основные команды в Git
git init
Чтобы проинициализировать (создать) пустой Git репозиторий введите команду:
git clone
Получаем копию существующего репозитория, клонировав удаленный, например, с gitHub.
Эта команда аналогично предыдущей, но все файлы перемещаются в папку [name_folder]
git status
Команда, показывающая статус репозитория, чтобы увидеть в каком состоянии находится наш проект:
git add (Отслеживание новых файлов)
Данная команда может работать как «Добавление файлов к проекту» (добавляем в индекс).
Чтобы сообщить git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью команды:
git add (Индексация изменённых файлов)
Также данная команда может работать как «Добавление содержимого к следующему коммиту».
Давайте модифицируем файл, уже находящийся под версионным контролем. Чтобы проиндексировать его, необходимо выполнить команду:
git reset (Отмена индексирования)
Примечательно, что команда git status покажет, как отменить индексирование:
git commit
При каждой фиксации мы сохраняем снимок проекта, к которому можно вернуться в любой момент, или чтобы сравнить с текущим состоянием.
git rm
Чтобы удалить директорию:
git amend (Изменение последнего коммита)
Если вы что-то не сделали в последнем коммите, то отредактировать его не сложно. Все, что нужно это добавить изменения в индекс обычным образом:
Эта команда берет индексированный файлы и включает в коммит всю обнаруженную там информацию.
Чтобы изменить название коммита выполните:
git checkout (Отмена изменение в файле)
С подсказкой опять поможет команда git status :
Итак, файлы могут быть возвращены в состояние последнего коммита с помощью команды:
git checkout (Получаем предыдущие версии файлов, не трогая остальные)
Допустим нам нужно вернуть версию файла, которая была два коммита назад. При этом нам требуется откатить лишь один файл.
Восстановим файл index.html на момент конкретного коммита ( 0b335 ):
Или откатим версию файла до состояния из текущего коммита (откатим изменения, которые нас не устраивают):
git clone
Очистка проекта от всех изменений (git clean)
Команда git clean предназначена для удаления только неотслеживаемых файлов и директорий
Просмотр (diff)
Команда git diff используется для сравнения коммитов или файлов.
Сравниваем с текущим состоянием
Покажем изменения в рабочей директории с момента последнего коммита:
Но при этом обе приведенные выше команды игнорируют неотслеживаемые файлы.
Ограничим сравнение по пути:
Сравним состояние 2-х коммитов
Сравним состояние 2-х веток
сравним, что сделано в feature по сравнению с веткой master :
Сравниваем файлы из разных коммитов
Сравнение по словам
Чтобы включить отличия по словам:
Удаленный репозиторий
git remote (прсматриваем уд. реп.)
Команда git remote позволяет просмотреть удаленные репозитории
git remote add (добавляем уд. реп., для работы локально)
Добавление удаленных репозиториев под коротким именем:
— теперь вместо полного URL-адреса в командную строку можно вводить имя alias_repo
В уже сущест. реп. добавляем реп. сторонний и стягиваем из него ветку master :
git fetch (Извлечение данных из уд. реп.)
Извлечение данных из удаленного репозитория выполняется командой:
После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта.
git push (проталкиваем изменения на уд. сервер)
Отправляем изменения в удаленный репозиторий:
Отправим ветку master на удаленный репозиторий master :
Или, что тоже самое:
Отправим ветку master на удаленный репозиторий masterB :
git push (удаляем удаленные ветки)
Удаляем ветку в удаленном репозитории:
git pull (скачиваем изменения)
git remote show (получаем инфо. об уд. реп.)
Удаленные ветки
Если вам потребуется своя локальная ветка ( name_branch ), аналогичная удаленной ветки, то можно воспользоваться командой:
Или создадим локальную ветку, чье имя будет отличаться от имени удаленной ветки:
Текущая ветка начнет следить за удаленной origin/test-git
Чтобы увидеть актуальные ветки наблюдения:
Ветвление
Ветки в Git всего лишь указатели на предыдущие коммиты, перед каждым коммитом указатель автоматически сдвигается вперед.
git branch (создаем ветку)
При создании новой ветки создается новый указатель, который, как отмечалось выше, автоматически сдвигается вперед (при каждом коммите).
Указатель HEAD указывает на текущую локальную ветку.
Узнаем указатели веток:
Обратите внимание. Узнаем указатели веток, историю коммитов, точки расхождения:
git branch (управление ветками)
Отобразим все ветки:
* указывает на ветку с указатедем HEAD(текущая).
Отобразим ветку с информацией о коммите:
Ветки слитые с текущей:
Ветки не слитые с текущей:
git checkout (смена веток)
Перейдем в существующую ветку:
Создадим и сразу перейдем в нее:
Переносим коммиты в другую ветку или Передвигаем (Откатываем) коммиты
Создадим ветку ( feature ) от текущей:
Теперь нам нужно передвинуть master на то количество коммитов, которое нам необходимо.
Или, пусть master указывает туда же куда и new_f :
Создадим ветку master на указанном коммите и переключимся на нее:
git merge
Объединяем текущую локальную ветку с удаленной:
Создаем новую ветку на основе изменений в другой ветке
Бывают ситуации, когда вы начинаете работать на какой-либо ветке, но изменения становится настолько большими, что вам хотелось бы перенести их в новую ветку. Это сделать довольно просто:
—ours к файлу
Допустим, после merge ветки feature в master в файле index.html появились конфликты, при этом мы уверены, что код на ветке master правильный. Чтобы разрешить конфликты в этом случае нам поможет команда:
—theirs к файлу
Если нам нужно взять версию из сливаемой ( feature ) ветки:
—merge к файлу
Вернуться к версии с маркерами конфликта:
Отменяем слияние и сбрасываем конфликты
reflog
Для адекватного вывода reflog используют команду, например, для ветки master :
Или без аргументов выведет reflog для HEAD :
Зачем нужен reflog:
Восстановим ветку по коммиту (под windows потребуются »):
Выводим reflog с датой:
2. Переходим на предыдущую ветку, с которой был checkout на текущую ветку:
Как работает: по reflog ищет ближайший checkout на текущую ветку.
git stash (сохраняем изменения)
Иногда возникает ситуация, когда вы работаете на одной ветке и вам срочно нужно переключиться на другую ветку, при этом регистрировать изменения нежелательно.
Для таких случае существует команда stash. Команда stash собирает незакоммиченные изменения, удаляет их из файлов и в специальном виде архивирует в Git.
git stash pop
Восстановить(вернуть) изменения поможет следующая команда:
Ошибки при git stash
Иногда мы можем сделать git stash pop не на той ветке, где сохранили изменения, это может привести к ошибке.
Просмотр истории и старых версий
git log
Для просмотра изменений (истории коммитов) используется команда
, которая покажет список последних коммитов и их хеши SHA1. Первыми показываются последние коммиты.
Или можно использовать
Или для конкретной ветки
У git log множество возможностей, например, мы можем выводить историю в более удобном формате:
Ограничивать коммиты по времени:
Показывать разницу, внесенную каждым коммитом:
Выведем коммиты достижимые из всех ссылок:
Просмотр коммитов (кроме)
Просмотр коммитов (И различий) по файлу
Выведем коммиты, в которых менялся файл index.html :
Выведем конкретные различия, в которых менялся файл index.html :
Флаги-фильтры для log (поиск изменений в файлах)
Поиск всех коммитов в описании которых есть слово word :
Найдем вызов функции:
Найдем объявление функции:
Не забывайте, что function doAny\( это регулярное выражение.
Выводи все коммиты с n-й по n-ю строку, например, выведем с 3-й по 7-ю строку:
Или найдем фрагмент кода по регулярному выражению:
Возможность очень полезная, так как позволяет отследить изменения любого блока кода в файле.
git show
git show используется для того чтобы проанализировать коммит, по хэшу:
git show (Смотрим на коммит родителя/предыдущий)
смотрит на 2 коммита вниз (
Тоже самое можно указать через число:
Как посмотреть на файл в предыдущем коммите
Флаг HEAD можно заменить @ :
Посмотрим на файл index.html в ветке master :
Смотрим на текущую (проиндексированную) версию файла
Ищем коммит по описанию (слову)
Кто написал эту строку? git blame
Вывести информацию о том, кто написал каждую строку в package.json:
Сократим дату и выведем только те строки, которые нас интересуют (например, с 5-й по 8-ю):
git reset
Как вернуть коммит, убранный reset
Подведем итог: мягкий reset отменяет коммит, но оставляет все подготовленные для коммита данные.
Передвигает ветку, сбрасывает индекс, но не трогает рабочую директорию. То есть изменения останутся в рабочей директории, но не будут проиндексированы. Пример использования:
reset переносит ветку, но так как HEAD указывает на текущий коммит, то ветка переносится туда же, где и сейчас, то есть ничего не происходит. Однако есть второй полезный момент: сброс индекса на состояние соответствующего коммита ( HEAD ), сами изменени останутся в рабочей директории, то есть очистка от всех изменений.
Для замены коммита запускаем:
Конфликты в Git
Команда git status позволяет увидеть файлы с конфликтами.
cherry-pick
Команда cherry-pick используется, чтобы переместить какой-либо коммит (по хешу) из одной ветки в другую.
Например, поместим коммит 268510c2f в ветку master (текущая).
rebase
Перенос веток
Отказ от переноса
Чтобы отказаться от переноса (например, ваш rebase остановился на конфликте) выполните команду:
Чтобы пропустить коммит при переносе, например, rebase остановился на конфликте, вы можете выполнить команду:
Отмена rebase
Отмена rebase после того как rebase завершился.
Или (что более надежно).
Работаем с bitbucket.org
1. кликаем по this repository Fork
3. создадим ветку (на основе удаленной ветки test-git )
4. и внесем в нее какие-либо изменения
5. Фиксация изменений
6. Отправка новой ветки в ветку на bitbucket
Далее переходи на bitbucket
7. Находим нужную ветку и делаем Create pull request (запрос на включение): где вы можете выбрать как проекты, так и ветки куда пойдет запрос на слияние.
Владелец проекта может выделить часть кода и написать к нему комментарий. Как только это произойдет пользователь, открывший запрос на включение получит уведомление. Пользователь вносит правки и отправляет его.
8. Принимаем pull request
Полезные приемы
Как в git заменить ветку master полностью другой веткой?
Я имею две ветки в моем репо:
2. seotweaks (создана от master )