|
2.16, eRIC (ok), 16:34, 14/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
SVN является как раз таки централизованной системой отслеживания кода, когда как GIT децентрализованная
| |
|
|
4.39, eRIC (ok), 22:03, 14/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> и чо?
ничего, идите в гугл кто сравнивает SVN vs GIT
| |
|
|
4.24, Аноним (-), 17:21, 14/01/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
> А у шара нет граней
Игроделы с этим тезисом мягко говоря не согласятся. Более того - у хорошего шара граней много.
| |
|
|
|
7.71, Попугай Кеша (?), 16:30, 20/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Те из них кто поумнее - не жалеет граней на шары :)
А потом - почему это игра тормозит на 16 Гб оперативы? )
| |
|
|
|
|
|
|
|
2.6, Аноним (6), 14:10, 14/01/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
В том то и дело, что именно "sparseCheckoutCone", а не "sparseCheckoutClone"
| |
|
1.3, iCat (ok), 13:56, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
1 коммит с каждого разработчика при учёте, что работали 7 дней...
Не густо... :)
| |
|
|
|
4.25, Аноним (-), 17:22, 14/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Сложна, там на сях надо писать
Ну так поэтому оно и крутое - работает шустро, ведет себя логично. И вообще, на что способны вебмакаки можно посмотреть в каком-нибудь hg. Фич навалили гору, зато все работает как картонный макет какой-то.
| |
|
5.40, анонн (ok), 22:21, 14/01/2020 [^] [^^] [^^^] [ответить] | –1 +/– | А то, что оно еще пару лет назад было наполовину на шелле code cloc git-2 0 ... большой текст свёрнут, показать | |
|
6.47, Аноним (46), 06:25, 15/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Кстати вебманки о себе напомнили в соседней новости. И таки очень предсказуемо напомнили: картина Репина "дохайповались".
| |
6.62, Ан оНим (?), 22:55, 15/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Неважно, шелл не шелл.
Важно насколько осилил изложить нужное. Хороший был бы алгоритм. Язык вторичен.
| |
|
7.69, Аноним (-), 18:51, 18/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Конечно, плохим алгоритмом можно и хороший ЯП ушатать, но все же теория ничто без практики. А алгоритм ничто без качественной реализации. И вот тут уже ЯП полностью сбросить со счетов сложно. Ну вот есть у вас офигенный алгоритм допустим шифрования - но на бэйсике, блин. И чего? Сами перепишете на что там вам хотелось? В процессе влепите десяток новых вулнов, сами того не желая. Потому что специфичная область, без владения которой стандартными подходами - только дров наломать можно.
| |
|
|
|
|
|
|
1.7, Ivan_83 (ok), 14:35, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
"В команду "git submodule" добавлена подкоманда "set-url"" - наконец то!
| |
1.9, Аноним (9), 14:57, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
> Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями
Не "одной из", а самой. По сути, на данный момент единственной.
| |
|
2.11, aa (?), 15:18, 14/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
самой популярной - да
по надежности и производительности возможно есть и лучше (пусть ими и пользуется 1 человек)
и любителей subversion и mercurial пока еще достаточно, чтобы не говорить,что гит - единственная
| |
|
3.12, microsoft (?), 15:33, 14/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> и любителей subversion и mercurial пока еще достаточно
но для них нет нашей прекрасной gitfs! Поэтому по производительности они безнадежно в пролете.
| |
3.26, Аноним (-), 17:25, 14/01/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
> и любителей subversion и mercurial пока еще достаточно
Пока еще. Ха, именно так. Постепенно даже до этих доползает что хорошие инструменты разработки от профессиональных програмеров а не макак с самомнением - использовать эффективнее, да и просто приятно, наконец.
| |
|
4.30, Аноним (30), 17:40, 14/01/2020 [^] [^^] [^^^] [ответить] | +1 +/– | хм какой смысл менять инструмент, который всем устраивает и под который уже отл... большой текст свёрнут, показать | |
|
5.31, Ordu (ok), 18:01, 14/01/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Не надо делать revert в таких случаях. revert ведь не удаляет коммит, а накладывает сверху ещё один, который обнуляет эффект первого.
Делай git reset, чтобы поставиь HEAD на нужный коммит, таким образом ветка приходит в состояние, будто никакого коммита и не было вовсе. Или вообще ничего не делай: внеси исправления в issue, и вторым мергом исправь первый. История коммитов будет чуть более грязной, но ты потом можешь исправить это, когда будешь перекидывать её из issue в master. Правда для этого надо не merge делать, а rebase. Но я бы вообще рекомендовал rebase, merge принудительно сливает все коммиты в один, rebase же позволяет некоторые слить, некоторые оставить как есть, некоторые опустить вообще.
| |
|
6.33, Аноним (30), 18:51, 14/01/2020 [^] [^^] [^^^] [ответить] | +/– | я это уже понял но для меня было несколько неожиданно, что новый MR не будет со... большой текст свёрнут, показать | |
|
7.35, Аноним (35), 18:58, 14/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> а если после этого слияния прошли новые? не всегда же нужно именно "верхний" MR откатить...
Просто для понимания: при откате неверхнего мержа могут и конфликты возникнуть, которые вам исправлять придётся. И результат исправления которых поломает и другие мержи.
| |
7.44, Ordu (ok), 02:31, 15/01/2020 [^] [^^] [^^^] [ответить] | –1 +/– | Оглядываясь назад на свой опыт освоения git, я бы рекомендовал забить для начала... большой текст свёрнут, показать | |
|
|
5.34, Аноним (35), 18:54, 14/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Сразу скажу, что практически не работал с гитлаб.
> если же там будет несколько человек топтаться
У нас в компании workflow реализован несколько по-иному, и за релиз-ветку всегда есть ответственный. Один. И только он может вливать в пререлизную/тестовую ветку задачные ветки. Соответственно, он в курсе всех ревертов и мерджей, и проблемы с топтанием нескольких человек не возникает.
> всякие CI/CD научить откатывать изменения, ломающие ветки
В таком случае разработчику issue должно уведомление слаться, что его ветку откатили, с номером реверта, чтобы при следующем MR он понимал, что в текущей testing его изменений нет и нужно ревертнуть автоматический реверт.
Кроме того, вы ссылаетесь на конкретный workflow, и для вашей организации он просто может не подходить.
| |
|
6.36, Аноним (30), 19:03, 14/01/2020 [^] [^^] [^^^] [ответить] | –1 +/– | интересно, где я спалился вроде ж не озвучивал, что именно с ним работаю а е... большой текст свёрнут, показать | |
|
7.41, Аноним (41), 22:57, 14/01/2020 [^] [^^] [^^^] [ответить] | +/– | Гит распределённый, у грамотных людей реквесты называются пулл-реквестами По... большой текст свёрнут, показать | |
|
8.55, Аноним (30), 11:57, 15/01/2020 [^] [^^] [^^^] [ответить] | +/– | спасибо за ликбез увы, в наших реалиях документирование не работает документа... большой текст свёрнут, показать | |
|
|
|
5.43, Alex (??), 01:53, 15/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Merge не делается до проверки работоспособности, а если возникают проблемы, то да, revert/частичный откат изменений.
Обычно flow выглядит так:
* master/develop/release -- рабочее состояние, ничего не сломано, можно собрать/запустить
* feature/my-cool-feature -- твоя ветка разработки, ты там делаешь все, что хочешь
CI всегда собирает master. Остальные ветки по возможности (железо слабое, проект тяжелый и т.п.)
Также всегда собираются и Pull Request'ы, но с оговоркой, что собирается не ветка, которую будут сливать, а merge commit -- по сути такое состояние репы, в котором твою ветку как бы слили в таргет-ветку (например, master). При таком подходе CI будет запускать сборку на новый коммит в PR-ветке, а также на новые коммиты в таргет-ветке (master).
Если нужен rollback, в случае если, например, релиз не поднялся, то в гите ничего я бы не стал менять, а просто на почту/месенджеры информацию послал бы.
| |
|
6.57, Аноним (30), 12:35, 15/01/2020 [^] [^^] [^^^] [ответить] | +/– | каким образом это реализуется допустим, имеем такие ветки - master, testing, is... большой текст свёрнут, показать | |
|
7.67, Аноним (67), 02:45, 18/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Как мне получить состояние ветки testing после апрува MR для проверки работоспособности, не выполняя собственно MR?
git checkout testing # или git switch по современному
git merge --no-ff --no-commit issue2
<проверка работоспособности> && git commit -m "I am the best." || echo "MR is BAD" | mail vasya
| |
|
|
5.48, Аноним (-), 06:41, 15/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> который всем устраивает и под который уже отлажены все процессы?
Если б все так рассуждали, прогресс застопорился бы на набедренной повязке из листьев пальмы.
> Зато взамен вы получите... что?
Нормальный инструмент от профессионалов и современные, эффективные workflow, например.
| |
|
6.59, Аноним (30), 12:48, 15/01/2020 [^] [^^] [^^^] [ответить] | +/– | подобного рода диалоги - неконструктивны у прогресса должна быть конкретная цел... большой текст свёрнут, показать | |
|
7.68, Аноним (67), 03:57, 18/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Зачем вашей компании гит если svn вас устраивает?
И Вам зачем? Чтоб не казаться ретроградом?
> И диалог с людьми, которые имеют реальный опыт работы с git - это тот конструктив, за которым я сюда пришел.
Однако приглашение к диалогу выглядит как "Ну поуговаривайте меня, поубеждайте перейти на GIT. А я буду говорить фууу, ваш GIT не решает наших проблем".
| |
7.70, Аноним (-), 19:07, 18/01/2020 [^] [^^] [^^^] [ответить] | +/– | Несомненно А чем цель в виде современного эффективного воркфлоу плоха Посмотри... большой текст свёрнут, показать | |
|
|
5.65, Аноним (65), 12:46, 17/01/2020 [^] [^^] [^^^] [ответить] | +/– | Подобные затруднения возникают когда не понимают не знают принципы работы инстру... большой текст свёрнут, показать | |
|
|
|
|
1.37, Аноним (37), 19:25, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
В subversion хотя бы удобнее хранить всякую мультимедию, где она централизовано хранится на сервере, есть svn lock и т.д. А git? Чтобы загрузить жалкий 14 Кбайтный xml файл нужно загрузить терабайт wav'ок. А в svn можно просто отдельные файлы загружать.
| |
|
2.49, Аноним (-), 06:42, 15/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> есть svn lock и т.д.
А, чо, это они у TFS'а "фиче" научились? Так офигенно, когда дев {слинял в отпуск, заболел, уволился, забухал} и оставил половину репы залоченой. Так что потом все околачивают груши и ждут пока одмины сшибут лок :)
| |
|
1.38, Аноним (38), 20:39, 14/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
С этой "partial clones" ещё работать и работать. До удобства и лёгкости SVN ещё далеко. Тут нельзя просто выкачать файлы из папки /A/B/C При таком частичном клонировании будет воссоздана структура вложенности каталогов что и даром не сдалось если человек хочет работать только с содержимым в папке C
| |
|
2.50, Аноним (-), 06:51, 15/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Удобство и легкость svn можно понаблюдать, сделав чекаут проекта месячной давности и сравнив как это "быстро" и "удобно" качает все и вся.
Про то чтобы ненапряжно закомитить пару мелочей с лаптопа, потому что пока млел под пальмой пришла в бошку хорошая мысля - речь и вовсе не идет.
| |
2.66, Аноним (67), 02:12, 18/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Тут нельзя просто выкачать файлы из папки /A/B/C
И это хорошо сдерживает от превращения репозитория в файлопомойку.
> если человек хочет работать только с содержимым в папке C
Если изменения в директории C не влияют на другие директории, то есть смысл оформить C как отдельный репозиторий.
А вообще, не нужно пытатся "прогнуться" под git.
Выбирайте те средства (svn например), которые решают ваши проблемы, а не добавляют новые.
| |
|
1.53, Ананимас009 (?), 10:53, 15/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вброшу https://svnvsgit.com/
Если со связью проблем не прдвидется и хотелось бы хранить бинарь с возможностью скачать именно содержимое директории n-го уровня в репозитории, то svn гораздо удобнее?
Вообще удивили проценты использования в опенсурсе. Я думал там давно один гит и гитгм погоняет.
| |
|