The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

Для создания нового репозитория в созданной директории "проект" нужно перейти в
эту директорию и выполнить:
  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 тэг_версии
 
25.09.2009
Ключи: git, cvs / Лицензия: CC-BY
Раздел:    Корень / Программисту и web-разработчику / Системы контроля версий и управления исходными текстами

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, XoRe (ok), 10:20, 29/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Для того, чтобы сгенерировать рабочий проект (в нашем случае сайт) на рабочем сервере
    нужно выполнить в директории с проектом:"
    Хорошо бы поставить запятую.
    А то не совсем понятно)
     
  • 1.2, Вова (?), 13:51, 29/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Недавно автор меркуриала отличную статью писал, про разницу между гитом, свн, меркуриалом; на опеннет её не пропустили: автор осмелился написать, что для различных проектов удобны различные системы.
     
     
  • 2.3, XoRe (ok), 15:37, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Недавно автор меркуриала отличную статью писал, про разницу между гитом, свн, меркуриалом;
    >на опеннет её не пропустили: автор осмелился написать, что для различных
    >проектов удобны различные системы.

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

     
     
  • 3.4, Вова (?), 18:10, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    статья тут: http://queue.acm.org/detail.cfm?id=1595636

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

     
     
  • 4.5, Slavaz (ok), 18:19, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >статья тут: http://queue.acm.org/detail.cfm?id=1595636
    >
    >весьма толково, именно то, что нужно. Спрашивал как-то на опеннете про реальный
    >опыт использования гитом, и тут в ответ читал фантазии, люди придумывали
    >дефекты свн и достоинства гита на их фоне, вместо подобного ответа
    >вкратце.

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

     
     
  • 5.7, Вова (?), 21:15, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    раскройте понятие секса с ветками.  По моему мнению, если файл был модифицирован и в ветке и в транке, это должно быть зафиксировано, и именно конфликтом, именно дифом.
     
     
  • 6.8, Slavaz (ok), 01:50, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >раскройте понятие секса с ветками.  По моему мнению, если файл был
    >модифицирован и в ветке и в транке, это должно быть зафиксировано,
    >и именно конфликтом, именно дифом.

    В 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.


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


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

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

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

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

     
     
  • 8.12, Slavaz (ok), 16:04, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Это похоже на последовательную разработку с всегда стабильным стволом Есть ещ... большой текст свёрнут, показать
     
     
  • 9.14, Вова (?), 12:13, 01/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Да, в этом случае, если одновременно менять один и тот же код, и постоянно ч... текст свёрнут, показать
     
     
  • 10.15, Slavaz (ok), 12:18, 01/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    git blame path to file ext Полный аналог svn blame aka svn annotate ... текст свёрнут, показать
     
  • 4.9, Andrey Mitrofanov (?), 14:31, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Спрашивал как-то на опеннете про реальный опыт использования гитом

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

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

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

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

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

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

     
     
  • 5.10, Вова (?), 15:24, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Xто там с бинарными файлами в свн и гите, Андрюш? Скорость чекаута? Попунктно только ересь несли, постыдились бы, ничего полезного в обсуждениях от вас - не было.
     
     
  • 6.13, Andrey Mitrofanov (?), 18:05, 30/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Xто там с бинарными файлами в свн и гите, Андрюш?

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

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

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

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

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

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

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

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

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

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

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

     
     
  • 7.16, Вова (?), 12:47, 01/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Про бинарные файлы говорил(*) не я, смирись.

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

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

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

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

     
     
  • 8.17, Andrey Mitrofanov (?), 15:19, 01/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Так чем лучше или чего рекламируют Кстати Чего не задать _эти_ свои чем-ч... текст свёрнут, показать
     
     
  • 9.18, rico (?), 16:31, 02/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Однако, Андрей, вы графоман Но читать забавно, только... текст свёрнут, показать
     
     
  • 10.19, Andrey Mitrofanov (?), 18:50, 02/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Вот оно Признание читалей -D А, забей недостатки лит стиля от недостатка ... текст свёрнут, показать
     
     
  • 11.20, rico (?), 19:15, 02/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    как раз стиль есть их много есть про скобочки это bash style был это я к тому... текст свёрнут, показать
     
  • 11.21, rico (?), 19:16, 02/10/2009 [^] [^^] [^^^] [ответить]  
  • +/
    у меня друг есть, так вот он так говорит не пишет друг философ по образованию ... текст свёрнут, показать
     
  • 2.6, Аноним (-), 18:32, 29/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Вроде здесь http://www.opennet.dev/opennews/art.shtml?num=23049 было: "Making Sense of Revision-control Systems" - выбор оптимальной системы контроля версий, сравниваются инструменты для централизованного и распределенного управления исходными тестами проекта.
     

  • 1.22, gara (??), 10:44, 15/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как создать репозиторий на удаленном сервере, и залить туда  все из локального репозитория.


    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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру