Comments 118
Периодически от студентов приходят вопросы о работе системы контроля
версий Git. Частая причина возникновения этих вопросов — непонимание
разницы между репозиторием и обычной папкой.
Причина скорее всего в том, что гит это инструмент и с ним нужно учится работать, но в курс обучения это не включают. Вот и получается, решите эту простенькую задачку через два дня и заодно изучити базовый гит и что-нибудь еще.
Мы когда делали обучение, получили фидбэк о проблемах с гитом, поэтому включили в первое занятие небольшую часть по гиту и гитхабу. Правда не уверен, что это сильно помогло.
но в курс обучения это не включают.
У нас на 2-ом курсе в колледже преподают Git (именно команды, но и интерфейс тоже)
Проблема в том, что гит это мультимегакомбайн. Нужно прочитать книгу, чтобы начать понимать как он работает.
И, это плохой признак. Инструмент задача которого сводится к "принять файлы, отдать файлы" не должен требовать прочтения книги для работы.
Что-то вы слишком упрощаете. Git предлагает решения проблемы управления версиями в распределенной системе. Это довольно навороченная тема даже со стороны науки. Передача файлов лишь технический момент.
Git предлагает решения проблемы управления версиями в распределенной системе. Это довольно навороченная тема даже со стороны науки.
Git — это про хранение истории изменений и про синхронизацию совместной работы нескольких человек над одними файлами. Начинать надо с этого, а остальное уже внутренние детали реализации, погружаться в которые надо или не надо в зависимости от специализации.
Точно так же, как рассказывать про телефон надо с того, как по нему звонить, а не с разделения полосы частот и с гостевого регистра абонентов.
"Распределенная" системы с централизованными lfs и lockами.
Система до сих пор поддерживающая патчи передаваемые через email.
Гит это эволюционно разросшийся комбайн обросший костылями, к сожалению.
Гит - порождение unix модели, который противоречит этой модели.
Основа unix идеологии - инструменты должно хоршо делать узкоспециализированную задачу. А гит - монстр, который пытается удовлетворить всех. Из-за этого превратившийся в нечто плохо перевариваемое.
А гит — монстр, который пытается удовлетворить всех. Из-за этого превратившийся в нечто плохо перевариваемое.
А что конкретно монструозного есть в гит? По-моему он неплохо справляется со своей задачей и не делает ничего лишнего. Даже наоборот, мог бы побольше фич иметь.
"Распределенная" системы с централизованными lfs и lockами.
lfs это расширение гита, а не сам гит. У меня с ним никаких проблем нет, потому что я им не разу не пользовался.
Система до сих пор поддерживающая патчи передаваемые через email.
Поддержка емейлов? Что-то не верится.
Гит - порождение unix модели, который противоречит этой модели.
Гит это система, а не юникс приложение.
. Из-за этого превратившийся в нечто плохо перевариваемое.
Насколько я знаю первая версия гита была очень сложная и приходилось писать много всего, для простых действий. То что вы видите сейчас это очень значительный прогресс.
Поддержка емейлов? Что-то не верится.
Файлов с diff-ом, не обязательно почтой. https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project#_patches_from_email
Инструмент задача которого сводится к «принять файлы, отдать файлы» не должен требовать прочтения книги для работы.У гита много уровней. Одних достаточно для джуна, как в анекдоте «Чукча, покорми собак и ничего не трогай». А некоторые только для тех, кто разрабатывает архитектуру приложения и его деплой.
Проблема в том, что гит это мультимегакомбайн. Нужно прочитать книгу, чтобы начать понимать как он работает.
По-моему вы слишком преувеличиваете.
Это достаточно простой инструмент, и совсем не нужно понимать как он работает внутри, чтобы пользоваться.
Если работать с гитом для себя - вообще достаточно получаса, чтобы разобраться.
В команде - подскажут и за день введут в курс.
Если же хочешь разобраться как работают GC, как хранятся объекты и как избегается их дублирование - тут да, надо немного колупнуть и в идеале сравнить с тем, как данные хранятся в CVS/SVN чтобы понимать к чему пришли SVC в принципе на сегодняшний день.
А вообще, было бы неплохо еще понимать разницу между SVC и Code Review, потому что у очень многих, наверное даже большинства, это в голове сливается в одно целое
Согласен с предыдущим оратором.
Это обучение ради обучения.
Ну и одному мешкаться в репозитории тоже смысла мало.
В одной ветке все вести тоже смысла мало.
Ну и самому вводить команды не так интересно, как в GUI IDE.
На простом проекте тоже git не раскроется.
Это вряд ли нормально в учебном процессе выучить.
Да и не везде в процессе разработки используют git или используют нормально.
Ну и самому вводить команды не так интересно, как в GUI IDE.
Ну не знаю, я чет так и не привык, мне проще везде использовать commit, checkout, push\pull и не париться IDE-зависимостью. Правда, я ближе к администрированию и на все системы IDE не поставишь.
Ну и одному мешкаться в репозитории тоже смысла мало.
В одной ветке все вести тоже смысла мало.
Потому что никто не объясняет пайплайны разработки и жизненного цикла файлов, да и вообще зачем нужен еще один слой хранения изменений. А как только кто-нибудь объяснит(ну или сами придете) то уже за уши от системы контроля версий не оттащить. Знаете какая боль после git'а работать с каким-нибудь автокадом? Где единственный вариант хранить изменения это file v1.dwg, file v2.dwg, file final.dwg, file final w comments.dwg
Почему вы автокад файлы не храните в гите?
Почему вы автокад файлы не храните в гите?
Почему вы гвозди забиваете молотком, а не микроскопом? Потому что он для этого не предназначен.
Начать стоит с того, что dwg, в отличии от dxf, бинарный формат, со всеми вытекающими для git'а проблемами. Во-вторых, diff\merge как делать? Даже, если перейти на dxf, вы вот поймете что произошло, можно это мержить?
по такому куску diff
30
0.0
-- 11
++ 22
1.0
21
-- 1.732050807568839
++ 1.505345345789953
31
0.0
1001Что осталось от системы контроля? Ветки и коммиты? Ну такое себе, напоминает натягивание совы на глобус
С какими вытекающими? Гит без проблем хранит бинарные файлы.
нет, серьезно, расскажите что там за проблемы у гита с бинарями. Не обтекаемыми фразами "у гита всегда были проблемы с бинарями", а по пунктам. Смею предположить что вы не знаете какие у него проблемы. Потому что в вашем кейсе у него никаких проблем нет. Будет работать как минимум не хуже, чем локальное хранение ручной истории.
Если у вас сейчас ситуация с размножением 1.dwg, 2.dwg 3.dwg - гит коммиты заменят её без проблем.
Не работает бинарный дифф? А с ручными1.dwg, 2.dwg 3.dwg - работает?
Что останется... Ветки и коммиты. Да, именно они и останутся. Это и есть суть VCS: заменить ручное "v1.zip, v2.zip, v3.zip" на автоматизированную систему. А что еще вам нужно?
С какими вытекающими? Гит без проблем хранит бинарные файлы.
Основная задача системы контроля версий - не только хранить, но и
1) показывать различия.
2) уметь сливать ветки
А просто хранить - это слегка продвинутой системы копирования достаточно.
Основная задача "системы контроля версий" напрямую описана в названии. А то что вы хотите - приятные бонусы.
Если у вас стоит задача "хранить версии", а в обсуждаемом топике именно такая задача и обозначена, "система контроля версий" подходит идеально. Причем любая.
Продвинутой системы наступания на грабли? Вот некоторые вообще не понимают, какую на самом деле клоаку разруливает git при разработке. Потом внезапно выясняется, что "вот та копия" вовсе и не та копия, потому что половину файлов удалили, половину случайно поменяли, а кое что и вовсе оказалось скопированным наполовину или хард/фс начало подыхать, но узнаете вы об этом не сразу... там где у СКВ есть хэш нужной версии и компактная история у вас будет гадюшник уже на десятке копий при локальной разработке, а если в команде больше одного разраба, активная разработка, РАСПРЕДЕЛЁННАЯ разработка (не всем же в офисе тухнуть) и проект будет жить не один год... там даже смешно уже становится в 2023 году наблюдать как люди старательно тратят время и силы на возможность с разбегу прыгать по граблям всех мастей, чтобы не учить базовых 6 команд (init, add, commit, push, pull, checkout), как они кидаются в архиваторы, скрипты, какие-то копии копий копий в которых потом сами разобраться не могут... 6 базовых команд... которые уже и учить не нужно - есть поддержка в IDE, есть GitExtensions и ещё вагон - выбирай на свой вкус и не дури людям голову на 100500 раз обсосанных элементарных вещах. Если кто-то считает что ему не нужен СКВ - пусть считает сам себе, пока не упорется огребать и не выучит элементраные вещи. Не нужно людям врать что раз кто-то не осилил, то СКВ "нинужно".
Показывать различия - вообще ни разу не задача системы контроля версий. Её задача уметь приводить всё из состояния A в состояние B и обратно, а красивые наглядные диффы для данных которые люди не могут себе организовать для некоторых форматов в принципе (да, давайте, сравните ещё два исполняемых файла на глазок) - это просто приятный бонус. И тут всё ещё у СКВ больше возможностей.
Уметь сливать ветки - а в какой момент вы решили, что в слегка продвинутой системе копирования это получится лучше, когда нужно делать это не один раз, а регулярно, а иногда и повторяя мерж некоторых групп файлов?
Уметь сливать ветки - а в какой момент вы решили, что в слегка продвинутой системе копирования это получится лучше, когда нужно делать это не один раз, а регулярно, а иногда и повторяя мерж некоторых групп файлов?
Я это не решил. Тезис как раз был в том, что если используемый инструмент не умеет мержей - то это не отличается от немного продвинутой системы архивирования и бакапа.
Те тоже 'текущий момент' фиксируют и присваивают им какую-то версию. И позволяют вытягивать нужную. При известном желании можно даже найти ветвление (инкрементный образ на основе....)
С какими вытекающими? Гит без проблем хранит бинарные файлы.
=) Вы видимо не знаете как работает гит под капотом. Хранит то он хранит - к этому не было претензий. Вопрос как он их хранит? и уот тут начинается веселая история про то что хранит он diff и меняя одну букву, у вас может поменяться половина бинаря. Например, меняя одну букву в текстовом файле, я получаю
git format-patch --stdout 29243dbc..594185 | wc -l
25Для dwg с изменениями как на КПДВ (см. ниже), где тоже изменился один символ:
git format-patch --stdout 50aa6d..bd6e2807 | wc -l
2107Т.е. чем больше коммитов бинарей тем бОльше будет отжиться места, т.е. надо вкорячивать LFS. Бонусом идет сжатие zlib'ом, и если тексты жмутся легко и непринужденно, то с бинарями, сами понимаете, история другая.
Соответственно езда по коммитам - это пучОк мержей от условного инита, до нужного места, через все коммиты. В общем, будет тормознуто и весело.
Не надо хранить бинари в гите.
Не работает бинарный дифф? А с ручными1.dwg, 2.dwg 3.dwg - работает?
К сожаленю, да, таков пайплайн. Автокад\word имеет функцию сравнения только ему для этого надо указать два файла одновременно.
КДПВ
Ветки и коммиты. Да, именно они и останутся. Это и есть суть VCS: заменить ручное "v1.zip, v2.zip, v3.zip" на автоматизированную систему. А что еще вам нужно?
Смысл теряется. Что делать с веткми, если вы не можете разрешить конфликт и у мержа провести ревью?
Проще уж скрипт на полтора регэкспа написать который будет менять индекс файла если файл с таким именем уже есть, а старый класть в папку old. Функционал тот же, а телодвижений меньше.
Так почему не можешь то конфликт разрешить? бери сравнивалку, которая умеет в твой бинарь, решай конфликт, сообщай гиту, что конфликт решен, файл актуальный, идем дальше.
Предполагаю, что все таки знаю как работает гит.
Если у вас в ручном варианте хранится история в виде v1.dwg, v2.dwg v3.dwg, то и в гите, даже без lfs, никакого оверхеда не будет.
Будет ровно тоже самое, только автоматизированное.
В вашей репе будет три ПОЛНЫХ dwg файла, да. Это чем-то отличается от ручного хранения тех же трех ПОЛНЫХ dwg файла?
Если у вас есть в автокаде дифф, прикрутите этот дифф к гиту. Ровно так работает скрипт mergetool из поставки гита. Он не работает с смердженным конфликтным файлом, а выдирает две версии файлов и отдает внешним тулам.
UPD: вы же в курсе про -delta? Просто весь ваш пост выглядит так, как будто не в курсе.
Это чем-то отличается от ручного хранения тех же трех ПОЛНЫХ dwg файла?
Да, тем что я мгновенно получаю доступ к любому из них, а гит будет делать пучек мержей, прежде чем выдаст нужную версию - и если это не принципиальный момент для файла весом в пару килобайт, то с 50-100 метровыми файлами начинается веселье.
Может не очень понятно описал, но проблема не в объеме как таковом, а в том что этот объем практически весь будет обрабатываться при езде по коммитам.
Он не работает с смердженным конфликтным файлом, а выдирает две версии файлов и отдает внешним тулам.
В целом, соглашусь, это реализуемо. Но тут начинается такая интересная петрушка в виде того что мы начинаем использовать 10% гита, выкидывая все остальное. Т.е. то с чего начал - можно ли забивать микроскопом гвозди? Можно, но по настоящему эффективен он в другом.
И еще раз перечитайте сообщение с которого все началось - боль, хранить не файлики и версии, боль в хранении изменений, а это как раз таки комплекс всего (того 90% функционала который не можем использовать для бинарей)
Не будет никаких мерджей. Вы тоже не знаете о -delta?
Да, тем что я мгновенно получаю доступ к любому из них, а гит будет делать пучек мержей, прежде чем выдаст нужную версию
Учите мат часть. Гит хранит разные версии файлов целиком, а не диффы между ними. Причем именно благодаря этому, в гите ветки и называются "легковесными" и штампуются пачками, в отличие от SVN/CVS, где работа с ветками вызывала гемор.
Гит не хранит по-коммитные дельты. Это вы с svn перепутали.
Ой, вот на мой взгляд как раз система контроля версий это именно система контроля версий.
То, что для текстовой версии есть встроенные просмотры дифов это мелкий бонус. Сорс Три вполне себе генерит 3 бинарника и возьми диф генератор для этого типа бинарников да смотри. Ключевое — поиск общего предка по коммитам для тройного сравнения.
Да, потеря блейма это жалко. Но сохранившийся хистори его заменит.
Не мешайте в кучу систему контроля версий (технологию) и ее конкретную реализацию(git)
У автокада есть своя VCS, правда входит в PDM, стоит конских денег и совсем не для небольших компаний
Для печатных чертежей и документов, есть ЕСКД с ГОСТ 2.503-2013 - когда-нибудь напишу статью-сравнение советской системы учета изменений и гита.
В общем если git создавался для кода и текстовых данных, то и использовать его надо для кода и текста, а не хранения порно
Гит создавался для обмена патчами через почту. Какая разница для чего он создавался, если он уже давно промышленный стандарт для самых разных проектов? Я так понимаю в гите lfs, partial cloning. и аттрибуты binary, -delta, lockable - для кода и текстовых файлов были введены...
промышленный стандарт
В какой области? Большая часть данных какая?
Повторюсь, хранить информацию и вести учет можно и по 2.503, только это будет больно и неэффективно. Точно так же git - не золотая пуля и у него есть границы применимости, если вы их не осознаете, ну... не сталкивались наверное. Вам в репку никто никогда 1.5 ТБ видео не пушили? Ну вот закиньте коллегам, посмотрите на реакцию.
1.5 террабайтное видео? Нет, не пушил. А мы здесь обсуждаем 1.5 террабайтные видео в репке? Простите, не знал. Для 1.5 террабайтных видео не надо гит использовать.
В какой области? Большая часть данных какая?
Геймдев, например. Проекты на UE. Подавляющая часть данных - бинари. HEAD - сотни гигабайт. Репозиторий - террабайты.
и все это на чистом гите без LFS?
Тут ребята из gitlab'а в статье про LFS вон чего говорят:
Managing large files such as audio, video and graphics files has always been one of the shortcomings of Git. The general recommendation is to not have Git repositories larger than 1 GB to preserve performance.
Так что думается мне у вас там под капотом LFS который работает немного не так как классическое хранение изменений в гите.
Я подозреваю, с большой вероятностью (если не куплено что-то дорогое) -- на SVN.
Конечно LFS используется. Хотя бы потому что нужны локи, а они как раз часть LFS.
Вполне можно жить без LFS На гите с большими репами, но это существенно сложнее(надо помнить об отключении дельты, использовать partical cloning, отказаться от локов и регулярно чистить локальные ветки), зачем это делать когда есть LFS - не понятно. Но это не значит, что гит без LFS не переваривает большие файлы. Просто работа с ним становится чуть требовательней к квалификации.
Тут вы конечно лукавите, в геймдеве гит точно не промышленный стандарт
Для бинарей есть такие вещи как Артифактори, Нексус и другие артефактные репозитории.
Гит, svn, cvs - для текстовых файлов.
Именно SVN для бинарников еще более-менее сносно.
SVN хранит бинарники также, как и git - целиком.
И понятное дело, что если у вас не так много бинарников и они не так часто изменяются, то можно использовать любую систему контроля версий.
Но именно такие вещи как Artifactory/Nexus и другие - позволяют гибко настроить ретеншн для артефактов, и сохраняя версионность, хранить бинарники с минимальными затратами по ресурсам (storage)
Немного не в тему, но надо сказать, что Автокад у себя внутри умеет хранить историю измений своих примитивов каждого в отдельности.
И ещё огромный плюс Автокаду, что у него undo действует не только на рабочий файл, но даже на конфигурацию среды. Наверняка и у вас часто бывает в какой-нибудь малознакомой (да и часто знакомой) программе вы нажали случайно какие-то кнопки и исчезла какая-нибудь нужная панель, или вы вообще переключились в какой-то экзотический режим. Так вот автокадовский undo всё "возвращает в зад", всю среду, откатывается любые действия пользователя, а не только относящиеся к рабочему файлу.
Ну и одному мешкаться в репозитории тоже смысла мало. В одной ветке все вести тоже смысла мало.
Есть множество случаев, когда репозиторий полезен для одного.
Чтобы отслеживать историю, чтобы следить за изменениями.
Например книжку или статью пишешь, редактируешь.
Банально: сделал фичу. Понял что сделал криво. Переделал. Понял что первый вариант был лучше... А его уже нет.
С VCS - просто откатил файл или посмотрел историю.
VCS в одиночных проектах удобен и нужен. Нет ни одной причины не использовать.
Согласен с вами. Хочется дополнить, что можно вести разработку в отдельной ветке и периодически сливать ее в мастер. А на мастере стоит триггер по деплою изменений.
Постоянно так делаю в своих пет проектах. Очень удобно автоматически деплоить пачку изменений на сервер.
Периодически от студентов приходят вопросы о работе системы контроля
версий Git.
Студенты уже не в состоянии сами найти какой-нибудь стартовый туториал по Git? Просто банально зайти на их страницу и почитать гайды, туториалы, документацию?
В туториале по git неподготовленный человек утонет. А для студентов можно было бы и методичку подготовить, в обьёме, достаточном для выполнения задания.
А после знакомства с методичкой можно и к документации отправлять.
на любой вкус и цвет
Неподготовленный человек может и вот такое руководство найти. Если вместо обучения отправлять искать туториалы - в чем тогда смысл учебного заведения?
Если вместо обучения отправлять искать туториалы — в чем тогда смысл учебного заведения?
Мы говорим о высшем учебном заведении? Тогда его "смысл" кроме всего прочего это научить искать информацию и изучать что-то самому.
Если завтра git потеряет свою популярность и/или появится какой-то новый тул, то что, опять идти в ВУЗ и учить всё заново?
Неподготовленный человек может и вот такое руководство найти.
Может. И если оно ему поможет и ответит на все его вопросы, то и хорошо. А если нет, то кто ему запрещает искать дальше?
научить искать информацию и изучать что-то самому
Ну, в git есть репозитории, а папок нет, пнятненько? Найдите что-нибудь и сдайте эту лабу.
И в чём проблема? В гугле по слову "git" их страница первая в выдаче. Документация там находится вообще без проблем. Даже на русском есть. Читаем "Введение" и потом "2.5 Основы Git — Работа с удалёнными репозиториями". Профит!
То есть я согласен что есть информация, которую без предварительных знаний не найти и/или не понять. Но не в данном случае...
ВУЗ должен объяснить что такое система контроля версий, какие проблемы она решает и как. А вот с конкретными реализациями, товарищи студенты, можете познакомиться в рамках лабораторных работ\доп. материала. На семинаре сравним SVN, Mercurial, Git, Bazaar, TFS
Судя по советам из статьи, что такое VCS и зачем оно, в вузе не объясняют.
Мыж не знаем контекста, может это ВУЗ международных языков, где АйТи отведено пол-семестра. Правда непонятно, зачем им вообще про гит рассказывать...
Мыж не знаем контекста, может это ВУЗ международных языков
Которые, в таком случае, работают с разными текстами (переводов).
И переводить толпой народа какой-нибудь один текст без Version Control (и "code Review")-- это как-то сильно бестолково. Так что объяснять и пробовать разные VC -- им строго обязательно. Как и вообще любым людям, работа которых состоит в "что-то делать с текстом".
В наших ВУЗ-ах изучение систем контроля версий? Да еще с лабораторными???
Вы шутите! Это в рамках какого курса может происходить?
Насколько я знаю специфику тематики обучения в наших ВУЗ-ах, даже просто разработка софта не определяется как какая то область научного знания, что уж говорить об инструментах которые нужны для разработки софта.
В некоторых вузах лабораторные по некоторым предметам сдают в ихний универовский gitlab. Методичка присутствует. Не вижу в этом ничего плохого.
Так то студенту этот ваш git на 99.9% не нужен. Не делает он ни долгоиграющих ни групповых проектов. Но дать представление, чтобы он понимал, что оно и зачем оно может быть полезно - это правильно.
на самом деле обучение в вузе должно включать в том числе и самостоятельный поиск информации.
update: надо было обновить комментарии перед отправкой, выше уже более развёрнуто высказали эту же мысль
Студенты в состоянии и пойти работать по специальности без участия ВУЗа, однако преподавателям необходимо что-нибудь рассказать. И лучше уж это будет git, чем то же GPSS
Студенты уже не в состоянии сами найти какой-нибудь стартовый туториал по Git?
Вы исходите из позиции профессионального разработчика, для которого man rtfm это увлечение и хлеб.
Допускаю, что для каких-то студентов git просто очередная тема - одна из сотен - препятствие перед заветным словом "зачёт", которые проходятся с единственной мыслью "сдать и забыть".
Потом конечно это аукнется, кто пойдет работать по специальности. Но здесь и сейчас: папки, шмапки - какая разница? Важнее планы на вечер и ближайшее выходные.
Я исхожу из позиции бывшего студента которому такие вот вещи никто не разжёвывал. А в мои времена ни поисковиков нормальных не было, ни гайдов, ни туториалов.
И как я уже писал выше: да, есть вещи которые для понимания требуют наличия каких-то знаний. Но базовые умения работы с Git к ним точно не относятся.
Когда я был студентом — я поступал ровно так же, и в том числе и по этой причине мне сегодня неплохо платят. Не вижу причин, почему не рекомендовать студентам сегодня поступать так же — читать rtfm. Вообще всегда.
Могут и найти, просто что плохого в том, чтобы упростить им эту задачу?
Задачу можно вообще до бесконечности упрощать. Например просто сразу выдать диплом и всё. Но вроде бы в этих самых вузах студентов учить должны. Или нет?
Ну, например, можно отправить студента читать f***ing manual по git, python, матану, органической физике, сопромату, анатомии, чему ещё в этих ваших универах и ПТУ учат.. А чтобы не сильно упрощать - пусть сами найдут правильный мануал.
И ещё раз: я согласен что есть вещи, которые надо объяснять и которые не понять, если не имеешь каких-то нужных знаний.
Умение пользоваться Git на базовом уровне к ним точно не относится.
Умение пользоваться Git на базовом уровне к ним точно не относится.
В эту схему не укладываются следующие вещи:
-- статья сверху этих комментариев
-- мой опыт, который говорит, что люди предпочитают не читать мануалы ;) в том числе и по git.
-- отличная методичка-шпаргалка в коментариях внизу ;) Схоронил.
Так то на базовом уровне git и не нужен. Разве что лабу чтобы сдать. Чтобы git помогал решать какие-то практически полезные задачи - в него нужно нормально погрузиться. Хотя бы до уровня из шпаргалки ;).
Статья сверху этих комментариев
Которая, если уж быть честным, вообще не понятно что делает на хабре...
мой опыт, который говорит, что люди предпочитают не читать мануалы ;) в том числе и по git.
Люди точно так же предпочитают хорошие оценки или даже зарплату за просто так получать. Но это не значит что оно так должно быть.
отличная методичка-шпаргалка в коментариях внизу ;) Схоронил.
Не вижу в каком месте она не укладывается.
Так то на базовом уровне git и не нужен.
Во первых нужно понимание что это такое, для чего оно вообще нужно и как им пользоваться. Потому что если мы говорим о айтишниках, то сложно будет мимо этого пройти в профессии.
А во вторых нужно учиться разбираться в таких вещах без посторонней помощи. Потому что точно так же сложно будет мимо этого пройти в профессии.
Не вижу в каком месте она не укладывается.
При наличии мануала, отправлять читать который легко и приятно, кто-то не поленился и написал эти git flight rules.
Во первых нужно понимание что это такое, для чего оно вообще нужно и как им пользоваться.
Вот именно. Откуда должно появится это понимание? Прямой необходимости использовать git при учебе нет. Даже при изучении C++ или алгоритмов ;)
При наличии мануала, отправлять читать который легко и приятно, кто-то не поленился и написал эти git flight rules.
Ну вот именно. Кто-то не поленился и выложил. Как мануал так и git flight rules. И кучу туториалов. И различных видео. И это всё совсем не сложно при желании найти.
Откуда должно появится это понимание?
Ваша "шпаргалка" имеет ссылку на книжку о Git на сайте самого Git. Там это вполне себе понятно написано.
Прямой необходимости использовать git при учебе нет.
Если необходимости нет, то и не надо. Тогда только не понятно зачем статья...
это всё совсем не сложно при желании найти
Чтобы найти, нужно знать что искать. Вот допустим изучает студент pascal (python, C++..) по учебнику. В учебнике про git ничего нет. Почему бы не упростить ему задачу и не рассказать, что оно такое и зачем нужно?
не понятно зачем статья.
Да ;) Если чел дошел до commit-merge - подобных вопросов возникать не должно.
Чтобы найти, нужно знать что искать.
Ну так студенту же дали как минимум информацию что речь идёт о "Git" и "репозитории". Этого вполне достаточно чтобы найти нужную информацию.
Почему бы не упростить ему задачу и не рассказать, что оно такое и зачем нужно?
В учебнике и про винду или линукс ничего нет. Это студентам тоже надо объяснять? Когда стоит начать прекращать ему всё разжёвывать? Когда он на пенсию пойдёт?
В учебнике и про винду или линукс ничего нет.
Не умеешь запускать программы в windows (linux) - не пройдёшь курс по программированию в pascal. Не умеешь в git - ну и ладно, это очень сильно опциональное умение.
Когда стоит начать прекращать ему всё разжёвывать? Когда он на пенсию пойдёт?
Обучение - процесс бесконечный. Если есть возможность какие-то места этого процесса упростить - что в этом плохого?
Не умеешь запускать программы в windows (linux) - не пройдёшь курс по программированию в pascal. Не умеешь в git
Значит не пройдёшь какой-то другой курс. Вообще не вижу разницы.
Обучение - процесс бесконечный. И кто-то должен бесконечно всё разжёвывать? Или стоит всё-таки уметь искать информацию и учиться самостоятельно?
Значит не пройдёшь какой-то другой курс.
Какой ? ;) Что имеет в зависимостях git?
Подозреваю что какие-то практические работы, которые надо сдавать в таком виде.
То есть не знаю как это выглядит в России в различных ВУЗах, а у нас сейчас так часто делают. И даже проверка частично или полностью автоматизирована.
Если папка — это то, к чему мы все привыкли как пользователи компьютеров, то репозиторий — это что-то новое, что нужно создать, инициализировать. Сам по себе репозиторий без наших указаний не появляется.
если у вас папки появляются сами по себе, то для вас, скорее всего, есть плохие новости...
Заголовок "Советы изучающим git". Содержание — как отличить репозиторий от папки.
Заголовок "Советы начинающим фотографам". Содержание — как отличить фотоаппарат от картошки.
Содержание — как отличить фотоаппарат от картошки
скорее «как отличить пейзаж от фотографии»
понятия «папка» (ИМХО не самый популярное слово для обозначения директорий, во всяком случае среди русскоязычных пользователей git; ну да ладно) и «репозиторий» несколько разноплановые, если вуз учит отвечать на вопрос «я сейчас нахожусь в репозитории или в папке», значит что-то пошло не так
Подкаталоги же! Ну и корневой каталог в нагрузку).
С лругой стороны, все чаще встречаю людей, для которых основной термин - папка (даже среди хороших специалистов). Тотальное длительное доминирование одной операционной системы все-таки сильно влияет на привычки.
И таки да, соглашусь, что студенту стоит понять, что не репозиторий или подкаталог, а репозиторий размещается в подкаталоге файловой системы (по крайней мере локальный).
Но если у студента оно уже "или", то концепция "фс есть специализированная бд" для него будет неподъемно сложной.
Уже лет 20 не принято называть каталоги директориями. Используйте устоявшийся перевод, а не эту кальку с английского написания.
Папка — тоже нормальное слово. Его придумали когда появились графические интерфейсы и каталоги реально изображали в виде папок.
«Ну вот, смотри, нажимаешь эту клавишу и появляется буква, как на печатающей машинке. А потом кладешь этот „документ“ вот в эту „папочку“. Все почти как ты привык, ничего страшного и сложного»
И перелетающие листочки из одной папочки в другую — тоже из этой оперы
Людям, понимающим происходящее на более низком уровне, эти условности из реальной жизни нафик не нужны
Это зависит от ситуации. Иногда нажать кнопку или шорткат просто быстрее чем печатать команду.
папка - нормальное название для GUI
Ибо в консоли ты make directory, а в GUI - create folder.
Вот каталог - это плохойперевод
А почему "русская виндовс"-то?
https://en.wikipedia.org/wiki/Directory_(computing)#Folder_metaphor
что-то сложнее ворда
Ворд - сложная контринтуитивная штука. Гит на порядки проще.
Впрочем, если глубоко не копать, то что гит, что ворд, все не просто, а очень просто. А если хочется совсем упростить, то поставьте tortoisegit, и будет вам счастье безмерной простоты. Или встроенными средствами IDE воспользуйтесь.
habr.com/ru/post/718830/#comment_25272426
Я извиняюсь, а это точно для студентов? Похоже на вопросы и ответы какого нибудь ученика 9-12 классов.
В школе уже изучают Git?
Совет №0: Скачайте Кракен и навсегда забудьте про консольный GIT. Намного лет вперёд сэкономите себе кучу времени и нервов - поверьте моему опыту, я этого говна нахлебался, хватило на всю жизнь.
В отличие от вас системы контроля версий в работе использую для дела, а не для баловства! Консоль оставьте для секты консольщиков, а нормальный человек, зная что можно работать с визуальной формой, где всё наглядно и видно сразу что к чему относится, без всяких веб-форм и прочего говна - не будет в принципе использовать консоль, где и на практике применяются только две операции!
ИМХО, самый главный совет — в любой непонятной ситуации см. сюда: https://github.com/k88hudson/git-flight-rules/blob/master/README_ru.md
Если подробно, то я для изучения гита рекомендую такой «рецепт»:
Сначала потратить час и пролистать первые три главы gitbook: https://git-scm.com/book/ru/v2. Этот час окупится, так как будет понимание, что же происходит.
Использовать git для любых своих проектов и аккуратно коммитить изменения (объединяя их по сути).
В любой непонятной ситуации смотреть рецепт в git flight rules: https://github.com/k88hudson/git-flight-rules/blob/master/README_ru.md
Ключевая ошибка статьи в том, что рабочий каталог репозитория почему-то обозвали репозиторием. Это категорически не так.
Каждому студенту нужно знать чем отличается репозиторий от рабочего каталога. Рабочих каталогов может быть несколько и внутри одного из них может лежать репозиторий.
А бывают репозитории без рабочего каталога вовсе.
Гит на самом деле довольно прост, но к сожалению не интуитивен. Чтобы понять как работает гит, нужно обязательно выучить основные понятия, тогда не будет проблем. А если пытать только запомнить некоторые команды, то у вас ничего не получится. Вы будете как обезьяна вбивать заклинания в командную строку и не понимать что они делают на самом деле.
[Студентам] Советы изучающим git