Git status что делает

A3.3 Приложение C: Команды Git — Основные команды

Всего несколько команд нужно для базового варианта использования 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

Команда git diff используется для вычисления разницы между любыми двумя Git деревьями. Это может быть разница между вашей рабочей копией и индексом (собственно git diff ), разница между индексом и последним коммитом ( git diff —staged ), или между любыми двумя коммитами ( git diff master branchB ).

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

О том как использовать эту команду для проверки на проблемы с пробелами с помощью аргумента —check можно почитать в разделе Правила создания коммитов главы 5.

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

В разделе Продвинутое слияние главы 7 показано использование опции -w для скрытия различий в пробельных символах, а также рассказано как сравнивать конфликтующие изменения с опциями —theirs , —ours и —base .

Использование этой команды с опцией —submodule для сравнения изменений в подмодулях показано в разделе Начало работы с подмодулями главы 7.

git difftool

Команда git difftool просто запускает внешнюю утилиту сравнения для показа различий в двух деревьях, на случай если вы хотите использовать что-либо отличное от встроенного просмотрщика git diff .

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

git commit

Команда git commit берёт все данные, добавленные в индекс с помощью git add , и сохраняет их слепок во внутренней базе данных, а затем сдвигает указатель текущей ветки на этот слепок.

Вы познакомились с основами модели коммитов в разделе Коммит изменений главы 2. Там же мы продемонстрировали использование опций -a для добавления всех изменений в индекс без использования git add , что может быть удобным в повседневном использовании, и -m для передачи сообщения коммита без запуска полноценного редактора.

В разделе Операции отмены главы 2 мы рассказали об опции —amend , используемой для изменения последнего совершённого коммита.

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

Мы показали вам как подписывать ваши коммиты, используя опцию -S в разделе Подпись коммитов главы 7.

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

git reset

Команда git reset , как можно догадаться из названия, используется в основном для отмены изменений. Она изменяет указатель HEAD и, опционально, состояние индекса. Также эта команда может изменить файлы в рабочем каталоге при использовании параметра —hard , что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его.

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

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

Мы использовали git reset —hard чтобы отменить слияние в разделе Прерывание слияния главы 7, там же было продемонстрировано использование команды git merge —abort для этих целей, которая работает как обёртка над git reset .

git rm

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

Мы немного разобрались с этой командой в разделе Удаление файлов главы 2, показали как удалять файлы из рабочего каталога и индекса и только из индекса, используя флаг —cached .

Ещё один вариант использования git rm приведён в разделе Удаление объектов главы 10, где мы вкратце объяснили как использовать опцию —ignore-unmatch при выполнении git filter-branch , которая подавляет ошибки удаления несуществующих файлов. Это может быть полезно для автоматически выполняемых скриптов.

git mv

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

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

git clean

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

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

Git для начинающих. Урок 3.
git status и git diff

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

Создаем тестовый сайт и инициализируем репозиторий

С этого момента мы будем проходить уроки на примере тестового сайта site-git. Проект содержит три файла: index.html, css/main.css и .gitignore. По мере прохождения уроков будем понемногу расширять сайт, вносить изменения и добавлять новые файлы.

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

Создайте на github новый приватный репозиторий site-git. Скачайте архив с файлами сайта и распакуйте содержимое в папку site-git

Обратите внимание на .gitignore

Кроме index.html и main.css в архиве лежит еще скрытый файл .gitignore. Это файл, в котором прописаны папки и файлы, которые git не отслеживает. Подробнее о .gitignore мы поговорим во второй части курса

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

 $ cd site-git $ git init $ git add . $ git commit -m "first commit" $ git remote add origin git@github.com:Webdevkin/site-git.git $ git push -u origin master 

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

Вводная

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

Git позволяет легко отслеживать все изменения, видеть добавленные и удаленные файлы в проекте, а также изменения в самих файлах. Если мы изменим хоть один символ в коде, git заметит это изменение и уже не потеряет. Команды git status и git diff (от слова difference — разница) позволяют отслеживать все изменения в проекте.

git status

Эта команда показывает список измененных файлов

 $ git status 

Также git status выводит некоторую дополнительную информацию, которую мы изучим позже.

В PhpStorm — окно Version Control (Вызов окна — Alt+9)

git diff

Это команда для просмотра изменений в файлах. В терминале мы видим добавленные и удаленные строки. То есть если в строке изменился хоть один символ, то git diff покажет 2 строки: одну удаленную, другую — добавленную.

Просмотр всех изменений

 $ git diff 

Просмотр изменений в отдельном файле

 $ git diff index.html 

Изменения в PhpStorm

В онке Version Control мы сразу видим список измененных файлов. Чтобы посмотреть изменения в конкретном файле, нужно кликнуть на него и нажать Crtl+D (diff). В окне difference видны не только добавленные и удаленные строки, но и изменения в отдельных строках.

Плюсы PhpStorm

• список измененных файлов можно держать открытым, не обязательно набирать git status
• измененные строки видны сразу же в редакторе кода
• просмотр изменений визуально нагляднее, чем в терминале (показываются даже изменения в отдельных строках)
• проще откатить отдельные изменения

PhpStorm отлично интегрируется с git. Конечно, не он один. Некоторые продвинутые редакторы кода тоже могут работать с git. Вы можете посмотреть, как реализована поддержка git, например, в sublime, но это далеко не так удобно, как в IDE от JetBrains. Это не реклама, а просто совет использовать удобные инструменты.

PhpStorm платная программа (9 $/месяц на январь 2020 года), но это затраты, которые окупятся. Рекомендую.

Поддержка git в Sublime Text 3

В Sublime Text 3 ситуация несколько изменилась — поддержка git улучшилась. Подробнее рассмотрим работу с git в sublime во второй части курса

На этом все. В конспекте информации мало, только основные команды, поэтому смотрите видеоурок. Там все нагляднее и понятнее.

В следующем уроке мы познакомимся с коммитами и научимся с ними работать.

Спасибо за внимание и до встречи!

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
• 16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
• 24. Мердж-реквесты
• * 25. Форки

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

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

С англ. status в данном случае так и переводится — «статус». То есть Вы можете посмотреть текущее состояние Вашего репозитория.

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

• Является ли папка Git репозиторием («есть» ли в ней Git) или нет. Например, если мы зайдем на Рабочий стол и напишем «git status»:

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

• Если же мы находимся в Git папке, увидим что-то подобное:

• Мы можем просматривать, какие файлы были добавлены или изменены. Например, если у нас появится новый файл, он будет отображаться красным:

• Если Git начнет за ним «следить», файл станет зеленым:

• Если мы поменяем файл file.txt (например, допишем одну строчку), то git status об этом нам сообщит (напротив файла написано modified — «изменено»):

• Если файл удалить, это тоже отобразится (напротив файла написано deleted — «удалено»):

Отлично! �� Теперь Вы знаете, что делает git status. Это важная команда — ее стоит запомнить!

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

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

• ← Команда git clone
• Основы работы с командной строкой (Терминалом) на Mac OS X →

Сведения о GIT

Узнайте о системе управления версиями, Git и о том, как она работает с GitHub.

Сведения об управлении версиями и GIT

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

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

• какие изменения были внесены;
• кто внес изменения;
• какие изменения были внесены;
• зачем потребовались изменения.

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

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

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

Сведения о репозиториях

Репозиторий или проект GIT включает в себя полный набор файлов и папок, связанных с проектом, а также журнал изменений каждого файла. Журнал файла представлен в виде моментальных снимков на определенные моменты времени. Эти снимки называются фиксациями. Фиксации можно упорядочивать по нескольким линиям разработки, называемым ветвями. Так как GIT — распределенная система управления версиями, репозитории являются автономными единицами и любой пользователь, имеющий копию репозитория, может получать доступ ко всей базе кода и ее истории. С помощью командной строки или других удобных интерфейсов возможны также следующие действия с репозиторием GIT: взаимодействие с журналом, клонирование репозитория, создание ветвей, фиксация, слияние, сравнение изменений в разных версиях кода и многое другое.

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

Принципы работы GitHub

GitHub служит для размещения репозиториев GIT и предоставляет разработчикам средства для поставки более качественного кода: функции командной строки, проблемы (цепочки обсуждений), запросы на вытягивание, проверка кода и коллекция бесплатных и платных приложений в GitHub Marketplace. С такими уровнями совместной работы, как поток GitHub, сообществом 100 миллионов разработчиков и экосистемой с сотнями интеграции, GitHub изменяет способ создания программного обеспечения.

GitHub позволяет интегрировать совместную работу непосредственно в процесс разработки. Работа организована по репозиториям, в которых разработчики могут устанавливать требования или давать указания участникам команды. Затем, используя поток GitHub, разработчики просто создают ветвь для работы с обновлениями, фиксируют изменения, чтобы сохранять их, открывают запросы на вытягивание, чтобы предлагать и обсуждать изменения, и выполняют слияние запросов на вытягивание после их согласования. Дополнительные сведения см. в разделе «AUTOTITLE».

Сведения о планах и затратах на GitHub см. в разделе GitHub Pricing. Сведения о том, как GitHub Enterprise сравнивается с другими параметрами, см. в статье Сравнение GitHub с другими решениями DevOps.

GitHub и командная строка

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

Работая с GIT, разработчики используют определенные команды для копирования, создания, изменения и объединения кода. Эти команды можно выполнять непосредственно из командной строки или с помощью приложения, например GitHub Desktop. Ниже приведены некоторые распространенные команды для работы с GIT.

• git init — инициализирует новый репозиторий GIT и начинает отслеживание существующего каталога. В существующий каталог добавляется скрытая вложенная папка, в которой размещается внутренняя структура данных, необходимая для управления версиями.
• git clone — создает локальную копию проекта, который уже существует удаленно. Клон включает в себя все файлы проекта, журнал и ветви.
• git add — подготавливает изменение. GIT отслеживает изменения в базе кода разработчика, но для включения изменений в журнал проекта необходимо подготавливать их и создавать моментальные снимки. Эта команда выполняет первую часть этого двухэтапного процесса, то есть подготовку. Все подготовленные изменения станут частью следующего моментального снимка и журнала проекта. Раздельные подготовка и фиксация дают разработчикам полный контроль над историей проекта без необходимости изменять подход к написанию кода и работе в целом.
• git commit — сохраняет моментальный снимок в журнале проекта и завершает процесс отслеживания изменений. Иначе говоря, фиксация похожа на создание фотографии. Все, что было подготовлено с помощью команды git add , станет частью моментального снимка при использовании git commit .
• git status — выводит состояние изменений: не отслеживаются, изменены или подготовлены.
• git branch — показывает ветви, с которыми ведется локальная работа.
• git merge — выполняет слияние линий разработки. Эта команда обычно применяется для объединения изменений, внесенных в двух разных ветвях. Например, разработчик выполняет слияние, когда необходимо объединить изменения из ветви функции с главной ветвью для развертывания.
• git pull — применяет к локальной линии разработки обновления из удаленного аналога. Разработчики используют эту команду, если коллега выполнил фиксации в ветви удаленного репозитория и эти изменения нужно отразить в локальной среде.
• git push — обновляет удаленный репозиторий с учетом фиксаций, выполненных в ветви локально.

Пример. Участие в существующем репозитории

# download a repository on GitHub to our machine # Replace `owner/repo` with the owner and name of the repository to clone git clone https://github.com/owner/repo.git # change into the `repo` directory cd repo # create a new branch to store any new changes git branch my-branch # switch to that branch (line of development) git checkout my-branch # make changes, for example, edit `file1.md` and `file2.md` using the text editor # stage the changed files git add file1.md file2.md # take a snapshot of the staging area (anything that's been added) git commit -m "my snapshot" # push changes to github git push --set-upstream origin my-branch 

Пример. Создание нового репозитория и его публикация в GitHub

Сначала необходимо создать репозиторий на GitHub. Дополнительные сведения см. в разделе «AUTOTITLE». Не инициализируйте репозиторий с помощью файла сведений, GITIGNORE или файла лицензии. Этот пустой репозиторий ожидает добавления кода.

# create a new directory, and initialize it with git-specific functions git init my-repo # change into the `my-repo` directory cd my-repo # create the first file in the project touch README.md # git isn't aware of the file, stage it git add README.md # take a snapshot of the staging area git commit -m "add README to initial commit" # provide the path for the repository you created on github git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY-NAME.git # push changes to github git push --set-upstream origin main 

Пример. Участие в существующей ветви на GitHub

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

# change into the `repo` directory cd repo # update all remote tracking branches, and the currently checked out branch git pull # change into the existing branch called `feature-a` git checkout feature-a # make changes, for example, edit `file1.md` using the text editor # stage the changed file git add file1.md # take a snapshot of the staging area git commit -m "edit file1" # push changes to github git push 

Модели совместной разработки

Существует два основных способа совместной работы на GitHub:

1. общий репозиторий;
2. создание вилок и вытягивание.

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

Для проектов с открытым кодом или проектов, в которых могут участвовать любые пользователи, управление отдельными разрешениями может быть непростой задачей. В этом случае удобнее модель на основе вилок и вытягивания, которая позволяет всем, кто может просматривать проект, принимать участие в нем. Вилка — это копия проекта в личной учетной записи разработчика. Каждый разработчик имеет полный контроль над вилкой и может свободно реализовывать исправление или новую функцию. Результаты работы в вилках либо хранятся отдельно, либо переносятся обратно в исходный проект с помощью запроса на вытягивание. Лица, ответственные за проект, могут проверять предлагаемые изменения перед их слиянием. Дополнительные сведения см. в разделе «AUTOTITLE».