Что показывает команда git status

Основные команды

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

git add

Команда git add добавляет содержимое рабочего каталога в индекс (staging area) для последующего коммита. По умолчанию git commit использует лишь этот индекс, так что вы можете использовать git add для сборки слепка вашего следующего коммита.

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

Знакомство с этой командой происходит в разделе Отслеживание новых файлов главы 2.

О том как использовать git add для разрешения конфликтов слияния написано в разделе Основные конфликты слияния главы 3.

В разделе Интерактивное индексирование главы 7 показано как использовать git add для добавления в индекс лишь отдельных частей изменённого файла.

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

git status

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

Мы познакомили вас с этой командой в разделе Определение состояния файлов главы 2, разобрали стандартный и упрощённый формат вывода. И хотя мы использовали git status повсеместно в этой книге, практически все варианты использования покрыты в указанной главе.

git diff

Мы познакомили вас с основами этой команды в разделе Просмотр индексированных и неиндексированных изменений главы 2, где показали как посмотреть какие изменения уже добавлены в индекс, а какие — ещё нет.

Мы показали вам как эффективно сравнивать ветки используя синтаксис git diff A…​B в разделе Определение применяемых изменений главы 5.

git difftool

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

git commit

В разделе О ветвлении в двух словах главы 3 мы более подробно познакомились с тем, что делает команда git commit и почему она делает это именно так.

И наконец мы заглянули внутрь команды git commit в разделе Объекты коммитов главы 10 и узнали что она делает за кулисами.

git reset

В разделе Раскрытие тайн reset, полностью посвящённой этой команде, мы разобрались в деталях её использования.

git rm

Команда git rm используется в Git для удаления файлов из индекса и рабочей копии. Она похожа на git add с тем лишь исключением, что она удаляет, а не добавляет файлы для следующего коммита.

git mv

Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.

Мы лишь вкратце упомянули эту команду в разделе Перемещение файлов главы 2.

git clean

Команда git clean используется для удаления мусора из рабочего каталога. Это могут быть результаты сборки проекта или файлы конфликтов слияний.

Мы рассмотрели множество опций и сценариев использования этой команды в разделе Очистка рабочего каталога главы 7.

Источник

Запись изменений в репозиторий

Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать «снимки» состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.

Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем снимке состояния проекта; они могут быть неизменёнными, изменёнными или подготовленными к коммиту. Если кратко, то отслеживаемые файлы — это те файлы, о которых знает Git.

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

Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, так как вы изменили их с момента последнего коммита. Вы индексируете эти изменения, затем фиксируете все проиндексированные изменения, а затем цикл повторяется.

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Определение состояния файлов

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

Индексация изменённых файлов

Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в CONTRIBUTING.md до коммита. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :

Сокращенный вывод статуса

Игнорирование файлов

Первая строка предписывает Git игнорировать любые файлы заканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут появиться во время сборки кода. Вторая строка предписывает игнорировать все файлы заканчивающиеся на тильду (

Стандартные шаблоны являются глобальными и применяются рекурсивно для всего дерева каталогов.

Чтобы избежать рекурсии используйте символ слеш (/) в начале шаблона.

Чтобы исключить каталог добавьте слеш (/) в конец шаблона.

Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.

Просмотр индексированных и неиндексированных изменений

Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:

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

Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.

Другой пример: вы проиндексировали файл CONTRIBUTING.md и затем изменили его, вы можете использовать git diff для просмотра как проиндексированных изменений в этом файле, так и тех, что пока не проиндексированы. Если наше окружение выглядит вот так:

Используйте git diff для просмотра непроиндексированных изменений

Коммит изменений

Эта команда откроет выбранный вами текстовый редактор.

В редакторе будет отображён следующий текст (это пример окна Vim):

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

Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит ( master ), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.

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

Игнорирование индексации

Удаление файлов

Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции «Changes not staged for commit» (измененные, но не проиндексированные) вывода команды git status :

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

Эта команда удаляет все файлы, имена которых заканчиваются на

Перемещение файлов

В отличие от многих других систем контроля версий, Git не отслеживает перемещение файлов явно. Когда вы переименовываете файл в Git, в нём не сохраняется никаких метаданных, говорящих о том, что файл был переименован. Однако, Git довольно умён в плане обнаружения перемещений постфактум — мы рассмотрим обнаружение перемещения файлов чуть позже.

Таким образом, наличие в Git команды mv выглядит несколько странным. Если вам хочется переименовать файл в Git, вы можете сделать что-то вроде:

и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:

Однако, это эквивалентно выполнению следующих команд:

Источник

Работаем с Git, основные команды для начинающих

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git statusКто вносил изменения в код можно определить по имени пользователя git. Для этого сообщим git свое имя и email-адрес. Для этого введите:

После инициализации каталога будет выведено соответствующее сообщение:

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

$ git add

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

$ git status

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

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

–a означает: добавить все изменения в индекс до передачи.
-m : сообщение.

Подтверждение с описанием выполненных действий.

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Мы сделали «снимок кода». Теперь мы можем редактировать файлы и регистрировать наши изменения.

$ git stash

$ git stash list

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

На изображении у нас одно незарегистрированное изменение. В самом файле эти изменения не будут отображены.

$ git stash pop

Восстановить же изменения поможет следующая команда:

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

$ git merge

Ветвление

Ветка позволяет отделить работу, например, над каким-то компонентом от основного кода сайта.

$ git checkout –b

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

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

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 status

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git statusЧто показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git statusЧто показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git statusЧто показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git statusЧто показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git statusЧто показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Привет! Это одна из статей из руководства «GIT основы: Курс молодого бойца»

Работать с Git можно двумя способоами:

Для чего нужна команда git status

Чтобы освоить Git и пользоваться им через командную строку, Вам необходимо освоить несколько команд. С их помощью Вы будете добавлять файлы, удалить файлы, изменять файлы и т.д. Но иногда Вам нужно будет проверить, сработала ли та или иная команда, или в общем понять, что Вы там «наделали» 🙂 В этом Вам поможет команда git status.

Итак, что можно проверить:

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

выводится сообщение об ошибке («Не является Git репозиторием, а также ни одна из материнских папок не является Git репозиторием»).

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Что показывает команда git status. Смотреть фото Что показывает команда git status. Смотреть картинку Что показывает команда git status. Картинка про Что показывает команда git status. Фото Что показывает команда git status

Спасибо, что были с нами! 🙂

Надеемся, что наша статья была Вам полезна. Можно записаться к нам на курсы по Java на сайте.

Источник

Основы Git

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

Когда я учил Git мне говорили, что в работе мне понадобятся всего 3 команды:

Правда, по сути мне немного слукавили, нужен был ещё как минимум:

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

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

Основная терминология

Работа с Git

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

init

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

clone

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

Данная команда понадобится вам, когда вам нужно добавить файл для кэширования. Давайте разберёмся как это работает:

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

Вы решаете «закоммитить» ваши файлы (сделать сохранение версии, для того чтобы Git запомнил все ваши изменения в файлах и как-то назвал их, для этого есть отдельная команда git commit )

Вы также можете добавить файлы, которые ранее не отслеживались, для того чтобы Git занёс их в свою систему хранения версий и вы могли откатываться на какую-то из версий файла

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

Но, что если вам не хочется вносить все файлы? Тогда вы может использовать следующий синтаксис:

Также мы можем сделать так, чтобы Git искал некоторые названия в дочерних директориях и игнорировал их:

Данная команда поможет, когда нам нужно избавиться от файла, она подобно команде rm удаляет файл из файловой системы и кэша Git, позволяя нам быстро избавиться от файла.

Данный пример удалит файл file.txt из кэша и файловой системы.

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

Данная команда удалит файл из «кэша», но что это значит? Допустим, что мы «закоммитили» (сохранили версию, об этом поговорим вот уже совсем скоро) наш файл, а теперь хотим, чтобы Git считал что мы его удалили, а сами просто оставили его на диске. Для этого и нужна команда выше. Она просто говорит Git: «Слушай, а давай ты просто удалишь этот файл из кэша и не будешь его показывать в репозитории, а я оставлю копию у себя на ПК, ок?»

Таким образом мы можем работать с данным файлом и Git не будет знать что именно в нём мы изменяем, а затем просто можем опять добавить его. Файл будет висеть в состоянии «untracked» (не отслеживается) до тех пор, покуда мы его опять не добавим.

commit

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

Обычно разработчики сохраняют версию программы с помощью данной команды:

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

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

show

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

Выведутся изменения следующим образом:

status

До этого момента мы могли только посмотреть что творилось в предыдущем коммите, однако с помощью git log мы можем посмотреть историю наших коммитов:

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

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

diff

С помощью данной команды мы можем посмотреть на изменения между коммитами. Эта комманда является одной из самых мощных в Git, вам стоит обратить на неё внимание:

Так называемые «ID-коммита» можно взять и вышеприведенной git log

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

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

branch

В Git есть ветки для разделения версий. Если коммит нужен для того, чтобы сделать snapshot (слепок изменений) файлов, то ветки нужны для того, чтобы эти snapshot’ы разделять. У вас может быть ветка

любое другое название

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

Для того чтобы создать новую ветку нужно ввести:

checkout

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

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

merge

Соединение веток не являются сложной темой. Для того чтобы слить текущую ветку с другой нужно ввести:

push

В завершение

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

Если вы хотите больше узнать о веб-разработке, а также о линуксе, то милости прошу в мой блог на телеграм.

Надеюсь данная статья помогла вам чуть лучше узнать Git. Хорошего дня и продуктивной недели!

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *