Полезные github команды и их описание:
git log просмотр истории коммитов
Имеется куча параметров этой команды, например:
> можно самому отредактировать нужную последовательность вывода лога format
> ограничить количество выводимых коммитов -2
> -p, который показывает дельту (разницу/diff), привнесенную каждым коммитом > дельту изменений по словам --word-diff
> количество выводимых деталей short, full, и fuller
> --graph показывает историю слияний и ветвлений в виде ASCII-граф
> ограничение по времени коммита --since и --until
> опция --author позволяет фильтровать по автору
> опция --grep позволяет искать по ключевым словам в сообщении
> либо указать путь изменений в конце команды
> --not [ветка] вывести все кроме указанной ветки
> --abbrev-commit при выводе будет сокращать хэш до уникальных значений
> [ветка1]..[ветка2] показывает каких коммитов нет в одной ветке, и есть у другой. Если опустить ветку2, то подставится HEAD
> [ветка1]...[ветка2] показывает какие коммиты недостижимы по обеим веткам сразу. Обычно используют с --left-right, которая показывает какой коммит к какой ветке отностися
git show для просмотра содержимого коммита
> [head / имя ветки]@{количество дней или название дня по-английски] показывает какое значение HEAD или ветки было в репозитории указанное время назад
> [HEAD / хэш]^[номер родителя] показывает родителя коммита, можно использовать ~ для показа прародителя или же несколько знаков ^^^, так же их можно комбинировать
можно создавать псевдонимы (alias) для любых команд
git config утилита, которая позволяет просматривать и устанавливать параметры, контролирующие все аспекты работы Git'а и его внешний вид. Эти параметры могут быть сохранены в трёх местах для различных уровней.
> user.name установка имени юзера
> user.email установка email юзера
> core.editor выбор редактора
> merge.tool встроенная diff-утилита для сравнения и разрешения конфликтов
> --list выводит текущие настройки
> --help список всех опций, которые есть в Git
> --global commit.template [file] использует по умолчанию данный файл в качестве комментария коммита
> --global user.signingkey [id-gpg-ключа] задаёт ключ для подписи аннотированных меток, чтобы каждый раз не указывать его в git tag -s <имя-метки>
> core.excludesfile указывает путь для .gitignore, если он будет лежать в другой директории
> --global core.autocrlf true автоматически концы строк из LF будут сконвертированы в CRLF при выгрузке кода. Windows использует для переноса строк и символ возврата каретки, и символ перехода на новую строку, в то время как в системах Mac и Linux используется только символ перехода на новую строку. Можно указать Git'у, чтобы он конвертировал CRLF в LF только при коммитах, установив настройку core.autocrlf в input. false если всё делается для Windows.
git init создание репозитория в существующем каталоге
> --bare для создания чистого репозитория на сервере
git add указывает индексируемые файлы
> -i или --interactive git переходит в режим интерактивной оболочки, позволяет выбрать необходимые изменения для добавления в коммит. Необходимости перехода в интерактивный режим особо нет, можно воспользоваться аналогом -p или --patch
git status инструмент, используемый для определения какие файлы в каком состоянии находятся
> у выводимой инфы указаны некоторые команды в виде подсказок возможных действий
файл-список .gitignore для игнорирования файлов (создать в корне рабочего каталога)
git stash прячет "грязные" незакоммиченные файлы. Позволяет вернуться к этим изменениям после смены ветки
> list показывает спрятанные изменения
> apply [name] применяет спрятанные изменения с именем из списка. Если опустить имя, применится последнее спрятанное
> apply --index пытается применить изменения в индексе
> drop [name] удалить спрятанное
> pop [name] применить изменения и сразу удалить их из стека
> branch создаст ветку из спрятанных изменений и удалит их из стека
git rm удаление файлов
> -f для принудительного удаления проиндексированного файла
> --cached для удаления файла из-под надзора Git (аналог фала .gitignore)
> можно передавать файлы, каталоги или glob-шаблоны
чтобы увидеть, что изменено, но пока не проиндексировано git diff без аргументов
> --cached или --staged (>Git 1.6.1) посмотреть проиндексированные файлы, которые войдут в следующий коммит
> --check выявляет ошибки с пробельными символами в тексте перед отправкой коммита
> [ветка1] ... [ветка2] увидеть дельту между последним коммитом ветки, на которой вы находитесь, и их общим предком с другой веткой. Эта команда покажет вам только те наработки в ветке2, которые были внесены после её ответвления от ветки1
git commit для фиксации изменений
> --amend для замены/корректировки сообщения последнего коммита, а также берёт файлы из индекса и добавляет к коммиту
> -v в комментарий будет помещена дельта/diff изменений, таким образом можно точно увидеть всё, что сделано
> -a заставляет Git автоматически индексировать каждый уже отслеживаемый на момент коммита файл, позволяя обойтись без git add
> -m "comment" добавляет комментарий к коммиту
git mv перемещение или переименование файла, директории или символьной ссылки
git remote просмотр настроенных удалённых серверов
> -v посмотреть какому URL соответствует сокращённое имя в Git
> show [удал. сервер] получить больше информации о сервере
> rename переименование сокращенного имени удалённого сервера. это также меняет для вас имена удалённых веток
> rm удалить ссылку
> add [сокращение] [url] добавить новый удалённый Git-репозиторий под именем-сокращением, к которому будет проще обращаться
git push [удал. сервер] [ветка] отправка ветку на удалённый сервер
> [ветка]:[удал.ветка] отправит ветку на сервер в ветку с названием [удал.ветка], тогда как без :[удал.ветка] отправит в ветку с тем же названием
> [удал. сервер] :[ветка] удалить ветку на удалённом сервере
> -f для замены ветки на сервере
git clone получить копию существующего репозитория. По умолчанию эта команда автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали (подразумевается, что на удалённом сервере есть ветка master). Автоматически добавляет удалённый репозиторий под именем origin.
git fetch [url] получение данных из удалённого сервера. Можно использовать сокращенное имя. Эта команда забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.
> git fetch original ищет, какому серверу соответствует origin; извлекает оттуда все данные, которых ещё нет, и обновляет локальное хранилище данных; сдвигает указатель origin/master на новую позицию
git pull автоматически извлекает и сливает данные из удалённой ветки в вашу текущую ветку. Используется, если есть ветка, настроенная на отслеживание удалённой ветки . Как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
git tag просмотр имеющихся меток
> метки по умолчанию не коммитятся, для отправки на удалённый сервер git push origin [tag] либо множественные метки опцией --tags для команды git push
git branch [name] создание ветки
> -d удалить ветку
git checkout [name] перейти на ветку
> -b чтобы создать ветку и сразу на неё перейти
> --track или git checkout -b [ветка] [удал. сервер]/[ветка] создается отслеживаемая ветка, на основе удалённой
git merge [branch] сливает текущую ветку с указанной [branch]
> чтобы посмотреть, какие файлы не прошли слияние (на любом этапе после возникновения конфликта), выполните команду git status
> git mergetool откроет графический инструмент для разрешения конфликта
> --squash берёт всю работу на сливаемой ветке и сжимает её в один коммит, не являющийся коммитом-слиянием, и помещает его на верхушку текущей ветки
> --no-commit сообщает Git'у, что не нужно автоматически записывать коммит
git rebase [осн.ветка] или git rebase [осн. ветка] [тем. ветка] осуществляет перемещение. Снимок состояния получается такой же как и при merge, разной будет только история. При перемещении история изменений будет отображаться линейной. rebase применяет изменения из одной линии разработки в другую в том порядке, в котором они были представлены, тогда как merge объединяет вместе конечные точки двух веток. Перемещенная ветка обгоняет основную по коммитам. Не перемещайте коммиты, которые вы уже отправили в публичный репозиторий
> --onto [куда] [промежуточное ответвление] [откуда] перемещение с промежуточным ответвлением
git request-pull выводит сообщение для отправки мейнтейнеру, через сайт "pull request". Команда request-pull принимает в качестве аргумента имя базовой ветки, в которую вы хотите включить свою работу, и URL репозитория, из которого мейнтейнер может получить ваши наработки
git format-patch генерирует файлы в формате mbox, которые можно отправить по почте. git send-email отправить патч по почте
> команда -m сообщает Git'у о необходимости отслеживания переименований файлов
git apply или git am применение патчей, полученных по почте либо через git diff. Есть ещё git patch. Команду git apply стоит использовать, только если нет другого выхода, и патчи уже созданы при помощи diff. Чтобы применить патч, созданный при помощи format-patch, используйте команду git am
> --check если вывода нет, то патч должен наложиться без ошибок
> -3 применить трёхходовое слияние, по умолчанию не включена
> -R применить патч в перевёрнутом виде (?)
git merge-base [ветка1] [ветка2] выделить предка двух веток
git cherry-pick [коммит] сливает коммит в ветку
git archive делает архив последнего состояния вашего кода для тех бедолаг, которые не используют Git
> --format=zip создаёт zip-архив
> export-ignore игнорирование файлов для добавления в архив
git shortlog получает что-то наподобие лога изменений, описывающего что появилось нового со времён последнего релиза
div rev-parse [ветка] показывает хэш SHA ветки
git reflog ссылочный лог где находились HEAD и ветки в течение последних нескольких месяцев
git blame посмотреть, когда и кем каждая строка была в последний раз отредактирована
> опция -L [number,num], чтобы ограничить вывод строк
> -C Git проанализирует аннотируемый файл и попытается выявить, откуда фрагменты кода в нём появились изначально, если они были скопированы откуда-то
git bisect выполняет бинарный поиск по истории коммитов, и призвана помочь как можно быстрее определить, в каком коммите была внесена ошибка
> start чтобы запустить процесс
> bad, чтобы сказать системе, что текущий коммит, на котором вы сейчас находитесь, сломан
> затем, необходимо сказать bisect, когда было последнее известное хорошее состояние с помощью git bisect good [хороший_коммит]
> reset, чтобы сбросить HEAD туда, где он был до начала бинарного поиска
git submodule add [link] [алиас] добавляет внешний проект в качестве подмодуля
> init для инициализации вашего локального файла конфигурации
> update для получения всех данных из подмодуля и перехода к соответствующему коммиту, указанному в вашем основном проекте
1. Руководство по созданию SSH ключей http://github.com/guides/providing-your-ssh-key
2. Документ с хорошими советами по созданию коммитов, из которых делаются патчи - лежит в исходном коде Git'а в файле Documentation/SubmittingPatches
3. При сопровождении проекта мейнтейнер, как правило, создаёт ветки с добавлением пространства имён — к примеру, 'sc/ruby_client', где 'sc' — это сокращённое имя автора, приславшего свою работу
3. Сопровождение проекта, его интегрирование и слияние
4. Перезапись/переупорядочивание/разбиение коммитов, filter-branch
