Страниц: 1 [2]
  Печать  
Автор Тема: Система контроля версий Git  (Прочитано 1389 раз)
lastcross
Full Member
***
Offline Offline

Сообщений: 224


Просмотр профиля
« Ответ #15 : Июня 27, 2017, 11:46:27 pm »

Верно. Но просто файловая помойка неудобна. Если я потом сделаю clone, он мне отправит весь мой каталог разработки, а это примерно 4 ГБайта.
Откуда у вас 4GB исходников на проекте?
Как правило все файлы проекта делят на части.
Папка с исходниками библиотеки которые используются в проекте (и возможно не только в текущем).
Папка с собранными библиотеками
Папка с исходниками собственно проекта (только исходники, фалы-проекта, ресурсы и все что необходимо для нормальной компиляции проекта) - никаких объектников или временно-созданых фалов (отладочной инфы), никаких построенных экзешников там быть не должно
Папка с внешними ресурсами используемые проектом (при условии, что они могут изменятся независимо от исходников проекта) - конфиги разного характера, текстуры и т.д.
И т.д.

Так вот  - каждая из этих папок может быть как отдельным репозиторием, так и одним. Папки могут находится или рядом или в разных местах. Но я не вижу откуда у вас на двоих для одного проекта возьмутся 4 гига исходников.

Цитировать
И я такому клонированию не обрадуюсь. Smiley
По мере увеличения комитов - репозиторий будет увеличиваться. Так что клонирование со временем Вас все равно не будет радовать)

Цитировать
Поэтому первый же вопрос появляется, как разграничить проекты. Но автор книжки про этот вопрос забыл.
Git не про язык, Git - инструмент. У каждого могут быть свое видение на организацию папок в своих проектах, у каждого языка могут быть свои ограничения. Поэтому автор не акцентировал никакого внимания (имхо)

Цитировать
Кстати,я так и не понял, могу ли я на локальной машине (т.е. не используя URL) клонировать репозиторий или нет? Типа git clone myproject.git.  Вроде бы нет - нужно поднимать сервер. И я также не понял, откуда берётся этот файл с расширением .git в репозитории (например, в сетевом). Изначально-то его нет в каталогах git, даже с созданным и инициализированным проектом. Но, возможно, я просто ещё не дочитал до нужного места.
Так и есть, не дочитали.
Для гита не нужен отдельный сервер. Он является распределенной системой - то есть содержит как клиент так и сервер сразу. И ничего не мешает вам зайди в другую папку, и написать там git clone указав следующий параметр файловый/сетевой путь к папке которая является репозиторием (т.е. под гитом)

Цитировать

Да. Но вот чтобы понять, как наши с Васей правки будут конфликтовать, придётся с консолью разбираться основательно. Надо попробовать поставить графическую оболочку. С git у меня ещё проблема одна - ему в текущей версии минимум Vista нужна. А у меня XP и обновлять я не планирую. Portable-версия запускается, но частенько не находит нужного в штатных dll Windows XP (что-то там с функцией синхронизации чего-то выскакивает). Но вроде как всё равно работает.

Зато у вас WindowsXP. =)
Записан
da-nie
Full Member
***
Offline Offline

Сообщений: 167



Просмотр профиля
« Ответ #16 : Июня 28, 2017, 08:48:39 am »

Цитировать
Откуда у вас 4GB исходников на проекте?

Не в проекте, а в рабочей папке. Там этих проектов сотни самых разных. И это не только исходники – там же и необходимые файлы для работы программ и сами исполняемые файлы. И я пока не планирую разделять исходники, исполняемый файл и данные для его работы – это мне неудобно.

Цитировать
У каждого могут быть свое видение на организацию папок в своих проектах, у каждого языка могут быть свои ограничения.

Я тоже не про язык. Я про инкапсуляцию данных.
Кстати, интересно, как git справится со слиянием изменений при одновременной правке файла, например, типа doc. Думаю, что никак.

Цитировать
Так и есть, не дочитали.

Ну, я меня он ругается, что не может прочесть проект:

Цитировать
D:\GIT\1>git clone d:\GIT\Project\TestOrtohonalization.git

Cloning into 'TestOrtohonalization'...
fatal: Could not read from remote repository.

Предлагает проверить права доступа. Но в книжке про права доступа упоминается только в разделе про Gitolite, а это как бы совсем не то. И сомнительно, что Git даёт мне обновлять проект в папке проекта, но не даёт его клонировать в папке уровня выше. Поэтому я так полагаю, что причина в том, что он не находит проект.
Записан

И день и ночь в пути
lastcross
Full Member
***
Offline Offline

Сообщений: 224


Просмотр профиля
« Ответ #17 : Июня 28, 2017, 11:39:58 am »

Не в проекте, а в рабочей папке. Там этих проектов сотни самых разных. И это не только исходники – там же и необходимые файлы для работы программ и сами исполняемые файлы. И я пока не планирую разделять исходники, исполняемый файл и данные для его работы – это мне неудобно.

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


Цитировать
Я тоже не про язык. Я про инкапсуляцию данных.
Именно разделение всех частей участвующих в построение проекта - и есть инкапсуляция (изменения в одном репозитории сокрыты от изменений в другом)

Цитировать
Кстати, интересно, как git справится со слиянием изменений при одновременной правке файла, например, типа doc. Думаю, что никак.
Он справляется - всегда можно принять правки свои или чужие. Мержить бинарные файлы, с автоматическим резолвом конфликтов - не стоит.
Вообще, для документации советую вам смотреть в сторону wiki-like сервисов.

Цитировать
Ну, я меня он ругается, что не может прочесть проект:
Пробуйте так

Цитировать
D:\GIT\1>git clone d:\GIT\Project\TestOrtohonalization

или так

Цитировать
D:\GIT\1>git clone d:\GIT\Project\TestOrtohonalization\.git

Если TestOrtohonalization - это папка под гитом
Записан
da-nie
Full Member
***
Offline Offline

Сообщений: 167



Просмотр профиля
« Ответ #18 : Июня 28, 2017, 07:47:17 pm »

Цитировать
Не совсем удачное решение. Я бы даже сказал - совсем неудачное!

У каждого проекта своя специфика. И чтобы не запутаться, мне нужно рядом с проектом хранить всё то, что он использует. Это даже для отладки нужно. А вот пользователь получит обновление по сети с сервера, как только я решу, что проект работает верно и отправлю программу туда.

Цитировать
Мержить бинарные файлы, с автоматическим резолвом конфликтов - не стоит.

Вот я про то, что doc близок по структуре к бинарнику. Тут просто изменение строки не отследить. Если только у git нет специального модуля для таких файлов.

Цитировать
Вообще, для документации советую вам смотреть в сторону wiki-like сервисов.

Спасибо за совет, но я её совместно почти не пишу. Так что... Пока не требуется. Smiley

Цитировать
Если TestOrtohonalization - это папка под гитом

Да, это папка с тестовым проектом в каталоге d:\GIT\Project. Но никак не клонирует. адо на семёрке попробовать - может, дело в той самой ошибке на XP.
Записан

И день и ночь в пути
lastcross
Full Member
***
Offline Offline

Сообщений: 224


Просмотр профиля
« Ответ #19 : Июня 29, 2017, 01:34:35 pm »

У каждого проекта своя специфика. И чтобы не запутаться, мне нужно рядом с проектом хранить всё то, что он использует. Это даже для отладки нужно. А вот пользователь получит обновление по сети с сервера, как только я решу, что проект работает верно и отправлю программу туда.

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


Цитировать
Вот я про то, что doc близок по структуре к бинарнику. Тут просто изменение строки не отследить. Если только у git нет специального модуля для таких файлов.
Изначально - дифф и мерж с резолыом у гита основывается на текстовых фалах. Хотите чтобы умел больше - да, ищите к нему отдельные модули.
Не пользовался, но говорят pandoc что-то умеет

Цитировать
Спасибо за совет, но я её совместно почти не пишу. Так что... Пока не требуется. Smiley
Дело ваше, но совет был дан опять же не для "совместного" написания, а возможности хранения историй изменений и публикации (доступности для прочтения по ссылке)

Цитировать
Да, это папка с тестовым проектом в каталоге d:\GIT\Project. Но никак не клонирует. адо на семёрке попробовать - может, дело в той самой ошибке на XP.

Если в папке TestOrtohonalization есть папка .git - то указанные мной рекомендации по команде должны отрабатывать (уж не знаю как там на windowsXP =) ), по крайней мере у меня они работают
« Последнее редактирование: Июня 29, 2017, 01:39:41 pm от lastcross » Записан
da-nie
Full Member
***
Offline Offline

Сообщений: 167



Просмотр профиля
« Ответ #20 : Июня 29, 2017, 08:09:39 pm »

Цитировать
Зачем Вам контроль версий? Ну право же - это инструмент (который требует другой подход к организации рабочего процесса), и Вам он вероятно понадобился.

Да как вам сказать...  Roll Eyes Мне не сам контроль версий нужен - мне хочется ему научиться и с ним разобраться. Да и вдруг он мне понравится и я его буду использовать повсеместно? Всё возможно. Сейчас у меня сделано так: я не храню версии программ с ошибками и с помощью Smart Sync Pro синхронизирую все каталоги разработки между различными компьютерами (чтобы не потерять в случае повреждения основного винчестера все данные). На отдельном сервере размещаются готовые программы, которые специальная программа обновляет у пользователей (и себя саму тоже). И, честно говоря, ни разу не было надобности делать откат на какую-то версию и запоминать изменения (которых может быть очень много). Эту версию проще скопировать и переименовать с пояснением, что за изменения в этой версии. Скажем, у меня есть три варианта программы для определения калибровочных коэффициентов. Они все три нужны одновременно. Одна - штатная. Вторая и третья - с очередными идеями начальника, которые он ещё сам не знает, работают лучше или или нет и их проверяет уже больше года. Все три версии актуальные и требуют сопровождения.

Цитировать
Ваш текущий ответ звучит как - "я привык забивать гвозди, поэтому я забиваю и шурупы".

Нет. Мой ответ звучит так: "я пока ещё сам не знаю, что мне понравится и пока не считаю удобным в моём случае разделять данные проекта от самого проекта". Может быть, имело бы смысл, чтобы данные остались в папке проекта (где exe-файл), но были под самостоятельным версионным контролем. Думаю, с помощью настроек что хранить и что не хранить в GIT это можно сделать (как бы два объекта один в другом физически, но идеологически они разделены).

Цитировать
Отделяя такой репозиторий от сорцов - вы гарантируете что тестер не будет путаться в истории,

Нет никакого тестера. Smiley Ну не так у нас всё. Я ж сказал, у меня тут НИИ. Помилуйте, какой тестер! Руководство просит методику тестирования отдельным документом издавать! Это, я так понимаю, тест, который программа всегда пройдёт (кто ж туда запишет тест, который программа не пройдёт? Такой тест давно исправлен в программе. И я когда аттестовывался на инженера первой категории, они меня спрашивали, как мы тестируем ПО. Ну как? В составе комплекса испытываем и проверяем. Плохо, говорят. Ничего вы не понимаете в этом - должен быть документ, который "методика". Надо само по себе, говорят, тестировать. Лолшто? Без аппаратуры комплекса? Smiley И на полном серьёзе эти маразматики считали, что без документа "методики тестирования" наше ПО будет плохим. Им в этом видится проблема с ПО. Это ещё ничего, они меня на полном серьёзе спрашивали первые две цифры ГОСТ'а на ПО. Huh? Откуда мне знать? Я его даже открывать не собираюсь - он мне сто лет не нужен. Да они и сами не знают, что там написано. Только эти первые две цифры и знают.). Пользователи у нас сугубо внутренние. Если что-то не пойдёт, они позвонят и позовут (и даже если всё пойдёт, тоже позовут - они часто не читают инструкции по использованию ПО и удивляются странным результатам испытаний приборов - а нефиг нажимать на блоке или в программе то, чего не надо и не нажимать то, что надо). Руководство (директор и прочие) у нас вообще не понимает, почему с уходом "погромиста" ПО получается не поддерживаемое и не сопровождаемое. Они вообще в ПО ничего не понимают, но свои цидульки на эту тему писать не стесняются. Сейчас вот какую-то хрень (ФИКС, вроде называется, но не уверен) желают к архиву прикрутить. Зачем она им... Что это вообще такое?
Но начальник отдела часто надоедает мне, как всё это исправить. Ага. Имея два-три человека, которые занимаются каждый своим проектом (и электроникой, и часто чертежами, и сдачей в архив, и программой, и отладкой, и тестированием, и написанием инструкций). Smiley Люблю юмор, но, почему-то, не таких юмористов. Но кое-что я бы внедрил. Например, систему контроля версий. Ну вот кажется мне, что она могла бы быть полезной. Ещё не знаю, как, но кажется. Smiley

Цитировать
Все кто это осознал - не могут представить как что-либо серьезное кодить/разрабатывать без этой возможности.

Верю. Но это вы с этим работали. А я не работал. Потому и хочу попробовать посмотреть, насколько это удобно и как позволяет решать различные проблемы.

Я понимаю, что вас удивляет мой подход. Smiley Но вот была такая юмористическая статья когда-то (я выделил только некоторые абзацы):
Код:
...
Ученику выдается компьютер и некоторое количество программных средств, с
которыми ему в дальнейшем придется работать. Описаний к этим программам либо не
выдается совсем, либо выдается минимальный набор. Если происходит обучение
какому-либо языку программирования, в качестве руководства желательно
использовать литературу на языке, заведомо незнакомом обучающемуся, либо
произведения советских авторов.
Когда будет замечено, что ученик работает с программой (языком программирования)
довольно сносно, можно предложить ему для изучения исчерпывающие руководства.
Они будут прочитаны как захватывающий детектив. Затем, после небольшого периода
переваривания полученных знаний, программист готов к активной деятельности.
Специалист, прошедший обучение подобным образом, как правило, удивляет других
программистов приемами программирования. Не исключено, что вместо
шестнадцатиричной системы счисления он будет использовать десятичную (если ему
до прохождения курса никто не объяснял, что программировать нужно в
шестнадцатиричной системе). Программы, написанные таким специалистом, будут
совершенны в работе, но перед желающим их улучшить или изменить встанет
практически неразрешимая задача (за исключением случаев, когда с этой задачей
сталкивается такой же специалист), так как прочитать эти программы и понять их
суть крайне тяжело, например, нелегко обычному программисту прочитать программу
на Ассемблере, в которой все числа - десятичные.
...
все, что хакер делает, он не считает работой, и если фирма платит ему деньги,
то, вероятно, только для того, чтобы он иногда произносил фразу: "Я работаю на
фирме ...";
...
хакер не всегда знает язык программирования, с которым он в данный момент
работает;
хакер способен объяснять по телефону способ, которым можно найти ячейку памяти,
определяющую количество жизней в игре SABOTEUR, одновременно восстанавливая
содержимое диска с полностью испорченной директорией, используя DISC DOCTOR
фирмы Technology Research (программу, написанную либо пьяным, либо сумасшедшим);
...
как правило, критику хакер воспринимает без мордобития, всегда находит
оправдание, но указанную ошибку исправляет (если ее не исправил другой хакер);
хакер может страдать тяжелой формой мании величия, но всегда об этом
предупреждает;
мыслительный процесс идет у хакера подсознательно. Это иногда приводит к тому,
что ложась с женщиной в постель, хакер вскакивает, осознав, что в пятисотой
строке его программы стоит неправильное условие перехода на метку QWERTASDF
(такая метка также в порядке вещей, так как хакеру не хватает энергии не только
на написание комментариев, но и на придумывание удобочитаемых меток - гораздо
проще провести кулаком по клавиатуре).
...
Поскольку сейчас в советских магазинах нельзя купить не только пакет P-CAD для
IBM PC, но и колбасу, хакер часто начинает с того, что собственными силами
собирает компьютер. Естественно, что это игрушка для дома и семьи с
восьмиразрядным процессором и памятью в пределах 64К, но именно на таком
аппарате хакер начинает воистину вытворять чудеса. Описать ощущения, вызываемые
сообщением языка Си "Числа с плавающей запятой не поддерживаются" после 3-х
минутной подгрузки библиотеки stdio.h с магнитофона, невозможно, это надо
прочуствовать.
...
Хакер некоторое время ходит вокруг машины (радиус хождения может
составлять до нескольких тысяч километров), затем садится за клавиатуру и делает
за один вечер то, на что было выделено 15 дней. Не надо думать, что четырнадцать
дней, которые хакер потратил на хождение вокруг машины пропали даром: все это
время хакер подсознательно обдумывал поставленную задачу. Другое дело, была ли
необходимость в этих раздумьях.
Когда хакер заканчивает какую-либо работу, он твердо уверен: все, что он сделал
- хлам, однако вслух это мнение не высказывает, так как заказчик всегда остается
доволен. Хакер, конечно, расстроится, если случайно уничтожит шестимесячную
работу, но глубоко в душе он будет рад тому, что, расставшись с хламом, он
сможет решить задачу гораздо красивее.

 Cheesy Cheesy Cheesy

Хоть Saboteur у меня и был (но он мне не был интересен - вечные жизни я ставил в других играх, например, в Dynamite Dan-2 или Dizzy-4), но TR-DOS'а не было - на моём ZX был только магнитофон. Что касается Hisoft C, то да, едва набрав #include <stdio.h> этот чудо компилятор сразу требовал загрузить эту библиотеку с ленты. Smiley Только у меня её не было в пакете. Smiley Сам компьютер, впрочем, был магазинным - на тот момент я не слишком понимал, как он работает. Ну и метки у меня изначально были аккуратные (комментарии тоже имелись). Smiley А в остальном почти биография. Smiley И десятичная система в ассемблере. Smiley

Цитировать
а возможности хранения историй изменений и публикации

Вот честно, не могу представить, чтобы, например, для инструкции по регулированию и контролю требовалось хранить изменения. А публикации зафиксированы в архиве.  Roll Eyes

Цитировать
Если в папке TestOrtohonalization есть папка .git - то указанные мной рекомендации по команде должны отрабатывать

Да. Есть. Но не работает. Надо на Windows 7 попробовать будет.
« Последнее редактирование: Июня 30, 2017, 09:30:27 am от da-nie » Записан

И день и ночь в пути
da-nie
Full Member
***
Offline Offline

Сообщений: 167



Просмотр профиля
« Ответ #21 : Июля 04, 2017, 10:27:35 am »

Под Windows 7 всё работает правильно. Клонирует без проблем. Smiley
Записан

И день и ночь в пути
Страниц: 1 [2]
  Печать  
 
Перейти в: