Если Вам ещё не доводилось применять никакую систему контроля версий (SCV) - значит у Вас нет навыков работы в команде.

Одной из таких систем является git. Его преимущества следующие:

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

Общая схема работы с git такая: есть "голый" репозиторий на сервере (bare-репозитарий), с которого происходит deploy продукта, отдельные разработчики ведут локальные зеркала, периодически синхронизируя их с сервером.

1. Создание репозитария

Создаем папку, заходим в нее и запускаем команду создания репозитария:

mkdir Project  
cd Project  
git init

2. Клонирование репозитория

git clone ssh://...

3. Коммит (внесение изменений в репозитарий)

git add .  
git status  
git commit -m "Commit message"

4. Ветвление

git branch new-feature  
git checkout new-feature  
...сделать что-нибудь...  
git add .  
git commit -m "Commit message"

5. Слияние ветвей

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

git checkout master  
git merge new-feature

6. Конфликт слияния и коммитов

Если изменения не могут быть примешаны автоматически (например, в каком-то файле в ветви master одна из строк изменилась иным образом, чем в ветви new-feature), следует использовать ключ -s resolve у команды merge:

git merge -s resolve new-feature  
...видим, какие файлы находятся в состоянии конфликта...  
...редактируем файлы нужным образом...  
git commit -a -m "Merged new-feature"

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

1.Отправка изменений и приём изменений основной ветки (master)

В ветви master имеются изменения, которые неплохо бы отдать своему коллеге (ну и выложить на сервер с целью последующего deploy’а новой версии).

git push origin

Всё. Изменения внесены.

2.Получение изменений

git pull origin

В некоторых случаях изменения с сервера невозможно автоматически добавить в вашу ветвь master, тогда вместо pull’a следует использовать merge:

git merge origin/master  
...или, в плохом случае...  
git merge -s resolve origin/master

Откуда взялся origin? Это имя удалённого репозитория, автоматически добавленное командой git clone. Источник клонирования. Ваш тот самый сервер из первого пункта, как вы уже догадались. Можно добавить другие удалённые репозитории

git remote add second-server ssh://second.example.com/path/to/repo

Формат команды очевиден. Все remote-репозитории одинаковы, origin не является чем-то особенным. Просто его создали автоматически :-)

В нашем случае сервер лишь один, поэтому работа с remote рассматриваться далее не будет.

3. Обмен изменениями без затрагивания ветки master

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

Что же делать, если вы не хотите затрагивать master, а хотите обменяться какими-то наработками в других ветвях?

  
git checkout new-feature  
git merge origin/new-feature  
...сделать что-нибудь...  
git push origin new-feature:new-feature  

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

Что дальше?

Собственно, это вся база, что требуется для начала использования Git’a.

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

git command –help

Источник: http://i-said.simplog.ru/posts/198-git-na-dvoih