Git — Как запустить git-console через cmd


Содержание

Командная строка Git в Windows

Я установил msysGit 1.7.10 на свою машину Windows 7. Что мне нужно знать, если я могу использовать Git из командной строки?

Когда я пытаюсь выполнить команду git в командной строке прямо сейчас, я вижу:

‘git’ не распознается как внутренняя или внешняя команда, операционная программа или командный файл.

Есть ли способ включить командную строку Git?

Как сказал @birryree, добавьте двоичный файл msysgit в свой PATH или используйте Git Bash (установленный с msysgit, насколько я помню), который лучше, чем консоль Windows и похожа на Unix.

У меня была такая же проблема и разрешила ее, добавив расположение каталога /bin в переменную среды PATH.

Найдите местоположение файла, где был установлен Git, мой — C:\Users\(My UserName)\AppData\Local\GitHub . Это также может быть C:\Program Files (x86)\Git

Как только вы разместите Git, вы увидите подпапку /bin . Он может быть в папке PortableGit (мой PortableGit_015aa71ef18c047ce8509ffb2f9e4bb0e3e73f13 ). Скопируйте этот путь.

Перейдите в Панель управления > Системa > Защита системы > Дополнительно > Переменные среды

Выберите PATH, нажмите править и вставьте путь к нему. Если в вашем PATH уже есть значения, вставьте свой путь Git в конец, разделенный точкой с запятой.

Теперь вы можете получить доступ к команде Git из CMD.

Эти инструкции работали для Windows 8 с установкой msysgit/TortoiseGit, но должны применяться для других типов установок git в Windows.

  • Перейдите в Панель управления\Система и безопасность\Система
  • Нажмите Расширенные системные настройки слева, что откроет Свойства системы.
  • Нажмите вкладку Дополнительно
  • Нажмите Окружение Переменные в нижней части диалогового окна.
  • Отредактируйте систему Переменная называется PATH.
  • Добавьте эти два пути в список существующих путей, уже присутствующих в системной переменной. Трудная часть была двумя путями. Эти пути могут отличаться для вашего ПК. ;C:\msysgit\bin\;C:\msysgit\mingw\bin\
  • Закройте окно подсказки CMD, если оно открыто. CMD необходимо перезапустить, чтобы получить обновленную переменную Path.
  • Попробуйте ввести git в командной строке, вы увидите список команд git, прокручивающихся по экрану.

В Windows 8.1 установка переменной PATH Environment в каталог Git bin не помогла мне. Вместо этого мне пришлось использовать каталог cmd C:\Program Files (x86)\Git\cmd .

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

Шпаргалка по основным командам для работы с файловой системой в консоли Git Bash.

Установка консоли Git Bash

Мы будем использовать консоль Git Bash.
Чтобы ее использовать, необходимо установить Git и Git Bash
Установим с сайта: https://git-scm.com.

Команды в Git Bash консоли

clear — Очистить консоль

pwd — Показать текущий каталог
ls — Показать файлы в данной папке, кроме скрытых
ls -f — Показать файлы в данной папке, включая и скрытые
cd c:/ — Перейти в конкретный каталог
cd — — Вернуться назад
cd .. — Выйти на 1 уровень вверх
cd ../.. — Выйти на 2 уровня вверх

Создание каталогов

mkdir — Создать папку
cd !$ — Перейти в только что созданную папку
mkdir -p — Создать сразу несколько папок
mkdir -p app/ — Создать сразу несколько вложенных папок

Создание файлов

touch index.html — Создать файл index.html
touch app/ — Создать сразу несколько файлов, никаких лишних пробелов быть не должно

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

touch — позволяет создавать файлы
rm test — Удалить пустую папку test
rm -r test — Удалить папку test с файлами внутри неё

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

mv app1/*.* app2 — Переместить все файлы из папки app1 в папку app2

Подробное введение в работу с Git

Что такое Git и зачем он мне?

Git — это распределённая система контроля версий, которая позволяет сохранять все изменения, внесённые в файлы, хранящиеся в репозитории. Изменения хранятся в виде снимков, называемых коммитами, которые могут размещаться на многих серверах. Считайте это стандартным облаком для бэкапов на стероидах — вы не только можете восстановить код в случае сбоя, но и откатить код до любого из предыдущих сохранённых состояний. Также вы легко можете взаимодействовать с другими разработчиками — опять же, как несколько человек могут работать над одним файлом в Google Docs, так и разработчики могут одновременно работать над одним репозиторием и сохранять свои изменения.

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

Как работать с Git

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

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

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

Если вы не знаете, как использовать команду, то можете открыть руководство с помощью git help , а если вам просто нужно напоминание, используйте git -h или git —help ( —help и -h эквивалентны).

Подготовка Git

Установка Git

Пользователи Windows могут скачать его отсюда.

В macOS (OS X) Git поставляется как часть инструментов командной строки XCode, поэтому нужно их установить. Чтобы проверить наличие Git, откройте терминал и введите git —version для проверки версии.

Если вы пользуетесь Linux, то используйте команду sudo apt install git-all (дистрибутивы на основе Debian) или sudo dnf install git-all (на основе RPM).

Настройка конфигурационного файла

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

Вы можете либо напрямую отредактировать файл .gitconfig с помощью текстового редактора, либо с помощью команды git config —global —edit , а также можете отредактировать отдельные поля, используя команду git config —global — нас интересуют поля user.name и user.email .

Также можно настроить текстовый редактор для написания сообщений коммитов, используя поле core.editor . Изначально используется системный редактор по умолчанию, например, vi для Linux/Mac. Поле commit.template позволяет указать шаблон, который будет использоваться при каждом коммите.

Есть множество других полей, однако одно из самых полезных — это alias , которое привязывает команду к псевдониму. Например, git config —global alias.st «status -s» позволяет использовать git st вместо git status -s

Команда git config —list выведет все поля и их значения из конфигурационного файла.

Создаём Git-репозиторий

Для инициализации нового репозитория .git можно использовать команду git init или, если вы хотите скопировать существующий, git clone .

История коммитов в Git

Git хранит данные в виде набора легковесных «снимков», известных как коммиты. Они хранят состояние файловой системы в определённый момент времени, а также указатель на предыдущий(-ие) коммит(-ы). Каждый коммит содержит уникальную контрольную сумму — идентификатор, который Git использует, чтобы ссылаться на коммит. Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый коммит (мы следуем по цепочке коммитов в обратном порядке, чтобы попасть к предыдущим коммитам).

Мы можем ссылаться на коммит либо через его контрольную сумму, либо через его позицию относительно HEAD, например HEAD

4 ссылается на коммит, который находится 4 коммитами ранее HEAD.

Файловая система Git

Git отслеживает файлы в трёх основных разделах:

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

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

Просмотр изменений в файловых системах

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

  1. Неотслеживаемый (untracked) — находится в рабочей директории, но нет ни одной версии в HEAD или в области подготовленных файлов (Git не знает о файле).
  2. Изменён (modified) — в рабочей директории есть более новая версия по сравнению с хранящейся в HEAD или в области подготовленных файлов (изменения не находятся в следующем коммите).
  3. Подготовлен (staged) — в рабочей директории и области подготовленных файлов есть более новая версия по сравнению с хранящейся в HEAD (готов к коммиту).
  4. Без изменений — одна версия файла во всех разделах, т. е. в последнем коммите содержится актуальная версия.

Примечание Файл может быть одновременно в состоянии «изменён» и «подготовлен», если версия в рабочей директории новее, чем в области подготовленных файлов, которая в свою очередь новее версии в HEAD.

Мы можем использовать опцию -s для команды git status , чтобы получить более компактный вывод (по строке на файл). Если файл не отслеживается, то будет выведено ?? ; если он был изменён, то его имя будет красным, а если подготовлен — зелёным.


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

  • git diff — сравнение рабочей директории с областью подготовленных файлов;
  • git diff —staged — сравнение области подготовленных файлов с HEAD.

Если использовать аргумент , то diff покажет изменения только для указанных файлов/папок, например git diff src/ .

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

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

Команда git commit обновляет HEAD новым коммитом, который делает снимки файлов в области подготовленных файлов.

Действие команды git reset состоит из трёх потенциальных шагов:

  1. Переместить указатель HEAD на (например, при откате коммита в рабочей директории и области подготовленных файлов будут более новые версии файлов, чем в HEAD). Также указатель HEAD ветки будет перемещён на этот коммит.
  2. Обновить область подготовленных файлов содержимым коммита. В таком случае только в рабочей директории будут новейшие версии файлов.
  3. Обновить рабочую директорию содержимым области подготовленных файлов. С этим нужно быть осторожнее, поскольку в итоге будут уничтожены изменения файлов.

По умолчанию команда git reset выполняет только шаги 1 и 2, однако её поведение можно изменить с помощью опций —soft (только 1 шаг) и —hard (все шаги).

Если передать путь к файлу/папке, то команда будет выполнена только для них, например git reset —soft HEAD

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

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

Наконец, git rm отменяет отслеживание файла и удаляет его из рабочей директории, опция —cached позволит сохранить файл.

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

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

  • файлы с чувствительной информацией вроде паролей;
  • большие бинарные файлы;
  • файлы сборок, которые генерируются после каждой компиляции;
  • файлы, специфичные для ОС/IDE, например, .DS_Store для macOS или .iml для IntelliJ IDEA — нам нужно, чтобы репозиторий как можно меньше зависел от системы.

Для игнорирования используется файл .gitignore . Чтобы отметить файлы, которые мы хотим игнорировать, можно использовать шаблоны поиска (считайте их упрощёнными регулярными выражениями):

  • /___ — позволяет избежать рекурсивности — соответствует файлам только в текущей директории;
  • __/ — соответствует всем файлам в указанной директории;
  • *___ — соответствует всем файлам с указанным окончанием;
  • ! — игнорирование файлов, попадающих под указанный шаблон;
  • [__] — соответствует любому символу из указанных в квадратных скобках;
  • ? — соответствует любому символу;
  • /**/ — соответствует вложенным директориям, например a/**/d соответствует a/d , a/b/d , a/b/c/d и т. д.

Мы даже можем использовать шаблоны поиска при указании файла/папки в других командах. Например, git add src/*.css добавит все файлы .css в папке src .

Коммиты

Так как коммиты являются основой истории версий, не будет лишним узнать о них немного больше.

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

  • -m позволяет написать сообщение вместе с командой, не открывая редактор. Например git commit -m «Пофиксил баг» ;
  • -a переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить git add перед коммитом);
  • —amend заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Несколько советов, к которым стоит прислушаться:

  • Коммитьте часто: вы не сможете откатить изменения, если откатывать не к чему.
  • Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
  • Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу this commit will ___ (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось. Здесь подробно расписано, как писать сообщения для коммитов.
  • (Опционально) Не коммитьте незначительные изменения: в большом репозитории множество небольших коммитов могут засорить историю. Хорошим тоном считается делать такие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

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

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

  • -p показывает изменения в каждом коммите;
  • —stat показывает сокращённую статистику для коммитов, например изменённые файлы и количество добавленных/удалённых строк в каждом их них;
  • -n показывает n последних коммитов;
  • —since=___ и —until=___ позволяет отфильтровать коммиты по промежутку времени, например —since=»2020-01-01″ покажет коммиты с 1 января 2020 года;
  • —pretty позволяет указать формат логов (например, —pretty=oneline ), также можно использовать —pretty=format для большей кастомизации, например —pretty=format:»%h %s» ;
  • —grep и -S фильтруют коммиты с сообщениями/изменениями кода, которые содержат указанную строку, например, git log -S имя_функции позволяет посмотреть добавление/удаление функции;
  • —no-merges пропускает коммиты со слиянием веток;
  • ветка1..ветка2 позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток). Например, git log master..test покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).
  • —left-right ветка1. ветка2 показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак обозначает коммиты из ветка1 , а > — из ветка2 . Обратите внимание: используется три точки, а не две;
  • -L принимает аргумент начало,конец:файл или :функция:файл и показывает историю изменений переданного набора строк или функции в файле.
Цукерберг рекомендует:  Авторские права - Авторские права на программу.

Другой полезной командой является git blame , которая для каждой строки файла показывает автора и контрольную сумму последнего коммита, который изменил эту строку. -L , позволяет ограничить эту команду заданными строками. Это можно использовать, например, для выяснения того, какой коммит привёл к определённому багу (чтобы можно было его откатить).

Наконец, есть команда git grep , которая ищет по всем файлам в истории коммитов (а не только в рабочей директории, как grep ) по заданному регулярному выражению. Опция -n отображает соответствующий номер строки в файле для каждого совпадения, а —count показывает количество совпадений для каждого файла.

Примечание Не путайте git grep с git log —grep ! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.

Удалённые серверы

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

Команда git remote -v выводит список удалённых репозиториев, которые мы отслеживаем, и имена, которые мы им присвоили.

При использовании команды git clone мы не только загружаем себе копию репозитория, но и неявно отслеживаем удалённый сервер, который находится по указанному адресу и которому присваивается имя origin.

Наиболее употребляемые команды:

  • git remote add — добавляет удалённый репозиторий с заданным именем;
  • git remote remove — удаляет удалённый репозиторий с заданным именем;
  • git remote rename — переименовывает удалённый репозиторий;
  • git remote set-url — присваивает репозиторию с именем новый адрес;
  • git remote show — показывает информацию о репозитории.

Следующие команды работают с удалёнными ветками:

  • git fetch — получает данные из ветки заданного репозитория, но не сливает изменения;
  • git pull — сливает данные из ветки заданного репозитория;
  • git push — отправляет изменения в ветку заданного репозитория. Если локальная ветка уже отслеживает удалённую, то можно использовать просто git push или git pull .

Таким образом несколько людей могут запрашивать изменения с сервера, делать изменения в локальных копиях и затем отправлять их на удалённый сервер, что позволяет взаимодействовать друг с другом в пределах одного репозитория.

Ветвление

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

Это ведёт нас к ключевой особенности Git — ветвлению, возможности работать над разными версиями проекта. Это значит, что вместо одного списка с упорядоченными коммитами история будет расходиться в определённых точках (что делает её похожей на дерево). Каждая ветвь в Git содержит легковесный указатель HEAD на последний коммит в этой ветке, что позволяет без лишних затрат создать много веток. Совет: называйте ветку в соответствии с разрабатываемой в ней функциональностью. Ветка по умолчанию называется master.

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

  • git branch — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент , то команда выведет список всех локальных веток;
  • git checkout — переключается на эту ветку. Можно передать опцию -b , чтобы создать новую ветку перед переключением;
  • git branch -d — удаляет ветку.

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( git clone привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязывание к удалённой ветке:

  • git branch -u / — привязывает текущую ветку к указанной удалённой ветке;
  • git checkout —track / — аналог предыдущей команды;
  • git checkout -b / — создаёт новую локальную ветку и начинает отслеживать удалённую;
  • git branch —vv — показывает локальные и отслеживаемые удалённые ветки;
  • git checkout — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем, git checkout связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как git reset перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды git stash . Чтобы вернуть изменения, используйте git stash apply .

Возможно, вместо этого вы захотите стереть все внесённые изменения. В таком случае используйте команду git clean . Опция -d также удалит неотслеживаемые файлы. Совет: добавьте опцию -n , чтобы увидеть, что произойдёт при запуске git clean без непосредственного использования.

Совмещение веток

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

Слияние

Оно включает в себя создание нового коммита, который основан на общем коммите-предке двух ветвей и указывает на оба HEAD в качестве предыдущих коммитов. Для слияния мы переходим на основную ветку и используем команду git merge .


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

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

Замените в этом блоке всё на версию, которую вы хотите оставить, и подготовьте файл. После разрешения всех конфликтов можно использовать git commit для завершения слияния.

Перемещение

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

Для перемещения используется команда git rebase , которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

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

Так зачем нужно слияние, если можно всё время пользоваться перемещением? К сожалению, перемещение не панацея от запутанных логов, так как перемещённые коммиты на самом деле отличаются от оригинальных, хотя и имеют одного и того же автора, сообщение и изменения.

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

Поэтому вот совет:

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

Похожие дебаты по поводу того, что лучше использовать, возникают, когда вы хотите откатить коммит. Команда git revert создаёт новый коммит, отменяющий изменения, но сохраняющий историю, в то время как git reset перемещает указатель HEAD, предоставляя более чистую историю (словно бы этого коммита никогда и не было). Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

Резюмируем

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

GitHub

GitHub — это платформа, которая хранит Git-репозитории на своих множественных серверах. Как пользователь GitHub вы можете хранить свои удалённые репозитории на их серверах, а также вносить вклад в другие open-source репозитории. GitHub дополняет использование Git некоторыми новыми возможностями.

Например, вы можете сделать форк удалённого репозитория, то есть создать свою копию репозитория на севере GitHub. Это полезно в тех случаях, когда у вас нет прав на создание ветки в оригинальном репозитории. Когда вы воспользуетесь командой git clone , ваш локальный репозиторий будет отслеживать удалённый форк как origin, а оригинальный репозиторий как upstream.

После этого вам может понадобиться слить тематическую ветку вашего удалённого репозитория в основную ветку оригинального. Для этого вы можете создать новый Pull Request — запрос на внесение изменений, где GitHub проверяет наличие конфликтов прежде чем повзолить вам провести слияние. Зачастую существуют и другие проверки перед слиянием, например просмотр и одобрение кода или даже запуск тестов. В запросе можно обсудить код, а все коммиты, которые вы отправляете в удалённую тематическую ветку, будут автоматически добавлены в запрос, даже если он был создан до этих коммитов.

Продвинутое использование: интерактивная подготовка

Вы можете с удобством управлять областью подготовленных файлов (например при фиксации нескольких небольших коммитов вместо одного большого) с помощью интерактивной консоли, которую можно запустить git add -i . В ней доступны 8 команд:

  • status — показывает для каждого файла краткое описание того, что (не)подготовлено;
  • update — подготавливает отслеживаемые файлы;
  • revert — убрать один или несколько файлов из подготовленной области;
  • add untracked — подготавливает неотслеживаемый файл;
  • patch — подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? . Можно ввести ? , чтобы узнать, что делает каждая команда;
  • diff — показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
  • quit — выходит из интерактивной консоли;
  • help — показывает краткое описание каждой команды.

Символ * рядом с файлом означает, что команда изменит его статус (подготовлен/неподготовлен в зависимости от того, происходит ли обновление или откат). Если нажать Enter, не введя ничего ни в одном из под-меню команды, то все файлы перейдут в (не)подготовленное состояние.

Обратите внимание, что создание патчей (подготовка только части файла) доступно не только в интерактивной консоли, но и через команду git add -p .

Продвинутое использование: правим историю

Для большего контроля над историей коммитов локальной ветки можно использовать команду git rebase -i HEAD

n , которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.

Измененяем сообщение коммита/разбиваем коммиты

Для указания коммита, который вы хотите изменить, используется команда edit . Затем, когда Git будет проводить перемещение, он остановится на этом коммите. После этого вы можете использовать git commit —amend , чтобы изменить сообщение или подготовить забытые файлы. Если вы хотите разделить коммит, после остановки введите git reset HEAD^ (в результате HEAD будет перемещён на один коммит назад и все изменённые в этом коммите файлы перейдут в статус неподготовленных). Затем вы сможете зафиксировать файлы в отдельных коммитах обычным образом.

После завершения редактирования введите git rebase —continue .

Перезапись нескольких коммитов

Иногда вам может потребоваться перезаписать несколько коммитов — в таких случаях можно использовать git filter-branch . Например, чтобы удалить случайно зафиксированный файл, можно ввести git filter-branch —tree-filter ‘git rm -f ‘ HEAD . Однако учтите, что при этом вся история перемещается.

Объединение нескольких коммитов

Во время работы над новой функцией в проекте вы можете постепенно фиксировать даже малейшие изменения в тематической ветке. Однако из-за этого история засоряется такими небольшими коммитами, что может противоречить правилам проекта. Это можно исправить, объединив несколько коммитов в один большой. Для этого сначала используйте команду pick для выбора первого коммита, а затем squash для последующих. Git применит все изменения в одном коммите и попросит отредактировать сообщение общего коммита.

Переносим отдельный коммит

Кроме слияния/перемещения всех коммитов в тематической ветке, вас может интересовать только определённый коммит. Допустим, у вас есть локальная ветка drafts, где вы работаете над несколькими потенциальными статьями, но хотите опубликовать только одну из них. Для этого можно использовать команду git cherry-pick . Чтобы получить определённые коммиты, из которых мы хотим выбирать, можно использовать git log .. .

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

Заключение

Вот мы и рассмотрели основные концепции Git. Вы можете использовать эту статью в качестве краткого справочника, а можете почитать книгу «Pro Git», которая гораздо больше (

450 страниц) и описывает Git более глубоко.

Хотите копнуть глубже в Git, но вам мало (или наоборот, много) одной большой книги? Тогда вам стоит взглянуть на наш план изучения.

Вопрос по batch-file, git, windows, cmd &#8211 Из консоли git: как выполнить командный файл и затем вернуться в консоль git?

У меня есть небольшой служебный скрипт под названием clear.bat это делает некоторую работу по дому на моих источниках.

Это .bat файл, чтобы я мог легко дважды щелкнуть его в проводнике Windows.

Иногда мне удобнее запускать его из моего Git-bash (msysgit, если это имеет значение).

Для этого я набираю

cmd превращает мой Git Bash в нормальный cmd окно, где я мог бы легко выполнить мою партию. Когда я печатаю exit , cmd среда завершена, и я вернулся в свой Git bash.

Может ли это быть достигнуто более простым способом?

Я старался cmd /C clean.bat посколькудокументы сказать

Edit:
Просто заметил, что пост сломан.

Я хочу выполнить clean.bat изнутри Git Bash без необходимости вводить три команды выше ( cmd , clear.bat , exit ). Я просто хочу выполнить .bat файл из моего Git Bash. Очевидным способом было бы создать отдельный .sh файл, который выполняет ту же работу, но это приведет к двойному коду.

Edit 2: Когда я выполню cmd /C clean.bat , Git bash превращается в обычную среду CMD и отображает только приглашение. Файл clean.bat не исполняется. Это так же, как если бы я просто набрал cmd .

Кроме того, добавив /debug Switch буквально ничего не делает. Похоже только cmd оценивается и все остальные параметры игнорируются.

‘git’ не распознается как внутренняя или внешняя команда

когда я пытаюсь использовать git команда на моем обычном Windows cmd или cmd с ruby, я получаю следующую ошибку:

‘git’ не распознается как внутренняя или внешняя команда, исполняемой программой или пакетным файлом.

Как я могу исправить эту проблему?

20 ответов:

вы правильно установили свой путь, чтобы указать на вашу установку git?

вот как вы можете это сделать:

  • Правой Кнопкой Мыши «Мой компьютер»,
  • выберите «Свойства»,
  • открыть «дополнительно»,
  • нажмите кнопку «Переменные среды»,
  • выделите переменную» Path»,
  • нажмите кнопку «Редактировать»,
  • добавьте свой конкретный путь перед полем «значение переменной», отделенным точкой с запятой от существующей записи. не добавляйте пробел; и последняя запись

вы открыли cmd подскажите перед установкой git? Если это так, закройте и снова откройте его.


  1. на Мой компьютер = > Локальный диск (C:) = > Program Files(x86) = > Git => cmd
  2. щелкните правой кнопкой мыши git = > выберите Свойства
  3. под расположение Скопировать текст например — C:\Program файлы (x86)\Git\cmd
  4. вернитесь на рабочий стол
  5. щелкните правой кнопкой мыши Мой Компьютер
  6. выберите свойства
  7. открыть Advanced
  8. клик Переменные Среды
  9. в системных переменных найдите вызов переменной путь
  10. выберите переменная
  11. выберите Редактировать
  12. выберите значение переменной Текстовое Поле .
  13. перейти к краю текста и поставить точка с запятой(;)
  14. щелкните правой кнопкой мыши и нажать вставить
  15. Нажмите Ok

Если вы установили git для window (http://windows.github.com/), Затем найдите git.exe в диске» C». это будет что-то вроде

добавить в переменные среды окна, как сказано выше

простой маршрут, чтобы избежать возиться с переменными пути: переустановите git и выберите «использовать Git из командной строки Windows». Он будет принимать переменные пути для вас, как уже упоминалось. смотрите скриншот

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

  1. открыть командную строку cmd>
  2. выполнить следующую команду.
    set PATH=C:\Program Files\Git\bin;%PATH%
  3. тип git, он будет работать.

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

а. нажмите окно+пауза
b. нажмите на предварительную настройку системы.

c. нажмите на переменную окружения на вкладке Advance.

д’. Отредактировать Переменную PATH.

e. добавить строку ниже в конце инструкции.
;c:\Program Files\Git\bin;

f. нажмите OK!!
г. Откройте новое окно командной строки .
ч. Типа git и нажимаем Enter

Пуск — > Все Программы — >Git — >Git Bash

приведет вас непосредственно к оболочке Git.

Git должен быть настроен в переменных пути.

(на Windows 7) Откройте кнопку Пуск и введите environment . Нажмите на Edit the system environment variables . Нажмите Environment Variables . Прокрутите вниз до Path переменная в нижней части окна по имени system variables . Нажмите edit . В нижнем поле с именем variable value добавьте путь к папке git bin. (для меня это C:\Program Files (x86)\Git\bin но это может быть по-другому для вас.) Если нет точки с запятой ( ; ) между вашим путем и предыдущим, добавьте один там. Убедитесь, что вы не удаляйте другие переменные пути, только добавьте папку git bin в конец.

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

  1. перетащите курсор мыши в правый нижний угол экрана
  2. нажмите на значок поиска и введите: Панель управления
  3. нажмите на — > панель управления — > Система — > Дополнительно
  4. нажмите на переменные среды, в разделе системные переменные, найдите путь и нажмите на него.
Цукерберг рекомендует:  List-style-image - Как сделать картинку маркера для списка меньше

C:\Program файлы (x86)\Git\bin;C:\Program файлы (x86)\Git\cmd

Это сработало для меня

Йоу! У меня было много проблем с этим. Похоже, что Github приносит свою собственную консоль, которую вам нужно искать в вашем диске. Мне удалось, наконец, запустить его следующим образом:

  1. Нажмите Кнопку Старт.
  2. Поиск «GitHub «(без кавычек)
  3. щелкните правой кнопкой мыши на «GitHub «и выберите»Открыть расположение файла»

здесь имя пользователя это ваш компьютер имя пользователя

  1. найдите программу под названием «Git Shell». Дважды щелкните по нему.

откроется командная строка PowerShell. Затем вы можете запустить свои команды git нормально на нем.

Это потому, что во время установки вы выбрали переключатель по умолчанию, чтобы использовать «git» только с «Git bash». Если бы вы выбрали «Git и инструмент командной строки», то это не было бы проблемой.

  • Решение#1: поскольку вы уже установили git tool, Теперь перейдите в нужную папку, а затем щелкните правой кнопкой мыши и используйте «git bash here», чтобы запустить ту же команду, и она будет работать правильно.
  • решение#2: повторите попытку установки git-scm и выберите правильный выбор.

просто хотел добавить к ответу Абизерн. Если кто-то использует учетную запись без администратора, вы можете создать «локальную» переменную вместо «системной» переменной, которая позволяет получить доступ к стандартным/ограниченным учетным записям.

когда в окне» Переменные среды»:

1) Выберите «Новая. кнопка «внутри» пользовательских переменных for . » раздел.

2) Установите «имя переменной:» как «путь» и » значение переменной: «как» [ваш-git-путь] «(обычно находится по адресу C:\Program Files (x86)\Git\bin ).

3) затем нажмите кнопку ОК.

в Windows используйте msysgit чтобы получить приглашение bash с командой git.

  1. Правой Кнопкой Мыши «Мой компьютер»,
  2. выберите «Свойства»,
  3. открыть «дополнительно»,
  4. нажмите кнопку «Переменные среды»,
  5. выделите переменную» Path»,
  6. нажмите кнопку «Изменить», добавьте каталоги в путь.
    Если вы установили git 64bit, без изменений в папке установки по умолчанию, git будет в
    C:\Program Files\Git\bin;C:\Program Files\Git\cmd
  7. измените путь с вашим точным путем к git
  8. клик ЛАДНО.

если вы не знаете, где находится ваша папка Git: в windows 7/8/10 git должен быть найден:
— C:\Program Files (x86)\Git\bin;C:\Program Files (x86)\Git\cmd
— C:\Program Files\Git\bin;C:\Program Files\Git\cmd

закройте командную строку и выйдите. Затем снова откройте командную строку.

Я установил Git и попытался использовать командную строку в разделе Действия в Team explorer/Changes.

добавить путь в переменные среды

Примечание: путь может отличаться, но вы должны добавить как bin и cmd

после установки откройте приложение GitHub и в правом верхнем углу вы заметите значок Настройки. Выберите Параметры из выпадающего списка и выберите «оболочка по умолчанию» в качестве Cmd.


теперь попробуйте ввести «git shell» в поиске (ключ и тип windows) и выберите Git Shell. Он должен открыться в CMD, и теперь git должен быть распознан.

Для Пользователей Windows 10:

попробуйте запустить окно командной строки от имени администратора. Тип:

вы должны получить ответ, что-то вроде «git версии 2.17.1.окна.2».

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

теперь вы должны увидеть, что вы вошли в оболочку Git Bash с помощью цветной текст и все.

мой не будет работать, несмотря ни на что, пока я не буду использовать оболочку Git bash в качестве администратора. Просто хотел поделиться, если кто-то еще столкнется с подобной проблемой.

Это помогает мне : Я C:\Program файлы (x86)\Git\bin;C:\Program файлы (x86)\Git\cmd в пути для переменной среды.

Windows 7 32 — бит

Я использую git для моего приложения Ruby on Rails. Первый раз так.

(The .bat файл для редактирования использование notepad++ следовательно, нет необходимости в длительном процессе всякий раз, когда вам нужно отредактировать путь, вы можете следовать этим простым процессом после создания .bat-файл, следующий за учебниками по ссылке выше » файл называется row.летучая мышь.»)

  1. щелкните правой кнопкой мыши на .файл bat,
  2. редактировать с помощью Notepad++.
  3. найти путь.

вставить путь ниже последнего введенного пути.

)
Во время уроков я не помню ничего, что было сказано в что касается использования команды git, поэтому при запуске нового проекта у меня была такая же проблема после установки git. Основная проблема, с которой я столкнулся, заключалась в поиске папки с bin/git.exe (git.exe не появился в поиске с помощью меню «Поиск программ и файлов» в меню «Пуск») Примечание теперь я понял, что расположение может сильно отличаться — см. ниже.

чтобы найти bin / git.exe я следовал этим шагам

1 щелкните левой кнопкой мыши меню «Пуск» и найдите ->> все программы ->> GitHub inc. 2 щелкните правой кнопкой мыши оболочку git и выберите Открыть расположение файла 3 щелкните по папкам в папке в папку «bin»

(У меня было 4 папки с именами 1. IgnoreTemplates_fdbf2020839cde135ff9dbed7d503f8e03fa3ab4 2. ОРС-x86_0.5.1 3. PortableGit_c2ba306e536fdf878271f7fe636a147ff37326ad («bin / exe, найдено здесь

скопируйте полную ссылку, нажав на url исследователей (мой был «C:\Users\username\AppData\Local\GitHub\PortableGit_c2ba306e536fdf878271f7fe636a147ff37326ad\bin») открыть .bat файл в notepad++ и вставить с помощью инструкции о том, как добавить путь к вашему .bat-файл из учебников выше. Проблема решена!

Шпаргалка по консольным командам Git

Rem amet est soluta numquam incidunt neque. Quaerat veniam a aliquid sit vel. Sit omnis distinctio quos. At voluptatem dolor sequi natus consequatur.

Quibusdam ut placeat sed. Ut qui ut beatae facere. Est facere omnis earum ullam.

Earum quam vel aut commodi sint vel nam. Hic placeat qui quia quia praesentium. Labore dolor sint vero unde excepturi dolorem et. Magni sapiente voluptas impedit dolore et. Suscipit est officiis ipsa. Doloremque aut laborum dignissimos ipsum accusamus harum nihil. Omnis ut natus et incidunt aut culpa. Repellendus et autem eum qui et quia. Aliquid ducimus consequatur cum. Qui culpa delectus quos repudiandae quaerat quo amet.

Vel dolore sequi similique et maiores. Et quia quis laboriosam. Rerum minus quibusdam error sed.

Repellendus nobis occaecati nostrum voluptas. Aut voluptas nobis maiores sunt occaecati molestiae fugit. Aliquid eos corporis dolore velit pariatur. Maxime ex eaque omnis consequatur corrupti eligendi veritatis quod. Hic aliquid repellat dicta sed assumenda et nobis. Est ducimus qui quo. Blanditiis sequi reiciendis eos omnis cupiditate autem voluptates voluptatem. Sapiente doloremque sint sit eaque. Odit officiis sunt et. Qui tempore laborum laborum velit. Sapiente aut in repudiandae nihil.

Общее

Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит). Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс ( git add ), потом «сохраняем» ( git commit ).

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

Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).

Концепция GIT

Ключ к пониманию концепции git — знание о «трех деревьях»:

  • Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
  • Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
  • Директория .git/ — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).

Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.

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

Простейший цикл работ

  • Редактирование, добавление, удаление файлов (собственно, работа).
  • Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
  • Коммит (фиксация изменений).
  • Возврат к шагу 1 или отход ко сну.

Указатели

  • HEAD — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
  • ORIG_HEAD — указатель на коммит, с которого вы только что переместили HEAD (командой git reset . , например).
  • Ветка ( master , develop etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
  • Теги — простые указатели на коммиты. Не перемещаются.

Настройки

Перед началом работы нужно выполнить некоторые настройки:

Если вы в Windows:

Указание неотслеживаемых файлов

Файлы и директории, которые не нужно включать в репозиторий, указываются в файле .gitignore . Обычно это устанавливаемые зависимости ( node_modules/ , bower_components/ ), готовая сборка build/ или dist/ и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, возможно использование шаблонов.

Консоль

Длинный вывод в консоли: Vim

Вызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой git log -p fileName.txt ). При этом прямо в консоли запускается редактор Vim. Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести :q . Переход в командный режим из любого другого: Esc .

Если нужно что-то написать, нажмите i — это переход в режим вставки текста. Если нужно сохранить изменения, перейдите в командный режим и наберите :w .

Как пользоваться GitHub на компьютере с Linux

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

В данной статье приведены примеры использования сервиса на компьютере под управлением операционных систем семейства Linux. Мы рассмотрим, как создать проект на локальном компьютере и залить его на сервис с помощью командной строки. Рассмотренные варианты использования git также можно применять на desktop системах, запустив окно терминала.

Установка git

Управление выполняется с помощью приложения git. Если его нет в системе, установку можно выполнить из репозитория.

Если используем CentOS / Red Hat:

yum install git-core

Если используем Ubuntu / Debian:

apt-get install git

Если мы хотим воспользоваться сервисом с компьютера Windows или Mac OS, необходимо скачать и установить desktop версию с официального сайта.


Синтаксис

Команды имеют следующий синтаксис:

* полный перечень опций, команд и аргументов можно получить командой man git.

Создание проекта на локальном компьютере

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

Инициализируем проект для git:

Мы получим ответ похожий на:

Initialized empty Git repository in /projects/.git/

Это означает, что репозиторий git создан.

Теперь добавим файлы в репозиторий:

* данной командой мы добавили папку и ее содержимое в репозиторий git.

Отправка данных на GitHub

Теперь можно отправить данные на сервис. Для этого у нас должна быть зарегистрированная учетная запись и создан репозиторий на GitHub.

Создание репозитория

Переходим на портал github.com и входим в систему или проходим несложную регистрацию:

Проходим процесс подтверждения, что мы не робот. Затем завершаем несколько шагов регистрации, нажимая Submit. В итоге мы получим письмо на адрес электронной почты, которую указали при регистрации. Необходимо будем подтвердить email, перейдя в письме по кнопке Verify email address.

Создаем репозиторий. Для этого кликаем по иконке профиля и переходим в раздел Your repositories:

И кликаем по кнопке New. В следующем окне даем название репозиторию и нажимаем Create repository:

Мы увидим страницу с путем к репозиторию:

Заливаем проект в репозиторий на GitHub

Добавляем комментарий к нашему проекту:

git commit -m «Очередное изменение проекта» -a

* где Очередное изменение проекта — произвольный комментарий; параметр -a указывает, что комментарий нужно применить ко всем измененным файлам.

Теперь подключаемся к созданному репозиторию:

git remote add origin https://github.com/dmosktest/project1.git

* где dmosktest — логин, который был указан при регистрации на github, а project1 — название, которое мы задали, когда создавали репозиторий.
* удалить удаленный репозиторий можно командой git remote rm origin.

Закидываем проект на GitHub:

git push origin master

* где master — ветка проекта (веток может быть несколько).

В нашем проекте на GitHub должны появиться файлы проекта:

Получение файлов с GitHub

Для загрузки на компьютер файлов, создаем каталог с проектом и переходим в него:

Проводим начальную настройку локального репозитория:

Подключаемся к удаленному репозиторию:

git remote add origin https://github.com/dmosktest/project1.git

Скачиваем проект командой:

git pull https://github.com/dmosktest/project1.git master

Клонирование проекта

Например, использую наш репозиторий:

git clone https://github.com/dmosktest/project1.git

* данная команда создаст в текущей папке каталог project1 и инициализирует его как локальный репозиторий git. Также загрузит файлы проекта.

Возможные ошибки

1. При попытке отправить данные на GitHub, получаем ошибку:

error: src refspec master does not match any.
error: failed to push some refs to ‘https://github.com/dmosktest/project1.git’

* где dmosktest/project1.git — путь к нашему репозиторию.

Причина: проект ни разу не был зафиксирован (закоммичен).

Решение: добавляем комментарий к нашему проекту:

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

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

Превратим наш проект в репозиторий git. Для начала просто создайте папку git_site , затем введите следующие команды:

Где mkdir — команда для создания новых каталогов;
cd — переход в указанную папку; команда cd используется для смены текущего каталога.
cd .. на уровень выше
cd \ в корень текущего диска
d: перейти на диск D
cd c:\windows перейти в каталог windows

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

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

$ git add

Далее в наш каталог ( git_site ) можно поместить файлы сайта. Скопируем файлы сайта в папку git_site . Далее, давайте добавим файлы в репозиторий.

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

$ git status

Команда $ git status позволяет отследить состояние репозитория. Эта команда позволяет узнать, какие изменения необходимо зарегистрировать git (при необходимости, отменить).

$ git commit –a , $ git commit –am «. «, $ git commit –a –m «. «

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

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

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

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

$ git stash

Иногда возникает ситуация, когда вы работаете на одной ветке и вам срочно нужно переключиться на другую ветку, при этом регистрировать изменения нежелательно. Для таких случае существует команда stash . Команда stash позволит сохранить изменения, не регистрируя их. Например:

$ git stash list

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

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

$ git stash pop


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

$ git merge

Чтобы объединить ветки, например, ветку hotfix с веткой master , необходимо выполнить следующие команды:

Давайте удалим ветку hotfix . Для этого воспользуемся следующей командой:

Ветвление

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

$ git checkout –b

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

Этим мы к тому же переключились на новую ветку hotfix . Теперь все внесенные в файлы изменения будут относиться к ветке hotfix .

Теперь давайте внесем изменения в файл index.html . Например, давайте подключим стилевой файл. И в самом стилевом файле увеличим размер шрифта у параграфа. Сделаем git status и зарегистрируем изменения:

Теперь, если мы переключимся на ветку master , мы не найдем там изменения, внесенные на ветке hotfix . Таким образом, git меняет содержимое файлов при изменении ветки.

git init (инициализируем git реп-й)

Чтобы проинициализировать Git репозиторий введите команду:

Будет создана папка /.git/ . Репозиторий — это скрытая папка, в которой работает Git.

git status (Проверяем статус)

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

git add (добавляем файл)

Чтобы сообщить Git о том, что пора начать отслеживать изменения, внесенные в файл, мы сначала должны добавить его с помощью:

Сейчас git отслеживает наш файл test.txt. Давайте выполним

снова, чтобы понять, что изменилось!

git commit (фиксируем изменения)

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

git commit -m «Add cute octocat story»

Если вы опустите метку -m из командной строки, git перенесет вас в редактор по вашему выбору. В первой строке введите комментарий: «Added h1 tag». Сохраните файл и выйдите из редактора (для этого в редакторе по-умолчанию (Vim) вам нужно нажать клавишу ESC , ввести :wq и нажать Enter ). Вы увидите . (http://githowto.com/ru/commiting_changes)

Используем маску

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

git commit –a –m ”new comment here”

Коммитится только то, что проиндексировано. Индексирование происходит функцией add (она и добавляет файлы и индексирует их).

Коммит идет не сразу: файлы, которые находятся под присмотром ГИТ необходимо проиндексировать (то есть если нам нужно сделать коммит для 1-файла, то мы помещаем его в индекс и закоммитится только он). С помощью ключа –a мы индексируем ВСЕ файлы и, соответственно, сразу выполняем коммит (например,

—amend

git commit —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

Где origin — имя удаленного репозитория.

Плюсы и минусы bitbucket.org и GitHub

На bitbucket.org можно создавать неограниченное количество приватных репозиториев (плата взимается, если к репо привязываются более 5 пользователей). На GitHub большинство проектов open source, также для приватного репо уже приходится платить – даже для 1-го пользователя. Для своих проектов я рекомендую все же использовать bitbucket.org.

Процесс разработки:

Переходим на боевой сервере по SSH и стягиваем (PULL) с GitHub, при этом разработка идет на ПК разработчика (может быть более 1-го разработчика, с локального ПК делаем PUSH на GitHub).

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

Ключ –v показывает путь к удаленному репо.

Подробно о любой команде можно узнать:

Коммитим и пушим на GitHub (global настройки matching и simple)

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

То по команде git push произойдет следующее: если на боевом репо есть 2 ветки, которые соответствуют 2-м локальным веткам, то на удаленный репо протолкнутся эти 2 ветки.

В данном случае протолкнется лишь текущая ветка.

git remote (прсматриваем уд. реп.)

Команда git remote позволяет просмотреть удаленные репозитории

git remote -v параметр -v позволяет увидеть URL-адреса.

git remote add (добавляем уд. реп.)

Добавление удаленных репозиториев под короким именем:

git remote add [сокращенное имя] [url]

git remote add kuku [url] — теперь вместо полного URL-адреса в командную строку можно вводить имя kuku

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

Иниц. пустой реп.
Добавляем реп.
извлекаем все данные (.git)
и стягиваем ветку master из реп. kuku

git remote show (получаем инфо. об уд. реп.)

Команда git remote show [имя удал. реп.] позволяет просмотреть дополнительную информацию о конкретном удал. реп.

git fetch (извлечение данных из уд. реп.)

Извлечение данных из уд. реп. выполняется командой:

После исполнения данной команды у вас должны появиться ссылки на все ветки удаленного проекта

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

git push (проталкиваем изменения)

Команда git push говорит Git, куда отправить наши изменения, когда все готово. Итак, запушим наши локальные изменения в наш удаленный репозиторий на GitHub. Имя удаленного репозитория origin , а ветка по умолчанию называется master (не думайте пока что о ветках). Параметр -u позволит нам в будущем не указывать дополнительные параметры, а просто выполнять git push . Git будет знать, что нужно делать.


git push -u origin master

где origin – это куда отправляем (удаленный репозитарий), а
master это то, что отправляем (в нашем случае master ).

git pull (стягиваем изменения)

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

git pull origin master

Забираем изменения из ветки ( master ) на удаленном сервере ( origin ) и проводим слияние с активной веткой.

git diff, git diff HEAD

Команда git diff показывает не все изменения, сделанные с момента последней фиксации состояния, а только те, которые еще не проиндексированы.

Команда git dif —cached покажет проиндексированные изменения

Ой! Похоже, кто-то еще вносил изменения в наш проект! Давайте посмотрим, что изменилось, с нашего последнего коммита, с помощью команды

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

Еще один полезный вариант использования git diff — просмотр изменения, которые уже были помещены в промежуточную область. Запомните! В этой области находятся файлы, которые git готов(!) закоммитить.

git reset (Откатываем изменения/удаляем файлы из промежуточной области)

Вы можете удалять файлы из промежуточной области с помощью git reset .

git reset octofamily/octodog.txt

git log (информация о последних коммитах)

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

покажет список последних коммитов и их хеши SHA1.

На самом верху мы видим самый последний коммит. Функция log очень богатая – позволяет смотреть, что было до и что было после, у git хорошая помощь (faq), чтобы просмотреть все возможности log можно воспользоваться командой:

Например, мы можем выводить историю в более удобном формате:

%h – короткий код самого коммита;
%an – автор;
%ar – когда был сделан;
%s — комментарий.

Ограничиваем коммиты по времени:

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

—stat используется для получения краткой статистики по каждому коммиту.

—graph добавляет графику с историей ветвлений и слияний

git checkout (Отмена изменений)

Файла был удален из промежуточной области. Но сам файл все еще находится в проекте! Файлы могут быть возвращены в состояние последнего коммита с помощью команды:

git checkout — octocat.txt

git checkout 82f5

Для указания коммита достаточно первых нескольких символов его хеша ( 82f5 ), но можете скопировать и весь хеш.

git checkout (получаем уд. ветку)

Для получения собственной копии [имя_ветки] (из уд. реп.) можно воспользоваться командой :

(?) или просто git checkout [имя_ветки] ; но тут главное, чтобы [имя_ветки] присутствовала в уд. реп.

git branch (создаем ветку)

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

Давайте создадим новую ветку и назовем ее clean_up :

git branch clean_up

git branch -d (удаление ветки)

Вы можете использовать команда git branch -d
для удаления ветки. Сделаем это:

git branch -d clean_up

git branch -vv (наблюдаем за уд. ветками)

Команда git branch -vv позволяет получить список всех веток, за которыми идет наблюдение (за какой веткой следит на уд. сервере и на сколько опережает соотв. ветку на уд. сервере).

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

git rm (удаляем файлы)

Команды git rm , которая не только удалит файлы с диска, но и добавит сведения об их удалении в Git.

Если вы проиндексировали файл, то следует воспользоваться параметром -f , который инициирует принудительное удаление

merge (смержим в текущую ветку другую)

Настал момент, когда вы должны смержить изменения из ветки clean_up в ветку master .

Мы уже находимся в ветке master (вы уже знаете, как в этом убедиться). Осталось только сказать Git, что мы хотим смержить в текущую ветку другую — clean_up :

git merge clean_up

git clone

По url создаем локальный репозиторий, склонировав удаленный, например, с gitHub. Предварительно необходимо выполнить команду git init .

$ mkdir epicgame & cd epicgame
$ git init
$ git remote add
$ git clone

rejected

Если при push появляется rejected , то это говорит о том, что необходимо скачать изменения с удаленного сервере и уже затем push -ть.

Конфликты

Сообщение о конфликте:

В статусе ( git st ) появляется блок:

То есть у нас появились файлы, которые автоматически не с merg -сь.

То есть в самом файле:

Это указатель на тот commit, с которым мы сейчас работаем. Нужно выбрать или оставить свои изменения ( // Fry comment ) или оставить строку пользователя Bender ( // Bender comment ).

Разные полезные команды:

Добавляем пользователя:

(config – работаем с конфигом; —global – ключ для глобального конфига; user.name — имя).

(задаем email глобально)

(данные о гите и о пользователе; хранятся в c:\users\name_user\.gitconfig )

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

На одном уровне с папкой .git создаем текстовый документ: .gitignore (убираем разрешение .txt, то есть сохраняем с All types(.) в Notepad++).

В самом файле указываем игнорирование, например:


$ git rm

Файл name_file.txt станет обратно ( untracked ; от track — следить), то есть вернется в состояние перед командой git add .

СВОЙ РЕДАКТОР ДЛЯ КОММЕНТАРИЕВ

Без ключа –m откроется редактор vim ( :x – означает сохранить и выйти).

Поменяем редактрор по умолчанию (vim), он будет открываться в том случае, если мы не прописываем комментарий в командной строке.

Изменения можно проверить в C:\Users\name_user\.gitconfig

ВЕТКИ ($ git checkout –b new_branch)

Создаем ветку new_f и тут же переходим в нее.

С использованием –v показывает ветки с последними коммитами.

merge

Чтобы избежать каких-либо недочетов сперва стоит merge -ть рабочую ветку(если она есть) с master , а уже потом на master merge -ть с рабочей (это делается для лучшего выявления конфликтов).

Указываем какой утилитой будем разрешать конфликты

Далее в случае наличия CONFLICT прописываем (этим мы запускаем утилиту):

Базовые команды

# Настройка

Флаг -global добавленный к командам выше позволит сохранить эти настройки для всех проектов:

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

Для того, чтобы использовать VS CODE как difftool запустите команду:

И добавьте строки:

# Справка по команде

git help [command-name]

Если вы используете VS Code, как редактор по умолчанию, то установите расширение open in browser, чтобы открывать документацию в браузере.

# Инициализация проекта

Для начала работы зайдите в вашем терминале в директорию, в которой собираетесь использовать Git и выполните команду git init , вы увидите сообщение похожее на это:

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

Добавляет выбранные версии файлов в staging область для последующего коммита.

Добавляет все файлы в очередь для последующего коммита.

# Commit

Создает коммит с комментарием после ключа -m . Предварительно должны быть указанны с помощью git add файлы.

Если не указать файлы командой git add , то команда git commit не создаст коммит. Эти два действия можно объединить, указав ключ -a . Данный ключ показывает, что нужно создать коммит всех измененных файлов, учитывая удаленные, но при этом новые файлы (которых еще нет в индексе) учитываться не будут.

# Pull и Push

Рассмотрим команды pull и push на практическом примере. Создадим на гитхабе новый тестовый проект. Поставьте галочку чтобы создать readme файл:

Затем создадим директорию, инициализируем в ней Git, и выполним команды remote add и pull :

Таким образом мы создали директорию и инициализировали в ней локальный репозиторий. С помощью команды remote add origin при привязали локальный репозиторий к удаленному. А с помощью команды git pull origin master были скопированы файлы (в данном случае файл readme) с удаленного репозитория на локальный из ветки origin master .

Теперь откроем файл README.md из локальной директории, добавим туда что-нибудь и выполним следующие команды:

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

  • git push — добавляет данные на удаленный сервер с локального компьютера
  • git pull — забирает данные на локальный компьютер с удаленного сервера

# Clone

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

Предыдущая команда создаст репозиторий в директории libgit2 . Для клонирование в директорию с другим именем:

Команду clone можно использовать как короткий вариант, заменяющий серию команд:

# Branch

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

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

Когда вы создаете новую ветвь, создается копия master ветви. В процессе работы над своей ветвью, ветвь master может обновиться кем-то. В таком случае, вы можете забрать эти изменения в свою ветвь, с помощью команды pull .

Перейти в ветвь:

Создать ветвь и сразу же в неё перейти:

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

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

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

Это удалит ветвь из локального репозитория. Для удаления ветви из удаленного репозитория выполните команду:

# Просмотр старых версий проекта

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

Посмотрите лог и скопируйте id интересующего коммита:

Затем выполните команду checkout для данного коммита, например:

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

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

Обратите внимание, что когда вы находитесь в предыдущей версии коммита с помощью команды checkout , то команда git log покажет лог только до текущего коммита, в котором вы находитесь. Чтобы увидеть все коммиты воспользуйтесь командой git reflog .

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

# Status

Посмотреть текущую ветку, незакоммиченные файлы и другую информацию:

# Stash

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

Просмотреть стек спрятанных данных можно с помощью команды git stash list . Дополнительные данные покажет команда git stash show .

Строка вида stash@ , отображаемая при выполнении команды git stash list — это номер сохраненных изменений в стеке, по которому можно эти данные восстановить или удалить.

Для восстановления данных есть команда git stash apply , если запустить её без параметров, будет восстановлена рабочая область последнего в стеке сохранения. Чтобы восстановить конкретный номер в стеке укажите его: git stash apply stash@ <0>или с помощью сокращенного варианта git stash apply 0 .

Команда git stash pop применяет спрятанные изменения и удаляет их из стека.

Команда git stash drop [stash-name] удаляет указанную заначку, или последнюю, если номер явно не указан.

# Дополнительно

Для получения подробной информации по командам смотрите их описание на официальном сайте.

Как запустить окно Git Bash с определенным рабочим каталогом с помощью script?

Как я могу запустить новое окно Git Bash с указанным рабочим каталогом с помощью script (либо Bash или пакета Windows)?

Моя цель — запустить несколько окон Git Bash из одного script, каждый из которых настроен на другой рабочий каталог. Таким образом, я могу быстро начать работу после загрузки компьютера вместо того, чтобы открывать окна Git Bash и перемещать их в правильный рабочий каталог.

Git Bash использует cmd.exe для своих терминалов плюс расширения от MSYS/MinGW, которые предоставляются sh.exe , своего рода оболочкой cmd.exe . В Windows вы запускаете новый терминал с помощью команды start .

Таким образом, оболочка script, которая запускает новый Git Bash терминал с определенным рабочим каталогом:

Эквивалентная партия Windows script:

Чтобы получить тот же размер шрифта и окна, что и Git Bash, запущенный из меню «Пуск», проще всего скопировать настройки ярлыка меню «Пуск» в значения по умолчанию для команд консоли (чтобы изменить значения по умолчанию, открыть cmd.exe , щелкните левой кнопкой мыши значок верхнего левого окна и выберите «По умолчанию» ).

Другой вариант — создать ярлык со следующими свойствами:

Цель должна быть:

«% SYSTEMDRIVE%\Program Files (x86)\ Git\bin\sh.exe» —login

В начало — папка, в которую вы хотите запустить приглашение Git Bash.

Попробуйте параметр —cd =. Предполагая, что ваш GIT Bash находится в папке C:\Program Files\Git, это будет:

«C:\Program Files\Git\git-bash.exe» —cd=»e:\SomeFolder»

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

«C:\Program Files\Git\git-bash.exe» —cd=»%1″

Давайте еще добавить ответ от @Drew Noakes:

Параметр cd должен быть одним из параметров указания рабочего каталога.

Также обратите внимание, что у меня нет никаких —login param: Вместо этого я использую другое дополнительное приложение, предназначенное только для ключей SSH: Pageant (агент аутентификации PuTTY).

Начало работы:

Точно так же, как @Drew Noakes упоминается/показывается здесь раньше, я тоже использую его.

Горячая клавиша:

Такие ярлыки — еще одна известная функция в Windows. Но есть ограничение: чтобы ярлык вступил в силу, он должен быть помещен где-то в подкаталог User: Рабочий стол в порядке.

Если вы не хотите, чтобы он был видимым, но все же активируемым, поместите этот файл .lnk , то есть в папку быстрого запуска, поскольку этот каталог предназначен для таких ярлыков. (независимо от того, отображается ли на рабочем столе) # 76080 # 3619355

Это команда, которая может быть выполнена непосредственно в Run dialog box (ярлык win + R ), а также хорошо сохраняется как .bat script:

Я не знаком с Git Bash, но считая, что это оболочка Git (например, git-sh ), находящаяся в /path/to/my/gitshell , и ваша любимая терминальная программа называется `myterm ‘, вы можете script следующее:

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

Windows 10

Это в основном ответ @*********, но обновленный для Win 10, и предполагает, что ваша установка bash от Git bash для Windows от git официальные загрузки.

cmd /c (start /b «%cd%» «C:\Program Files\GitW\git-bash.exe») && exit

Я закончил использование этого после того, как я потерял элементы контекстного меню для Git bash в качестве моей команды для запуска из параметров реестра. Если вам это интересно, я сделал это:

  • Создайте новый ключ с именем Bash в shell в HKEY_CLASSES_ROOT\Directory\Background\shell
  • Добавьте строковое значение в Icon (а не новый ключ!), это полный путь к вашему git — bash.exe, включая часть git — bash.exe. Возможно, вам придется обернуть это в кавычки.
  • Измените значение по умолчанию Bash на текст, который вы хотите использовать в контекстном меню
  • Добавить под-ключ к Bash под названием command
  • Изменить значение command по умолчанию на cmd /c (start /b «%cd%» «C:\Program Files\GitW\git-bash.exe») && exit

Затем вы сможете закрыть реестр и начать использовать Git bash из любого места, где находится настоящий каталог. Например, This PC не является реальным каталогом.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих