git

Коммиты из "вливаемой" ветке при rebase записываются перед коммитами текущей ветки.

Практика

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

1. Создадим тестовый репоизторий с двумя ветками
2. Переключимся на новую неосновную ветку:
   

   git checkout newbranch

3. Посмотрим ее список коммитов:
   

   git log --oneline --name-only

   Получим:

Как устанавливать плагины

См. инструкцию по установке

Список коммитов

git log origin/имяветки..HEAD

Разница между публикованным и неопубликованным состоянием

git diff origin/имяветки..HEAD

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

Базы данных (SQL)

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

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

Предположим, что вы работаете в ветке br1, а вам надо периодически заливать свои изменения в br2, которая является основной (часто вместо br2 эта ветка имеет имя master)), ещё раз:

• Рабочая директория ("working directory", "working tree") -- файлы на диске.
• Git-директория - папка, где гит хранит свои данные, в т.ч. и файл индекса.
• Область подготовленных файлов (это же "Индекс", ''staging area') — это файл, обычно располагающийся в вашей Git-директории, в нём содержится информация о том, какие изменения попадут в следующий коммит. Эту область ещё называют “индекс”, однако называть её stage-область также общепринято.

Прежде всего убедитесь, что git status говорит, что коммитить нечего (это же относится и к правке файла gitattributes, если он у вас есть - закоммитьте его изменения, если требуется):

On branch ....
Your branch is up to date with ...

nothing to commit, working tree clean

Затем чтобы обновить все файлы из истории коммитов (как в последнем коммите, с учетом текущих настроек, напр. из .gitattributes) :

Проблема

/usr/bin/env: 'php\r': No such file or directory

проблема наблюдалась при запуске команд терминала для симфони в windows 10 (сам проект запущен в контейнере linux, но git делал выгрузку в винду, что приводит по-умолчанию к конвертации символа окончания строки).

Проблема связана с разными переносами строк в разных ОС, и тем как Git работает с этими различиями.

Довольно интересная тема, обсуждается в т.ч. тут: https://stackoverflow.com/questions/5730...

В случае, если дело в разных переносах строк в разных ОС (см. пример), то рекомендуют выполнить команду:

git config --global core.autocrlf false 

-- для игнорирования изменений в переносах строк.

Обновлено: смотри полное описания имеющихся вариантов.