в какой ситуации надо делать git status
Git для начинающих. Урок 3.
git status и git diff
Видеоурок
Конспект урока
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Создаем тестовый сайт и инициализируем репозиторий
Гнаться за красотой не будем, сайт очень простой. Главное, сосредоточиться на сути, поэтому верстки и стилей будет минимум. Даже если вы не знакомы с html и css, то легко разбересь в нашем простом примере.
Создайте на github новый приватный репозиторий site-git. Скачайте архив с файлами сайта и распакуйте содержимое в папку site-git
После этого нужно инициализировать репозиторий, как мы делали в прошлом уроке. Не забудьте поправить имя Webdevkin на свое.
Теперь все приготовления сделаны, приступим к изменениям в проекте.
Вводная
Когда мы работаем над проектом, то делаем много изменений в разных файлах. Эти изменения легко потерять или запутаться в них.
git status
Эта команда показывает список измененных файлов
Также git status выводит некоторую дополнительную информацию, которую мы изучим позже.
git diff
Просмотр всех изменений
Просмотр изменений в отдельном файле
Изменения в PhpStorm
В онке Version Control мы сразу видим список измененных файлов. Чтобы посмотреть изменения в конкретном файле, нужно кликнуть на него и нажать Crtl+D (diff). В окне difference видны не только добавленные и удаленные строки, но и изменения в отдельных строках.
Плюсы PhpStorm
PhpStorm отлично интегрируется с git. Конечно, не он один. Некоторые продвинутые редакторы кода тоже могут работать с git. Вы можете посмотреть, как реализована поддержка git, например, в sublime, но это далеко не так удобно, как в IDE от JetBrains. Это не реклама, а просто совет использовать удобные инструменты.
Поддержка git в Sublime Text 3
На этом все. В конспекте информации мало, только основные команды, поэтому смотрите видеоурок. Там все нагляднее и понятнее.
В следующем уроке мы познакомимся с коммитами и научимся с ними работать.
Git для новичков (часть 1)
Что такое Git и зачем он нужен?
С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.
Так же ваши репозитории можно хранить и в интернете. Обычно для этого используют три сервиса:
Как работает
В итоге получается очень простой граф, состоящий из одной ветки ( main ) и четырех commit. Все это может превратиться в более сложный граф, состоящий из нескольких веток, которые сливаются в одну.
Об этом мы поговорим в следующих статьях. Для начала разберем работу с одной веткой.
Установка
Основой интерфейс для работы с Git-ом является консоль/терминал. Это не совсем удобно, тем более для новичков, поэтому предлагаю поставить дополнительную программу с графическим интерфейсом (кнопками, графиками и т.д.). О них я расскажу чуть позже.
Но для начала, все же установим сам Git.
Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.
Для Mac OS. Открываем терминал и пишем:
Linux. Открываем терминал и вводим следующую команду.
Настройка
Вы установили себе Git и можете им пользоваться. Давайте теперь его настроим, чтобы когда вы создавали commit, указывался автор, кто его создал.
Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.
Создание репозитория
Теперь вы готовы к работе с Git локально на компьютере.
Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.
Теперь Git отслеживает изменения файлов вашего проекта. Но, так как вы только создали репозиторий в нем нет вашего кода. Для этого необходимо создать commit.
Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.
Процесс работы с Git
Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:
Создан новый функционал
Добавлен новый блок на верстке
Исправлены ошибки по коду
Вы завершили рабочий день и хотите сохранить код
Это поможет держать вашу ветки в чистоте и порядке. Тем самым, вы будете видеть историю изменений по каждому нововведению в вашем проекте, а не по каждому файлу.
Визуальный интерфейс
Как я и говорил ранее, существуют дополнительные программы для облегчения использования Git. Некоторые текстовые редакторы или полноценные среды разработки уже включают в себя вспомогательный интерфейс для работы с ним.
Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:
Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.
Создаем свой первый проект и выкладываем на GitHub
Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).
Перед началом предлагаю зарегистрироваться на GitHub.
Создайте папку, где будет храниться ваш проект. Если такая папка уже есть, то создавать новую не надо.
Установите себе дополнительно анализаторы кода для JavaScript и PHP
Откройте вашу папку, которую создали ранее
После этого у вас появится вот такой интерфейс
Здесь будут располагаться все файлы вашего проекта
Здесь можно работать с Git-ом
Кнопка для создания нового файла
Кнопка для создания новой папки
Давайте теперь перейдем во вкладу для работы с Git-ом.
Откроется вот такое окно:
Кнопка для публикации нашего проекта на GitHub
Вы создали и опубликовали репозиторий на GitHub.
Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.
Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:
Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки
Добавляем наш файл для будущего commit
Отправляем наш commit в GitHub
Поздравляю, вы научились создавать commit и отправлять его в GitHub!
Это первая вводная статья по утилите Git. Здесь мы рассмотрели:
Как его устанавливать
Как его настраивать
Как инициализировать репозиторий и создать commit через консоль
Как на примере VS Code, опубликовать свой код на GitHub
Забегая вперед, советую вам погуглить, как работают следующие команды:
P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.
10 Git-команд, которые стоит знать разработчику
В этой статье мы обсудим разные Git-команды, которые могут оказаться полезными для разработчика или специалиста по Big Data. Вы узнаете, как проверять, удалять и приводить код в порядок. А еще рассмотрим способы выхода из Vim и экономию времени с помощью псевдонимов Bash и конфигурации редактора Git.
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Проверяем все и вся
Вернуть, как было
Если вы работаете в коллективе и коммиты общие, тогда ваш выбор — git revert.
Не забывайте убедиться в том, что вы не отменяете коммит из опубликованной ветки, от которой зависят другие члены команды.
HEAD часто используется для my_commit, чтобы отменить изменения в вашем локальном рабочем каталоге с момента последней фиксации.
checkout лучше всего использовать для локальных отмен. В этом случае коммиты из удаленной ветки, от которой зависят ваши коллеги, не будут затронуты!
Если вы используете checkout с веткой вместо коммита, HEAD переключается на указанную ветвь, а рабочий каталог обновляется для соответствия изменениям. Это самое распространенное использование этой команды.
git revert my_commit — отмена последствий изменений в my_commit. revert выполняет новый коммит после отмены изменений.
revert безопасен для общих проектов, поскольку команда не перезаписывает изменения, от которых могут зависеть другие ветки.
Иногда вы просто хотите удалить неотслеживаемые файлы в вашем локальном каталоге. К примеру, запустив какой-то код, который создал много разных типов файлов, которые вам не нужны. К сожалению. Clean поможет мгновенно удалить их!
-n — флаг для пробного запуска, ничего не удаляется.
-f — флаг для удаления файлов.
-d — флаг для удаления неотслеживаемых директорий.
Наводим порядки
Если ничего не проиндексировано, команда позволяет вам редактировать последнее сообщение коммита. Используйте команду только в том случае, если коммит не был объединен с удаленной master-веткой.
Помогите, я застрял в Vim и не могу выбраться!
Git в некоторых случаях открывает сессию редактора Vim. И если вы не слишком хорошо знакомы с ним, то можете оказаться в затруднительной ситуации. Да и не только вы — к примеру, на Stack Overflow более 4 тысяч пользователей хотят знать, как выбраться из Vim.
Вот четырехэтапный план, который поможет закрыть Vim и сохранить изменения:
Изменяем редактор по умолчанию.
Вы можете избавиться от Vim совсем, если смените редактор по умолчанию. Вот команды для работы с популярными редакторами. Пример выбора другого редактора, в нашем случае Atom:
Ярлыки для команд Git
Что касается способа, приведенного выше, то теперь вы можете использовать gs вместо git status.
Собственно, это все на сегодня. Если есть возможность, укажите в комментариях, какие Git-команды используете вы и почему.
19 советов по повседневной работе с Git
Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!
1. Параметры для удобного просмотра лога
Вообще, в Git есть много всяких полезных параметров. Просто попробуйте выполнить man git-log чтобы посмотреть все варианты просмотра истории. Если ни один из предложенных вариантов вас не устроит, вы всегда можете воспользоваться параметром —pretty, с помощью которого можно настраивать выдачу в широких пределах.
2. Вывод актуальных изменений в файл
Далее можно использовать функцию поиска утилиты less, набрав «слеш» и введя поисковый запрос: /<<поисковый-запрос>> (используйте маленькую «n» для перехода к следующему результату поиска и большую «N» для того, чтобы вернуться к предыдущему):
3. Просмотр изменений в определённых строках файла
С помощью команды git blame filename можно определить автора последних изменений для каждой строки в файле.
Это замечательный инструмент, однако иногда бывает недостаточно информации, которую он предоставляет.
В качестве альтернативы можно использовать команду git log с флагом -L, который позволяет указать номер интересующей строки в нужном файле, и Git отобразит только те изменения, которые связаны с этой строкой.
4. Просмотр ещё не влитых в родительскую ветку изменений
Если вам приходилось работать с долгоживущими ветками, над которыми трудится много людей, то вы наверняка сталкивались с множественными вливаниями (мёржами) родительской ветки (например, master) в ветку с разрабатываемой фичей. Такие мёржи затрудняют просмотр истории изменений рабочей ветки, потому что будет сложно отличить коммиты, сделанные в родительской ветке от коммитов рабочей ветки.
5. Извлечение файла из другой ветки
Пример команды: git show some-branch:some-file.js
Иногда бывает удобно посмотреть на какой-либо файл в другой ветке, не переключаясь на неё. Это можно сделать с помощью команды git show some-branch-name:some-file-name.js, которая выведет содержимое файла в указанной ветке прямо в терминал.
А с помощью перенаправления вывода можно сохранить этот файл в указанное место на диске, например, если вы заходите открыть два файла одновременно в своём редакторе: git show some-branch-name:some-file-name.js > deleteme.js.
Примечание: если вам нужно всего лишь сравнить два файла, то можно выполнить такую команду: git diff some-branch some-filename.js
6. Пара слов о ребейзе
Ранее мы говорили о многочисленных мёржах мастера в рабочую ветку. Некоторых из них можно избежать, используя команду git rebase. Вообще, ребейз — очень мощная функция, и, пожалуй, будет лучше оставить её подробное описание для отдельного поста. Вот, например, что говорится в книге «Pro Git»:
Несмотря на все свои преимущества, у ребейза есть и свои недостатки, которые можно выразить одним предложением:
Не делайте ребейз коммитов, находящиеся вне вашего репозитория.
Если вы последуете этому совету, то всё будет хорошо. В противном случае все будут вас ненавидеть, а друзья и семья станут вас презирать.
Однако ребейза не нужно бояться, просто следует соблюдать осторожность при работе с ним.
Например, вы работаете с локальной копией ветки и сделали небольшой коммит. А в это время кто-то ещё залил в удалённую копию ветки результаты своего недельного труда. Когда вы попытаетесь запушить свои изменения, Git скажет вам, что он не может это сделать, и что вам сначала нужно сделать git pull для разрешения конфликта. Как добропорядочный человек вы так и поступите и после выполнения команды git pull в истории вашей локальной копии ветки получится вот такой вот коммит, сгенерированный автоматически: «Merge remote-tracking branch ‘origin/master’».
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
Этот совет очень простой. Допустим, вы сделали изменения, закоммитили их, а потом обнаружили опечатку. Вы можете сделать новый коммит с описанием «исправление опечатка», но есть вариант получше.
Если вы ещё не запушили изменения в удалённую ветку, то можно сделать вот так вот:
9. Три состояния в Git и переключение между ними
Как вы, наверное, уже знаете, файл в Git может находится в одном из трёх состояний:
(На самом деле есть ещё, как минимум, статус untracked — файл не добавлен в репозиторий — прим. перев.).
Очевидно, что команда git status не покажет вам уже закоммиченные файлы, для их просмотра следует использовать команду git log.
Есть ещё несколько команд для переключения состояния файлов.
Сброс состояния файлов
Сброс позволяет откатиться на определённую версию в истории изменений Git. Всего есть три вида сброса:
Поналачу эта информация может показаться бесполезной, однако, когда вы начнёте работать с разными версиями файлов, она вам очень пригодится. Например, я для себя выделил вот такие сценарии использования этих команд:
Выгрузка отдельных файлов
Также можно забирать разные версии файла из других коммитов или веток: git checkout some-branch-name file-name.js и git checkout <
Обратите внимание, что выгруженные файлы будут находиться в состоянии «Staged for commit», и чтобы убрать их из индекса для коммита нужно будет использовать команду git reset HEAD file-name.js. Для возврата в исходное состояние просто наберите git checkout file-name.js ещё раз.
10. Мягкая отмена коммитов
Это очень удобная команда на тот случай, если вам нужно откатить последние пару коммитов, покопаться в изменениях и найти проблемное место.
Обычный git revert автоматически закоммитит те изменения, которые откатили, запросив у вас примечание к новому коммиту отката. Флаг «-n» говорит гиту, чтобы тот не переживал по поводу срочного коммита новых изменений, ведь мы хотим просто посмотреть на них.
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
Моя любимая программа для сравнения файлов в графическом интерфейсе — Meld. Я влюбился в неё ещё со времён Linux, и с тех пор она всегда со мной.
Я, кстати, не пытаюсь пропагандировать Meld. Скорее всего, у вас уже есть любимая программа для сравнения файлов, и, вероятнее всего, она умеет работать с Git, как для сравнения, так и для разрешения конфликтов. Просто запустите следующие команды, заменив «meld» на свою любимую утилиту:
После этого всё, что вам нужно — запустить команду git difftool some-file.js для просмотра изменений в соответствующей программе вместо консоли.
12. Игнорирование пробелов
Если вам когда-нибудь приходилось менять отступы или переформатировать файлы, то вы наверняка сталкивались с тем, что, по мнению команды git blame, вы теперь ответственны за все изменения в этих файлах.
К счастью, Git достаточно умён, чтобы понимать, что к чему. Вы можете запускать многие команды (такие, как git diff, git blame и т.д.) с флагом «-w» и Git будет просто игнорировать все изменения, связанные с пробельными символами (пробел, табуляция и другие).
13. Добавление определённых изменений из файла
Кто-то из разработчиков Git явно неравнодушен к флагу «-p«, поскольку обычно он добавляет очень удобные штуки к различным командам.
В случае с командой git add, этот флаг позволяет в интерактивном режиме выбрать, какие именно изменения из файла вы хотите закоммитить. Таким образом, вы можете более логично огранизовать последовательность своих коммитов, чтобы их проще было смотреть.
14. Поиск и удаление старых веток
Зачастую проекты обрастают большим количеством веток в удалённом репозитории, некоторые из них остаются там даже после того, как они были вмёржены в основную ветку (master). Если вы такой же фанат чистоты (по крайней мере во всём, что касается кода), как и я, вас наверняка раздражает наличие подобных веток.
Можно изощриться и вывести списки всех удалённых веток, комментарии к последним коммитам в них и дату последних изменений:
К сожалению, насколько я знаю, нет более лёгкого способа получить список смёрженных веток. Так что здесь придётся сравнивать два списка или писать для этого скрипт.
15. Откладывание изменений определённых файлов
Если вы ещё не знаете, что делает команда git stash, то она просто кладёт все незакоммиченные изменения в специальный стек Git. Потом вы в любой момент можете выполнить git stash pop и применить все эти изменения назад. Вы так же можете посмотреть список всех сохранённых состояний в стеке с помощью команды git stash list, для более подробной информации посмотрите справку: man git-stash.
У команды git stash есть один недостаток: она откладывает сразу все файлы, а иногда бывает удобно отложить только некоторые файлы, а остальные оставить и продолжить работать с ними.
Помните магический ключ «-p«? У команды git stash он тоже есть, и, как вы уже, наверное, догадались, этот при использовании этого ключа Git предложит вам выбрать те изменения, которые нужно отложить.
Обязательно попробуйте нажать «?«, чтобы посмотреть список всех возможных опций.
Есть ещё один способ отложить только те файлы, которые нужно:
16. Хорошие примечания к коммиту
По этой теме можно посоветовать замечательную статью «Как писать примечания к коммитам».
Здесь же я хочу особо подчеркнуть одно важное правило: хорошее примечание к коммиту должно заканчивать следующее предложение: «После применения данный коммит << текст вашего примечания >>». Например:
17. Автодополнения команд Git
Для некоторых операционных систем (например, Ubuntu), автодополнение для Git в шелле включено по умолчанию. Если в вашей операционной системе это не так (а в Mac OS X это не так), вы легко можете включить автодополнение.
18. Создание алиасов для часто используемых команд
TL;DR: используйте алиасы Git или bash для наиболее часто используемых команд Git.
Лучше всего работать с Git через командную строку. А лучший способ освоиться с командной строкой — каждый раз делать всё в полном объёме (набирать длинные команды). Однако рано или поздно приходит желание создать более короткие и удобные алиасы, чтобы не вводить каждый раз одни и те же команды.
Git имеет встроенную систему алиасов, например, если вы выполните следующую команду:
19. Быстрый поиск плохого коммита
Пример команды: git bisect
Команда git bisect использует принцип «разделяй и властвуй» для поиска плохого коммита в большой истории изменений.
Представьте, что вы вернулись из продолжительного отпуска. Вы забираете последнюю версию проекта из удалённого репозитория и обнаруживаете, что та фича, над которой вы работали перед самым отпуском, теперь не работает. Вы проверяете последний сделанный вами коммит — там всё работает. Однако за время вашего отпуска в проекте появились сотни других коммитов, и вы представления не имеете, который из них оказался плохим и сломал вашу фичу.
Наверняка вы будете пытаться найти баг, поломавший вашу фичу и с помощью команды git blame на злополучном коммите найти человека, которому можно предъявить претензию. Но если баг трудно обнаружить, вы можете попробовать изучить историю изменений, в надежде отыскать плохой коммит.
Вот второй вариант — это именно тот случай, когда пригождается команда git bisect. Она позволяет вам найти плохой коммит в кратчайшие сроки.
Так что же делает git bisect?
После того, как вы укажете коммит, в котором ничего не работает («плохой» коммит) и коммит, в котором всё работает («хороший» коммит), git bisect разделит все коммиты, которые располагаются между ними пополам, переключится в новую (безымянную) ветку на этом срединном коммите и позволит вам проверить, работает ли в нём ваша фича.
Предположим, в этом «срединный» коммите всё работает. Тогда вы говорите об этом гиту с помощью команды git bisect good и у вас останется только половина всех коммитов для поиска того самого, поломавшего всё.
После выполнения этой команды Git разделит оставшиеся коммиты пополам и снова переключится в безымянную ветку на новом срединном коммите, позволив вам протестировать работоспособность вашей фичи. И так далее, пока вы не обнаружите тот самый «плохой» коммит.
Благодаря тому, что вы каждый раз делите группу коммитов пополам, для обнаружения искомого вам потребуется примерно log(n) итераций (см. Сложность алгоритма).
Список команд, которые понадобятся вам для работы с git bisect:
Данную процедуру можно автоматизировать с помощью скрипта.
Перевёл Dreadatour, текст читал %username%.