forum.opennet.ru - "Выпуск распределенной системы управления исходными текстами ..." (72)

"Выпуск распределенной системы управления исходными текстами ..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск распределенной системы управления исходными текстами ..."	+/–
Сообщение от opennews (??), 14-Янв-20, 13:53
Доступен выпуск распределенной системы управления исходными текстами Git 2.25.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52180
Ответить \| Правка \| Cообщить модератору

Оглавление

SVN в 100 раз, Аноним (1), 13:53 , 14-Янв-20, (1) +5

чем гит, Анонец (?), 14:56 , 14-Янв-20, (8) +3

Что , Снайпе (?), 16:10 , 14-Янв-20, (13) +2

SVN в 100 раз, Аноним (15), 16:33 , 14-Янв-20, (15) +4

Зато Git в 100 раз, Аноним (19), 17:03 , 14-Янв-20, (19) +4

тоже верночем свн , little Bobby tables (?), 17:32 , 14-Янв-20, (28) +3

Медленнее , Аноним (-), 17:19 , 14-Янв-20, (23) +4

SVN является как раз таки централизованной системой отслеживания кода, когда как, eRIC (ok), 16:34 , 14-Янв-20, (16)

и чо , конь в пальто (?), 16:45 , 14-Янв-20, (17) +1

ничего, идите в гугл кто сравнивает SVN vs GIT, eRIC (ok), 22:03 , 14-Янв-20, (39) –1

Код SVN красивше чем, Ан оНим (?), 22:52 , 15-Янв-20, (60)

А у шара нет граней, тогда как у куба их целых 6 , A.Stahl (ok), 16:47 , 14-Янв-20, (18) +12

Можно сказать, что у шара - бесконечное число граней , Попугай Кеша (?), 17:19 , 14-Янв-20, (22) +3
Игроделы с этим тезисом мягко говоря не согласятся Более того - у хорошего шара, Аноним (-), 17:21 , 14-Янв-20, (24) +5

Игроделы намного умнее чем ты о них думаешь , A.Stahl (ok), 17:27 , 14-Янв-20, (27)

Те из них кто поумнее - не жалеет граней на шары , Аноним (46), 06:24 , 15-Янв-20, (46) +1

Больше граней -- легче катать , Анонымоус (?), 07:08 , 15-Янв-20, (51) +1

Шары не катают, Ан оНим (?), 22:52 , 15-Янв-20, (61)

А потом - почему это игра тормозит на 16 Гб оперативы , Попугай Кеша (?), 16:30 , 20-Янв-20, (71)

а ещё был случай идем в столовку талоны профилакта проедать а навстречу бабы с и, little Bobby tables (?), 17:33 , 14-Янв-20, (29) +2

l залипает , Аноним (2), 13:55 , 14-Янв-20, (2) –2

В том то и дело, что именно sparseCheckoutCone , а не sparseCheckoutClone , Аноним (6), 14:10 , 14-Янв-20, (6) +5

1 коммит с каждого разработчика при учёте, что работали 7 дней Не густо , iCat (ok), 13:56 , 14-Янв-20, (3) –1

иди, да помоги им своими коммитами, анонимус_потерял_свой_логин (?), 14:07 , 14-Янв-20, (5)

Сложна, там на сях надо писать, НяшМяш (ok), 15:16 , 14-Янв-20, (10) +1

ну да, на опеннете-то писульки писать проще намного, анонимус_потерял_свой_логин (?), 17:09 , 14-Янв-20, (21) +2
Ну так поэтому оно и крутое - работает шустро, ведет себя логично И вообще, на , Аноним (-), 17:22 , 14-Янв-20, (25) +1

А то, что оно еще пару лет назад было наполовину на шелле code cloc git-2 0 0-, анонн (ok), 22:21 , 14-Янв-20, (40) –1

Кстати вебманки о себе напомнили в соседней новости И таки очень предсказуемо н, Аноним (46), 06:25 , 15-Янв-20, (47) –1
Неважно, шелл не шелл Важно насколько осилил изложить нужное Хороший был бы алг, Ан оНим (?), 22:55 , 15-Янв-20, (62)

Конечно, плохим алгоритмом можно и хороший ЯП ушатать, но все же теория ничто бе, Аноним (-), 18:51 , 18-Янв-20, (69)

перепиши на расте - это проста , Аноним (32), 18:41 , 14-Янв-20, (32) +1

а переход на следущую sha что надоело чтоль , X5asd (?), 13:56 , 14-Янв-20, (4) –2

коллизии почти научились подбирать, Alex (??), 16:20 , 14-Янв-20, (14) –3

В команду git submodule добавлена подкоманда set-url - наконец то , Ivan_83 (ok), 14:35 , 14-Янв-20, (7) +3
Не одной из , а самой По сути, на данный момент единственной , Аноним (9), 14:57 , 14-Янв-20, (9) –2

самой популярной - дапо надежности и производительности возможно есть и лучше п, aa (?), 15:18 , 14-Янв-20, (11) +1

но для них нет нашей прекрасной gitfs Поэтому по производительности они безнаде, microsoft (?), 15:33 , 14-Янв-20, (12)

Ты еще скажи VFS for Git , Аноним (19), 17:04 , 14-Янв-20, (20) –1

Пока еще Ха, именно так Постепенно даже до этих доползает что хорошие инструме, Аноним (-), 17:25 , 14-Янв-20, (26) –3

хм какой смысл менять инструмент, который всем устраивает и под который уже отл, Аноним (30), 17:40 , 14-Янв-20, (30) +1

Не надо делать revert в таких случаях revert ведь не удаляет коммит, а накладыв, Ordu (ok), 18:01 , 14-Янв-20, (31) +3

я это уже понял но для меня было несколько неожиданно, что новый MR не будет со, Аноним (30), 18:51 , 14-Янв-20, (33)

Просто для понимания при откате неверхнего мержа могут и конфликты возникнуть, , Аноним (35), 18:58 , 14-Янв-20, (35)
Оглядываясь назад на свой опыт освоения git, я бы рекомендовал забить для начала, Ordu (ok), 02:31 , 15-Янв-20, (44) –1

Сразу скажу, что практически не работал с гитлаб У нас в компании workflow реали, Аноним (35), 18:54 , 14-Янв-20, (34) +1

интересно, где я спалился вроде ж не озвучивал, что именно с ним работаю а ес, Аноним (30), 19:03 , 14-Янв-20, (36) –1

Гит распределённый, у грамотных людей реквесты называются пулл-реквестами По, Аноним (41), 22:57 , 14-Янв-20, (41)

Соврал, не на lkml это видел, а на kernel org Например https git kernel org , Аноним (41), 23:07 , 14-Янв-20, (42)
спасибо за ликбез увы, в наших реалиях документирование не работает документац, Аноним (30), 11:57 , 15-Янв-20, (55)

Да бежать надо из компании, где все так быстро меняется Обычно это менеджеры ка, Попугай Кеша (?), 16:37 , 20-Янв-20, (72)

Merge не делается до проверки работоспособности, а если возникают проблемы, то д, Alex (??), 01:53 , 15-Янв-20, (43)

каким образом это реализуется допустим, имеем такие ветки - master, testing, iss, Аноним (30), 12:35 , 15-Янв-20, (57)

git checkout testing или git switch по современномуgit merge --no-ff --no-comm, Аноним (67), 02:45 , 18-Янв-20, (67)

Если б все так рассуждали, прогресс застопорился бы на набедренной повязке из ли, Аноним (-), 06:41 , 15-Янв-20, (48) –1

подобного рода диалоги - неконструктивны у прогресса должна быть конкретная цел, Аноним (30), 12:48 , 15-Янв-20, (59)

Зачем вашей компании гит если svn вас устраивает И Вам зачем Чтоб не казаться р, Аноним (67), 03:57 , 18-Янв-20, (68)
Несомненно А чем цель в виде современного эффективного воркфлоу плоха Посмотри, Аноним (-), 19:07 , 18-Янв-20, (70)

Подобные затруднения возникают когда не понимают не знают принципы работы инстру, Аноним (65), 12:46 , 17-Янв-20, (65)

В subversion хотя бы удобнее хранить всякую мультимедию, где она централизовано , Аноним (37), 19:25 , 14-Янв-20, (37) –1

Git LFS, Anonymqwe (?), 05:07 , 15-Янв-20, (45)
А, чо, это они у TFS а фиче научились Так офигенно, когда дев слинял в отпус, Аноним (-), 06:42 , 15-Янв-20, (49)

С этой partial clones ещё работать и работать До удобства и лёгкости SVN ещё , Аноним (38), 20:39 , 14-Янв-20, (38) –2

Удобство и легкость svn можно понаблюдать, сделав чекаут проекта месячной давнос, Аноним (-), 06:51 , 15-Янв-20, (50)
И это хорошо сдерживает от превращения репозитория в файлопомойку Если изменения, Аноним (67), 02:12 , 18-Янв-20, (66)

Интересно просто, с философской точки зрения, в git есть репозиторий git , Анатоним (?), 10:50 , 15-Янв-20, (52)

git лежит в репозитории git, ага, рекурсия - она такая , Аноним (32), 11:20 , 15-Янв-20, (54)
Ч-чё прям, как маленький-то Микрософт Гитхабб заботится о Вас I Git via GitI, Andrey Mitrofanov_N0 (??), 12:32 , 15-Янв-20, (56)

Вброшу https svnvsgit com Если со связью проблем не прдвидется и хотелось бы х, Ананимас009 (?), 10:53 , 15-Янв-20, (53)

Никому верить нельзя, мне - можно ц старина Мюллер I and LLVM continue to use, Andrey Mitrofanov_N0 (??), 12:45 , 15-Янв-20, (58) +1

какой нафиг SHA-2 SHA-3 давно стандарт, Аноним (63), 02:14 , 16-Янв-20, (63) –1
Однако Два двадцать пять c 12 стульев, trolleybus (?), 09:30 , 16-Янв-20, (64) +1

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 14-Янв-20, 13:53 +5 +/–

SVN в 100 раз

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #16

2. Сообщение от Аноним (2), 14-Янв-20, 13:55 –2 +/–

l залипает?)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

3. Сообщение от iCat (ok), 14-Янв-20, 13:56 –1 +/–

1 коммит с каждого разработчика при учёте, что работали 7 дней...
Не густо... :)

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

4. Сообщение от X5asd (?), 14-Янв-20, 13:56 –2 +/–

а переход на следущую sha что? надоело чтоль?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14

5. Сообщение от анонимус_потерял_свой_логин (?), 14-Янв-20, 14:07 +/–

иди, да помоги им своими коммитами

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #10

6. Сообщение от Аноним (6), 14-Янв-20, 14:10 +5 +/–

В том то и дело, что именно "sparseCheckoutCone", а не "sparseCheckoutClone"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

7. Сообщение от Ivan_83 (ok), 14-Янв-20, 14:35 +3 +/–

"В команду "git submodule" добавлена подкоманда "set-url"" - наконец то!

Ответить | Правка | Наверх | Cообщить модератору

8. Сообщение от Анонец (?), 14-Янв-20, 14:56 +3 +/–

чем гит

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13

9. Сообщение от Аноним (9), 14-Янв-20, 14:57 –2 +/–

> Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями
Не "одной из", а самой. По сути, на данный момент единственной.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

10. Сообщение от НяшМяш (ok), 14-Янв-20, 15:16 +1 +/–

Сложна, там на сях надо писать

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #21, #25, #32

11. Сообщение от aa (?), 14-Янв-20, 15:18 +1 +/–

самой популярной - да
по надежности и производительности возможно есть и лучше (пусть ими и пользуется 1 человек)
и любителей subversion и mercurial пока еще достаточно, чтобы не говорить,что гит - единственная

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #12, #26

12. Сообщение от microsoft (?), 14-Янв-20, 15:33 +/–

> и любителей subversion и mercurial пока еще достаточно
но для них нет нашей прекрасной gitfs! Поэтому по производительности они безнадежно в пролете.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #20

13. Сообщение от Снайпе (?), 14-Янв-20, 16:10 +2 +/–

Что?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #15, #23

14. Сообщение от Alex (??), 14-Янв-20, 16:20 –3 +/–

коллизии (почти) научились подбирать

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

15. Сообщение от Аноним (15), 14-Янв-20, 16:33 +4 +/–

SVN в 100 раз

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #19

16. Сообщение от eRIC (ok), 14-Янв-20, 16:34 +/–

SVN является как раз таки централизованной системой отслеживания кода, когда как GIT децентрализованная

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #17, #18

17. Сообщение от конь в пальто (?), 14-Янв-20, 16:45 +1 +/–

и чо?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #39

18. Сообщение от A.Stahl (ok), 14-Янв-20, 16:47 +12 +/–

А у шара нет граней, тогда как у куба их целых 6.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #22, #24, #29

19. Сообщение от Аноним (19), 14-Янв-20, 17:03 +4 +/–

Зато Git в 100 раз

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #28

20. Сообщение от Аноним (19), 14-Янв-20, 17:04 –1 +/–

Ты еще скажи VFS for Git.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

21. Сообщение от анонимус_потерял_свой_логин (?), 14-Янв-20, 17:09 +2 +/–

ну да, на опеннете-то писульки писать проще намного

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

22. Сообщение от Попугай Кеша (?), 14-Янв-20, 17:19 +3 +/–

Можно сказать, что у шара - бесконечное число граней )

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

23. Сообщение от Аноним (-), 14-Янв-20, 17:19 +4 +/–

> Что?
Медленнее.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

24. Сообщение от Аноним (-), 14-Янв-20, 17:21 +5 +/–

> А у шара нет граней
Игроделы с этим тезисом мягко говоря не согласятся. Более того - у хорошего шара граней много.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #27

25. Сообщение от Аноним (-), 14-Янв-20, 17:22 +1 +/–

> Сложна, там на сях надо писать
Ну так поэтому оно и крутое - работает шустро, ведет себя логично. И вообще, на что способны вебмакаки можно посмотреть в каком-нибудь hg. Фич навалили гору, зато все работает как картонный макет какой-то.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #40

26. Сообщение от Аноним (-), 14-Янв-20, 17:25 –3 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #30

27. Сообщение от A.Stahl (ok), 14-Янв-20, 17:27 +/–

Игроделы намного умнее чем ты о них думаешь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #46

28. Сообщение от little Bobby tables (?), 14-Янв-20, 17:32 +3 +/–

тоже верно
чем свн.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

29. Сообщение от little Bobby tables (?), 14-Янв-20, 17:33 +2 +/–

а ещё был случай идем в столовку талоны профилакта проедать а навстречу бабы с иняза

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

30. Сообщение от Аноним (30), 14-Янв-20, 17:40 +1 +/–

хм. какой смысл менять инструмент, который всем устраивает и под который уже отлажены все процессы? сможешь объяснить преимущества перехода с того же SVN на GIT для распределенной команды разработчиков (с разными скиллами)? Ну так, чтобы сказать бизнесу - мы хотим перейти на Git, ближайшие пол года минимум у нас будут периодически возникать простои в работе (как часто - мы не знаем), да и сам переход не бесплатен. Зато взамен вы получите... что?
И еще вопрос. Я вот для себя начал смотреть в сторону git. И столкнулся с такой проблемой:
есть 2 ветки - для issue и вторая - testing. закомитил (C1) в issue, сделал merge request (MR1) в testing, обновил тестовое окружение. и вижу, что обновление создает проблемы. делаю revert этого MR1, чиню проблемы в ветке issue, создаю MR2 для слияния ветки issue в testing и понимаю, что C1 в этот самый MR2 не попадает. Потому что он уже есть в ветке testing. Хотя изменения этого комита я ревертнул... И теперь вопрос - как с такой ситуацией бороться, или как в нее не попадать? Я то выкрутился (сделал revert для первого revert), но меня не покидает ощущение, что это неправильное решение. и это я пока один в этом репозитории, если же там будет несколько человек топтаться, да еще и всякие CI/CD научить откатывать изменения, ломающие ветки, то этот бардак потом вряд-ли кто-то сможет разгрести для релиза.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #31, #34, #43, #48, #65

31. Сообщение от Ordu (ok), 14-Янв-20, 18:01 +3 +/–

Не надо делать revert в таких случаях. revert ведь не удаляет коммит, а накладывает сверху ещё один, который обнуляет эффект первого.
Делай git reset, чтобы поставиь HEAD на нужный коммит, таким образом ветка приходит в состояние, будто никакого коммита и не было вовсе. Или вообще ничего не делай: внеси исправления в issue, и вторым мергом исправь первый. История коммитов будет чуть более грязной, но ты потом можешь исправить это, когда будешь перекидывать её из issue в master. Правда для этого надо не merge делать, а rebase. Но я бы вообще рекомендовал rebase, merge принудительно сливает все коммиты в один, rebase же позволяет некоторые слить, некоторые оставить как есть, некоторые опустить вообще.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #33

32. Сообщение от Аноним (32), 14-Янв-20, 18:41 +1 +/–

перепиши на расте - это проста! )))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

33. Сообщение от Аноним (30), 14-Янв-20, 18:51 +/–

>> Не надо делать revert в таких случаях. revert ведь не удаляет коммит, а накладывает сверху ещё один, который обнуляет эффект первого.
я это уже понял. но для меня было несколько неожиданно, что новый MR не будет содержать этот коммит. и в контексте перехода команды на новый инструмент - подобных неожиданных вещей для разных разработчиков будет немало...
>> Делай git reset, чтобы поставиь HEAD на нужный коммит, таким образом ветка приходит в состояние, будто никакого коммита и не было вовсе.
а если после этого слияния прошли новые? не всегда же нужно именно "верхний" MR откатить..
>> Или вообще ничего не делай: внеси исправления в issue, и вторым мергом исправь первый.
если исправление можно сделать быстро - это норм вариант. но если на исправление нужно время - тогда не катит. я пытаюсь выработать общую стратегию поведения, которую мне нужно будет донести другим разработчикам, и такой вариант даже озвучивать нельзя.
>> Но я бы вообще рекомендовал rebase, merge принудительно сливает все коммиты в один, rebase же позволяет некоторые слить, некоторые оставить как есть, некоторые опустить вообще.
с rebase я еще не разбирался детально, а т.к. ранее мне попадались холивары по поводу его использования, я решил заняться им позже, когда чуть лучше разберусь с базовыми вещами.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #35, #44

34. Сообщение от Аноним (35), 14-Янв-20, 18:54 +1 +/–

Сразу скажу, что практически не работал с гитлаб.
> если же там будет несколько человек топтаться
У нас в компании workflow реализован несколько по-иному, и за релиз-ветку всегда есть ответственный. Один. И только он может вливать в пререлизную/тестовую ветку задачные ветки. Соответственно, он в курсе всех ревертов и мерджей, и проблемы с топтанием нескольких человек не возникает.
> всякие CI/CD научить откатывать изменения, ломающие ветки
В таком случае разработчику issue должно уведомление слаться, что его ветку откатили, с номером реверта, чтобы при следующем MR он понимал, что в текущей testing его изменений нет и нужно ревертнуть автоматический реверт.
Кроме того, вы ссылаетесь на конкретный workflow, и для вашей организации он просто может не подходить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #36

35. Сообщение от Аноним (35), 14-Янв-20, 18:58 +/–

> а если после этого слияния прошли новые? не всегда же нужно именно "верхний" MR откатить...
Просто для понимания: при откате неверхнего мержа могут и конфликты возникнуть, которые вам исправлять придётся. И результат исправления которых поломает и другие мержи.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

36. Сообщение от Аноним (30), 14-Янв-20, 19:03 –1 +/–

>> Сразу скажу, что практически не работал с гитлаб.
интересно, где я спалился? вроде ж не озвучивал, что именно с ним работаю...
>> У нас в компании workflow реализован несколько по-иному, и за релиз-ветку всегда есть ответственный. Один. И только он может вливать в пререлизную/тестовую ветку задачные ветки. Соответственно, он в курсе всех ревертов и мерджей, и проблемы с топтанием нескольких человек не возникает.
а если он заболел, в отпуск ушел, еще по каким-то причинам недоступен? как по мне, процессы не должны зависеть от одного человека...
>> В таком случае разработчику issue должно уведомление слаться, что его ветку откатили, с номером реверта, чтобы при следующем MR он понимал, что в текущей testing его изменений нет и нужно ревертнуть автоматический реверт.
когда человек должен что-то понимать или помнить - это плохо выстроенный процесс. я пытаюсь этого избегать.
>> Кроме того, вы ссылаетесь на конкретный workflow, и для вашей организации он просто может не подходить.
workflow собственно я сам и пытаюсь выработать, т.е. я ничем не ограничен "снаружи". но есть некие "внутренние" ограничения, которые сложно описать словами (как пример - никто не должен ничего держать в голове, и никаких дополнительных листочков с записями. да, есть коменты, есть метки... но хочется, чтобы все было максимально прозрачно)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #41

37. Сообщение от Аноним (37), 14-Янв-20, 19:25 –1 +/–

В subversion хотя бы удобнее хранить всякую мультимедию, где она централизовано хранится на сервере, есть svn lock и т.д. А git? Чтобы загрузить жалкий 14 Кбайтный xml файл нужно загрузить терабайт wav'ок. А в svn можно просто отдельные файлы загружать.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #49

38. Сообщение от Аноним (38), 14-Янв-20, 20:39 –2 +/–

С этой "partial clones" ещё работать и работать. До удобства и лёгкости SVN ещё далеко. Тут нельзя просто выкачать файлы из папки /A/B/C При таком частичном клонировании будет воссоздана структура вложенности каталогов что и даром не сдалось если человек хочет работать только с содержимым в папке C

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50, #66

39. Сообщение от eRIC (ok), 14-Янв-20, 22:03 –1 +/–

> и чо?
ничего, идите в гугл кто сравнивает SVN vs GIT

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #60

40. Сообщение от анонн (ok), 14-Янв-20, 22:21 –1 +/–

>> Сложна, там на сях надо писать
> Ну так поэтому оно и крутое - работает шустро, ведет себя логично.
А то, что оно еще пару лет назад было наполовину на шелле:

cloc git-2.0.0-rc4
    2652 text files.
    2530 unique files.
    1124 files ignored.
github.com/AlDanial/cloc v 1.82  T=3.91 s (391.9 files/s, 143939.1 lines/s)
-----------------------------------------------------------------------------------
Language                         files          blank        comment           code
-----------------------------------------------------------------------------------
C                                  350          21503          19042         139199
Bourne Shell                       804          22951           8112         137664
cloc git-2.25.0
    3645 text files.
    3513 unique files.
    1593 files ignored.
github.com/AlDanial/cloc v 1.82  T=6.42 s (320.8 files/s, 159399.4 lines/s)
-----------------------------------------------------------------------------------
Language                         files          blank        comment           code
-----------------------------------------------------------------------------------
PO File                             51          76781          83594         222214
C                                  473          35176          29663         209198
Bourne Shell                      1079          33464          13447         202936

https://www.opennet.ru/opennews/art.shtml?num=43057
> Выпуск распределенной системы управления исходными текстами Git 2.6.0
> 29.09.2015
> Реализации "git pull" и "git am" переписаны на языке Си
...
https://www.opennet.ru/opennews/art.shtml?num=49751
> Выпуск распределенной системы управления исходными текстами Git 2.20
> 10.12.2018 09:46
> Реализации команд "git submodule update", "git rebase" и "git rebase -i" полностью переписаны на языке Си
https://www.opennet.ru/opennews/art.shtml?num=50202
> Выпуск распределенной системы управления исходными текстами Git 2.21
> 25.02.2019 10:07
> Некоторые части "git bisect", ранее реализованные на Shell, переписаны на языке Си;
так то было давно и уже почти неправда =)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #47, #62

41. Сообщение от Аноним (41), 14-Янв-20, 22:57 +/–

> интересно, где я спалился?
Гит распределённый, у (грамотных?) людей реквесты называются пулл-реквестами. Потому что нужно сделать пулл (стянуть данные с ДРУГОГО репозитория и смержить их), а не мерж (смержить данные из централизованного репозитория в него же самого только в другую ветку). На том же lkml Линуса просят смержить именно в форме "Линус, сделай пжл пулл-реквест к себе с репозитория git://some.git.repo/url.git из ветки for-linus". А в гитлабе это именно "Глав, смерж пжл в нашем ЦЕНТРАЛИЗОВАННОМ репозитории в свою ветку из моей".
Сам был удивлён, когда узнал, что в гитлабе, оплоте гита, используются "мерж-реквесты". Но, насколько я понимаю, сам гитлаб является, в общем-то, централизованной системой, построенной на основе распределённого гита. Так что подобная терминология объяснима.
> а если он заболел, в отпуск ушел, еще по каким-то причинам недоступен?
> когда человек должен что-то понимать или помнить - это плохо выстроенный процесс. я пытаюсь этого избегать.
А если в середине реализации issue заболел программист, который её реализует? Всё аналогично. На время болезни его подменяет другой, который видит всю историю ветки testing и принимает решения. Суть не в том, что есть только один человек, кто в курсе происходящего. А в том, что в один момент времени есть только один человек, ответственный за ветку, который может мержить и коммитить в неё и принимает решения относительно её прогресса. Если основной недоступен, то замещающему, конечно, потребуется время, чтоб войти в процесс. И имхо запоминание можно заменить на документирование.
Но у нас нет CI (и вообще хардкорной автоматизации), так что если что-то ломается, то это мешает только тестировщикам, а программисты варятся в своих ветках. И виновный исправляет, после чего ответственный за ветку вливает исправление. Тестировщики тем временем тестируют предыдущий слепок ветки или другой проект.
Насколько я понял вашу проблему, если у вас в разработке 10 задач, то 10 разных программистов в случайные моменты времени могут коммитить в testing, этакое коллективное владение кодом. Имхо это бардак. У нас это исключено, за ветку отвечает ровно один человек.
> workflow собственно я сам и пытаюсь выработать
У нас небольшая компания, и управление проектами организовано так, что а. нет необходимости держать testing работоспособным 100% времени (по сути мы реализуем согласованный объём работ, и только после этого начинается активное тестирование), б. если кто-то поломал testing, всегда есть возможность посадить его вне очереди исправлять проблему. Так что ревертов, подобных вашему, не требуется.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #42, #55

42. Сообщение от Аноним (41), 14-Янв-20, 23:07 +/–

> На том же lkml
Соврал, не на lkml это видел, а на kernel.org . Например:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Все мержи содержат адреса репозиториев, причём везде разные.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

43. Сообщение от Alex (??), 15-Янв-20, 01:53 +/–

Merge не делается до проверки работоспособности, а если возникают проблемы, то да, revert/частичный откат изменений.
Обычно flow выглядит так:
* master/develop/release -- рабочее состояние, ничего не сломано, можно собрать/запустить
* feature/my-cool-feature -- твоя ветка разработки, ты там делаешь все, что хочешь
CI всегда собирает master. Остальные ветки по возможности (железо слабое, проект тяжелый и т.п.)
Также всегда собираются и Pull Request'ы, но с оговоркой, что собирается не ветка, которую будут сливать, а merge commit -- по сути такое состояние репы, в котором твою ветку как бы слили в таргет-ветку (например, master). При таком подходе CI будет запускать сборку на новый коммит в PR-ветке, а также на новые коммиты в таргет-ветке (master).
Если нужен rollback, в случае если, например, релиз не поднялся, то в гите ничего я бы не стал менять, а просто на почту/месенджеры информацию послал бы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #57

44. Сообщение от Ordu (ok), 15-Янв-20, 02:31 –1 +/–

> я пытаюсь выработать общую стратегию поведения, которую мне нужно будет донести другим разработчикам, и такой вариант даже озвучивать нельзя.
Оглядываясь назад на свой опыт освоения git, я бы рекомендовал забить для начала на стратегию, и заняться тактикой, то есть начать с того, что начать использовать git в каком-нибудь side-проекте, который делается чисто по фану, причём посредством создания ветки work и коммитов туда всего подряд в естественном беспорядке этих изменений. По мере выполнения каких-то задач, надо брать ветку work и разгребать её (создавая временные ветки, раскидывая коммиты по ним, после чего сливая эти ветки в master), создавая красивую историю решения этих задач и скидывать эту историю в master, оставляя в work только изменения связанные с незаконченными задачами. Причём делать всё это ограничивая себя командами add, commit, checkout, reset, branch и rebase. Тут я могу посоветовать: https://github.com/salemove/gojo там есть задачки на разгребание бардака в репе и приведение его в няшный вид. (В инете есть и другие задачники, в том числе и интерактивные в браузере, просто я ссылок не вижу у себя в закладках, но если поискать в гугле можно найти, я уверен.) Надо довести свои навыки в "тактике" использования git до уровня, когда ты эти задачки будешь решать не задумываясь, и может быть разок на задачу консультируясь с man'ом, чтобы понять с какими опциями надо вызывать, например, git-reset, чтобы получить именно такой reset, который нужен.
Такой подход гарантирует, что ты довольно быстро поймёшь зачем нужны ветки с коммитами, как с ними надо обходиться, и более того доведёшь всё это до автоматизма. Со временем ты подстроишь этот процесс под себя -- будешь в процессе написания кода и commit'ов его в локальную ветку лучше делить изменения кода на коммиты; научишься использовать commit --amend, чтобы сразу склеить коммиты, которые потом всё равно склеивать придётся; использовать commit --patch, чтобы разбить какие-то изменения на разные коммиты сразу, а не задним числом при помощи rebase; сразу создавать ветки изменений, чтобы не задним числом при помощи rebase отделять одно от другого; писать комментарии к коммитам, которые помогают разгребать бардак -- но это всё будет выглядеть как оптимизации workflow, с тем чтобы потом было бы проще разгребать.
После этого надо отправляться в гугл с запросом "git workflow" искать описание того, как с git огранизовывают проекты. То есть, к этому моменту у тебя уже будет создан какой-то workflow, он самоорганизуется, пока ты будешь приспосабливаться к git, приспосабливая его к себе. Но возможны разные способы организации работы с git: git это инструмент для жонглирования коммитами, не более того, как лучше ими жонглировать, сколько веток иметь непрерывных, иметь ли вообще какие-либо непрерывные ветки кроме master (может всякие testing удобнее форкать по мере надобности, и потом просто удалять их?) -- это уже как тебе удобнее. И вот тут лучше чужой опыт пособирать, чем самостоятельно пробовать все разные способы. И собирать этот опыт лучше после освоения тактики, потому что в этом случае тебе будешь гораздо легче понимать, о чём говорит автор.
ps. Насчёт холиваров о rebase/merge, я бы не рекомендовал на этом этапе обращать на них внимание. Эти холивары можно почитать потом, когда ты поймёшь основные workflow, с тем чтобы понять, когда не надо использовать rebase. Зачем же rebase надо использовать, можно почитать/посмотреть здесь: https://mtyurt.net/post/git-using-advanced-rebase-features-f...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

45. Сообщение от Anonymqwe (?), 15-Янв-20, 05:07 +/–

Git LFS

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

46. Сообщение от Аноним (46), 15-Янв-20, 06:24 +1 +/–

Те из них кто поумнее - не жалеет граней на шары :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #51, #71

47. Сообщение от Аноним (46), 15-Янв-20, 06:25 –1 +/–

Кстати вебманки о себе напомнили в соседней новости. И таки очень предсказуемо напомнили: картина Репина "дохайповались".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

48. Сообщение от Аноним (-), 15-Янв-20, 06:41 –1 +/–

> который всем устраивает и под который уже отлажены все процессы?
Если б все так рассуждали, прогресс застопорился бы на набедренной повязке из листьев пальмы.
> Зато взамен вы получите... что?
Нормальный инструмент от профессионалов и современные, эффективные workflow, например.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #59

49. Сообщение от Аноним (-), 15-Янв-20, 06:42 +/–

> есть svn lock и т.д.
А, чо, это они у TFS'а "фиче" научились? Так офигенно, когда дев {слинял в отпуск, заболел, уволился, забухал} и оставил половину репы залоченой. Так что потом все околачивают груши и ждут пока одмины сшибут лок :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

50. Сообщение от Аноним (-), 15-Янв-20, 06:51 +/–

Удобство и легкость svn можно понаблюдать, сделав чекаут проекта месячной давности и сравнив как это "быстро" и "удобно" качает все и вся.
Про то чтобы ненапряжно закомитить пару мелочей с лаптопа, потому что пока млел под пальмой пришла в бошку хорошая мысля - речь и вовсе не идет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

51. Сообщение от Анонымоус (?), 15-Янв-20, 07:08 +1 +/–

Больше граней -- легче катать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #61

52. Сообщение от Анатоним (?), 15-Янв-20, 10:50 +/–

Интересно просто, с философской точки зрения, в git есть репозиторий git?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #54, #56

53. Сообщение от Ананимас009 (?), 15-Янв-20, 10:53 +/–

Вброшу https://svnvsgit.com/
Если со связью проблем не прдвидется и хотелось бы хранить бинарь с возможностью скачать именно содержимое директории n-го уровня в репозитории, то  svn гораздо удобнее?
Вообще удивили проценты использования в опенсурсе. Я думал там давно один гит и гитгм погоняет.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58

54. Сообщение от Аноним (32), 15-Янв-20, 11:20 +/–

git лежит в репозитории git, ага, рекурсия - она такая!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

55. Сообщение от Аноним (30), 15-Янв-20, 11:57 +/–

>> Сам был удивлён, когда узнал, что в гитлабе, оплоте гита, используются "мерж-реквесты". Но, насколько я понимаю, сам гитлаб является, в общем-то, централизованной системой, построенной на основе распределённого гита. Так что подобная терминология объяснима.
спасибо за ликбез.
>> И имхо запоминание можно заменить на документирование.
увы, в наших реалиях документирование не работает. документация слишком быстро устаревает. и тратить время на разборки - так себе выход. лучше стараться минимизировать влияние человеческого фактора.
>> Насколько я понял вашу проблему, если у вас в разработке 10 задач, то 10 разных программистов в случайные моменты времени могут коммитить в testing, этакое коллективное владение кодом. Имхо это бардак. У нас это исключено, за ветку отвечает ровно один человек.
у нас распределенная команда, поэтому одного человека назначить не получится - он может банально спать в то время, когда другие програмеры в другом конце планеты активно пашут и им нужно как можно быстрее выкатить изменения тестировщикам.
>> Насколько я понял вашу проблему, если у вас в разработке 10 задач, то 10 разных программистов в случайные моменты времени могут коммитить в testing, этакое коллективное владение кодом. Имхо это бардак. У нас это исключено, за ветку отвечает ровно один человек.
у нас несколько уровней тестовых окружений, и чем выше - тем меньше людей занимаются обновлениями. но тестовое окружение самого первого уровня должны иметь возможность обновлять все. а дальше уже проходят только избранные изменения, и тут круг лиц уже можно ограничить.
>> нет необходимости держать testing работоспособным 100% времени
поскольку у нас сейчас SVN, то это - основное требование для комита - приложение должно собираться  запускаться. да, какой-то функционал может быть сломан, тот который в разработке скорее всего и будет сломан, но любой должен иметь возможность обновиться и запустить приложуху у себя локально, либо в любой момент обновить тестовое окружение. Возможно, в случае с Git можно как-то по другому, но я пока слабо себе представляю как - для каждой ветки поднимать отдельный инстанс, на который направлять тестеров? Они не будут рады. И не только они. И потом все равно нужно тестировать testing ветку, из которой изменения пойдут дальше...
>> если кто-то поломал testing, всегда есть возможность посадить его вне очереди исправлять проблему.
к сожалению, у нас не получится, т.к. о том, что ветка кардинально сломана, можно узнать в тот момент, когда человек недоступен. У нас в этом случае принимается решение откатить изменения, и это может сделать кто угодно. А виновник торжества утром спокойно придет на работу, увидит уведомление и спокойно сядет разбираться - его не будут поторапливать и он никого не задержит. Но сломать ветку кардинально, это надо умудриться, т.к. перед комитом обычно все проверяется локально и сразу же обновляется тестовое окружение (пока вручную, но есть мысли автоматизировать этот процесс, если решимся перейти на git). Т.е. это крайне редкая ситуация. А в случае, когда мержить изменения будет не автор кода, тут уже возможны варианты...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #72

56. Сообщение от Andrey Mitrofanov_N0 (??), 15-Янв-20, 12:32 +/–

> Интересно просто, с философской точки зрения, в git есть репозиторий git?
Ч-чё прям, как маленький-то?!  Микрософт Гитхабб заботится о Вас.

Git via Git
If you already have Git installed, you can get the latest development version via Git itself:
  git clone https://github.com/git/git

-- https://git-scm.com/downloads

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

57. Сообщение от Аноним (30), 15-Янв-20, 12:35 +/–

>> Merge не делается до проверки работоспособности
каким образом это реализуется?
допустим, имеем такие ветки - master, testing, issue1, issue2
ветки issue* основаны на master, пусть даже одновременно (хотя на практике будет не так)
issue1 уже слита в testing и протестирована. есть MR на слияние issue2 в testing. Как мне получить состояние ветки testing после апрува MR для проверки работоспособности, не выполняя собственно MR? Я так понимаю, только вручную делать merge в локальной копии и потом push? но если issue2 по каким-то причинам сливается частично, то это получается достаточно трудозатраная операция с увеличенным шансом на ошибку... и всякие CI/CD сюда уже не прикрутить. или я ошибаюсь?
>> При таком подходе CI будет запускать сборку на новый коммит в PR-ветке, а также на новые коммиты в таргет-ветке (master).
я еще до настройки CI не дошел. и если есть возможность собирать MR перед их аппрувом - это решает много проблем. надо будет почитать на эту тему.
но с другой стороны - вероятность ошибки все равно полностью не исключается, и может произойти ситуация, что изменения таки нужно временно откатить из testing (не обязательно даже по причине ломающих изменений) - в такой ситуации можно каким-то образом выпилить конкретные MR (или на крайний случай - комиты) из ветки, чтобы потом можно было бы без проблем их накатить заново? Rebase, насколько я понимаю, откатит все изменения с какого-то момента, в том числе и те MR, которые нужно оставить. Не накатывать же их заново
>> master/develop/release
я пока остановился на master/testing/issue*
master - в любой момент может быть отправлен на prod
testing - ветка на dev сервере, где тестируются и апрувятся изменения
issue* - соответственно ветки для исправлений/новых фич
и у меня имеется некоторое недопонимание, на основании какой ветки нужно создавать ветки для issue - master или testing? пока в этом проекте я работаю один, а заказчик апрувит изменения пачками, мне удобнее каждый новый issue делать на основе testing, чтобы потом меньше мержить. но у меня стойкое ощущение, что это не совсем корректно в случае командной работы, т.к. например я могу сделать ветку с включением тех изменений, которые позже могут быть откачены, и это со временем обязательно приведет к проблемам. в master же всякого рода откаты - это уже исключительная ситуация, насколько я понимаю.
ну а release же должен быть tag-ом на master, или тут тоже есть какие-то подводные камни и лучше держать для этого отдельную ветку?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #67

58. Сообщение от Andrey Mitrofanov_N0 (??), 15-Янв-20, 12:45 +1 +/–

> Вброшу
> Вообще удивили проценты использования в опенсурсе. Я думал там давно один гит
> и гитгм погоняет.
Никому верить нельзя, мне - можно.(ц)старина Мюллер
" and LLVM continue to use Subversion as the main version control system. "
  <=>
http://www.phoronix.com/scan.php?page=news_item&px=LLVM-SVN-...
  & https://lists.llvm.org/pipermail/llvm-dev/2019-October/13610...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

59. Сообщение от Аноним (30), 15-Янв-20, 12:48 +/–

>> Если б все так рассуждали, прогресс застопорился бы на набедренной повязке из листьев пальмы.
подобного рода диалоги - неконструктивны. у прогресса должна быть конкретная цель, а не движение ради движения.
>> Нормальный инструмент от профессионалов и современные, эффективные workflow, например.
на это бла-бла-бла ни один адекватный бизнес денег не выделит.
разве SVN не инструмент от профессионалов? Многие компании выросли с использованием этого инструмента и не планируют от него отказываться. И с аргументацией такого уровня - не откажутся никогда.
И по поводу эффективных workflow. Звучит конечно красиво, но если уже существует workflow, отработанный годами и не дающий сбоев - нужно предложить что-то, что решит какие-то конкретные проблемы, а не создаст новые. Я пока не вижу, какие проблемы workflow нашей компании GIT может решить (а за годы пользования SVN мы уже научились обходить множество разнообразных проблем и на данный момент каких-то неразрешимых проблем не имеем). Т.е. пока мне нечего предложить бизнесу как аргумент для перехода, кроме "стильно модно молодежно" и "весь опенсорс и даже ядро Linux его используют". Но тем не менее - я для себя решил поближе познакомиться с данным инструментом, т.е. назвать меня упорным ретроградом не получится. И диалог с людьми, которые имеют реальный опыт работы с git - это тот конструктив, за которым я сюда пришел. А демагоги, разбрасывающие красивые но при этом пустые фразы мне неинтересны.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #68, #70

60. Сообщение от Ан оНим (?), 15-Янв-20, 22:52 +/–

Код SVN красивше чем

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

61. Сообщение от Ан оНим (?), 15-Янв-20, 22:52 +/–

Шары не катают

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

62. Сообщение от Ан оНим (?), 15-Янв-20, 22:55 +/–

Неважно, шелл не шелл.
Важно насколько осилил изложить нужное. Хороший был бы алгоритм. Язык вторичен.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #69

63. Сообщение от Аноним (63), 16-Янв-20, 02:14 –1 +/–

какой нафиг SHA-2?
SHA-3 давно стандарт

Ответить | Правка | Наверх | Cообщить модератору

64. Сообщение от trolleybus (?), 16-Янв-20, 09:30 +1 +/–

> 2.25
"Однако... Два двадцать пять!" (c) 12 стульев

Ответить | Правка | Наверх | Cообщить модератору

65. Сообщение от Аноним (65), 17-Янв-20, 12:46 +/–

> И еще вопрос. Я вот для себя начал смотреть в сторону git. И столкнулся с такой проблемой:
> есть 2 ветки - для issue и вторая - testing. закомитил (C1) в issue, сделал merge request (MR1) в testing,
>обновил тестовое окружение. и вижу, что обновление создает проблемы. делаю revert этого MR1,
> чиню проблемы в ветке issue, создаю MR2 для слияния ветки issue в testing и понимаю,
> что C1 в этот самый MR2 не попадает.
> Потому что он уже есть в ветке testing. Хотя изменения этого комита я ревертнул...
Подобные затруднения возникают когда не понимают/не знают принципы работы инструмента (git, svn, hg да и любого другого).
Вы пытаетесь сделать то, от чего scm как раз и защищает - "десять раз наложился один и тот же коммит".
1. "понимаю, что C1 в этот самый MR2 не попадает" - попадает. Точнее "там, куда вы его хотите засунуть, он уже есть".
2. "Хотя изменения этого комита я ревертнул" - это не значит что коммит исчез.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

66. Сообщение от Аноним (67), 18-Янв-20, 02:12 +/–

> Тут нельзя просто выкачать файлы из папки /A/B/C
И это хорошо сдерживает от превращения репозитория в файлопомойку.
> если человек хочет работать только с содержимым в папке C
Если изменения в директории C не влияют на другие директории, то есть смысл оформить C как отдельный репозиторий.
А вообще, не нужно пытатся "прогнуться" под git.
Выбирайте те средства (svn например), которые решают ваши проблемы, а не добавляют новые.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

67. Сообщение от Аноним (67), 18-Янв-20, 02:45 +/–

> Как мне получить состояние ветки 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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

68. Сообщение от Аноним (67), 18-Янв-20, 03:57 +/–

Зачем вашей компании гит если svn вас устраивает?
И Вам зачем? Чтоб не казаться ретроградом?
> И диалог с людьми, которые имеют реальный опыт работы с git - это тот конструктив, за которым я сюда пришел.
Однако приглашение к диалогу выглядит как "Ну поуговаривайте меня, поубеждайте перейти на GIT. А я буду говорить фууу, ваш GIT не решает наших проблем".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

69. Сообщение от Аноним (-), 18-Янв-20, 18:51 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

70. Сообщение от Аноним (-), 18-Янв-20, 19:07 +/–

> подобного рода диалоги - неконструктивны. у прогресса должна быть конкретная цель,
Несомненно. А чем цель в виде современного эффективного воркфлоу плоха? Посмотрите как это у хотя-бы ядерщиков линукс происходит. И сравните с тем что у вас. И ощутите разницу.
> а не движение ради движения.
Немного этого все же нужно для избежания стагнации. Потому что иначе - зачем нам ткань и столько заморочек с прядением и ткачеством, когда можно листья с ближайшей пальмы взять?
> на это бла-бла-бла ни один адекватный бизнес денег не выделит.
А я разве пытаюсь денег выбить? И разработчики гита тоже вроде не пытаются. Гит вообще по другому поводу появился: Торвальдса попробовали нагнуть разработчики BitBaker, решившие что они уже достаточно крутые чтобы руки другим выворачивать. Тот оказался не робкого десятка и сам их нагнул от души, накодив замену. И кто теперь вообще про этот bitbaker помнит?
> уже существует workflow, отработанный годами и не дающий сбоев
Я тоже не понимаю, чего люди заморочились с прядением и ткачеством когда можно просто листьев надрать. Может, секрет в том что постепенно, по мере отладки, новые воркфлоу оказываются чем-то лучше старых? Я кстати не утверждаю что отказаться от листьев пальмы должны вообще все. До сих пор можно найти племена которым и так нормально. Что уж говорить про git? Они вообще такими абстракциями не оперируют.
> А демагоги, разбрасывающие красивые но при этом пустые фразы мне неинтересны.
А что до конструктива - возьмите да попробуйте с гитом поучаствовать в каком-нибудь проекте. Это и все грабли подсветит, и ощущение инструмента даст.
Для лично меня основные преимущества гита:
1) Используется толпой народа. Как угодно но это упрощает взаимодействие с окружающими. Не знаю надо ли это вашему бизнесу, но мне это явно не лишнее.
2) Он не требует сервер. Это позволяет мне пользоваться им без лишних напрягов на куче компов. В том числе иногда перекидываясь кодом между ними.
3) При всем этом - можно ПОЛНОЦЕННО работать с версиями и всем таким. Так что я даже валяясь под пальмой могу взять да и покодить, если удачная мысля пришла именно здесь, именно сейчас.
4) При всем этом он еще и довольно резвый. Иерархию размером с линуксный кернел он разворачивает просто влет. Это позволяет шариться по версиям со скоростью ракеты.
5) Кстати как в SVN сделать что-то типа git bisect? И сколько времени перекачка всего проекта цать раз займет? Впрочем, если вашему бизнесу положить на эффективность програмеров, можно и с SVNом конечно. Но я плохо представляю себе на нем такой воркфлоу.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

71. Сообщение от Попугай Кеша (?), 20-Янв-20, 16:30 +/–

> Те из них кто поумнее - не жалеет граней на шары :)
А потом - почему это игра тормозит на 16 Гб оперативы? )

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

72. Сообщение от Попугай Кеша (?), 20-Янв-20, 16:37 +/–

>>> И имхо запоминание можно заменить на документирование.
> увы, в наших реалиях документирование не работает. документация слишком быстро устаревает.
> и тратить время на разборки - так себе выход. лучше стараться
> минимизировать влияние человеческого фактора.
Да бежать надо из компании, где все так быстро меняется. Обычно это менеджеры как ошалевшие девки носятся в истерике и меняют требования. В итоге (мне "нравится" прям) часто ходят фразы "код должен быть самодокументированным", хотя документацией в коде даже и не пахло.
В нормальных компаниях документация редко меняется. Только так можно выстроить нормально работающую систему. Планомерно, четко, без потогонной работы, без истерик.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Аноним (1), 14-Янв-20, 13:53	+5 +/–
SVN в 100 раз
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #8, #16

2. Сообщение от Аноним (2), 14-Янв-20, 13:55	–2 +/–
l залипает?)
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #6

3. Сообщение от iCat (ok), 14-Янв-20, 13:56	–1 +/–
1 коммит с каждого разработчика при учёте, что работали 7 дней... Не густо... :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #5

4. Сообщение от X5asd (?), 14-Янв-20, 13:56	–2 +/–
а переход на следущую sha что? надоело чтоль?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #14

5. Сообщение от анонимус_потерял_свой_логин (?), 14-Янв-20, 14:07	+/–
иди, да помоги им своими коммитами
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #10

6. Сообщение от Аноним (6), 14-Янв-20, 14:10	+5 +/–
В том то и дело, что именно "sparseCheckoutCone", а не "sparseCheckoutClone"
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

7. Сообщение от Ivan_83 (ok), 14-Янв-20, 14:35	+3 +/–
"В команду "git submodule" добавлена подкоманда "set-url"" - наконец то!
Ответить \| Правка \| Наверх \| Cообщить модератору

8. Сообщение от Анонец (?), 14-Янв-20, 14:56	+3 +/–
чем гит
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #13

9. Сообщение от Аноним (9), 14-Янв-20, 14:57	–2 +/–
> Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями Не "одной из", а самой. По сути, на данный момент единственной.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #11

10. Сообщение от НяшМяш (ok), 14-Янв-20, 15:16	+1 +/–
Сложна, там на сях надо писать
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #21, #25, #32

11. Сообщение от aa (?), 14-Янв-20, 15:18	+1 +/–
самой популярной - да по надежности и производительности возможно есть и лучше (пусть ими и пользуется 1 человек) и любителей subversion и mercurial пока еще достаточно, чтобы не говорить,что гит - единственная
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #12, #26

12. Сообщение от microsoft (?), 14-Янв-20, 15:33	+/–
> и любителей subversion и mercurial пока еще достаточно но для них нет нашей прекрасной gitfs! Поэтому по производительности они безнадежно в пролете.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #20

13. Сообщение от Снайпе (?), 14-Янв-20, 16:10	+2 +/–
Что?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #15, #23

14. Сообщение от Alex (??), 14-Янв-20, 16:20	–3 +/–
коллизии (почти) научились подбирать
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4

15. Сообщение от Аноним (15), 14-Янв-20, 16:33	+4 +/–
SVN в 100 раз
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13 Ответы: #19

16. Сообщение от eRIC (ok), 14-Янв-20, 16:34	+/–
SVN является как раз таки централизованной системой отслеживания кода, когда как GIT децентрализованная
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #17, #18

17. Сообщение от конь в пальто (?), 14-Янв-20, 16:45	+1 +/–
и чо?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #39

18. Сообщение от A.Stahl (ok), 14-Янв-20, 16:47	+12 +/–
А у шара нет граней, тогда как у куба их целых 6.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #22, #24, #29

19. Сообщение от Аноним (19), 14-Янв-20, 17:03	+4 +/–
Зато Git в 100 раз
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #28

20. Сообщение от Аноним (19), 14-Янв-20, 17:04	–1 +/–
Ты еще скажи VFS for Git.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

21. Сообщение от анонимус_потерял_свой_логин (?), 14-Янв-20, 17:09	+2 +/–
ну да, на опеннете-то писульки писать проще намного
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10

22. Сообщение от Попугай Кеша (?), 14-Янв-20, 17:19	+3 +/–
Можно сказать, что у шара - бесконечное число граней )
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18

23. Сообщение от Аноним (-), 14-Янв-20, 17:19	+4 +/–
> Что? Медленнее.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13

24. Сообщение от Аноним (-), 14-Янв-20, 17:21	+5 +/–
> А у шара нет граней Игроделы с этим тезисом мягко говоря не согласятся. Более того - у хорошего шара граней много.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18 Ответы: #27

25. Сообщение от Аноним (-), 14-Янв-20, 17:22	+1 +/–
> Сложна, там на сях надо писать Ну так поэтому оно и крутое - работает шустро, ведет себя логично. И вообще, на что способны вебмакаки можно посмотреть в каком-нибудь hg. Фич навалили гору, зато все работает как картонный макет какой-то.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #40

26. Сообщение от Аноним (-), 14-Янв-20, 17:25	–3 +/–
> и любителей subversion и mercurial пока еще достаточно Пока еще. Ха, именно так. Постепенно даже до этих доползает что хорошие инструменты разработки от профессиональных програмеров а не макак с самомнением - использовать эффективнее, да и просто приятно, наконец.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #30

27. Сообщение от A.Stahl (ok), 14-Янв-20, 17:27	+/–
Игроделы намного умнее чем ты о них думаешь.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #24 Ответы: #46

28. Сообщение от little Bobby tables (?), 14-Янв-20, 17:32	+3 +/–
тоже верно чем свн.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #19

29. Сообщение от little Bobby tables (?), 14-Янв-20, 17:33	+2 +/–
а ещё был случай идем в столовку талоны профилакта проедать а навстречу бабы с иняза
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18

30. Сообщение от Аноним (30), 14-Янв-20, 17:40	+1 +/–
хм. какой смысл менять инструмент, который всем устраивает и под который уже отлажены все процессы? сможешь объяснить преимущества перехода с того же SVN на GIT для распределенной команды разработчиков (с разными скиллами)? Ну так, чтобы сказать бизнесу - мы хотим перейти на Git, ближайшие пол года минимум у нас будут периодически возникать простои в работе (как часто - мы не знаем), да и сам переход не бесплатен. Зато взамен вы получите... что? И еще вопрос. Я вот для себя начал смотреть в сторону git. И столкнулся с такой проблемой: есть 2 ветки - для issue и вторая - testing. закомитил (C1) в issue, сделал merge request (MR1) в testing, обновил тестовое окружение. и вижу, что обновление создает проблемы. делаю revert этого MR1, чиню проблемы в ветке issue, создаю MR2 для слияния ветки issue в testing и понимаю, что C1 в этот самый MR2 не попадает. Потому что он уже есть в ветке testing. Хотя изменения этого комита я ревертнул... И теперь вопрос - как с такой ситуацией бороться, или как в нее не попадать? Я то выкрутился (сделал revert для первого revert), но меня не покидает ощущение, что это неправильное решение. и это я пока один в этом репозитории, если же там будет несколько человек топтаться, да еще и всякие CI/CD научить откатывать изменения, ломающие ветки, то этот бардак потом вряд-ли кто-то сможет разгрести для релиза.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #26 Ответы: #31, #34, #43, #48, #65