https://89.19.215.112/openforum/vsluhforumID3/119478.html Доступен выпуск распределенной системы управления исходными текстами Git 2.25.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52180<br> https://89.19.215.112/openforum/vsluhforumID3/119478.html#72 Mon, 20 Jan 2020 13:37:27 GMT &gt;&gt;&gt; И имхо запоминание можно заменить на документирование.<br>&gt; увы, в наших реалиях документирование не работает. документация слишком быстро устаревает. <br>&gt; и тратить время на разборки - так себе выход. лучше стараться <br>&gt; минимизировать влияние человеческого фактора.<br><br>Да бежать надо из компании, где все так быстро меняется. Обычно это менеджеры как ошалевшие девки носятся в истерике и меняют требования. В итоге (мне "нравится" прям) часто ходят фразы "код должен быть самодокументированным", хотя документацией в коде даже и не пахло.<br><br>В нормальных компаниях документация редко меняется. Только так можно выстроить нормально работающую систему. Планомерно, четко, без потогонной работы, без истерик.<br> https://89.19.215.112/openforum/vsluhforumID3/119478.html#71 Mon, 20 Jan 2020 13:30:40 GMT &gt; Те из них кто поумнее - не жалеет граней на шары :) <br><br>А потом - почему это игра тормозит на 16 Гб оперативы? )<br> https://89.19.215.112/openforum/vsluhforumID3/119478.html#70 Sat, 18 Jan 2020 16:07:57 GMT &gt; подобного рода диалоги - неконструктивны. у прогресса должна быть конкретная цель,<br><br>Несомненно. А чем цель в виде современного эффективного воркфлоу плоха? Посмотрите как это у хотя-бы ядерщиков линукс происходит. И сравните с тем что у вас. И ощутите разницу.<br><br>&gt; а не движение ради движения.<br><br>Немного этого все же нужно для избежания стагнации. Потому что иначе - зачем нам ткань и столько заморочек с прядением и ткачеством, когда можно листья с ближайшей пальмы взять?<br><br>&gt; на это бла-бла-бла ни один адекватный бизнес денег не выделит.<br><br>А я разве пытаюсь денег выбить? И разработчики гита тоже вроде не пытаются. Гит вообще по другому поводу появился: Торвальдса попробовали нагнуть разработчики BitBaker, решившие что они уже достаточно крутые чтобы руки другим выворачивать. Тот оказался не робкого десятка и сам их нагнул от души, накодив замену. И кто теперь вообще про этот bitbaker помнит?<br><br>&gt; уже существует workflow, отработанный годами и не дающий сбоев<br><br>Я тоже не понимаю, чего люди заморочились с пря https://89.19.215.112/openforum/vsluhforumID3/119478.html#69 Sat, 18 Jan 2020 15:51:19 GMT Конечно, плохим алгоритмом можно и хороший ЯП ушатать, но все же теория ничто без практики. А алгоритм ничто без качественной реализации. И вот тут уже ЯП полностью сбросить со счетов сложно. Ну вот есть у вас офигенный алгоритм допустим шифрования - но на бэйсике, блин. И чего? Сами перепишете на что там вам хотелось? В процессе влепите десяток новых вулнов, сами того не желая. Потому что специфичная область, без владения которой стандартными подходами - только дров наломать можно.<br> https://89.19.215.112/openforum/vsluhforumID3/119478.html#68 Sat, 18 Jan 2020 00:57:15 GMT Зачем вашей компании гит если svn вас устраивает?<br>И Вам зачем? Чтоб не казаться ретроградом?<br><br>&gt; И диалог с людьми, которые имеют реальный опыт работы с git - это тот конструктив, за которым я сюда пришел.<br><br>Однако приглашение к диалогу выглядит как "Ну поуговаривайте меня, поубеждайте перейти на GIT. А я буду говорить фууу, ваш GIT не решает наших проблем".<br> https://89.19.215.112/openforum/vsluhforumID3/119478.html#67 Fri, 17 Jan 2020 23:45:43 GMT &gt; Как мне получить состояние ветки testing после апрува MR для проверки работоспособности, не выполняя собственно MR?<br><br>git checkout testing # или git switch по современному<br>git merge --no-ff --no-commit issue2<br>&lt;проверка работоспособности&gt; && git commit -m "I am the best." &#124;&#124; echo "MR is BAD" &#124; mail vasya<br> https://89.19.215.112/openforum/vsluhforumID3/119478.html#66 Fri, 17 Jan 2020 23:12:02 GMT &gt; Тут нельзя просто выкачать файлы из папки /A/B/C<br><br>И это хорошо сдерживает от превращения репозитория в файлопомойку.<br><br>&gt; если человек хочет работать только с содержимым в папке C<br><br>Если изменения в директории C не влияют на другие директории, то есть смысл оформить C как отдельный репозиторий.<br><br>А вообще, не нужно пытатся "прогнуться" под git.<br>Выбирайте те средства (svn например), которые решают ваши проблемы, а не добавляют новые.<br> https://89.19.215.112/openforum/vsluhforumID3/119478.html#65 Fri, 17 Jan 2020 09:46:43 GMT &gt; И еще вопрос. Я вот для себя начал смотреть в сторону git. И столкнулся с такой проблемой:<br>&gt; есть 2 ветки - для issue и вторая - testing. закомитил (C1) в issue, сделал merge request (MR1) в testing,<br>&gt;обновил тестовое окружение. и вижу, что обновление создает проблемы. делаю revert этого MR1,<br>&gt; чиню проблемы в ветке issue, создаю MR2 для слияния ветки issue в testing и понимаю,<br>&gt; что C1 в этот самый MR2 не попадает.<br>&gt; Потому что он уже есть в ветке testing. Хотя изменения этого комита я ревертнул...<br><br>Подобные затруднения возникают когда не понимают/не знают принципы работы инструмента (git, svn, hg да и любого другого).<br>Вы пытаетесь сделать то, от чего scm как раз и защищает - "десять раз наложился один и тот же коммит".<br><br>1. "понимаю, что C1 в этот самый MR2 не попадает" - попадает. Точнее "там, куда вы его хотите засунуть, он уже есть".<br>2. "Хотя изменения этого комита я ревертнул" - это не значит что коммит исчез.<br> https://89.19.215.112/openforum/vsluhforumID3/119478.html#64 Thu, 16 Jan 2020 06:30:33 GMT &gt; 2.25<br><br>"Однако... Два двадцать пять!" (c) 12 стульев<br>