The OpenNET Project / Index page

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



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

"Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от opennews (??), 14-Янв-20, 13:53 
Доступен выпуск распределенной системы управления исходными текстами Git 2.25.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52180

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

Оглавление

Сообщения [Сортировка по времени | 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.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ообщить модератору

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 +/
Сообщение от trolleybusemail (?), 16-Янв-20, 09:30 
> 2.25

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

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

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

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




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

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