Как навсегда удалить несколько коммитов из удаленной ветки

05 Ничего никогда не теряется

Что же случается с ошибочными коммитами? Оказывается, что коммиты все еще находятся в репозитории. На самом деле, мы все еще можем на них ссылаться. Помните, в начале этого урока мы создали для отмененного коммита тег «oops». Давайте посмотрим на все коммиты.

Результат:

$ git hist --all
* 45fa96b 2011-03-09 | Revert "Oops, we didn't want this commit" (oops) 
* 846b90c 2011-03-09 | Oops, we didn't want this commit 
* fa3c141 2011-03-09 | Added HTML header (HEAD, v1, master) 
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) 
* 43628f7 2011-03-09 | Added h1 tag 
* 911e8c9 2011-03-09 | First Commit 

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

Разное

git fetch -p

Alternatives:

git remote prune origin
git fetch origin pull/id>/head:branch-name>

Alternatives:

git pull origin pull/id>/head:branch-name>
git remote

Alternatives:

git remote show

Автокомплит Git-команд в bash

curl http://git.io/vfhol > ~/.git-completion.bash && echo '[ -f ~/.git-completion.bash ] && . ~/.git-completion.bash' >> ~/.bashrc

Не отслеживать файл (без удаления)

Удаляет файл из git, сохраняя при этом его локальную копию

git rm --cached file_path>

Alternatives:

git rm --cached -r directory_path>

Обновить все субмодули

git submodule foreach git pull

Alternatives:

git submodule update --init --recursive
git submodule update --remote

Alternatives:

git cherry -v master branch-to-be-merged>

Retrieve the commit hash of the initial revision

 git rev-list --reverse HEAD | head -1

Alternatives:

git rev-list --max-parents=0 HEAD
git log --pretty=oneline | tail -1 | cut -c 1-40
git log --pretty=oneline --reverse | head -1 | cut -c 1-40

Adding a project to repo using subtree

git subtree add --prefix=directory_name>/project_name> --squash git@github.com:username>/project_name>.git master

Get latest changes in your repo for a linked project using subtree

git subtree pull --prefix=directory_name>/project_name> --squash git@github.com:username>/project_name>.git master

Ignore one file on commit (e.g. Changelog)

git update-index --assume-unchanged Changelog; git commit -a; git update-index --no-assume-unchanged Changelog

Поиск коммита с багом при помощи бинарного поиска

git bisect start                    # Search start 
git bisect bad                      # Set point to bad commit 
git bisect good v2.6.13-rc2         # Set point to good commit|tag 
git bisect bad                      # Say current state is bad 
git bisect good                     # Say current state is good 
git bisect reset                    # Finish search 

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

git blame file-name>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

V конференция «Клеверенс»

27 марта в 12:00, Москва, беcплатно

tproger.ru

События и курсы на tproger.ru

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

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

Log

git log --no-merges --raw --since='2 weeks ago'

Alternatives:

git whatchanged --since='2 weeks ago'
git log --branches --not --remotes

Alternatives:

git log @{u}..
git cherry -v

Показать количество строк, которое добавил/удалил пользователь

git log --author='Your Name Here' --pretty=tformat: --numstat | gawk '{ add += ; subs += ; loc +=  -  } END { printf "added lines: %s removed lines: %s total lines: %s
", add, subs, loc }' -

Alternatives:

git log --author='Your Name Here' --pretty=tformat: --numstat | awk '{ add += ; subs += ; loc +=  -  } END { printf "added lines: %s, removed lines: %s, total lines: %s
", add, subs, loc }' - # on Mac OSX
git log --pretty=oneline --graph --decorate --all

Alternatives:

gitk --all

Общее

Git — система контроля версий (файлов). Что-то вроде возможности сохраняться в компьютерных играх (в Git эквивалент игрового сохранения — коммит)

Важно: добавление файлов к «сохранению» двухступенчатое: сначала добавляем файл в индекс (), потом «сохраняем» ()

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

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

Ключ к пониманию

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

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

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

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

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

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

Указатели

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

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

Если вы в Windows:

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

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

# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти
```bash
# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти

# Ввод в командном режиме
:q!             — выйти без сохранения
:wq             — сохранить файл и выйти
:w filename.txt — сохранить файл как filename.txt

GitHub

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

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

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

Операции отмены

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

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

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

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

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

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

Note

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

Очевидно, смысл изменения коммитов в добавлении незначительных правок в последние коммиты и, при этом, в избежании засорения истории сообщениями вида “Ой, забыл добавить файл” или “Исправление грамматической ошибки”.

Отмена индексации файла

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

Прямо под текстом “Changes to be committed” говорится: используйте для исключения из индекса.
Давайте последуем этому совету и отменим индексирование файла :

Команда выглядит несколько странно, но — работает!
Файл изменен, но больше не добавлен в индекс.

Note

Команда может быть опасной если вызвать её с параметром .
В приведенном примере файл не был затронут, следовательно команда относительно безопасна.

На текущий момент этот магический вызов — всё, что вам нужно знать о команде .
Мы рассмотрим в деталях что именно делает и как с её помощью делать действительно интересные вещи в главе Раскрытие тайн reset.

Отмена изменений в файле

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

В выводе команды из последнего примера список изменений выглядит примерно так:

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

Как видите, откат изменений выполнен.

Important

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

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

Помните, все что попало в коммит почти всегда Git может восстановить.
Можно восстановить даже коммиты из веток, которые были удалены, или коммиты, перезаписанные параметром (см. Восстановление данных).
Но всё, что не было включено в коммит и потеряно — скорее всего, потеряно навсегда.

prev | next

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

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

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

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

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

  • — добавляет удалённый репозиторий с заданным именем;
  • — удаляет удалённый репозиторий с заданным именем;
  • — переименовывает удалённый репозиторий;
  • — присваивает репозиторию с именем новый адрес;
  • — показывает информацию о репозитории.

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

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

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

Branch

git checkout -b branch-name>

Alternatives:

git branch branch-name> && git checkout branch-name>
git branch -m new-branch-name>

Alternatives:

git branch -m  new-branch-name>
git push origin --delete remote-branch-name>

Alternatives:

git push origin :remote-branch-name>

Удалить ветки, которые уже слиты с master

git branch --merged master | grep -v '^\*' | xargs -n 1 git branch -d

Alternatives:

git branch --merged master | grep -v '^\*\|  master' | xargs -n 1 git branch -d # will not delete master if master is not checked out
git branch -a --contains commit-ish>

Alternatives:

git branch --contains commit-ish>

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

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

Слияние

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

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

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

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

Перемещение

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

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

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

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

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

Представим сценарий:

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

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

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

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

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

Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

Подготовка Git

Установка Git

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

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

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

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

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

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

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

Базавые операции:

Рабочая схема:

  1. Создать локальный репозиторий.(клонировать удаленный или создать новый).

  2. Выбрать версию проекта. «git checkout хеш»(если нужна свежая скачанная версия, пропускаем этот пункт).

  3. Внести изменения в файлах.

  4. Проверить изменнения с помощью «git status». Если все хорошо, надписи красные , продолжаем работу.

5)$ git add имя файла — проиндексировать изменненые файлы, зафиксировать.

  1. Пришло время создать коммит $ git commit -m»комментарий». После этого появится новая версия вашего проекта.

  2. Проверить новый коммит командой $ git log. Если все нормально переходим дальше.

  3. Самое время отправить на сервер.

$ git push https://github.com/Eclerrr/readme.git master.

Ссылка примерная

Работа с историей:

Эти команды помогут избежать ошибок в будущем.

$ git log - показывает все создынные коммиты на текущей версии.

Отображается примерно так:

commit 903badab46602ecfdd504e16f099f837901789b7
Author: Eclerr eclerrrr@yandex.ru>
Date:   Tue Jan 19 18:24:50 2016 +0300
Создан файл commands.txt. Добавлен абзац 'Начало работы'

903badab46602ecfdd504e16f099f837901789b7 — хеш коммита(Имя коммита)

Если изменения нужно откатить до индексации, поможет команды:

$ git checkout файл.

По факту эта команда переместит вас в последнию версию файла, без каких либо изменений. Данная операция напоминает ctrl + z в обычном редакторе. Естественно, нужно находится в тойже ветке, что и изменяемый файл.

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

$ git reset HEAD файл

Команда отменяет индексацию , а затем можно опять воспользоваться checkout.

Работа с коммитами:

После создания локального репозитория можно начинать в нем работу(создание, удаление, редактирование файлов). Как только вы ввели в консоль $ git init или $ git clone,git сразу начинает отслеживать папку в которой лежит скрытый файлик .git. Любые изменения фиксируются в гите.


$ git status — Определить состояние файлов.

$ git add — Многофунциональная команда.

$ git add имя файла — Фиксирует измененный файл в гите. Предворительная фаза перед коммитом(подстраховка).

$ git add

— фиксирует все файлы в каталоге.(Использовать с осторожностью)

После фиксирования, файлы можно коммитеть(Сохранять).

$ git commit -m"комментарий" - Создает коммит (версию) вашего проекта.

Метка -m добавляет комментарий к комиту. Можно коммитеть без метки , но тогда git выведет редактор по умолчанию(Редактор linux). Настройка редактора будет описана в другом разделе. Лучше делать логичные коммeнтарии, типа «Добавлен файл index.html».

$ git shortlog -s -n  - количество сделанных коммитов у данного пользователя

Перемещение по коммитам:

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

$ git checkout 903ba - переходит на указанный коммит. 

903ba в данном случае 5 первых символов хеша коммита. checkout возвращает вас назад во времени, а это значит что коммиты, созданные после указанного не будут отображаться в git log(их по факту еще не создали).

$ git checkout master - переместит на последний коммит(вернет в настоящие).

Редактирование коммитов:

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

$ git commit --amend -m"Перезапись коммита", При этом перезапишется последний коммит.

Работа с удаленным репозиторием

После того, как вы сделали достаточное количество коммитов, самое время отправить ваш проект со всеми сохранениями на удаленный репозиторий(к примеру GitHub).

$ git push https://github.com/Eclerrr/readme.git master   -  отправляет проиндексированные и закоммиченные изменения вашего проекта на сервер.

url репозитория указан тестовый

master — начальная ветка удаленного репозитория(Можно использовать любую другую ветку)

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

$ git ************************************************

Для удобства url можно поместить в короткое имя:

$ git remote add pb git://github.com/paulboone/ticgit.git

pb — короткое имя url, в дальнейшем с ним можно работать.

$ git remote -v - позволяет вывести все имена url.
Ссылка на основную публикацию