Git - the simple guide - no deep shit!

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

Создать локальную рабочую копию репозитория можно командой
git clone /путь/к/репозиторию
когда используется удаленный сервер, команда будет
git clone юзер@хост:/путь/к/репозиторию

Ваш локальный git репозиторий состоит из трех "сущностей". Рабочий каталог (Working Directory) содержит файлы. Индекс (Index) или область подготовленных файлов (Staging Area). содержит информацию о том, что должно войти в следующий коммит и HEAD указывает на последний коммит что вы сделали.

Чтобы подготовить изменения (добавить их в Индекс ) используйте
git add <имя_файла>
git add *
Это первый шаг в основном рабочем процессе. Сделать коммит подготовленных изменений можно командой
git commit -m "Описание коммита"
Теперь изменения закреплены в локальном репозитории и на них указывает HEAD. но еще не в удаленном репозитории.

Чтобы отправить эти изменения в ваш удаленный репозиторий, выполните
git push origin master
Можно изменить master на любую другую ветвь чтобы отправить изменения на неё.

Если вы еще не клонировали существующий репозиторий и хотите подключить ваш к удаленному, вам нужно добавить его, выполнив
git remote add origin <адрес_сервера>
Теперь вы можете отправлять изменения на удаленный репозиторий

Ветки используются для разработки функционала изолированного от остального. Ветка master используется по умолчанию когда вы создаете репозиторий. Используйте другие ветки для разработки и слияние в master когда разработка завершена.

Создать новую ветку с названием "feature_x" и переключиться на неё можно командой
git checkout -b feature_x
переключиться обратно на master
git checkout master
удалить ветку
git branch -d feature_x
ветка не будет доступна тем, кто пользуется с вами удаленным репозиторием пока вы не отправите её туда
git push origin <имя_ветки>

Обновить ваш локальный репозиторий, можно командой
git pull
которая заберет изменения из удаленного репозитория и проведет слияние с активной веткой.
Для того чтобы слить другую ветку с активной (например master), используйте команду
git merge <имя_ветки>
В обоих случаях git пытается автоматически слить изменения. К сожалению, это не всегда возможно и результатом станет конфликт. Вы ответственны за разрешение возникших конфликтов. путем ручного редактирования файлов указанных git. После изменений вам надо пометить их как слитые
git add <имя_файла>
перед слиянием вы можете предварительно посмотреть на изменения
git diff <имя_ветки> <имя_другой_ветки>

Рекомендуется использовать метки для закрепления момента выпуска версий. Это популярная практика, которая так же используется в SVN. Создать новую метку с именем 1.0.0 можно выполнив
git tag 1.0.0 1b2e1d63ff
1b2e1d63ff это первые десять цифр уникального идентификатора (id) с которым будет связана метка. Чтобы посмотреть идентификаторы коммитов, выполните
git log
Можно использовать меньшее количество символов в качестве идентификатора с учетом того что он является уникальным.

В случае если вы сделали что-то не то, вы можете заменить локальные изменения, используя команду
git checkout -- <имя_файла>
произойдет замена изменений в вашем рабочем каталоге, на то что сейчас находится в HEAD. Изменения уже внесенные в индекс, так же как новые файлы будут сохранены.

Если же вы хотите удалить все ваши локальные изменения и коммиты, получите (fetch) последние изменения с сервера и укажите локальной ветке master на них вот так
git fetch origin
git reset --hard origin/master

встроенный в git графический интерфейс
gitk
использовать цветной вывод в терминале
git config color.ui true
выводить в логе коммит на одной строке
git config format.pretty oneline
интерактивный способ добавления в индекс
git add -i

Самая простая инструкция по работе с git - Stack Overflow на русском

Я никогда не работал с системами контроля кода. Сейчас подключился к существующему репозиторию на bitbucket для работы с сайтом (при подключении выбрал clone). Про эти системы есть множество статей, но они изобилуют разными подробностями, которые мне на данный момент не нужны. Я не использую командную строку и не работаю с файлами локально (использую редактор Coda и правлю прямо на сервере по ftp). Мне нужна самая простая инструкция: я изменил файл, что дальше делать, чтобы сохранить изменения в репозитории? Я думал что нужно нажать для этого Commit, но данный пункт в меню у меня почему-то неактивен, активны только Push/Pull changes to/from origin, но Push у меня не работает так как я ожидал (а ожидал я что потом если нажать Pull, то файл восстановится до моего измененного состояния, но он восстановился до состояния до того, как я его менял). В списке branches я выбрал master.

задан 17 апр '14 в 19:39

Git - распределенная система, репозиторий на компьютере и сервере - это два совершенно разных репозитория, и push/pull просто синхронизирует эти репозитории по сети. При работе с репозиторием (оставим пока синхронизацию в стороне) нужны три команды - git add добавляет файлы к следующему коммиту (операция называется stage. команда для обратной операции - git rm --cached %file% ), git commit записывает изменения отдельным коммитом, git reset выполняет простой откат к выбранному коммиту (здесь я сам плаваю), git revert похож на git reset. только его изменения могут быть представлены коммитом (в то время как ресет просто откатывается к некоторому коммиту). Таким образом обычный flow может выглядеть так:

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

В следующий раз уже достаточно будет сделать просто git push

И все новые коммиты (но не изменения) уйдут на сервер.

git pull сольет с сервера репозиторий в том виде, который он есть, и, скорее всего, затрет имеющиеся изменения (если над ними не была произведена операция stage - в этом случае git откажется выполнять операцию до тех пор, пока stage-area не опустеет или ключ --force не заставит это сделать).

1. Создаются / меняются файлы
2. Файлы добавляются к грядущему коммиту c помощью git add %path%
3. Совершается коммит git commit. если не указывать ключ -m, то вылезет редактор, где нужно будет вписать сообщение с описанием изменений
4. git push отправляет свежие коммиты на сервер
5. git pull вытягивает репу в состоянии последнего коммита на сервере

• Уже сделанный, но не отправленный коммит можно поправить с помощью команды git commit --amend. Уже отправленный коммит тоже можно, но ни в коем случае не надо этого делать. ничего страшного, если исправления улетят следующим.
• Ненужные файлы исключаются из коммитов с помощью файла .gitignore. Можно один раз настроить его на игнорирование всяких *.log. *.pyc и прочего мусора, а потом безопасно делать git add.
• IDE очень часто будет смешивать команды git add и git commit до неразличимости

Ну и последнее. Git может быть (и будет) сложен, но это только к лучшему, это очень гибкая система.

Спасибо, но не совсем то, о чем я спрашивал :) Меня не интересует командная строка и теория, именно поэтому я этот вопрос и задал, ключевое слово в нем - ПРОСТАЯ. Лично я считаю, что можно много найти интересных занятий, если не хочется заниматься непосредственно делом - и системы контроля кода далеко не лучший выбор в этом плане. Просто требованием заказчика по одному проекту является работа с git, и мне нужно только знать как эти несчастные файлы, которые я поменял, запихать в репозиторий :) Хотя что может быть сложного в автоматическом бекапе с парой доп. функций, я тоже не понимаю. – baduga 18 апр '14 в 0:51

@baduga я не знаком с конкретно этим редактором. Но суть от этого сильно не меняется: файлы добавляются в stage area - делается коммит - коммит отправляется на сервер (push). Перед коммитом необходимо делать pull, чтобы избежать конфликтов. И да, без изучения некоторой теории (тут ее минимум) будет сложно. – Etki 18 апр '14 в 1:02

Практическое краткое руководство по Subversion (SVN) и Git для начинающих

Материал страницы находится в разработке!

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

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

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

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

Subversion — система управления версиями в свободной лицензии. Известна под сокращенным именем SVN. Разработка Subversion началась в 2000 году по инициативе и финансовой поддержке компании CollabNet Inc.

Основной целью проекта Subversion считается замена устаревший, на тот момент системы контроля версий CVS (Concurrent Versions System). Новый проект должен был сохранить всю функциональность CVS и избавиться от ряда его недостатков.

Официальный выпуск Subversion — 2004 год.

Разработка Git началась в 2005 году, по инициативе разработчика Linux — Линуса Торвальдса.

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

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

1. Lock-Modify-Unlock — чтобы внести изменение, надо заблокировать файловое хранилище, выполнить изменение и, после этого, разблокировать (вернуть в общее пользование). Такая схема может работать в полностью автоматическом режиме, так как исключает возможные коллизии изменений, и используется в многопоточном программировании для защиты критических секций данных. В файловых репозиториях, такая схема не удобна, так как исключает возможность параллельной работы пользователей над изменением файлов.
2. Copy-Modify-Merge — каждый из пользователей работает со своей копией данных, которая потом синхронизируется с состоянием центрального репозитория. Недостатком таких схем является необходимость ручного вмешательства в процесс синхронизации разных копий, если в них содержатся изменения одного и того же фрагмента данных.

Обе системы, Subversion и Git, используют вторую схему разделения данных (Copy-Modify-Merge ), но делают это немного по-разному.

SVN относится к типу централизованных систем. в отличии от Git и Mercurial, которые являются представителями класса распределенных систем. Централизованность означает работу схемы только при наличии централизованного хранилища данных.

Развертывание системы Subversion может опираться на две разные физические системы хранения данных репозитория. Исторически, первый вариант организации репозитория был основан на использовании СУБД Berkeley DB. Позже, была выполнена реализация на основе специального файлового хранилища данных (FSFS), поддерживаемое собственными программными библиотеками. Начиная с релиза 1.2 для новых хранилищ, по умолчанию, используется FSFS.

Реализацию на основе СУБД Berkley DB можно считать более капризной. Во-первых, ее настройка требует большего внимания администратора. Во-вторых, Berkley DB требовательна к выбору низлежащей файловой системы — она должна поддерживать блокировки.

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

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

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

SVN vs Git. Здесь мы наблюдаем существенное различие в использовании, и, особенно,
администрировании систем SVN и Git. В Git, под каждый проект в любой директории
можно реализовать работу локального репозитория, чего, часто, для индивидуальной
работы, бывает достаточно. Централизованный репозиторий, при его необходимости,
так же организуется под каждый проект отдельно, позволяя для каждого проекта
построить свою политику прав доступа. Если быть более точным, то Git значительно
сосредоточен именно на средствах управления версиями и, при использовании
централизованных репозиториев, для тонкого разделения доступа к коду проекта
множества пользователей удобнее использовать дополнительные оберточные средства
администрирования Git. Cреди последних, известными являются gitolite и gitosys.

Различают понятия стержневых ревизий (peg revision) и оперативных ревизий (operative revision). Стержневая ревизия представляет собой номер ревизии предназначенный для уточнения файловых историй для оперативных ревизий по которым выполняются операции команд. Т.е. Команда может быть задана по диапазону оперативных ревизий в которых может быть коллизии файловых историй связанных с операциями копирования, перемещения и уничтожения файлов. Чтобы однозначно указать требуемую файловую историю необходимо указывать стержневую ревизию по правому краю диапазона оперативных ревизий, так как история файла однозначно отслеживается только в обратном направлении. При
отслеживании истории в прямом направлении можно столкнуться, например, с разветвлением, созданным при копировании файла. Работа пользователя с файлами проекта выполняется в рабочей копии репозитория, которая создается получением файлового снимка всего репозитория SVN или его части (через уточнение нужной поддиректории) с помощью операции svn checkout (по умолчанию будет передана последняя ревизия). Если пользователь хочет зафиксировать изменения в репозитории проекта, то он должен выполнить операцию svn commit. При каждой фиксации кода создается новая ревизия с большим номером.

Основная суть организации репозитория Git в том, что он хранит файлы в виде файлов, а в качестве имени файла в репозитории используется значение хэш-функции SHA1, вычисленной по содержимому файла.

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

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

Объекты репозитория Git бывают четырех типов — blob, tree, commit и tag.

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

svn help checkout
svn help commit
svn help mkdir

Продумаем размещение и выберем имя для директории будущего репозитория SVN. При этом подумайте о правах доступа, если репозиторий будет разделяемый. Для простоты я
сделаю репозиторий в своем домашнем каталоге /home/knz с именем 0-svn-repository. Имя начинающееся с нуля предоставит дополнительный приоритет для данной директории для
многих типов сортировок при выводе списка директорий и такая директория не затеряется в окружении многих других директорий домашнего каталога.

Находясь в домашней директории выполним команду.

svnadmin create 0-svn-repository

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

1. Создадим где-нибудь начальный оригинал будущего проекта.
2. Выполним импорт этого оригинала проекта в репозиторий SVN с помощью команды svn import.
3. Оригинал проекта теперь стратегического смысла не имеет и его можно удалить.
4. Создаем рабочую копию проекта из репозитория SVN с помощью команды svn checkout.
5. Работаем с рабочей копией, вносим в нее изменения. Чтобы зафиксировать изменения необходимо передать их в репозиторий SVN с помощью команды svn commit. При
   этом, в репозитории проекта, будет создана очередная по счету ревизия.

Игнорирование файлов SVN
Сделать файл list с именами или масками, разделённые переводом строки
$ svn propset ‘svn:ignore’ -F list

Моя шпаргалка по работе с Git

Некоторое время назад я открыл для себя Git. И знаете, я проникся. То есть, по-настоящему проникся. Теперь я использую Git не только на работе (где я с ним, собственно, познакомился), но и для своих проектиков, которые я стал хранить на BitBucket. Последний начал поддерживать Git относительно недавно. В отличие от GitHub BitBucket позволяет совершенно бесплатно создавать как открытые, так и закрытые репозитории.

Главное отличие Git от Subversion заключается в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это означает очень простую вещь. Каждый разработчик держит у себя на диске отдельный репозиторий. Обратите внимание — не копию репозитория, не некоторые бранчи. а тупо отдельный и при этом абсолютно полноценный репозиторий.

Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мерджим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мердж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мердж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

В результате имеем:

• Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion .
• Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
• Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
• Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
• Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
• Git не раскидывает по каталогам служебную информацию (помните «.svn»?). вместо этого она хранится только в корне репозитория.
• Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
• Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
• Git поддерживают многие хостинги репозиториев (GitHub. BitBucket. SourceForge. Google Code. … ) — есть из чего выбрать.
• Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell. сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

В первую очередь необходимо поставить Git:

Затем создаем пару ssh ключей, если не создавали ее ранее :

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

mkdir -p / tmp / git-copy
cd / tmp / git-copy
git clone --bare git @ example.com:afiskon / cpp-opengl-tutorial1.git
cd cpp-opengl-tutorial1.git
git push --mirror git @ example.com:afiskon / cpp-opengl-tutorial2.git

Следует отметить, что Git позволяет использовать короткую запись хэшей. Вместо «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можно писать «d8578edf» или даже «d857».

Дополнение: Также в 6-м пункте Мини-заметок номер 9 приводится пример объединения коммитов с помощью git rebase. а в 10-м пункте Мини-заметок номер 11 вы найдете пример объединения двух репозиториев в один без потери истории.

Более подробно сабмодули и зачем они нужны объясняется в заметке Простой кроссплатформенный OpenGL-проект на C++. Здесь упомянем самое главное.

git submodule add https: // github.com / glfw / glfw glfw

git submodule init

Обновление сабмодулей, например, если после git pull поменялся коммит, на который смотрит сабмодуль:

git submodule update

Удаление сабмодуля производится так:

1. Скажите git rm --cached имя_сабмодуля ;
2. Удалите соответствующие строчки из файла .gitmodules;
3. Также грохните соответствующую секцию в .git/config;
4. Сделайте коммит;
5. Удалите файлы сабмодуля;
6. Удалите каталог .git/modules/имя_сабмодуля;

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

Как обычно, любые замечания, дополнения и вопросы категорически приветствуются. И кстати, с наступающим вас!

Автоматическое развертывание приложений при помощи Git

Размещение серверов в надежных дата-центрах Европы. Откройте облачный VPS/VDS сервер на быстрых SSD за 1 минуту!

Лучший хостинг:
- оградит данные от нежелательного доступа в охраняемом европейском ЦОДе
- примет оплату хоть в bitcoin.
- позволит поставить свой дистрибутив

- защита от DDos-атак
- бесплатный backup
- Uptime 99,9999%
- ЦОД - TIER III
- провайдер - TIER I

Поддержим на русском языке 24/7/365 Работаем с юрлицами и физлицами. Вам прямо сейчас нужно 24 ядра и 72 Gb RAM. Пожалуйста!

Наши выгодные тарифы докажут, что дешевый хостинг вы еще не знали!

Минутное дело: выберите конфигурацию, оплатите и CMS на VPS готова.
Money Back – 30 дней!

Банковскими картами, электронной валютой, через терминалы Qiwi, Webmoney, PayPal, Новоплат и др.

Задайте вопрос в службу поддержки 24/7/365

Найдите ответы в нашей базе и познакомьтесь с рекомендациями

VPS

Примечание. Данное руководство не охватывает установку Git; инструкции по установке можно найти в этой статье .

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

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

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

В этом руководстве условное рабочее пространство выглядит так:

• Каталог сервера: /var/www/domain.com
• Репозиторий сервера: /var/repo/site.git

Итак, что же нужно сделать, чтобы толкнуть приложение в репозиторий site.git и открыть доступ к контенту в /var/www/domain.com?

Введите следующее на виртуальном выделенном сервере:

cd /var
mkdir repo && cd repo
mkdir site.git && cd site.git
git init --bare

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

Репозитории Git имеют подкаталог «hooks», в котором хранятся перехватчики (hooks) — образцы файлов для автоматизации распространенных действий, которые перехватывают и выполняют пользовательские действия.

В документации Git упоминаются три возможных перехватчика: pre-receive, post-receive и update. Перехватчик pre-receive выполняется, когда сервер получает команду push; update работает аналогичным образом, но выполняется для каждой ветки; post-receive выполняется, когда команда push уже выполнена.

Если набрать в репозитории:

на экране появится несколько файлов и папок, среди которых будет папка hooks. Откройте её:

В ней создайте файл post-receive, набрав:

cat > post-receive

При выполнении данной команды на экране будет пустая строка; все, что вы введете в строку, будет сохранено в этот файл. Введите:

#!/bin/sh
git --work-tree=/var/www/domain.com --git-dir=/var/repo/site.git checkout -f

Введя этот код, нажмите Ctrl D, чтобы сохранить. Теперь нужно установить права на файл:

chmod +x post-receive

Как сказано в документации. git-dir – это путь к каталогу; work-tree определяет другой путь, по которому и нужно переместить файлы.

Файл post-receive будет просматриваться при каждом выполнении команды push, в нем сказано, что файлы нужно передавать в /var/www/domain.com.

Создайте локальный репозиторий. Измените путь и имя на свое усмотрение. Чтобы выйти с VPS, просто введите:

Чтобы создать репозиторий:

cd /my/workspace
mkdir project && cd project
git init

Теперь нужно настроить удаленный путь репозитория. Для этого используйте:

git remote add live ssh://user@mydomain.com/var/repo/site.git

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

git add .
git commit -m "My project is ready"

Примечание. Точка после git add означает, что нужно добавить в хранилище все файлы. После git commit используется флаг –m, который позволяет ввести сообщение.

В завершение нужно толкнуть все на сервер при помощи команды push:

git push live master
Counting objects: 7, done.Delta compression using up to 4 threads.Compressing objects: 100% (7/7), done.Writing objects: 100% (7/7), 10.56 KiB, done.Total 7 (delta 0), reused 0 (delta 0)To ssh://user@mydomain.com/var/repo/site.git* [new branch] master -> master

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

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

Для этого нужно создать отдельный репозиторий. Вернитесь на VPS и выполните:

cd /var/www/
mkdir beta

Чтобы создать репозиторий:

cd /var/repo
mkdir beta.git && cd beta.git
git init --bare

Теперь нужно снова создать файл post-receive, чтобы просмотреть наш проект в бета-каталоге:

cd hooks
cat > post-receive

Внесите в файл следующее:

#!/bin/sh
git --work-tree=/var/www/beta --git-dir=/var/repo/beta.git checkout -f

Нажмите Ctrl D, чтобы сохранить файл. Вернитесь в локальный репозиторий:

exit
cd /my/workspace/project

Теперь можно добавить еще один удаленный репозиторий, указывающий на бета-репозиторий:

git remote add beta ssh://user@mydomain.com/var/repo/beta.git

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

git add .
git commit -m "New version"
git push beta master
git push live master

Чтобы развернуть приложение, нужно связать репозитории beta и live. Войдите на сервер и введите:

cd /var/repo/beta.git
git remote add live. /site.git

Теперь можно передавать файлы из beta в live:

cd /var/repo/beta.git
git push live master

Сервер полностью готов к развертыванию приложения!