Пше сокращение что это
Подборка удобных Git-алиасов от разработчика
Авторизуйтесь
Подборка удобных Git-алиасов от разработчика
git please
git commend
Когда-нибудь коммитили и вдруг осознавали, что забыли проиндексировать файл? Больше не о чем волноваться! git commend по-тихому прикрепляет все индексированные файлы к последнему коммиту, используя уже существующее сообщение.
git it
git staaash
git stash — это одна из самых полезных команд. Она берет изменения в отслеживаемых файлах и откладывает их для дальнейшего использования, освобождая поле для дальнейших действий. Однако неиндексированные, неотслеживаемые и игнорируемые файлы команда не трогает.
Я создал несколько удобных сокращений для различные вариаций команды:
Самый последний вариант всегда откатит состояние проекта так, будто это только что сделанный клон репозитория.
git shorty
Команду git status я точно использую чаще, чем любую другую. Команда очень полезна и понятна новичкам, но для более продвинутых пользователей её вывод слишком громоздок. Вот типичный пример:
git shorty сообщает мне тоже самое так:
git merc
git grog
Мой алиас git grog (graphical log) развивался в течение нескольких лет, поэтому я и сам уже смутно понимаю, что он делает. Но выглядит он точно неплохо:
Вот стандартный вид git log для сравнения:
Форматировать вывод можно как угодно, так что берите мой вариант за основу и фантазируйте 🙂
Кстати, вот другой удобный вариант — git lg.
Если у вас есть полезные алиасы, делитесь ими в комментариях!
Малоизвестные Git-команды
У Git есть строгие обязательства по обратной совместимости: многие продвинутые возможности скрыты за разнообразными опциями, а не применяются как поведение по умолчанию. К счастью, Git также поддерживает и алиасы, так что вы можете создавать свои собственные команды, которые делают всю характерную для Git магию. Под катом — подборка полезных (или как минимум забавных) алиасов, определённых в моём .gitconfig.
git please
Каждому разработчику приходилось хотя бы раз общаться со своим тимлидом на тему принудительного пуша (force pushing) в общую ветку (не делайте этого). Ребейз (rebasing), внесение правок и squash — всё это забавно до тех пор, пока вы не перезапишете часть общей истории и не раскидаете дублирующиеся коммиты по всему репозиторию. К счастью, Git не позволит вам невольно перезаписать историю на сервере. Вам придётся явным образом передать в git push опцию —force, чтобы доказать серьёзность своих намерений. Но принудительный пуш — это грубый подход: вы затаптываете локальной версией вышерасположенную ветку, и все изменения, которые вы к тому моменту не подтянули (fetch), будут стёрты из истории.
git commend
Бывало так, что вы закоммитили и тут же сообразили, что забыли проиндексировать (stage) файл? Больше не нужно об этом беспокоиться! Алиас git commend тихо прикрепляет к последнему созданному вами коммиту все проиндексированные файлы, повторно используя уже имеющееся сообщение о коммите.
git it
Первому коммиту в репозитории нельзя сделать ребейз, как обычному. Поэтому рекомендуется в качестве корневого создавать пустой коммит. Алиас git it инициализирует ваш репозиторий и за одну операцию создаёт пустой корневой коммит. И когда вы в следующий раз запустите проект, то не надо просто добавлять его в систему управления версиями: выполните git it!
git staaash
git stash — одна из самых восхитительных и полезных Git-команд. Она регистрирует все изменения, вносимые в отслеживаемый файл в вашем рабочем дереве, и скрывает их для последующего использования, а вам показывает чистое дерево, чтобы вы могли спокойно работать с другой его частью. Но если вы создали новые файлы и ещё не проиндексировали их, то по умолчанию git stash их не тронет, поэтому у вас будет неопрятное рабочее дерево. Соответственно, по умолчанию не скрывается и содержимое неотслеживаемых или игнорируемых файлов.
Я сделал несколько удобных алиасов для разных вариантов git stash, в зависимости от того, какие биты вашего рабочего дерева нужно скрыть:
Если сомневаетесь в выборе, то самый длинный алиас (git staaash) всегда сможет восстановить рабочее дерево состояния свежего клона вашего репозитория.
git shorty
Я запускаю git status чаще любой другой Git-команды. Встроенная помощь в Git за последние годы стала куда удобнее, что очень хорошо для начинающих, но для более опытных пользователей информация слишком многословна. Например, git status объясняет мне в 12 строках, что у меня пара индексированных, неиндексированных и неотслеживаемых изменений:
Всё то же самое git shorty говорит мне тремя строками:
Для краткости я сделал это в виде алиаса git st, не смог остановиться.
git merc
Если вы используете обычный рабочий процесс ветвления без ребейза, то будет не лучшим решением запускать стандартный git merge для слияния веток с фичами с мастер-веткой. Если не добавить к этой команде опции, то по умолчанию станет использоваться стратегия слияния —ff, при которой новый коммит слияния будет создан только в том случае, если в мастер-ветке нет новых изменений. В противном случае мастер-ветка просто «перемотается» до места последнего коммита в вашей ветке. Лишь иногда, создавая коммит слияния, при просмотре Git-истории бывает непросто сказать, какой код был разработан в какой ветке.
git merc использует стратегию —no-ff, при которой всегда создаётся коммит слияния.
Между прочим, —no-ff всегда используется по умолчанию в ходе слияния pull request’ов в Bitbucket.
git grog
Мой алиас git grog (или graphical log) в последние годы разросся настолько, что я больше не уверен, будто точно знаю, что он делает. Но выглядит красиво:
Для сравнения, вот стандартный git log:
Там доступны все виды удобных форматов, так что форкайте вышеуказанную команду и пользуйтесь на здоровье!
Для поклонников GUI
Если вы поклонник Git GUI и работаете под Mac или Windows, то, возможно, вы используете наш бесплатный Git-клиент Atlassian SourceTree. Если да, то примените описанные в этой статье алиасы, создав новое кастомное действие — можно назначить комбинацию клавиш — в настройках SourceTree:
Это действие запускается с помощью меню (Actions → Custom Actions) или клавиатурной комбинации:
Основы 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. Хорошего дня и продуктивной недели!
Как облегчить себе жизнь при использовании Git (а также подборка материалов для глубокого погружения)
На Хабре опубликовано много статей, как начать работу с Git, как устроен Git под капотом, описания лучших стратегий ветвления. Здесь автор сфокусировался на том, как упростить работу с Git.
Наводим порядок
Смысл Git в том, чтобы сохранять свою работу, переключать контекст — и делать что-то ещё. Это может быть резервное копирование кода или возможность асинхронно разрабатывать несколько различных функций. Было бы ужасно выбрасывать вторую версию только потому, что в первой обнаружена ошибка. Не менее стыдно сохранять файлы с именами типа v1_final_bug_fixed. Как известно, это ведет к полному бардаку.
Все мы знаем, что жизнь становится гораздо проще, когда наши обновления аккуратно разложены по веткам Git, которыми можно поделиться с коллегами. Но часто возникают ситуации, когда вы меняете контекст, потом возвращаетесь назад — и не можете найти правильную ветвь. Был ли коммит вообще? Может, он скрытый? Может, коммит не прошел, теперь все ушли в неправильную ветку, и всё плохо, и я ужасно справляюсь со своей работой! Да уж, каждый там был и чувствовал такие сомнения. Есть способы справиться с этой ситуацией.
Сортировка веток по дате
Сортировка по дате показывает все ваши локальные ветки, начиная с последней. Довольно банально, но помогало мне много раз:
Предыдущая ветка
Оказывается, есть простой выход:
Показать информацию обо всех ветках
Флаг v показывает список всех ветвей с последним идентификатором коммита и сообщением. Двойной vv также покажет удаленные ветки upstream, за которыми следят локальные ветки:
Найти файл
Мы все попадали в такую ситуацию: каким-то образом получилось, что один файл остался не в той ветке. Что делать? Переделать всю работу или скопировать код из одной ветки в другую? Нет, к счастью, есть способ найти конкретный файл.
Понятный статус
У большинства команд Git есть такие флаги, поэтому стоит изучить, как их использовать для настройки своего рабочего процесса:
Вся история
Вы можете сделать git show с ID коммита — и увидеть конкретное изменение. Если это то, что вы искали, то git checkout перенесет вас в нужную ветку или даже позволит выбрать конкретный файл, как показано выше:
Подготовительные файлы, которые пропустили коммит
В крайнем случае, если git reflog не поможет получить ваши файлы обратно (например, вы запустили жесткий сброс с промежуточными файлами), есть еще один трюк.
Git в командной работе
Использование Git в одиночку — это одно, но когда вы работаете в команде людей, обычно с совершенно разным опытом, навыками и инструментами, Git может стать как благословением, так и проклятием. Это мощный инструмент для совместного использования одной и той же кодовой базы, проведения код-ревью и наблюдения за прогрессом всей команды. В то же время от всех сотрудников требуется общее понимание, как его использовать в командной работе. Независимо от того, о чем идет речь: о конвенции именования ветвей, форматировании сопроводительного сообщения в коммите или выборе того, какие файлы внести в коммит, — важно обеспечить хорошую коммуникацию и договориться, как использовать этот инструмент.
Всегда важно обеспечить простоту онбординга для новичков и продумать, что произойдет, если они начнут совершать коммиты, не зная принятых в компании принципов и конвенций. Это не конец света, но может вызвать некоторую путаницу и потребует времени, чтобы вернуться к согласованному подходу.
В этом разделе — несколько рекомендаций, как интегрировать принятые соглашения непосредственно в сам репозиторий, автоматизировать и оформить в декларациях максимальное количество задач. В идеальном случае любой новый сотрудник почти сразу начинает работать в том же стиле, что и остальная команда.
Одни и те же окончания строк
По умолчанию Windows использует окончания строк DOS \r\n (CRLF), в то время как Mac и Linux используют окончания строк UNIX \n (LF), а самые старые версии Mac используют \r (CR). Таким образом, по мере роста команды становится более вероятной проблема несовместимых окончаний строк. Это неудобно, они (обычно) не ломают код, но из-за них коммиты и пул-реквесты показывают различные нерелевантные изменения. Часто люди просто игнорируют их, ведь довольно хлопотно ходить и менять все неправильные окончания строк.
Существует решение — вы можете попросить всех членов команды настроить свои локальные конфигурации на автоматическое завершение строк:
Всё это хорошо, но оказывается, что ни один из этих файлов конфигурации не может быть установлен через сам репозиторий. Вы можете добавить конфигурации, специфичные для репозитория, но они не будут распространяться на других членов команды.
Автоматическое скрытие
Всё, что уменьшает стресс и когнитивную нагрузку в процессе код-ревью, улучшает его качество и сокращает время.
Например, вы хотите внести файлы ресурсов (asset) в репозиторий, но не собираетесь их потом изменять и отслеживать, поэтому можно добавить в файл с атрибутами следующую строчку:
Чаще используйте git blame
Следует представлять git blame не только как нечто хорошее, но и как средство коммуникации, которое помогает всей команде уменьшить хаос и не тратить время на выяснение, кому что известно. Некоторые IDE, такие как Visual Studio, активируют эту функцию в качестве аннотаций. Для каждой функции вы мгновенно видите, кто последним ее изменил (и, следовательно, с кем об этом говорить).
Аналог git blame для пропавших файлов
Шаблон сообщения коммитов
Сообщения коммитов часто нуждаются в улучшении. Рано или поздно разработчики в команде приходят к такому выводу. Есть много способов улучшения. Например, можно ссылаться на идентификаторы багов из внутреннего инструмента управления проектами или, возможно, поощрить написание хоть какого-то текста вместо пустого сообщения.
Эту команду нужно запускать вручную каждый раз, когда кто-то клонирует репозиторий, поскольку конфигурационные файлы не фиксируются в репозитории. Однако она удобна, потому что можно завести общий файл с любым именем, который действует как шаблон сообщения коммитов:
Git для автоматизации
Git является мощным средством автоматизации. Это не сразу очевидно, но подумайте сами: он видит всю вашу активность в репозитории — плюс активность других участников — и у него много информации, которая может быть очень полезной.
Хуки Git
Довольно часто вы видите, что участники команды во время работы выполняют повторяющиеся задачи. Это может быть проверка прохождения тестов и линтеров перед отправкой ветки на сервер (хук перед отправкой) или принудительная стратегия именования ветвей (хук перед коммитом). На эту тему Константинос Леймонис в журнале Smashing Magazine написал статью под названием «Как упростить рабочий процесс с помощью хуков Git».
Ручная автоматизация
Одной из ключевых функций автоматизации в Git является git bisect. Многие слышали о ней, но мало кто использует. Суть в обработке дерева Git (истории коммитов) и поиске, в каком месте введена ошибка.
Это более мощная фича, чем кажется на первый взгляд, потому что она не прогоняет линейно журнал Git, что можно было сделать вручную как итеративный процесс. Вместо этого она использует двоичный поиск, который эффективно проходит по коммитам с наименьшим количеством шагов:
Идем дальше: автоматизация научным методом
В своем докладе «Отладка с помощью научного метода» Стюарт Хэллоуэй объяснил, как использовать команду git bisect для автоматизации отладки.
Он фокусируется на Clojure, но нам необязательно знать этот язык, чтобы извлечь пользу из его доклада.
Git bisect — это отчасти автоматизация научным методом. Вы пишете небольшую программу, которая будет что-то тестировать, а Git прыгает туда-сюда, с каждым прыжком разрезая мир пополам, пока не нащупает ту границу, на которой ваш тест меняет состояние.
Стюарт Хэллоуэй
Поначалу git bisect может показаться интересной и довольно крутой функцией, но в итоге она не очень полезна. Выступление Стюарта в значительной степени показывает, что на самом деле контрпродуктивно выполнять отладку так, как мы привыкли. Если вместо этого сосредоточиться на эмпирических фактах, проходит тест или нет, то вы можете запустить его на всех коммитах, начиная с рабочей версии, и уменьшить ощущение «блуждания в темноте», к которому мы привыкли.
На каждом прошлом коммите
Камран Ахмед в твите написал, как rebase находит, какой коммит не проходит тест:
Находим коммит, который не проходит тест:
Команда запускает «yarn test» на всех коммитах между d294ae9 и HEAD и останавливается на том коммите, где тест падает.
Мы уже рассматривали git bisect для выполнения этой задачи, что может быть более эффективно, но в данном случае мы не ограничены одним вариантом использования.
Здесь есть место для творчества. Возможно, вы хотите сгенерировать отчет о том, как изменялся код с течением времени (или показать историю тестов), и простого парсинга журнала Git недостаточно. Может, это не самый полезный трюк в этой статье, но он интересный и показывает задачу, в реальность выполнения которой мы могли и не поверить раньше:
Подборка статей и мануалов, которые помогут углубиться в Git
В такой статье невозможно углубиться в тему, иначе получится целая книга. Я выбрал несколько маленьких трюков, о которых могут не знать даже опытные пользователи. Но в Git гораздо больше возможностей: от базовых функций до сложнейших скриптов, точных конфигураций и интеграции в консоль. Поэтому вот некоторые ресурсы, которые могут быть вам интересны:
Введение в Git
Оглавление
Предисловие
Git — самая популярная распределённая система контроля версиями.[1][2]
Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).
Эта статья для тех, кто имеет по крайней мере базовые знания и навык работы с git и желает расширить свои знания.
Здесь рассматриваются только технические аспекты git’а, для более подробного погружения в философию git’а и его внутреннюю реализацию, советую прочитать несколько полезных книг (см. Рекомендуемая литература).
1. Настройка git
Прежде чем начинать работу с git необходимо его настроить под себя!
1.1 Конфигурационные файлы
которая позволит вам изменить стандартное поведение git, если это необходимо, но вы можете редактировать конфигурационные файлы в ручную (я считаю так быстрее).
1.2 Настройки по умолчанию
Есть куча настроек git’а как для сервера так и для клиента, здесь будут рассмотрены только основные настройки клиента.
где name это название параметра, а value его значение, для того что бы задать настройки.
Пример:
установит редактор по умолчанию nano.
1.3 Псевдонимы (aliases)
Если вы не хотите печатать каждую команду для Git целиком, вы легко можете настроить псевдонимы. Для создания псевдонима используйте:
где SHORT_NAME это имя для сокращения, а COMMAND команда(ы) которую нужно сократить. Пример:
после выполнения этой команды вы можете просматривать информацию о последнем коммите на текущей ветке выполнив git last.
Я советую вам использовать следующие сокращения (вы также можете определить любые свои):
2. Основы git
2.1 Создание репозитория
2.2 Состояние файлов
Для просмотра состояния файлов в вашем репозитории используйте:
Жизненный цикл файлов
Как видно на картинке файлы могут быть не отслеживаемые (Untracked) и отслеживаемые. Отслеживаемые файлы могут находится в 3 состояниях: Не изменено (Unmodified), изменено (Modified), подготовленное (Staged).
Если вы добавляете (с помощью git add) «Не отслеживаемый» файл, то он переходит в состояние «Подготовлено».
Если вы изменяете файл в состояния «Не изменено», то он переходит в состояние «Изменено». Если вы сохраняете изменённый файл (то есть находящийся в состоянии «Изменено») он переходит в состояние «Подготовлено». Если вы делаете коммит файла (то есть находящийся в состоянии «Подготовлено») он переходит в состояние «Не изменено».
Если версии файла в HEAD и рабочей директории отличаются, то файл будет находится в состояний «Изменено», иначе (если версия в HEAD и в рабочем каталоге одинакова») файл будет находится в состояний «Не изменено».
Если версия файла в HEAD отличается от рабочего каталога, но не отличается от версии в индексе, то файл будет в состоянии «Подготовлено».
2.3 Работа с индексом
Надеюсь вы поняли, как выглядит жизненный цикл git репозитория. Теперь разберём как вы можете управлять индексом и файлами в вашем git репозитории.
Индекс — промежуточное место между вашим прошлым коммитом и следующим. Вы можете добавлять или удалять файлы из индекса. Когда вы делаете коммит в него попадают данные из индекса, а не из рабочей области.
Что бы просмотреть индекс, используйте git status.
Что бы добавить файлы в индекс используйте
Полезные параметры команды git add:
Что бы удалить файлы из индекса вы можете использовать 2 команды git reset и git restore.
git-restore — восстановит файлы рабочего дерева.
git-reset — сбрасывает текущий HEAD до указанного состояния.
По сути вы можете добиться одного и того же с помощью обеих команд.
Что бы удалить из индекса некоторые файлы используйте:
С помощью git status вы можете посмотреть какие файлы изменились но если вы также хотите узнать что именно изменилось в файлах то воспользуйтесь командой:
2.4 Работа с коммитами
Теперь, когда ваш индекс находится в нужном состояний, пора сделать коммит ваших изменений. Запомните, что все файлы для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. На деле файлы в нём будут, но только их старая версия (если таковая имеется).
Для того что бы сделать коммит ваших изменений используйте:
Полезные опции команды git commit:
где commit это верхний коммит в вашей цепочке с которого вы бы хотели что либо изменить.
pick 2748cb4 first commit
edit 750f5ae second commit
pick 716eb99 third commit
После сохранения скрипта вы вернётесь в командную строку и git скажет что необходимо делать дальше:
Остановлено на 750f5ae … second commit
You can amend the commit now, with
Once you are satisfied with your changes, run
Для удаления коммита
Необходимо удалить строку с коммитом.
Пример: вы хотите удалить коммит 750f5ae
Нужно изменить скрипт с такого:
pick 2748cb4 third commit
pick 750f5ae second commit
pick 716eb99 first commit
на такой:
pick 2748cb4 first commit
pick 716eb99 third commit
Для объединения коммитов
Необходимо изменить pick на squash над коммитами которые вы хотите объединить.
Пример: вы хотите объединить коммиты 750f5ae и 716eb99.
Необходимо изменить скрипт с такого:
pick 2748cb4 third commit
pick 750f5ae second commit
pick 716eb99 first commit
На такой
pick 2748cb4 third commit
squash 750f5ae second commit
squash 716eb99 first commit
Заметьте что в интерактивном скрипте коммиты изображены в обратном порядке нежели в git log. С помощью squash вы объедините коммит 750f5ae с 716eb99, а 750f5ae с 2748cb4. В итоге получая один коммит содержащий изменения всех трёх.
2.5 Просмотр истории
вы можете просматривать историю коммитов вашего репозитория. Есть также куча параметров для сортировки и поиска определённого коммита.
Полезные параметры команды git log:
Также вы можете настроить свои формат вывода коммитов с помощью
покажет список коммитов состоящий из хэша времени и сообщения коммита.
2.6 Работа с удалённым репозиторием
Так как git это распределённая СКВ вы можете работать не только с локальными но и с внешними репозиториеми.
Удалённые репозитории представляют собой версии вашего проекта, сохранённые на внешнем сервере.
Для работы с внешними репозиториями используйте:
Если вы с клонировали репозитории через http URL то у вас уже имеется ссылка на внешний. В другом случае вы можете добавить её с помощью
Для загрузки данных с внешнего репозитория используйте git pull [rep] [branch]. Если ваши ветки отслеживают внешние, то можете не указывать их при выполнение git pull. По умолчанию вы получите данные со всех отслеживаемых веток.
Для отправки данных на сервер используйте
Для удаления внешних веток используйте
Для получения подробной информации о внешнем репозитории (адреса для отправки и получения, на что указывает HEAD, внешние ветки, локальные ветки настроенные для git pull и локальные ссылки настроенные для git push)
Для переименования названия внешнего репозитория используйте
Для удаления ссылки на внешний репозитории используйте
3. Ветвление в git
Ветвление это мощные инструмент и одна из главных фич git’а поскольку позволяет вам быстро создавать и переключатся между различным ветками вашего репозитория. Главная концепция ветвления состоит в том что вы можете откланяться от основной линии разработки и продолжать работу независимо от нее, не вмешиваясь в основную линию. Ветка всегда указывает на последний коммит в ней, а HEAD указывает на текущую ветку (см. Указатели в git).
3.1 Базовые операций
Для создания ветки используйте
Здесь branch_name это название для новой ветки, а start_commit это коммит на который будет указывать ветка (то есть последний коммит в ней). По умолчанию ветка будет находится на последнем коммите родительской ветки.
3.2 Слияние веток
Полезные параметры для git merge:
При разрешении конфликта вам необходимо выбрать какую часть изменений из двух веток вы хотите оставить. При открытии конфликтующего файла, в нём будет содержатся следующее:
>>>>>> Тут название ветки с которой сливаем
Разрешив конфликт вы должны завершить слияния выполнив коммит.
3.3 Rerere
Rerere — «reuse recorded resolution” — “повторное использование сохраненных разрешений конфликтов». Механизм rerere способен запомнить каким образом вы разрешали некую часть конфликта в прошлом и провести автоматическое исправление конфликта при возникновении его в следующий раз.
Что бы включить rerere выполните
Используйте git rerere status для того что бы посмотреть для каких файлов rerere сохранил снимки состояния до начала слияния.
Используйте git rerere diff для просмотра текущего состояния конфликта.
Если во время слияния написано: Resolved ‘nameFile’ using previous resolution. Значит rerere уже устранил конфликт используя кэш.
4. Указатели в git
в git есть такие указатели как HEAD branch. По сути всё очень просто HEAD указывает на текущую ветку, а ветка указывает на последний коммит в ней. Но для понимания лучше представлять что HEAD указывает на последний коммит.
4.1 Перемещение указателей
В книге Pro git приводится очень хороший пример того как вы можете управлять вашим репозиторием поэтому я тоже буду придерживается его. Представите что Git управляет содержимым трех различных деревьев. Здесь под “деревом” понимается “набор файлов”.
В своих обычных операциях Git управляет тремя деревьями:
Используя различные опций этой команды вы можете:
В общем думаю вы сможете придумать намного больше примеров чем я. В заключение скажу, что с помощью git reset можно творить магию…