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

Для создания нового репозитория в созданной директории "проект" нужно перейти в эту директорию и выполнить:
  git init

А затем добавить ранее созданные там файлы:
  git add .

Для того, чтобы с локальной машины по SSH зайти на "хост" под именем "логин" и клонировать на свою
машину репозиторий, находящийся с директории "/home/логин/проект" (префикс ssh:// добавляктся по умолчанию)
  git clone логин@хост:/home/логин/проект master

Для того чтобы через некоторое время синхронизировать из основного или другого репозитория
изменения, нужно выполнить:
  git pull логин@хост:/home/логин/проект master

Локальный клон сделан.
Далее правим в созданной на локальной машине "проект"
  git commit -a -m "комментарий о проделанной работе"    

Если ошиблись и нужно вернуть все обратно:
  git revert

Чтобы зафиксировать версию (если наступил такой момент):
  git tag тэг_версии

Когда все готово, помещаем изменния в основой репозиторий:
  git push логин@хост:/home/логин/проект master                      

Для того, чтобы сгенерировать рабочий проект (в нашем случае сайт) на рабочем сервере
нужно выполнить в директории с проектом:
  git update-server-info                                                          
  git checkout HEAD -f

Вернуться к прошлой ревизии:
  git checkout HEAD~1

К позапрошлой:
  git checkout HEAD~2

Построить проект с заданным номером версии:
  git checkout тэг_версии

URL:
Обсуждается: https://www.opennet.ru/tips/info/2179.shtml

• Пример работы с персональным Git репозиторием,XoRe, 10:20 , 29-Сен-09
• а оно надо?,Вова, 13:51 , 29-Сен-09
  • а оно надо?,XoRe, 15:37 , 29-Сен-09
    • перевода и не было,Вова, 18:10 , 29-Сен-09
      • перевода и не было,Slavaz, 18:19 , 29-Сен-09
        • что такое секс в вашем понимании,Вова, 21:15 , 29-Сен-09
          • что такое секс в вашем понимании,Slavaz, 01:50 , 30-Сен-09
            • спасибо за ответ,Вова, 15:37 , 30-Сен-09
              • спасибо за ответ,Slavaz, 16:04 , 30-Сен-09
                • спасибо за ответ,Вова, 12:13 , 01-Окт-09
                  • спасибо за ответ,Slavaz, 12:18 , 01-Окт-09
      • перевода и не было,Andrey Mitrofanov, 14:31 , 30-Сен-09
        • клоуны опять на сцене,Вова, 15:24 , 30-Сен-09
          • клоуны опять на сцене,Andrey Mitrofanov, 18:05 , 30-Сен-09
            • психоанализ?,Вова, 12:47 , 01-Окт-09
              • ниасилилгенезис,Andrey Mitrofanov, 15:19 , 01-Окт-09
                • ниасилилгенезис,rico, 16:31 , 02-Окт-09
                  • ниасилилгенезис,Andrey Mitrofanov, 18:50 , 02-Окт-09
                    • ниасилилгенезис,rico, 19:15 , 02-Окт-09
                    • ниасилилгенезис,rico, 19:16 , 02-Окт-09
  • а оно надо?,Аноним, 18:32 , 29-Сен-09
• Пример работы с персональным Git репозиторием,gara, 10:44 , 15-Окт-09

"Для того, чтобы сгенерировать рабочий проект (в нашем случае сайт) на рабочем сервере
нужно выполнить в директории с проектом:"
Хорошо бы поставить запятую.
А то не совсем понятно)

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

>Недавно автор меркуриала отличную статью писал, про разницу между гитом, свн, меркуриалом;
>на опеннет её не пропустили: автор осмелился написать, что для различных
>проектов удобны различные системы.

А можно ссылку?
На оригинал и на перевод.

статья тут: http://queue.acm.org/detail.cfm?id=1595636

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

>статья тут: http://queue.acm.org/detail.cfm?id=1595636
>
>весьма толково, именно то, что нужно. Спрашивал как-то на опеннете про реальный
>опыт использования гитом, и тут в ответ читал фантазии, люди придумывали
>дефекты свн и достоинства гита на их фоне, вместо подобного ответа
>вкратце.

У гита есть одно достоинство, ради которого стоит забыть svn - работа  ветками. Не секс с ветками, а работа :)

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

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

В git проще управлять разработкой, разнесённой по веткам, нежели чем в svn. Попробовав git я с уверенностью могу сказать, что работа с бранчами в svn - это секс :)

Ну для сравнения:

1) Создаём ветку:
git branch new_branch_name
svn cp trunk branches/new_branch_name

2) Переключаемся в ветку:
git checkout new_branch_name
cd branches/new_branch_name

3) Поработали, обнаружили что основная "стволовая" ветка обновилась, да так, что желательно получить её функционал в бранче:
git rebase master
svn merge r???:??? (тут игра в сапёра. Во-первых, не ошибиться бы с номерами коммитов. Во-вторых, коммиты в ветке окажутся позади отмерженного)

Вот уже тут чувствуется разница. Особенно если придётся конфликты разгребать. Наилучший выход здесь с svn: получить патчи (один патч = один коммит) из ветки, пересоздать ветку с транка (или откатить свои коммиты и отмержить новые коммиты с транка) и вручную наложить сохранённые патчи.

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

git rebase -i master # потом в интерактивном режиме сливаем коммиты, меняем описание, редактируем и т.д.
svn ???? Опять пляски с патчами?

5) вливаем бранч в стволовую ветку:
git checkout master; git merge new_branch_name
svn merge r???:??? (Опять же - ошибка в номерах и "опа").

Это из личных ощущений. Если у Вас опыта работы с svn поболее моего - буду рад увидеть Ваши приёмы работы с svn.

Возможно мне везло с проджект-менеджерами, но на двух моих местах работы в качестве разработчика в команде, практически единственным местом, где возможны были конфликты транка и бранча были различные словари - хедеры с энумами, константами и тп; в затрагиваемых веткой исходниках  изменения были всегда несущественны, решать конфликты было более чем просто.
То есть схема работы была следующая: такой-то функционал решено разрабатывать в отдельной ветке, создаётся бранч, ведётся разработка, затем 1м (!) коммитом вливается с меткой "мерджед бранч такая-то". Лично я  чаще всего при этом вообще не использовал merge - делал дифф и накладывал на транк, с "ручным" добавлением новых файлов.
  
   То есть постоянного мерджа из ветки -> в транк -> в ветку -> в транк  я ни разу и не видел.  В данном случае одновременной модификации одного и того же кода действительно необходимо какой-то сценарий слияния, но это немного другая идеология разработки, вы не находите?
И я правильно понял, что git rebase - это те же самые решения конфликтов, только в профиль?

>svn merge r???:??? (тут игра в сапёра. Во-первых, не ошибиться бы с
>номерами коммитов. Во-вторых, коммиты в ветке окажутся позади отмерженного)

Действительно, надо знать номера ревизий, определять их по stop-on-copy опции.

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

так ведь остались коммиты в бранче, зачем дублировать в транк? Лучше одним коммитом заливать, чтобы не было "я обновился когда ты не всё залил".

> То есть схема работы была следующая: такой-то функционал решено разрабатывать в
>отдельной ветке, создаётся бранч, ведётся разработка, затем 1м (!) коммитом вливается
>с меткой "мерджед бранч такая-то". Лично я  чаще всего при
>этом вообще не использовал merge - делал дифф и накладывал на
>транк, с "ручным" добавлением новых файлов.

Это похоже на последовательную разработку с "всегда стабильным стволом". Есть ещё параллельная разработка, в которой ветки могут развиваться одновременно. Ну и вливаться раньше или позже. Соответственно, оставшиеся ветки нужно приводить к стволовой ветке.

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

Да, многое зависит от идеологии и правил разработки. Иногда можно (и нужно) обойтись svn, иногда использование git предпочтительнее. Не буду спорить о вкусе устриц, но, думаю, есть ситуации, когда и mercurial предпочтительнее.

> И я правильно понял, что git rebase - это те же
>самые решения конфликтов, только в профиль?

Не только. Это довольно мощная операция. Она позволяет менять родительскую ветку (или стартовый коммит), позволяет менять коммиты в ветке.

http://www.kernel.org/pub/software/scm/git/docs/user-manual....
По ссылке рассказывается и показывается в псевдографике, что происходит при смене стартового коммита.

>насчёт:
>>Перестраиваем коммиты, ибо было туча промежуточных с отладкой (чтобы другие девелоперы ознакомились с мыслями и догадками)
> так ведь остались коммиты в бранче, зачем дублировать в транк? Лучше
>одним коммитом заливать, чтобы не было "я обновился когда ты не
>всё залил".

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

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

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

> git rebase  довольно мощная операция. Она позволяет менять родительскую ветку (или
>стартовый коммит), позволяет менять коммиты в ветке.
>
>http://www.kernel.org/pub/software/scm/git/docs/user-manual....
>По ссылке рассказывается и показывается в псевдографике, что происходит при смене стартового
>коммита.

спасибо.

>кстати в гите есть аналог blame?

git blame path/to/file.ext

Полный аналог svn blame (aka svn annotate)

>Спрашивал как-то на опеннете про реальный опыт использования гитом

Типа белый и пушистый весь??
google.ru + site:opennet.ru/openforum/ Вова git svn

В новостях с упоминанием git-а, регулярно, да?
"Ихде мои проффиты?!" Уйди обратно под корягу...

>>>Я и третий раз повторю: для _Вас_ преимуществ нет. По этому тезису вопросы?

По этому тезису вопросов не было. И-и-и? Снова?!
http:/openforum/vsluhforumID3/57223.html#14

>подобного ответа вкратце.

В рот жёваной морковкой не?
И отдельное "СПАСИБО!" за протухший $X-vs-$Y.

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

>Xто там с бинарными файлами в свн и гите, Андрюш?

Я ж сказал - не прижимайся, отмазался-отмазался и опять?
Про бинарные файлы говорил(*) не я, смирись. И начинай отмазываться.

Там я говорил про "git он другой"=[вытянуть diff - нет и не будет]+[со "сделайте мне CVS" - в садд] и проблемы на медленых каналах=[есть, в хотелках GSC, студенты никак не порешают эту проблему, и в wontfix у Линуса].

* Для ту^Wлюбознательных повторяю: список был не мой. "общайтесь свободно, "без трубы"" => вопросы по списку _к_его_автору_.

>Скорость чекаута?

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

Ну, тогда "Большая Земля сказала, что ты умрёшь" - у нас гамаки другой системы.

>Попунктно только ересь несли, постыдились бы,

Передёргиваешь? Стыдливый такой. Продолжай отмазываться, кстати.

>ничего полезного в обсуждениях от вас - не было.

Как?
А психоанализ?!
А окончательный и исчерпывающий ответ (даже как-то и не один) на _все_ твои отве^Wвопросы про git? Проигнорировал??

Хочешь git-а - http:/openforum/vsluhforumID9/7808.html#3 попробуй.

>Про бинарные файлы говорил(*) не я, смирись.

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

>>ничего полезного в обсуждениях от вас - не было.
>
>Как?
>А психоанализ?!

   По поводу психоанализа: ты, Митрофанов, принадлежишь к тому подвиду обитателей  ИТ, который на любую тему выстреливает набором терминов и событий, имеющих какое-либо отношение к обсуждаемой теме; при этом полезность этих "выстрелов" нулевая, самомнение же - астрономически высокое.

  В данной теме всё просто: если ты не работал с цвс и свн, то ты вообще ни разу не работал программистом, и в обсуждении данного вопроса - не нужен.

> Я задавал вопрос "чем гит лучше свн", что же его так
>рекламируют на опеннет

Так "чем лучше" или "чего рекламируют"?

>Было очевидно, что ответившие люди просто не  работали с свн,

Кстати! Чего не задать _эти_ свои "чем-чего" в новостях про CVS/SVN?
Об их новостей не пишут... Странно!

>решили дописаться из-за своей уверенности в ценности их мнения.

Неее, твой уникальный слог привлёк только их.

>я попросил дописаться кого-нибудь, кто действительно использовал и свн и гит.

Тебя на гугле забанили? Или интернету не доверяешь? Языками ущербен?

И... немного _рекламы_!

"git is better than svn" ~ 17 200
"git is better than subversion"~ 11 300
"subversion is better than cvs"~ 5 550
"svn is better than cvs" ~ 2 090
"subversion is better than git" ~ 8
"cvs is better than svn" ~ 7
"git is better than cvs" ~ 6
"svn is better than git" ~ 5
"cvs is better than git" ~ 2

Отдельное спасибо google.ru.

>И у вас началась истерика сводящаяся к повторению "для вас преимуществ нет и не будет".

Каких ответов ты ждал на "сделайте мне харашоу, немедленно!"?

>>>ничего полезного в обсуждениях от вас - не было.
>>А психоанализ?!
>   По поводу психоанализа: ты, Митрофанов, принадлежишь

Ты ж так и не сказал, чем тебя не устраивает ответ, что _преимуществ_нет_? Что CVS из git-а, возможно, хреновый? Что дифы надо качать wget-ом, а не git-ом? Тогда продолжим с того же места.

>самомнение же - астрономически высокое.

Соревновательность в этом вопросе -- первейшее дело! :-P

>  В данной теме всё просто:

Если ты не заметил, твои возгласы в _этой_ новости такой же офф, как и мои.

> если ты не работал с цвс и свн, то ты вообще ни разу не работал программистом,

Да-да-да, ...

>и в обсуждении данного вопроса - не нужен.

... какие проблемы - нефиг было и начинать.

>[оверквотинг удален]
>Если ты не заметил, твои возгласы в _этой_ новости такой же офф,
>как и мои.
>
>> если ты не работал с цвс и свн, то ты вообще ни разу не работал программистом,
>
>Да-да-да, ...
>
>>и в обсуждении данного вопроса - не нужен.
>
>... какие проблемы - нефиг было и начинать.

Однако, Андрей, вы графоман =)
Но читать забавно, только про квадратные скобочки не понял :-D

>Однако, Андрей, вы графоман =)
>Но читать забавно,

Вот оно! Признание читалей. :-D

>только про квадратные скобочки не понял :-D

А, забей: недостатки "лит.стиля" от недостатка :> образования. /"мне B-) часто говорят, что не врубаются, что я говорю" /"И да, многие полагают, что я "непонятно излагаю". (Нет, меня зовут не Стиг!)"

как раз стиль есть =)
их много есть

про скобочки это bash style был

это я к тому, что в дискуссии интересно было следить только за Вашим стилем

>>Однако, Андрей, вы графоман =)
>>Но читать забавно,
>
>Вот оно! Признание читалей. :-D
>
>>только про квадратные скобочки не понял :-D
>
>А, забей: недостатки "лит.стиля" от недостатка :> образования. /"мне B-) часто говорят, что не врубаются, что я говорю" /"И да, многие полагают, что я "непонятно излагаю". (Нет, меня зовут не Стиг!)"

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

Вроде здесь https://www.opennet.ru/opennews/art.shtml?num=23049 было: "Making Sense of Revision-control Systems" - выбор оптимальной системы контроля версий, сравниваются инструменты для централизованного и распределенного управления исходными тестами проекта.

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

ssh git@myserver.com
mkdir /home/git/progect
exit

# on local progect dir

scp -r .git git@myserver.com:/home/git/progect/.git

# изаливаем все на удаленный сервер.
git push --all git@myserver.com:/home/git/progect