Git команды консоли: cyberspacedk/Git-commands: Шпаргалка по консольным командам Git

Основные Git команды: шпаргалка

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

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

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

Системы контроля версий: немного теории

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

Условно системы контроля версий можно разделить на три типа:

• локальные;
• централизованные;
• распределенные.

Виды систем контроля версий

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

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

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

Git: описание и особенности системы

Система контроля версий Git обладает своими особенностями. Большинство систем хранит файлы, изменяя их в соответствии с инструкциями в проекте. То есть, к примеру, версия текущей разработки под номером 3 может содержать данные об изменениях в файле А и Б. А уже версия 4 будет иметь в себе А, Б и В. Таким образом, файлы меняются по необходимости.

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

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

Для сохранения целостности данных применяется метод хеширования каждого изменённого файла методом SHA-1. Это позволяет системе контроля версий точно знать, где, кто и когда изменил файл.

Git: установка

Для того чтобы начать работать с Git, нужно его установить. Система контроля версий доступна для использования в Windows, Mac OS, Linux.

Версию для Windows можно скачать по адресу: git-for-windows.github.io. После загрузки программу нужно установить. Инсталлятор простой, так что эта процедура не должна вызвать проблем.

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

Первые команды

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

• git config —global user.name »Имя»;
• git config —global user.mail »Адрес электронной почты».

На этом же этапе необходимо настроить метод окончания строк с помощью двух команд:

• git config —global core.autocrlf true;
• git config —global core.safecrlf false.

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

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

• Init: данная команда создаёт новый репозиторий.

Пример использования: init имя проекта.

• Clone. Производит копирование существующего репозитория с удалённого источника.

Вот так используется команда git clone: clone git://github.com/путь к репозиторию.

• Add. Наиболее часто используемая команда в системе контроля версий Git. Она выполняет простую задачу — добавляет указанные файлы в особую область, именуемую индексом или сценой. В неё можно перенести несколько файлов или папок, которые необходимо будет впоследствии добавить в репозиторий или, выражаясь на языке Git, «закоммитить».

Пример использования этой Git команды выглядит так: add некий_файл.txt.

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

• Diff. Показывает разницу состояний. Например, с помощью этой Git команды можно определить, есть ли изменения между папкой с проектом и индексом.
• Commit. Выполняет сохранение слепка всего того, что находилось в индексе непосредственно в базу данных. В результате работы Git команды на экране отобразится текстовый файл, в котором можно указать, какие именно изменения были произведены. А также будет выведена информация о том, сколько файлов подверглись коммиту, и его контрольная сумма. Главное — не забывать о том, что после изменения в базу попадут только те данные, которые были занесены в индекс командой git add.

Дополнительные команды Git

• Reset. О функциях этой команды говорит ее название. Она просто выбрасывает из специальной промежуточной области — индекса, указанный файл, помещённый туда по случайности. Стоит осторожно обращаться с reset при использовании команды с ключом — — hard, так как это затронет и файлы в рабочей папке, что может привести к непредвиденным последствиям.
• Rm. Наиболее точно эту команду можно описать как обратную git add, так как она удаляет файлы из индекса. Правда, при этом ещё и из рабочей папки.

Пример использования: git rm некий_файл.txt.

• Mv. Служит для перемещения файла.
• Clean. Предназначена для очистки папки проекта от ненужных файлов.

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

Работа с ветками репозиториев в Git

Для управления ветками в Git имеется специальный набор команд. Они способны соединять, удалять, создавать ветвления в Git. Список команд представлен ниже.

• Branch. У этой команды имеется в наличии несколько ключей, используя которые можно гибко управлять ветками в проекте. Branch представляет собой некий многопрофильный инструмент для полноценного контроля за состоянием репозитория. Простой вызов git branch выдаст перечень всех имеющихся веток хранилища. Ключ -v добавленный к команде отобразит какие коммиты были зафиксированы за последнее время. А использование -d приведёт к удалению указанной ветки. Branch умеет не только удалять, но и создавать. Выполнение git branch имя_ветки приведёт к организации новой ветки в проекте. Стоит учесть, что при этом указатель текущего рабочего положения бывает иным. К примеру, создав имя_ветки, можно на самом деле находится в ветке master.
• Чтобы переместиться в нужный пункт, существует команда Git checkout нужная_ветка, которая переставит указатель в необходимую ветку.
• Checkout. Как уже говорилось выше, выполняет переключение.
• Merge. Данная команда позволяет производить слияние нескольких веток воедино.
• Log. Функция отображает все изменения от начала проекта и до последнего коммита. Использование разнообразных ключей совместно с вызовом команды позволяет расширить ее функционал. Например, вызов git log -p -2 позволит просмотреть подробную информацию об изменениях в каждом коммите. Второй ключ -2 говорит о том, что нужно показать лишь 2 последних изменения. Аргумент —stat, добавленный к вызову git log, выполнит практически то же самое, что и -р, но в более подробной и при этом компактной форме. Также с помощью git log можно выводить информацию об изменениях, создав собственный формат отображения, используя опции format ключа pretty. Для придания особого вида нужно использовать некое подобие регулярных выражений. Например, такая запись get log —pretty=format »%h, %an, %ar, %s» выведет краткий хэш коммита, затем его автора, дату и комментарий изменения. Это очень удобно использовать при просмотре большого количества коммитов.

Команды для распределенной работы в системе

• Fetch. При вводе данной команды git консоль выполнит перенос всех изменений с удалённого хранилища в локальное.
• Pull. Команда git pull представляет собой симбиоз двух перечисленных выше — git fetch и git merge. То есть она сначала получает сведения из удалённого репозитория, а затем выполняет слияние с использующейся в данный момент веткой.
• Push. Именно от названия этой команды в среде пользователей появилось выражение «запушить», что означает соединение с удаленным репозиторием и передачу туда изменений из локального.

Команды удаленного управления

• Remote. Представляет собой мощный инструмент для управления удалёнными репозиториями. С помощью remote их можно удалять, просматривать, перемещать или же создавать новые.
• Archive. Название говорит само за себя. Команда позволяет создавать архив с нужными изменениями, например, для подготовки к передаче его по Сети.

Как использовать данную шпаргалку

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

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

Командная работа в Git / Хабр

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

Ниже я хочу описать свой опыт командной работы над проектом с использованием git’а.

1. Общий принцип

Рабочий процесс у меня организован следующим образом.

Я ведущий разработчик тире руководитель отдела тире проджект менеджер. У меня в команде есть несколько разработчиков.

Моя работа заключается в следующем:

1) поговорить с заказчиком

2) превратить смутное и путанное пожелание заказчика в четко сформулированную задачу

3) поставить эту задачу разработчику

4) проверить результат выполнения задачи разработчиком

5) неудовлетворительный результат вернуть разработчику на доработку

6) удовлетворительный результат представить заказчику на утверждение или сразу отправить в продакшн

7) утвержденный заказчиком результат отправить в продакшн

8) неутвержденный заказчиком результат вернуть разработчику на доработку

Работа разработчика, соответственно, заключается в следующем:

1) получить от меня задачу

2) выполнить ее

3) отправить мне результат

4) если задача вернулась на доработку — доработать и снова отправить мне

Для управления задачами я использую Trac. Так же в Trac’е ведется документация по проекту, как программерская, так и пользовательская.

Сформулировав задачу, я записываю ее в Trac и назначаю какому-то разработчику. Разработчик, выполнив задачу, переназначает ее мне. Я проверяю результат и, либо снова переназначаю ее разработчику, либо отмечаю как выполненную.

Алгоритм работы с git’ом и общая картина происходящего схематически представлены на картинке:

Теперь от теоретической части перейдем к практической и разберемся, что все это значит и как работает.

2. Git

Установите Git. Прочитайте какой-нибудь мануал. Разберитесь с локальным репозиторием.

Обратите внимание — эта статья не про команды git’а, а про то, как увязать эти команды в нужную последовательность. Поэтому далее я буду приводить команды git’а без подробных объяснений, предполагая, что назначение отдельных команд вам известно.

3. Доступ к репозиторию

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

Gitosis — это набор скриптов, реализующих удобное управление git-репозиториями и доступом к ним. Работает это так:

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

— все обращения к репозиториям происходят по SSH, под именем этого пользователя, авторизация пользователей производится по ключам

— при входе по SSH автоматически запускаются скрипты gitosis, которые, в зависимости от настройки, разрешают или запрещают дальнейшие действия с репозиториями

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

4. Установка gitosis

Для установки gitosis’а нужно (сюрприз!) вытянуть установочный репозиторий gitosis’а с сервера разработчика gitosis’а:

$ git clone git://eagain.net/gitosis.git

Установить gitosis:

$ cd gitosis

$ su

# python setup.py install

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

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

$ su

# adduser gituser

А затем инициализировать gitosis в домашнем каталоге созданного пользователя, с открытым ключом того, кто будет администратором gitosis’а. Открытый ключ, понятно, нужно положить куда-то, откуда его сможет прочитать пользователь gituser:

# su gituser

$ cd ~

$ gitosis-init < id_rsa.pub

Обратите внимание — пользователь gituser и администратор gitosis’а — это не одно лицо. Пользователь gituser является просто «хранителем» репозиториев и сам никаких действий вообще никогда не выполняет.

Я в качестве администратора gitosis’а использую другого зарегистрированного в системе пользователя. Но, вообще говоря, администратору вовсе не обязательно быть зарегистрированным в системе пользователем. Главное, указать при инициализации gitosis’а открытый ключ администратора.

После инициализации gitosis’а в домашнем каталоге пользователя gituser появится каталог repositories, в котором и будут храниться все репозитории. Сначала там будет только репозиторий gitosis-admin.git, в котором хранятся настройки самого gitosis’а.

Обратите внимание — по некоторым причинам, связанным с особенностями разных версий Питона, может понадобиться прописать права на исполнение скрипту post-update, находящемуся в репозитории gitosis’а:

$ chmod 755 ~/repositories/gitosis-admin.git/hooks/post-update

На этом установка gitosis’a закончена и начинается настройка.

5. Настройка gitosis’а и создание репозиториев

Настройка gitosis’а заключается в изменении администратором содержимого репозитория gitosis’а.

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

Теперь вытягиваем настроечный репозиторий gitosis’а:

$ git clone gituser@githost:gitosis-admin.git

Где githost — это имя сервера, на котором мы установили gitosis (и где будем хранить репозитории).

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

После этого в домашнем каталоге администратора появится каталог gitosis-admin. В этом каталоге нас интересует файл gitosis.conf, именно в нем производится настройка всех репозиториев.

По умолчанию в нем будет нечто такое:

[group gitosis-admin]

writable = gitosis-admin

members = admin@host

Что означает «пользователю admin разрешена запись в репозиторий gitosis-admin».

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

[group project-write]

writable = project

members = superdeveloper

[group project-read]

readonly = project

members = developer1 developer2 developer3 user1 user2

[group dev]

writable = dev

members = superdeveloper developer1 developer2 developer3

где superdeveloper — ведущий разработчик, developer* — разработчики, user* — прочие интересующиеся

Этот конфиг означает следующее:

1) ведущему разработчику позволено писать в главный репозиторий

2) всем позволено читать из главного репозитория

3) ведущему разработчику и всем разработчикам позволено писать в рабочий репозиторий

Все эти пользователи, как и администратор gitosis’а, вовсе не обязательно должны быть зарегистрированными в системе пользователями. Главное, чтобы у них были открытые ключи.

Открытые ключи указанных в конфиге пользователей нужно скопировать в каталог gitosis-admin/keydir. Файлы ключей должны иметь имена вида имя_пользователя.pub. В данном примере это будут имена superdeveloper.pub, developer1.pub, user1.pub и.т.д.

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

$ git add.

$ git commit -am ‘Add project Project’

И отправить коммит в центральный репозиторий, где сделанные настройки подхватит gitosis:

$ git push

Все, теперь наш сервер репозиториев настроен и нужные репозитории созданы (вру, репозитории еще не созданы, но будут созданы автоматически при первом коммите).

6. Назначение репозиториев

Если в предыдущем разделе у вас возник вопрос — почему для одного проекта нужно два репозитория — то вот ответ.

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

Я пробовал разные схемы командной работы и наиболее удобной на данный момент мне представляется «двухрепозиторная» схема. Работа в ней ведется примерно следующим образом:

1) я ставлю задачу разработчику

2) разработчик берет актуальную ветку проекта из главного репозитория и делает с нее локальный бранч

3) в этом бранче разработчик решает поставленную задачу

4) бранч с выполненной задачей разработчик отправляет в рабочий репозиторий

5) я беру из рабочего репозитория этот бранч и проверяю его

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

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

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

Во-вторых, актуальная ветка у меня никогда не бывает в нерабочем состоянии.

Вторая причина, на самом деле, является более важной. Несанкционированные изменения в любой момент можно откатить, на то и система контроля версий. А вот разрулить нерабочее состояние актуальной ветки может быть весьма затруднительно.

Поясню на примере.

Допустим, разработчик Р1 сделал правку П1 и отправил ее в ветку master. Я проверил эту правку и нашел ее плохой. Плохую правку нужно переделывать.

Пока я проверял, разработчик Р2 сделал правку П2 и тоже отправил ее в master. Эта правка оказалась хорошей. Хорошую правку нужно отправлять в продакшн.

Но теперь в ветке master находятся две правки, хорошая и плохая. Хорошую правку нужно бы отправить в продакшн, но присутствие плохой правки не позволяет это сделать. Придется ждать, пока плохая правка будет исправлена.

Или другой пример — все правки хорошие, но некоторые не утверждены заказчиком. Неутвержденные правки не дают попасть в продакшн утвержденным, а утверждение может происходить довольно долго.

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

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

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

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

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

7. Первичная загрузка проекта в репозиторий

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

Создаем локальный репозиторий в каталоге проекта и загоняем в него файлы проекта:

$ cd /старый/каталог/проекта

$ git init

$ git add.

$ git commit -am ‘poehali!’

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

$ git remote add origin gituser@githost:project.git

Теперь оправляем коммит в главный репозиторий:

$ git push origin master

Все, проект отправлен в главный репозиторий. Теперь старый каталог проекта можно смело грохнуть и начать работу уже в новом каталоге (или вообще на другом компе), под управлением git’а.

8. Репозиторий ведущего разработчика

Переходим в новый каталог (или вообще на другой комп) и вытягиваем главный репозиторий:

$ cd /новый/каталог/проекта

$ git clone gituser@githost:project.git

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

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

$ git push origin master:stage

А затем вытянем тестовую ветку из главного репозитория уже под собственным именем:

$ git checkout -b stage origin/stage

Теперь локальный репозиторий содержит две ветки, master и stage. Обе ветки связаны с одноименными ветками в главном репозитории.

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

Кроме того, нужно указать местонахождение рабочего репозитория dev:

$ git remote add dev gituser@githost:dev.git

9. Инфраструктура проекта

Проект у нас включает не только репозитории, но и «исполняющие» узлы — продакшн и отладку.

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

Запуск продакшна, не вдаваясь в детали, был таким:

1) зарегистрировать в системе нового пользователя, из-под которого будет работать продакшн

2) добавить этого пользователя в gitosis (см. раздел 5, в моем примере это user*)

3) клонировать главный репозиторий project в каталог этого пользователя

4) Настроить виртуальный хост Apache (или что там вам больше нравится) на каталог проекта

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

$ git pull

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

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

$ git checkout -b stage origin/stage

Теперь pull в отладке будет вытягивать обновления из тестовой ветки.

10. Репозиторий разработчика

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

Главный репозиторий нужно склонировать:

$ git clone gituser@githost:project.git

А рабочий репозиторий просто добавить в конфиг:

$ git remote add dev gituser@githost:dev.git

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

11. Памятка разработчика

Проверить почту. Если пришло уведомление из Trac’а о новой задаче — начать работать:

$ quake exit

Создать новый бранч на основе актуальной ветки из главного репозитория (мы у себя договорились называть бранчи номерами тикетов из Trac’а):

$ git checkout -b new_branch origin/master

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

$ git checkout -b old_branch dev/old_branch

Вытянуть последние изменения:

$ git pull

---
Выполнить задачу в новом бранче. Тут происходит работа с кодом.
---

Если в процессе работы были созданы новые файлы — добавить их в бранч:

$ git add .

Сохранить изменения в локальном репозитории:

$ git commit -am ‘komment’

Отправить новый бранч в рабочий репозиторий:

$ git push dev new_branch

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

$ git push

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

10 goto проверить почту;

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

Во-первых, бранчи, отправленные в рабочий репозиторий, более не нужны локально и могут быть смело удалены:

$ git branch -D new_branch

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

$ git branch -r

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

$ git remote prune dev

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

12. Действия ведущего разработчика

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

Затем я обновляю данные об удаленных репозиториях:

$ git remote update

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

$ git branch -r

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

$ git checkout -b branch dev/branch

Если это не новый бранч, а исправление старого, то нужно еще вытянуть обновления:

$ git pull

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

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

Если правка простая, то я просто сливаю проверенный бранч с актуальной веткой и отправляю обновленную актуальную ветку в главный репозиторий:

$ git checkout master

$ git merge branch

$ git push

После этого я удаляю бранч у себя локально и из рабочего репозитория, больше этот бранч никому и никогда не понадобится:

$ git branch -D branch

$ git push dev :branch

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

Если же правка требует согласования, то проверяемый бранч сливается не с актуальной веткой, а с тестовой:

$ git checkout stage

$ git merge branch

$ git push

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

$ git branch -D branch

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

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

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

(оригинал статьи)

Github — без командной строки / Хабр

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

Многие опытные пользователи github-а знают, что отнюдь не для всего обязательно нужно использовать командную строку. Все это так.

Здесь я собрал несколько рецептов, используя которые, вы сможете без единой команды git, скопировать себе репозиторий, создать там вспомогательную ветку, в ней что-то отредактировать, добавить/удалить файлы/папки, сделать пулл-реквест в оригинальный репозиторий. А по истечению какого-то времени, когда в оригинальном репозитории накопятся изменения не отраженные в нашей копии — синхронизировать эти два репозитория — причем тоже без единой git-команды.

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

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

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

Создать новую ветку (копированием из текущей) можно прямо в окошке смены ветки. Вводим имя — enter — готово.

Добавление файлов

Создание новых файлов здесь же — далеко ходить не нужно. Жмем «+»

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

Здесь можно отредактировать как сам файл, так и его имя. В редактировании имени есть одна интересная особенность — используя ‘/’ и ‘../’ можно перемещаться по дереву каталогов. (в итоге, при создании файла, заодно будут созданы, не существовавшие до этого папки)

Синхронизация форка с основным репозиторием

Часто бывает так, мы делаем форк репозитория, правим там что-то, делаем pull-request. Автор принимает этот pull-request и мы успокаиваемся на некоторое время. Через пару месяцев, мы вновь хотим что-то улучшить, но наша копия уже безнадежно устарела. Здесь требуется синхронизация. Легко можно найти как это сделать, используя командную строку. Намного реже встречается объяснение того, как это сделать непосредственно на github.

Итак:

• открываем свой форк на github
• заходим с список его pull-request-ов
• жмем «New Pull Request», по умолчанию github берет за базу оригинальный репозиторий и сравнивает наш с ним, но нам нужно наоборот
• жмем «switching the base», (если мы что-то редактировали в своей копии, нужно нажать Edit, и вручную поменять базу) — сразу же увидим все, что в оригинальном репозитории было добавлено в последнее время
• жмем «Создать Pull-request», даем ему какое-нибудь понятное имя, типа «Update from original»
• жмем «Send pull request»
• жмем «Merge pull request» и подтверждаем это действие — все

Столько пунктов, скажите вы — согласен, в виде списка выглядит громоздко, попробуйте видео — всего 53 секунды. Я сам, попробовав всего раз, сразу же запомнил и стал использовать.

P.S.

Я не стал здесь описывать очевидные вещи: как сделать форк, как сделать pull-request — так как они делаются в 1 клик.

А что еще из неочевидного можно делать с репами без использовани командной строки?

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

Настройка

git config user.name "Username"
git config user.email "[email protected]"

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

git config --global user.name ‘Username’
git config --global user.email ‘[email protected]’

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

git config --global core.editor "code --wait"

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

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

[diff]
    tool = vscode
[difftool "vscode"]
    cmd = code --wait --diff $LOCAL $REMOTE

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

git help [command-name]

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

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

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

D:\webdev\git\first-use>git init
Initialized empty Git repository in D:/webdev/git/first-use/.git/

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

Add

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

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

Commit

git commit -m "this is comment"

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

git commit -am "this is another comment"

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

Pull и Push

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

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

mkdir test-project
cd test-project
git init
git remote add origin https://github.com/ValeriyDyachenko/test-project
git pull origin master

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

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

git add .
git commit -m "test push"
git push origin master        

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

Подведем итог:

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

Clone

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

git clone https://github.com/libgit2/libgit2 

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

git clone https://github.com/libgit2/libgit2 newname

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

mkdir test-project
cd test-project
git init
git remote add origin https://github.com/ValeriyDyachenko/test-project
git pull origin master 

Branch

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

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

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

Создать ветвь:

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

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

git checkout -b newbranch

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

git push origin newbranch

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

git checkout master
git merge newbranch

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

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

git push -d origin newbranch

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

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

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

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

git checkout bc9f07bbadb153d88a4daa3bd21aafe054b15055

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

git checkout -b [your-new-branch-name]

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

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

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

git reset --hard [commit-id]

Status

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

Stash

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

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

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

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

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

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

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

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

  редактировать статью

Источник — bxnotes

обновлено May 8, 2018

ОсновыКонтрибьют

15 команд Git, о которых вы, возможно, не знали

Перевод статьи
«15 Git Commands You May Not Know».

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

Я хочу познакомить вас со списком из 15 команд Git, о которых вы, возможно, еще не знаете, но я надеюсь, что они вам пригодятся при освоении этого прекрасного инструмента.

1. Изменение последнего
коммита

git commit --amend

—amend позволяет добавлять подготовленные
(staged) изменения к предыдущему коммиту
(например, добавлять забытый файл). Если
изменений нет, то —amend даст вам возможность
переписать сообщение этого коммита
(commit message). А если приписать —no-edit, то
наоборот: можно будет внести изменения
в сам коммит, не затрагивая commit message.

Узнать больше: git help commit

2. Интерактивное добавление
отдельных частей файлов

git add -p

-p (или —patch) позволяет интерактивно
выбирать для добавления в коммит части
отслеживаемый файлов. Таким образом
коммит будет содержать только нужные
изменения.

Узнать больше: git help add

3. Интерактивное скрытие
отдельных частей файлов

git stash -p

Опцию —patch можно добавлять не только
к git-add. Добавленная к git stash, она позволяет
интерактивно выбирать части отслеживаемых
файлов, которые вы хотели бы скрыть.

Узнать больше: git help stash

4. Скрытие файлов, включая
неотслеживаемые

По умолчанию при скрытии файлов
неотслеживаемые файлы не учитываются.
Чтобы изменить это поведение и включить
в stash также и эти файлы, нужно использовать
параметр -u. Есть также параметр -a
(—all), который позволяет скрывать как
неотслеживаемые, так и игнорируемые
файлы, но это, вероятно, не то, что вам
обычно нужно.

5. Интерактивный «сброс»
выбранных частей файлов

git checkout -p

—patch можно также использовать для
выборочного сброса частей отслеживаемых
файлов. Я задал этой команде псевдоним
git discard.

Узнать больше: git help checkout

6. Переключение в предыдущую
ветку

git checkout -

Эта команда позволяет вам быстро
переключиться на ранее просматриваемую
ветку. Знак дефиса это псевдоним
предыдущей ветки. Его можно использовать
и с другими командами.

7. Сброс всех локальных
изменений

git checkout .

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

8. Показать изменения

git diff --staged

Эта команда показывает все подготовленные
изменения (проиндексированные). Если
вы введете просто git diff, будут показаны
изменения только в рабочей директории.

Узнать больше: git help diff

9. Локальное переименование
веток

git branch -m old-name new-name

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

git branch -m new-name

Узнать больше: git help branch

10. Переименование веток
удаленно

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

git push origin :old-name

git push origin new-name

11. Открыть все файлы с
конфликтами одновременно

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

git diff --name-only --diff-filter=U | uniq  | xargs $EDITOR

12. Что изменилось?

git whatchanged --since=‘2 weeks ago’

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

13. Удаление файла из последнего
коммита

Скажем, вы сделали коммит файла по
ошибке. Этот файл можно быстро удалить
из последнего коммита путем комбинации
команд rm и commit —amend:

git rm --cached <file-to-remove>

git commit --amend

14. Поиск веток

git branch --contains <commit>

Эта команда покажет все ветки, содержащие
указанный коммит.

15. Локальная оптимизация
репозитория

git gc --prune=now --aggressive

Узнать больше: git help gc

Бонус

Хотя мне очень нравится CLI, я настоятельно
рекомендую обратить внимание на Magit,
чтобы еще больше улучшить вашу работу
с Git. Это одна из лучших программ, которые
я использовал.

Кроме того, с помощью команды help можно
получить совершенно фантастический
обзор рекомендуемых рабочих процессов
Git. Почитайте внимательно!

git help workflows

11 концепций и команд git, которые заставят вас плакать

В самой популярной системе контроля версий нужно хорошо разбираться. Проверьте знание команд git, ответив на 11 каверзных вопросов.

Последние опросы на Stack Overflow показывают, что более 70% разработчиков используют git для ПО с открытым исходным кодом и для коммерческих продуктов. Преимущества этой VCS для командной работы сложно переоценить.

Вопрос 1. В чем разница между fork, branch и clone?

Сложность: ⭐⭐

• Fork – удаленная копия репозитория на сервере, отличная от оригинала. Это даже не git-концепция, а, скорее, политико-социальная идея.
• Clone – это не то же самое, что и fork. Клон удаленного репозитория располагается локально. Фактически при клонировании копируются все данные, включая историю коммитов и существующие ветки.
• Branch, или создание ветки, – это способ внести изменения в проект и объединить их в итоге с остальным кодом. Ветка является частью репозитория.

Источник: stackoverflow.com

Вопрос 2. В чем разница между pull request и branch?

Сложность: ⭐⭐

• Branch – это просто отдельная версия кода.
• Pull request – этот попытка добавить собственные изменения в репозиторий другого владельца. Чтобы сделать такой запрос, нужно взять чей-то проект, создать отдельную ветку, а затем предложить слить ее с остальными.

Источник: stackoverflow.com

Вопрос 3. Объясните разницу команд git pull и git fetch?

Сложность: ⭐⭐

Простыми словами, git pull = git fetch + git merge.

• Когда вы делаете pull, git старается автоматически выполнить всю работу за вас. Этот процесс зависит от контекста, git объединит все коммиты и обновит ту ветку, на которой вы в данный момент находитесь. Слияние осуществляется автоматически, без вашего участия. Если система обнаружит несопоставимые различия, произойдет конфликт.
• Когда вы делаете fetch, git просто собирает все коммиты целевой ветки, которых у вас еще нет, и сохраняет их локально. Объединения веток при этом не происходит. Это очень полезно, если вам необходимо актуальное состояние репозитория, но оно может нарушить вашу работу. Ознакомившись с изменениями, вы можете слить их в вашу ветку с помощью merge.

Источник: stackoverflow.com

Вопрос 4. Как отменить предыдущий коммит?

Сложность: ⭐⭐⭐

Предположим, у вас сложилась следующая ситуация. Указатель HEAD находится в C, а (F) – это текущее состояние ваших файлов.

   (F)
A-B-C
    ↑
  master

Откатиться к предыдущему состоянию можно с помощью группы команд git reset с разными флагами.

• Чтобы полностью отменить коммит, используйте

git reset --hard HEAD~1

Теперь HEAD указывает на B. Флаг --hard стирает все изменения ваших файлов до состояния B.

• Чтобы отменить коммит, но сохранить сделанные в нем изменения, просто выполните

git reset HEAD~1

Так мы передвигаем HEAD на один коммит назад (на B), но оставляем файлы в том состоянии, в котором они находятся. git status покажет, что файлы соответствуют фиксации C.

• Чтобы отменить коммит и сохранить все проиндексированные файлы, используйте

git reset --soft HEAD~1

Вызовите git status и убедитесь, что в индексе git находятся те же файлы, что и раньше.

Источник: stackoverflow.com

Вопрос 5. Что такое git cherry-pick?

Сложность: ⭐⭐⭐

Команда git cherry-pick используется для перенесения отдельных коммитов из одного места репозитория в другое, обычно между ветками разработки и обслуживания. Этот механизм отличается от привычных команд git merge и git rebase, которые переносят коммиты целыми цепочками.

git cherry-pick <commit-hash>

Источник: stackoverflow.com

Вопрос 6. Расскажите о преимуществах forking workflow.

Сложность: ⭐⭐⭐

Работа через форки принципиально отличается от других популярных методов организации командной разработки. Вместо того чтобы использовать один серверный репозиторий в качестве центральной кодовой базы, здесь каждый разработчик получает свой собственный репозиторий. Чаще всего эта модель применяется в общедоступных open source проектах.

Основное преимущество forking workflow заключается в том, что все изменения вносятся без загрязнения истории проекта. Разработчики делают push в собственные репозитории, а доступ к центральному есть только у менеджера.

Когда обновление готово к интеграции, программист делает pull-запрос в главный репозиторий, а менеджер одобряет и вносит его.

Источник: atlassian.com

Вопрос 7. В чем разница между HEAD, рабочим деревом и индексом?

Сложность: ⭐⭐⭐

• Рабочее дерево (рабочая директория, рабочее пространство) – это дерево исходных файлов, которые вы можете видеть и редактировать.
• Индекс (область подготовленных файлов, staging area) – это один большой бинарный файл .git/index, в котором указаны все файлы текущей ветки, их SHA1, временные метки и имена. Это не отдельная директория с копиями файлов.
• Указатель HEAD – это ссылка на последний коммит в текущей извлеченной ветке.

Источник: stackoverflow.com

Вопрос 8. Расскажите о gitflow-организации рабочего процесса.

Сложность: ⭐⭐⭐

Модель gitflow использует две параллельные «долгие» ветки для хранения истории проекта: master и develop.

• Master – это полностью готовое к релизу состояние со всеми пройденными тестами.
  • Hotfix – ветки обслуживания, или хотфиксы, которые используются для быстрых патчей. Они очень похожи на feature, но вместо develop-ветки базируются на master.
• Develop – ветка, в которой объединяются и тестируются все отдельные разработки. После прохождения проверок они отправляются в master.
  • Feature – отдельная ветка для каждой новой функциональности, изменения из которой отправляются в develop.

Источник: atlassian.com

Вопрос 9. Когда следует использовать git stash?

Сложность: ⭐⭐⭐

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

$ git status
On branch master
Changes to be committed:
new file: style.css
Changes not staged for commit:
modified: index.html
$ git stash
Saved working directory and index state WIP on master: 5002d47 our new homepage
HEAD is now at 5002d47 our new homepage
$ git status
On branch master
nothing to commit, working tree clean

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

# спрятать все, что вы уже успели сделать
$ git stash save

# внести необходимые изменения

# добавить их в последний коммит
$ git add -u
$ git commit --ammend

# вернуться к работе
$ git stash pop

Источник: atlassian.com

Вопрос 10. Как удалить файл из git, но оставить его в файловой системе компьютера?

Сложность: ⭐⭐⭐⭐

Если вы не будете осторожны с использованием команд git add, то можете случайно добавить в индекс файлы, которые там быть не должны. git rm может удалить их из индекса, но одновременно сотрет и из файловой системы (рабочего дерева). Это не всегда то, что требуется.

Используйте вместо этого git reset:

git reset filename         
echo filename >> .gitingore # добавьте файлы в .gitignore

Команда git reset <path> противоположна git add <path>.

Источник: codementor.io

Вопрос 11. Когда следует использовать git rebase вместо git merge?

Сложность: ⭐⭐⭐⭐⭐

Предназначение этих команд git – интеграция изменений из одной ветки в другую, но делают они это по-разному.

Предположим, у вас сложилась такая ситуация:

A <- B <- C    [master]
^
 \
  D <- E       [branch]

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

A <- B <- C
^         ^
 \         \
  D <- E <- F

А после git rebase– так:

A <- B <- C <- D <- E

Rebase указывает на то, что коммиты нужно буквально перенести со старого места на новое.

Что выбрать?

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

Учитывайте следующие факторы:

1. Если ветка, в которую вы хотите внести изменения доступна для других разработчиков (например, в open source проекте), не используйте rebase. Эта команда удаляет ветку целиком и приводит к рассинхронизации копий репозиториев.
2. Представляет ли исходная ветка ценность? Некоторые команды работают по принципу «одна функция – одна ветка», при этом ветка идентифицирует последовательность коммитов. В модели «один разработчик – одна ветка» в этом нет особой необходимости, так как автор коммита известен.
3. Не захотите ли вы вдруг отменить слияние? Возврат rebase значительно затруднен по сравнению с обычным слиянием, а иногда даже невозможен.

Источник: stackoverflow.com

Перевод статьи Alex Ershov: 11 Painful Git Interview Questions You Will Cry On

Много полезных материалов о git

Использование общих команд Git — GitHub Docs

Документы GitHub

• Все продукты

• GitHub.com

• Начиная

  • Быстрый старт
    • Настроить Git
    • Создать репо
    • Форк репо
    • Быть социальным
  • Изучение GitHub
    • Продукты GitHub
    • Изучение выпусков раннего доступа с предварительным просмотром функций
    • Типы аккаунтов GitHub
    • Часто задаваемые вопросы об изменениях в планах GitHub
    • GitHub CLI
    • GitHub Desktop
    • GitHub для мобильных устройств
    • Разрешения на доступ на GitHub
    • Глоссарий GitHub
    • Шпаргалка по Git
    • Учебные ресурсы Git и GitHub
  • Регистрация на GitHub
    • Регистрация новой учетной записи GitHub
    • Подтверждение адреса электронной почты
    • Настройка пробной версии GitHub Enterprise Cloud
    • Настройка пробной версии GitHub Enterprise Server
  • Изучение проектов на GitHub
    • Поиск способов внести свой вклад в открытый исходный код на GitHub
    • Сохранение репозиториев со звездочками

.

Использование расширенных команд Git — GitHub Docs

Документы GitHub

• Все продукты

• GitHub.com

• Начиная

  • Быстрый старт
    • Настроить Git
    • Создать репо
    • Форк репо
    • Быть социальным
  • Изучение GitHub
    • Продукты GitHub
    • Изучение выпусков раннего доступа с предварительным просмотром функций
    • Типы аккаунтов GitHub
    • Часто задаваемые вопросы об изменениях в планах GitHub
    • GitHub CLI
    • GitHub Desktop
    • GitHub для мобильных устройств
    • Разрешения на доступ на GitHub
    • Глоссарий GitHub
    • Шпаргалка по Git
    • Учебные ресурсы Git и GitHub
  • Регистрация на GitHub
    • Регистрация новой учетной записи GitHub
    • Подтверждение адреса электронной почты
    • Настройка пробной версии GitHub Enterprise Cloud
    • Настройка пробной версии GitHub Enterprise Server
  • Изучение проектов на GitHub
    • Поиск способов внести свой вклад в открытый исходный код на GitHub
    • Сохранение репозиториев со звездочками

.

Руководство по Git ™ — Общие команды Git

Руководство по Git ™ — Общие команды Git

Последнее изменение: 9 апреля 2020 г.

Обзор

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

Важно:

• Этот документ не является исчерпывающим .Он намеренно опускает информацию о промежуточных и расширенных функциях Git. Для получения дополнительной информации о дополнительных командах и параметрах прочтите документацию Git.

• Терминология в этом документе предполагает базовое знакомство с командной строкой.

  git add [параметры] путь к файлу  

  git commit -m "Сообщение о фиксации здесь." 

  git checkout [параметры] имя ветви  

  git rm [параметры] files_or_dirs  

  git fetch [параметры] удаленное имя  

  git pull [параметры] репо или ветка  

  git push [параметры] ветка репозитория  

  ветка git [параметры] имя ветки  

  git виноват [параметры] путь к файлу  

  1
2
3
4
5
6
7
  

  5f033c48d84a (Джейн Э.Кодер 24.05.2017 18:25:53 -0600 1) 
5f033c48d84a (Джейн Э. Кодер 24.05.2017 18:25:53 -0600 2) 
5f033c48d84a (Джейн Э. Кодер 24.05.2017 18:25:53 -0600 3)
5f033c48d84a (Джейн Э. Кодер 24.05.2017 18:25:53 -0600 4) 
54222e949682 (John B. Developer 2018-01-08 10:57:07 +0000 5) 
 Вот текст. 
5f033c48d84a (Джейн Э. Кодер, 24 мая 2017 г. 18:25:53 -0600 6)
5f033c48d84a (Jane E. Coder 2017-05-24 18:25:53 -0600 7)