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

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

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

"Выпуск распределенной системы управления исходными текстами ..."	+/–
Сообщение от opennews (??), 14-Янв-20, 13:53
Доступен выпуск распределенной системы управления исходными текстами Git 2.25.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов... Подробнее: https://www.opennet.dev/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. "Выпуск распределенной системы управления исходными текстами ..." +5 +/–

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

SVN в 100 раз

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

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

Сообщение от Анонец (?), 14-Янв-20, 14:56

чем гит

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

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

Сообщение от Снайпе (?), 14-Янв-20, 16:10

Что?

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

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

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

SVN в 100 раз

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

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

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

Зато Git в 100 раз

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

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

Сообщение от little Bobby tables (?), 14-Янв-20, 17:32

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

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

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

Сообщение от Аноним (-), 14-Янв-20, 17:19

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

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

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

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

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

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

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

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

и чо?

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

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

Сообщение от eRIC (ok), 14-Янв-20, 22:03

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (-), 14-Янв-20, 17:21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от little Bobby tables (?), 14-Янв-20, 17:33

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

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

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

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

l залипает?)

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

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

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

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

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

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

Сообщение от iCat (ok), 14-Янв-20, 13:56

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (-), 14-Янв-20, 17:22

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

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

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

Сообщение от анонн (ok), 14-Янв-20, 22:21

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

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

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

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

Сообщение от Аноним (46), 15-Янв-20, 06:25

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от X5asd (?), 14-Янв-20, 13:56

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

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

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

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

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

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

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

Сообщение от Ivan_83 (ok), 14-Янв-20, 14:35

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

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

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

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

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

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

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

Сообщение от aa (?), 14-Янв-20, 15:18

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Аноним (-), 14-Янв-20, 17:25

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

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

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

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

хм. какой смысл менять инструмент, который всем устраивает и под который уже отлажены все процессы? сможешь объяснить преимущества перехода с того же 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ообщить модератору

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

Сообщение от Ordu (ok), 14-Янв-20, 18:01

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Ordu (ok), 15-Янв-20, 02:31

> я пытаюсь выработать общую стратегию поведения, которую мне нужно будет донести другим разработчикам, и такой вариант даже озвучивать нельзя.
Оглядываясь назад на свой опыт освоения 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...

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

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

Сообщение от Аноним (35), 14-Янв-20, 18:54

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

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

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

Сообщение от Аноним (30), 14-Янв-20, 19:03

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

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

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ообщить модератору

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

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

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

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

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

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

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

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

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

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

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

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

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, в случае если, например, релиз не поднялся, то в гите ничего я бы не стал менять, а просто на почту/месенджеры информацию послал бы.

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

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ообщить модератору

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ообщить модератору

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

Сообщение от Аноним (-), 15-Янв-20, 06:41

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответить | Правка | К родителю #59 | Наверх | 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. "Хотя изменения этого комита я ревертнул" - это не значит что коммит исчез.

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

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

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

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

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

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

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

Git LFS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщение от Andrey Mitrofanov_N0 (??), 15-Янв-20, 12:45

> Вброшу
> Вообще удивили проценты использования в опенсурсе. Я думал там давно один гит
> и гитгм погоняет.
Никому верить нельзя, мне - можно.(ц)старина Мюллер
" 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ообщить модератору

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

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

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

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

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

Сообщение от trolleybus (?), 16-Янв-20, 09:30

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

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

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

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

Партнёры:

Хостинг:

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

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

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


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


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


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


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


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


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


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


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


	39. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от eRIC (ok), 14-Янв-20, 22:03
	> и чо? ничего, идите в гугл кто сравнивает SVN vs GIT
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ан оНим (?), 15-Янв-20, 22:52
	Код SVN красивше чем
	Ответить \| Правка \| Наверх \| Cообщить модератору


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


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


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


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


	46. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Аноним (46), 15-Янв-20, 06:24
	Те из них кто поумнее - не жалеет граней на шары :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Анонымоус (?), 15-Янв-20, 07:08
	Больше граней -- легче катать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ан оНим (?), 15-Янв-20, 22:52
	Шары не катают
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Попугай Кеша (?), 20-Янв-20, 16:30
	> Те из них кто поумнее - не жалеет граней на шары :) А потом - почему это игра тормозит на 16 Гб оперативы? )
	Ответить \| Правка \| К родителю #46 \| Наверх \| Cообщить модератору


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

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


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

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


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


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


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


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


	40. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от анонн (ok), 14-Янв-20, 22:21
	>> Сложна, там на сях надо писать > Ну так поэтому оно и крутое - работает шустро, ведет себя логично. А то, что оно еще пару лет назад было наполовину на шелле: 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.dev/opennews/art.shtml?num=43057 > Выпуск распределенной системы управления исходными текстами Git 2.6.0 > 29.09.2015 > Реализации "git pull" и "git am" переписаны на языке Си ... https://www.opennet.dev/opennews/art.shtml?num=49751 > Выпуск распределенной системы управления исходными текстами Git 2.20 > 10.12.2018 09:46 > Реализации команд "git submodule update", "git rebase" и "git rebase -i" полностью переписаны на языке Си https://www.opennet.dev/opennews/art.shtml?num=50202 > Выпуск распределенной системы управления исходными текстами Git 2.21 > 25.02.2019 10:07 > Некоторые части "git bisect", ранее реализованные на Shell, переписаны на языке Си; так то было давно и уже почти неправда =)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Аноним (46), 15-Янв-20, 06:25
	Кстати вебманки о себе напомнили в соседней новости. И таки очень предсказуемо напомнили: картина Репина "дохайповались".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ан оНим (?), 15-Янв-20, 22:55
	Неважно, шелл не шелл. Важно насколько осилил изложить нужное. Хороший был бы алгоритм. Язык вторичен.
	Ответить \| Правка \| К родителю #40 \| Наверх \| Cообщить модератору