Здравствуйте, koandrew, Вы писали:
K>Вот потому он и не нужен™
Не, почему? Пока используешь gitflow (sourcetree и студия умеют) или любой другой расписанный местным гуру процесс — всё более-менее ок.
Хотя лично я предпочитаю не страдать без необходимости и просто поставить svn. Для команд до 10-20 активно коммитящих человек он точно удобнее.
Во всяком случае в последний раз с ситуацией "необратимо испорчена рабочая копия svn" (не сам репо) я сталкивался где-то в 2007м,
с ситуацией "а что, не надо было делать rebase?" — где-то с год назад.
Здравствуйте, Dair, Вы писали:
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
1) все твои коммиты есть в git reflog
2) На сервере стоит принудительно включать запрет на force push — тогда гарантированно репозиторий на сервере никто не сломает
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, Dair, Вы писали:
D>Консольный Git, 2.6.0
D>Наменял файлов. D>git add ... D>git commit -a D>и так несколько раз.
D>git pull --rebase
D>почему-то появились изменённые и незакоммиченные файлы
То есть rebase pull прошёл молча, но "появились изменённые и незакоммиченные файлы"?
И больше ничего не делалось?
Что-то крайне слабо верится.
D>git rebase --continue
А это ещё зачем? Оно показало конфликт? Если нет, то какой к лешему continue?
Если да, то почему не разобрался с тем, что в конфликте?
D>git push D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
И пользователь, который совершенно не хочет понимать инструмент и действует на уровне "тут вылезло красненькое, я нажала и всё пропало".
Здравствуйте, Dair, Вы писали:
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
Без паники. Твои обновлённые файлы, деревья и коммиты уже стали объектами локального хранилища. Даже если каким-то образом ты потеряешь все указатели на них — у них всё равно ещё есть достаточный срок годности, в течении которого GC их не тронет.
Здравствуйте, Sinix, Вы писали:
S>Хотя лично я предпочитаю не страдать без необходимости и просто поставить svn. Для команд до 10-20 активно коммитящих человек он точно удобнее.
Здравствуйте, Dair, Вы писали:
D>Консольный Git, 2.6.0
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
А я вот уже более года юзаю TortoiseGit в паре с TotalCmd и никогда не было проблем.
Правда некоторые действия все же удобнее из консоли выполнять. Просто отображение списков это явно не для консоли. Тут нужен именно GUI.
Просто я в качестве развлечения разрабатываю прошивки под андройд. И пишу весь код на винде (просто без TotalCmd я как без рук), а собираю все на убунте. На убунте я в git выполняю только простейшие операции.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
S>>Хотя лично я предпочитаю не страдать без необходимости и просто поставить svn. EP>А как же скорость? Например log или blame?
Начиная с 1.7 свн здорово допилили почти по всем фронтам, на практике проблем ни разу не возникало, даже на долгоживущих репо с сильно пятизначными номерами коммитов
Хотя не, вру. Если приспичило прокрутить всю историю на лет шесть назад — поседеешь, пока дождёшься. При этом реально нужное, например посмотреть изменения по конкретной папке/файлу, даже если менялось года три назад, работает нормально. Секунд 5 где-то.
Ещё из тормозов — repo browser тортойза, ну и чекаут репо на несколько Гб может минут 20 занять. Больше ничего из тормозов не вспомнил.
Как по мне, плата за модель "тыкнул кнопку — забрал, тыкнул кнопку — отправил" более чем достойная.
P.S. Blame — 2-3 секунды на больших файлах с длинной историей.
Это всё с учётом того, что сервер не в локальной сети.
D>Консольный Git, 2.6.0
Неужели под виндой
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
Совет: Никогда, никогда не делай rebase пока не заучиш GitMagic наизусть на оригинальном языке.
Впрочем когда заучиш, тоже делать rebase его не стоит.
D>А я вот уже более года юзаю TortoiseGit в паре с TotalCmd и никогда не было проблем.
Неужили Черепахой стало наконец можно пользоваться. Непрошло и 6-7 лет...
D>Правда некоторые действия все же удобнее из консоли выполнять.
Некоторые из чуть большего кол-ва чем все.
D>Просто отображение списков это явно не для <виндовой> консоли. D>Тут нужен именно GUI.
Не нужен вообще. Хочеш полистать список — используй less. Хочеш его отсортировать — используй sort. Хочеш сделать это одновременно — используй sort | less.
А ведь можно его еще и грепнуть, например на предмет всех коммитов васи пупкина за 32-е января...
D>Просто я в качестве развлечения разрабатываю прошивки под андройд. И пишу весь код на винде (просто без TotalCmd я как без рук), а собираю все на убунте. На убунте я в git выполняю только простейшие операции.
Когда то смотрел код фаром или wincmd-шным листером, правил его ultraedit-ом на примонтированной в венду Самбовой шаре и запускал компиляцию батников через любезно предоставленный putty тунель ssh.
В то время я был слишком молод и продлилось к счастью это совсем недолго.
Здравствуйте, eskimo82, Вы писали:
D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git E>Совет: Никогда, никогда не делай rebase пока не заучиш GitMagic наизусть на оригинальном языке. E>Впрочем когда заучиш, тоже делать rebase его не стоит.
Пользуюсь rebase почти каждый день. Что такое GitMagic, даже не помню.
Дело не в GitMagic или в чём-то подобном. Дело в том, чтобы 1) читать, что тебе вывела команда (именно поэтому предыдущее сравнение), 2) помнить банальность — что "внутри rebase" это состояние репо и в нём нельзя делать посторонних действий, а нужно делать только те, что выводят из этого состояния как можно быстрее.
Вспомнилось у Раскина определение понятия "режим" (mode), и как он настоятельно рекомендовал избегать этого в проектировании (в частности, он категорически отвергал modal dialogs, даже если кажется, что они нужны). У меня никогда не было серьёзных проблем с режимами, но есть люди, которые с ними принципиально "не дружат". Подозреваю, что проблема ТС из этой области.
Здравствуйте, Sinix, Вы писали:
S>Хотя не, вру. Если приспичило прокрутить всю историю на лет шесть назад — поседеешь, пока дождёшься. При этом реально нужное, например посмотреть изменения по конкретной папке/файлу, даже если менялось года три назад, работает нормально. Секунд 5 где-то. S>... S>P.S. Blame — 2-3 секунды на больших файлах с длинной историей. S>Это всё с учётом того, что сервер не в локальной сети.
С трудом верится, особенно вспоминая жёсткие roundtrip'ы при работе с SVN, даже на мелких репозиториях в пару сотен коммитов. Но хорошо если действительно так.
Я думал там тормоза принципиальные, из-за архитектуры.
S>ну и чекаут репо на несколько Гб может минут 20 занять.
Первоначальный checkout не сильно волнует (если рассматривать работу над парой проектов). Git'ом выкачивал тысячи коммитов из SVN несколько дней, и ничего
Но, это же переход на старую ревизию или ветку может быть очень долгим, так? Например в целях поиска коммита внёсшего баг, а-ля git bisect.
S>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал.
Это говорит о сомнительном удобстве инструмента, как мне кажется.
Но я до вчерашнего момента считал, что неплохо знаю Git
Ошибался, был не прав.
S>Или использовать ui-инструменты, они хоть предупреждают о возможных косяках, или страдать.
UI-инструменты, увы, безудержно тупят. Консоль работает на порядки быстрее. Ну и я учусь на своих ошибках.
