Периодически от студентов приходят вопросы о работе системы контроля версий Git. Частая причина возникновения этих вопросов — непонимание разницы между репозиторием и обычной папкой.
Вот небольшая заметка на эту тему. Давайте разберемся, как работать с папками и репозиториями с точки зрения практики, то есть без строгих определений.
Пункт 1. Про папки и репозитории
Если папка — это то, к чему мы все привыкли как пользователи компьютеров, то репозиторий — это что-то новое, что нужно создать, инициализировать. Сам по себе репозиторий без наших указаний не появляется. Репозиторий в наших задачах — это папка, над которой были произведены некоторые действия, и Git в ней начинает выполнять свои задачи, например:
отслеживать изменения файлов;
хранить информацию о ветках.
Важно! Репозиторий не возникает сам по себе, его нужно создать.
Пункт 2. Как понять, в репозитории мы находимся или в папке
Самый простой способ это сделать — набрать в терминале команду «git status». Если в ответ вы увидите ошибку «fatal: not a git repository (or any of the parent directories): .git», значит, в терминале вы вызываете команду не из репозитория, а из обычной папки. Если вы увидели что-то другое, то вы находитесь в репозитории или внутри одной из папок, которая находится в нем.
Важно! Репозиторий отслеживает изменения во всех вложенных в него папках.
Если вы сделаете репозиторием корневую папку на диске C (не делайте этого!), то весь ваш диск станет репозиторием и Git будет пытаться отслеживать все изменения на этом диске. Создаем репозитории очень аккуратно.
Пункт 3. Как можно создать репозиторий
Чаще всего на начальных этапах рассматривают два способа создания репозитория:
Если мы находимся в папке (!) и хотим сделать из нее репозиторий, то вызываем команду «git init», и эта папка становится репозиторием.
Если мы хотим клонировать репозиторий из GitHub на свой ПК, то мы пользуемся командой «git clone». При этом обратите внимание: не нужно пользоваться командой «git init», команда clone не только скачивает файлы из интернета, но и инициализирует репозиторий в скачанной папке. На самом деле она делает сильно больше, но нам важно, что в скачанной папке у нас уже будет репозиторий и никак дополнительно инициализировать его не надо.
Пункт 4. Внимательно следим за тем, из какой папки вы вызываете команды
Терминал всегда показывает, в какой папке вы сейчас находитесь, но первое время студенты чаще смотрят на то, какая папка открыта в визуальном интерфейсе редактора (например, VSCode), а не на то, что написано в терминале. Обращайте, пожалуйста, внимание на название папки, которая указана в приглашении к вводу команд терминала. До тех пор, пока вы не привыкнете к работе с терминалом, внимательно следите за тем, что вы создаете репозитории только во вновь созданных для урока папках. Не нужно создавать репозитории из рабочего стола или других больших папок.
Пункт 5. Не нужно создавать репозитории внутри другого репозитория
Повторюсь: не нужно создавать репозиторий внутри репозитория. Прежде чем вызывать команды «git init» или «git clone», сначала убедитесь, что вы точно не внутри репозитория. Вызовите «git status» и убедитесь, что вы находитесь в папке, а не в репозитории. Если «git status» выдал ошибку «fatal: not a git repository (or any of the parent directories): .git», значит, вы в этой папке можете воспользоваться одним из способов создания репозитория, рассмотренным выше и на лекциях. Либо «git init», либо «git clone», но не обоими одновременно.
Важно! Иногда студенты сначала вызывают «git init» и потом «git clone». Но тем самым вы нарушаете правило не создавать репозиторий внутри репозитория. Обращайте на это внимание.
Пункт 6. Как репозиторий сделать обычной папкой
Когда вы создаете репозиторий, у вас в папке появляется новая скрытая папка с названием «.git». Это специальная папка, в которой хранится все, что необходимо для работы системы контроля версий. Если вы удалите эту папку, то потеряете всю историю, которую Git успел сохранить, но при этом превратите ваш репозиторий обратно в папку.
Итак, чтобы из репозитория снова сделать папку, достаточно всего лишь удалить скрытую папку «.git». При этом вы потеряете историю, которую собрал Git (все коммиты, ветки и т. п.), но файлы в самой папке останутся в том же виде, в котором они были в момент удаления папки «.git».
Пункт 7. Что делать, если все вокруг стало репозиторием
У студентов, которые неаккуратно вводят команду «git init», такое встречается. Поэтому давайте разберемся, что делать в такой ситуации. Надо проверить, успели ли вы уже совершить такую ошибку. Создайте новую пустую папку, например на рабочем столе, и в терминале вызовите «git status» в этой папке. Если вы увидите «fatal: not a git repository …», то радуемся. Все у вас в порядке.
Если же вы увидели что-то другое, значит, ваша вновь созданная папка является частью какого-то другого репозитория. Важно: мы только что создали новую папку и внутри нее никаких команд кроме «git status» не вызывали, то есть мы не создали сейчас новый репозиторий, но Git при этом не говорит нам, что это «not a git repository». Это может быть только в том случае, если вы эту новую папку создали уже внутри другого репозитория, то есть чуть раньше сделали репозиторием ваш рабочий стол или даже весь ваш диск C. Вылечить такую ситуацию можно следующим образом: нужно найти репозиторий, который вы создали по ошибке, и сделать его обратно папкой (см. предыдущий пункт — нужно удалить папку .git).
Если вы работаете на Windows, включите отображение скрытых файлов и папок, так как папка .git скрытая. Далее начинаем подниматься по иерархии папок вверх и искать в них папки «.git». Например, если вы создали папку по адресу «C:\Users\User\Pictures\ControlCenter\Scan», то сначала проверяете папку Scan, потом проверяете папку ControlCenter, потом Pictures и так далее, пока не найдете скрытую папку .git. Когда нашли и удалили, проводим проверку из начала этого пункта заново.
Успехов в освоении Git и терминала!
Комментарии (118)
php7
00.00.0000 00:00+2Согласен с предыдущим оратором.
Это обучение ради обучения.
Ну и одному мешкаться в репозитории тоже смысла мало.
В одной ветке все вести тоже смысла мало.
Ну и самому вводить команды не так интересно, как в GUI IDE.
На простом проекте тоже git не раскроется.
Это вряд ли нормально в учебном процессе выучить.
Да и не везде в процессе разработки используют git или используют нормально.
NAI
00.00.0000 00:00+13Ну и самому вводить команды не так интересно, как в GUI IDE.
Ну не знаю, я чет так и не привык, мне проще везде использовать commit, checkout, push\pull и не париться IDE-зависимостью. Правда, я ближе к администрированию и на все системы IDE не поставишь.
Ну и одному мешкаться в репозитории тоже смысла мало.
В одной ветке все вести тоже смысла мало.
Потому что никто не объясняет пайплайны разработки и жизненного цикла файлов, да и вообще зачем нужен еще один слой хранения изменений. А как только кто-нибудь объяснит(ну или сами придете) то уже за уши от системы контроля версий не оттащить. Знаете какая боль после git'а работать с каким-нибудь автокадом? Где единственный вариант хранить изменения это file v1.dwg, file v2.dwg, file final.dwg, file final w comments.dwg
AllexIn
00.00.0000 00:00-2Почему вы автокад файлы не храните в гите?
NAI
00.00.0000 00:00+4Почему вы автокад файлы не храните в гите?
Почему вы гвозди забиваете молотком, а не микроскопом? Потому что он для этого не предназначен.
Начать стоит с того, что dwg, в отличии от dxf, бинарный формат, со всеми вытекающими для git'а проблемами. Во-вторых, diff\merge как делать? Даже, если перейти на dxf, вы вот поймете что произошло, можно это мержить?
по такому куску diff
30 0.0 -- 11 ++ 22 1.0 21 -- 1.732050807568839 ++ 1.505345345789953 31 0.0 1001Что осталось от системы контроля? Ветки и коммиты? Ну такое себе, напоминает натягивание совы на глобус
AllexIn
00.00.0000 00:00+5С какими вытекающими? Гит без проблем хранит бинарные файлы.
нет, серьезно, расскажите что там за проблемы у гита с бинарями. Не обтекаемыми фразами "у гита всегда были проблемы с бинарями", а по пунктам. Смею предположить что вы не знаете какие у него проблемы. Потому что в вашем кейсе у него никаких проблем нет. Будет работать как минимум не хуже, чем локальное хранение ручной истории.
Если у вас сейчас ситуация с размножением 1.dwg, 2.dwg 3.dwg - гит коммиты заменят её без проблем.
Не работает бинарный дифф? А с ручными1.dwg, 2.dwg 3.dwg - работает?
Что останется... Ветки и коммиты. Да, именно они и останутся. Это и есть суть VCS: заменить ручное "v1.zip, v2.zip, v3.zip" на автоматизированную систему. А что еще вам нужно?
inkelyad
00.00.0000 00:00+9С какими вытекающими? Гит без проблем хранит бинарные файлы.
Основная задача системы контроля версий - не только хранить, но и
1) показывать различия.
2) уметь сливать ветки
А просто хранить - это слегка продвинутой системы копирования достаточно.
AllexIn
00.00.0000 00:00+6Основная задача "системы контроля версий" напрямую описана в названии. А то что вы хотите - приятные бонусы.
Если у вас стоит задача "хранить версии", а в обсуждаемом топике именно такая задача и обозначена, "система контроля версий" подходит идеально. Причем любая.
UMenyaNeudobnieVoprosiki
00.00.0000 00:00+3Продвинутой системы наступания на грабли? Вот некоторые вообще не понимают, какую на самом деле клоаку разруливает git при разработке. Потом внезапно выясняется, что "вот та копия" вовсе и не та копия, потому что половину файлов удалили, половину случайно поменяли, а кое что и вовсе оказалось скопированным наполовину или хард/фс начало подыхать, но узнаете вы об этом не сразу... там где у СКВ есть хэш нужной версии и компактная история у вас будет гадюшник уже на десятке копий при локальной разработке, а если в команде больше одного разраба, активная разработка, РАСПРЕДЕЛЁННАЯ разработка (не всем же в офисе тухнуть) и проект будет жить не один год... там даже смешно уже становится в 2023 году наблюдать как люди старательно тратят время и силы на возможность с разбегу прыгать по граблям всех мастей, чтобы не учить базовых 6 команд (init, add, commit, push, pull, checkout), как они кидаются в архиваторы, скрипты, какие-то копии копий копий в которых потом сами разобраться не могут... 6 базовых команд... которые уже и учить не нужно - есть поддержка в IDE, есть GitExtensions и ещё вагон - выбирай на свой вкус и не дури людям голову на 100500 раз обсосанных элементарных вещах. Если кто-то считает что ему не нужен СКВ - пусть считает сам себе, пока не упорется огребать и не выучит элементраные вещи. Не нужно людям врать что раз кто-то не осилил, то СКВ "нинужно".
Показывать различия - вообще ни разу не задача системы контроля версий. Её задача уметь приводить всё из состояния A в состояние B и обратно, а красивые наглядные диффы для данных которые люди не могут себе организовать для некоторых форматов в принципе (да, давайте, сравните ещё два исполняемых файла на глазок) - это просто приятный бонус. И тут всё ещё у СКВ больше возможностей.
Уметь сливать ветки - а в какой момент вы решили, что в слегка продвинутой системе копирования это получится лучше, когда нужно делать это не один раз, а регулярно, а иногда и повторяя мерж некоторых групп файлов?
inkelyad
00.00.0000 00:00+1Уметь сливать ветки - а в какой момент вы решили, что в слегка продвинутой системе копирования это получится лучше, когда нужно делать это не один раз, а регулярно, а иногда и повторяя мерж некоторых групп файлов?
Я это не решил. Тезис как раз был в том, что если используемый инструмент не умеет мержей - то это не отличается от немного продвинутой системы архивирования и бакапа.
Те тоже 'текущий момент' фиксируют и присваивают им какую-то версию. И позволяют вытягивать нужную. При известном желании можно даже найти ветвление (инкрементный образ на основе....)
NAI
00.00.0000 00:00+3С какими вытекающими? Гит без проблем хранит бинарные файлы.
=) Вы видимо не знаете как работает гит под капотом. Хранит то он хранит - к этому не было претензий. Вопрос как он их хранит? и уот тут начинается веселая история про то что хранит он 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. Функционал тот же, а телодвижений меньше.
AllexIn
00.00.0000 00:00+4Предполагаю, что все таки знаю как работает гит.
Если у вас в ручном варианте хранится история в виде v1.dwg, v2.dwg v3.dwg, то и в гите, даже без lfs, никакого оверхеда не будет.
Будет ровно тоже самое, только автоматизированное.
В вашей репе будет три ПОЛНЫХ dwg файла, да. Это чем-то отличается от ручного хранения тех же трех ПОЛНЫХ dwg файла?Если у вас есть в автокаде дифф, прикрутите этот дифф к гиту. Ровно так работает скрипт mergetool из поставки гита. Он не работает с смердженным конфликтным файлом, а выдирает две версии файлов и отдает внешним тулам.
UPD: вы же в курсе про -delta? Просто весь ваш пост выглядит так, как будто не в курсе.
NAI
00.00.0000 00:00-2Это чем-то отличается от ручного хранения тех же трех ПОЛНЫХ dwg файла?
Да, тем что я мгновенно получаю доступ к любому из них, а гит будет делать пучек мержей, прежде чем выдаст нужную версию - и если это не принципиальный момент для файла весом в пару килобайт, то с 50-100 метровыми файлами начинается веселье.
Может не очень понятно описал, но проблема не в объеме как таковом, а в том что этот объем практически весь будет обрабатываться при езде по коммитам.
Он не работает с смердженным конфликтным файлом, а выдирает две версии файлов и отдает внешним тулам.
В целом, соглашусь, это реализуемо. Но тут начинается такая интересная петрушка в виде того что мы начинаем использовать 10% гита, выкидывая все остальное. Т.е. то с чего начал - можно ли забивать микроскопом гвозди? Можно, но по настоящему эффективен он в другом.
И еще раз перечитайте сообщение с которого все началось - боль, хранить не файлики и версии, боль в хранении изменений, а это как раз таки комплекс всего (того 90% функционала который не можем использовать для бинарей)
saboteur_kiev
00.00.0000 00:00Да, тем что я мгновенно получаю доступ к любому из них, а гит будет делать пучек мержей, прежде чем выдаст нужную версию
Учите мат часть. Гит хранит разные версии файлов целиком, а не диффы между ними. Причем именно благодаря этому, в гите ветки и называются "легковесными" и штампуются пачками, в отличие от SVN/CVS, где работа с ветками вызывала гемор.
KvanTTT
00.00.0000 00:00Может и целиком, но при этом сжатие вроде тоже есть, чтобы репозиторий не раздувался до неприличного размера. Все несколько сложней устроено.
saboteur_kiev
00.00.0000 00:00Не сложней. Каждый файл хранится отдельным объектом.
Множество объектов со временем упаковываются в контейнер.
Но извлечь готовый файл даже с разжатием из контейнера - это минимальные накладные расходы. Никаких тысячи мержей, чтобы вытащить конкретную версию из конкретной ветки - нет.
Ndochp
00.00.0000 00:00+1Ой, вот на мой взгляд как раз система контроля версий это именно система контроля версий.
То, что для текстовой версии есть встроенные просмотры дифов это мелкий бонус. Сорс Три вполне себе генерит 3 бинарника и возьми диф генератор для этого типа бинарников да смотри. Ключевое — поиск общего предка по коммитам для тройного сравнения.Да, потеря блейма это жалко. Но сохранившийся хистори его заменит.
NAI
00.00.0000 00:00+1Не мешайте в кучу систему контроля версий (технологию) и ее конкретную реализацию(git)
У автокада есть своя VCS, правда входит в PDM, стоит конских денег и совсем не для небольших компаний
Для печатных чертежей и документов, есть ЕСКД с ГОСТ 2.503-2013 - когда-нибудь напишу статью-сравнение советской системы учета изменений и гита.
В общем если git создавался для кода и текстовых данных, то и использовать его надо для кода и текста, а не хранения порно
AllexIn
00.00.0000 00:00+1Гит создавался для обмена патчами через почту. Какая разница для чего он создавался, если он уже давно промышленный стандарт для самых разных проектов? Я так понимаю в гите lfs, partial cloning. и аттрибуты binary, -delta, lockable - для кода и текстовых файлов были введены...
NAI
00.00.0000 00:00+1промышленный стандарт
В какой области? Большая часть данных какая?
Повторюсь, хранить информацию и вести учет можно и по 2.503, только это будет больно и неэффективно. Точно так же git - не золотая пуля и у него есть границы применимости, если вы их не осознаете, ну... не сталкивались наверное. Вам в репку никто никогда 1.5 ТБ видео не пушили? Ну вот закиньте коллегам, посмотрите на реакцию.
AllexIn
00.00.0000 00:00-11.5 террабайтное видео? Нет, не пушил. А мы здесь обсуждаем 1.5 террабайтные видео в репке? Простите, не знал. Для 1.5 террабайтных видео не надо гит использовать.
AllexIn
00.00.0000 00:00В какой области? Большая часть данных какая?
Геймдев, например. Проекты на UE. Подавляющая часть данных - бинари. HEAD - сотни гигабайт. Репозиторий - террабайты.NAI
00.00.0000 00:00и все это на чистом гите без 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 который работает немного не так как классическое хранение изменений в гите.
inkelyad
00.00.0000 00:00Я подозреваю, с большой вероятностью (если не куплено что-то дорогое) -- на SVN.
AllexIn
00.00.0000 00:00Конечно LFS используется. Хотя бы потому что нужны локи, а они как раз часть LFS.
Вполне можно жить без LFS На гите с большими репами, но это существенно сложнее(надо помнить об отключении дельты, использовать partical cloning, отказаться от локов и регулярно чистить локальные ветки), зачем это делать когда есть LFS - не понятно. Но это не значит, что гит без LFS не переваривает большие файлы. Просто работа с ним становится чуть требовательней к квалификации.
SiGGthror
00.00.0000 00:00Тут вы конечно лукавите, в геймдеве гит точно не промышленный стандарт
AllexIn
00.00.0000 00:00Перфорс и Гит использует подавляющее количество студий. От инди и до крупных студий. Так что смею утверждать что не лукавлю.
Причем даже наличие Перфорса в студии не отменяет использования Гита. Поэтому и существуют всякие костыли в виде git-p4
saboteur_kiev
00.00.0000 00:00Для бинарей есть такие вещи как Артифактори, Нексус и другие артефактные репозитории.
Гит, svn, cvs - для текстовых файлов.inkelyad
00.00.0000 00:00Именно SVN для бинарников еще более-менее сносно.
saboteur_kiev
00.00.0000 00:00SVN хранит бинарники также, как и git - целиком.
И понятное дело, что если у вас не так много бинарников и они не так часто изменяются, то можно использовать любую систему контроля версий.
Но именно такие вещи как Artifactory/Nexus и другие - позволяют гибко настроить ретеншн для артефактов, и сохраняя версионность, хранить бинарники с минимальными затратами по ресурсам (storage)
Tyusha
00.00.0000 00:00Немного не в тему, но надо сказать, что Автокад у себя внутри умеет хранить историю измений своих примитивов каждого в отдельности.
И ещё огромный плюс Автокаду, что у него undo действует не только на рабочий файл, но даже на конфигурацию среды. Наверняка и у вас часто бывает в какой-нибудь малознакомой (да и часто знакомой) программе вы нажали случайно какие-то кнопки и исчезла какая-нибудь нужная панель, или вы вообще переключились в какой-то экзотический режим. Так вот автокадовский undo всё "возвращает в зад", всю среду, откатывается любые действия пользователя, а не только относящиеся к рабочему файлу.
NAI
00.00.0000 00:00Ну автокад тут такой... немного собирательный образ, потому что есть еще миллон САПРов, разной степени доступности.
saboteur_kiev
00.00.0000 00:00+9Ну и одному мешкаться в репозитории тоже смысла мало. В одной ветке все вести тоже смысла мало.
Есть множество случаев, когда репозиторий полезен для одного.
Чтобы отслеживать историю, чтобы следить за изменениями.
Например книжку или статью пишешь, редактируешь.AllexIn
00.00.0000 00:00+12Банально: сделал фичу. Понял что сделал криво. Переделал. Понял что первый вариант был лучше... А его уже нет.
С VCS - просто откатил файл или посмотрел историю.
VCS в одиночных проектах удобен и нужен. Нет ни одной причины не использовать.
PrinceKorwin
00.00.0000 00:00+1Согласен с вами. Хочется дополнить, что можно вести разработку в отдельной ветке и периодически сливать ее в мастер. А на мастере стоит триггер по деплою изменений.
Постоянно так делаю в своих пет проектах. Очень удобно автоматически деплоить пачку изменений на сервер.
Kanut
00.00.0000 00:00+11Периодически от студентов приходят вопросы о работе системы контроля
версий Git.Студенты уже не в состоянии сами найти какой-нибудь стартовый туториал по Git? Просто банально зайти на их страницу и почитать гайды, туториалы, документацию?
iig
00.00.0000 00:00+1В туториале по git неподготовленный человек утонет. А для студентов можно было бы и методичку подготовить, в обьёме, достаточном для выполнения задания.
А после знакомства с методичкой можно и к документации отправлять.
Kanut
00.00.0000 00:00+8Вы это сейчас серьёзно? Даже у Git на их страничке лежит книжка где уже всё считай разжёвано и даже какие-то видео.
А уж в сети можно найти туториалы на любой вкус и цвет.
iig
00.00.0000 00:00+1на любой вкус и цвет
Неподготовленный человек может и вот такое руководство найти. Если вместо обучения отправлять искать туториалы - в чем тогда смысл учебного заведения?
Kanut
00.00.0000 00:00+4Если вместо обучения отправлять искать туториалы — в чем тогда смысл учебного заведения?
Мы говорим о высшем учебном заведении? Тогда его "смысл" кроме всего прочего это научить искать информацию и изучать что-то самому.
Если завтра git потеряет свою популярность и/или появится какой-то новый тул, то что, опять идти в ВУЗ и учить всё заново?
Неподготовленный человек может и вот такое руководство найти.
Может. И если оно ему поможет и ответит на все его вопросы, то и хорошо. А если нет, то кто ему запрещает искать дальше?
iig
00.00.0000 00:00+1научить искать информацию и изучать что-то самому
Ну, в git есть репозитории, а папок нет, пнятненько? Найдите что-нибудь и сдайте эту лабу.
Kanut
00.00.0000 00:00И в чём проблема? В гугле по слову "git" их страница первая в выдаче. Документация там находится вообще без проблем. Даже на русском есть. Читаем "Введение" и потом "2.5 Основы Git — Работа с удалёнными репозиториями". Профит!
То есть я согласен что есть информация, которую без предварительных знаний не найти и/или не понять. Но не в данном случае...
NAI
00.00.0000 00:00+5ВУЗ должен объяснить что такое система контроля версий, какие проблемы она решает и как. А вот с конкретными реализациями, товарищи студенты, можете познакомиться в рамках лабораторных работ\доп. материала. На семинаре сравним SVN, Mercurial, Git, Bazaar, TFS
randomsimplenumber
00.00.0000 00:00+1Судя по советам из статьи, что такое VCS и зачем оно, в вузе не объясняют.
NAI
00.00.0000 00:00+1Мыж не знаем контекста, может это ВУЗ международных языков, где АйТи отведено пол-семестра. Правда непонятно, зачем им вообще про гит рассказывать...
inkelyad
00.00.0000 00:00Мыж не знаем контекста, может это ВУЗ международных языков
Которые, в таком случае, работают с разными текстами (переводов).
И переводить толпой народа какой-нибудь один текст без Version Control (и "code Review")-- это как-то сильно бестолково. Так что объяснять и пробовать разные VC -- им строго обязательно. Как и вообще любым людям, работа которых состоит в "что-то делать с текстом".
blueboar2
00.00.0000 00:00+1Я работал в таких системах. Они называются CAT (Computer Assisted Translation). И Code Review там по принципу Word'а - ты переводишь предложение, а рядом комментарии редактора - "Мне кажется тут надо вот так и так". И твой потом - "Исправлено".
rukhi7
00.00.0000 00:00В наших ВУЗ-ах изучение систем контроля версий? Да еще с лабораторными???
Вы шутите! Это в рамках какого курса может происходить?
Насколько я знаю специфику тематики обучения в наших ВУЗ-ах, даже просто разработка софта не определяется как какая то область научного знания, что уж говорить об инструментах которые нужны для разработки софта.
randomsimplenumber
00.00.0000 00:00+1В некоторых вузах лабораторные по некоторым предметам сдают в ихний универовский gitlab. Методичка присутствует. Не вижу в этом ничего плохого.
Так то студенту этот ваш git на 99.9% не нужен. Не делает он ни долгоиграющих ни групповых проектов. Но дать представление, чтобы он понимал, что оно и зачем оно может быть полезно - это правильно.
edo1h
00.00.0000 00:00+1на самом деле обучение в вузе должно включать в том числе и самостоятельный поиск информации.
update: надо было обновить комментарии перед отправкой, выше уже более развёрнуто высказали эту же мысль
Beryl_vl
00.00.0000 00:00Студенты в состоянии и пойти работать по специальности без участия ВУЗа, однако преподавателям необходимо что-нибудь рассказать. И лучше уж это будет git, чем то же GPSS
Kanut
00.00.0000 00:00Ложная дихотомия детектед :) Лучше пусть преподаватели что-то действительно полезное расскажут. Или просто не тратят своё и чужое время.
funca
00.00.0000 00:00Студенты уже не в состоянии сами найти какой-нибудь стартовый туториал по Git?
Вы исходите из позиции профессионального разработчика, для которого man rtfm это увлечение и хлеб.
Допускаю, что для каких-то студентов git просто очередная тема - одна из сотен - препятствие перед заветным словом "зачёт", которые проходятся с единственной мыслью "сдать и забыть".
Потом конечно это аукнется, кто пойдет работать по специальности. Но здесь и сейчас: папки, шмапки - какая разница? Важнее планы на вечер и ближайшее выходные.
Kanut
00.00.0000 00:00+1Я исхожу из позиции бывшего студента которому такие вот вещи никто не разжёвывал. А в мои времена ни поисковиков нормальных не было, ни гайдов, ни туториалов.
И как я уже писал выше: да, есть вещи которые для понимания требуют наличия каких-то знаний. Но базовые умения работы с Git к ним точно не относятся.
sshikov
00.00.0000 00:00+2>Вы исходите из позиции профессионального разработчика, для которого man rtfm это увлечение и хлеб.
Когда я был студентом — я поступал ровно так же, и в том числе и по этой причине мне сегодня неплохо платят. Не вижу причин, почему не рекомендовать студентам сегодня поступать так же — читать rtfm. Вообще всегда.
Chillingwilli
00.00.0000 00:00Могут и найти, просто что плохого в том, чтобы упростить им эту задачу?
Kanut
00.00.0000 00:00Задачу можно вообще до бесконечности упрощать. Например просто сразу выдать диплом и всё. Но вроде бы в этих самых вузах студентов учить должны. Или нет?
iig
00.00.0000 00:00Ну, например, можно отправить студента читать f***ing manual по git, python, матану, органической физике, сопромату, анатомии, чему ещё в этих ваших универах и ПТУ учат.. А чтобы не сильно упрощать - пусть сами найдут правильный мануал.
Kanut
00.00.0000 00:00+1И ещё раз: я согласен что есть вещи, которые надо объяснять и которые не понять, если не имеешь каких-то нужных знаний.
Умение пользоваться Git на базовом уровне к ним точно не относится.
iig
00.00.0000 00:00Умение пользоваться Git на базовом уровне к ним точно не относится.
В эту схему не укладываются следующие вещи:
-- статья сверху этих комментариев
-- мой опыт, который говорит, что люди предпочитают не читать мануалы ;) в том числе и по git.
-- отличная методичка-шпаргалка в коментариях внизу ;) Схоронил.
Так то на базовом уровне git и не нужен. Разве что лабу чтобы сдать. Чтобы git помогал решать какие-то практически полезные задачи - в него нужно нормально погрузиться. Хотя бы до уровня из шпаргалки ;).
Kanut
00.00.0000 00:00+1Статья сверху этих комментариев
Которая, если уж быть честным, вообще не понятно что делает на хабре...
мой опыт, который говорит, что люди предпочитают не читать мануалы ;) в том числе и по git.
Люди точно так же предпочитают хорошие оценки или даже зарплату за просто так получать. Но это не значит что оно так должно быть.
отличная методичка-шпаргалка в коментариях внизу ;) Схоронил.
Не вижу в каком месте она не укладывается.
Так то на базовом уровне git и не нужен.
Во первых нужно понимание что это такое, для чего оно вообще нужно и как им пользоваться. Потому что если мы говорим о айтишниках, то сложно будет мимо этого пройти в профессии.
А во вторых нужно учиться разбираться в таких вещах без посторонней помощи. Потому что точно так же сложно будет мимо этого пройти в профессии.
iig
00.00.0000 00:00Не вижу в каком месте она не укладывается.
При наличии мануала, отправлять читать который легко и приятно, кто-то не поленился и написал эти git flight rules.
Во первых нужно понимание что это такое, для чего оно вообще нужно и как им пользоваться.
Вот именно. Откуда должно появится это понимание? Прямой необходимости использовать git при учебе нет. Даже при изучении C++ или алгоритмов ;)
Kanut
00.00.0000 00:00При наличии мануала, отправлять читать который легко и приятно, кто-то не поленился и написал эти git flight rules.
Ну вот именно. Кто-то не поленился и выложил. Как мануал так и git flight rules. И кучу туториалов. И различных видео. И это всё совсем не сложно при желании найти.
Откуда должно появится это понимание?
Ваша "шпаргалка" имеет ссылку на книжку о Git на сайте самого Git. Там это вполне себе понятно написано.
Прямой необходимости использовать git при учебе нет.
Если необходимости нет, то и не надо. Тогда только не понятно зачем статья...
iig
00.00.0000 00:00+1это всё совсем не сложно при желании найти
Чтобы найти, нужно знать что искать. Вот допустим изучает студент pascal (python, C++..) по учебнику. В учебнике про git ничего нет. Почему бы не упростить ему задачу и не рассказать, что оно такое и зачем нужно?
не понятно зачем статья.
Да ;) Если чел дошел до commit-merge - подобных вопросов возникать не должно.
Kanut
00.00.0000 00:00Чтобы найти, нужно знать что искать.
Ну так студенту же дали как минимум информацию что речь идёт о "Git" и "репозитории". Этого вполне достаточно чтобы найти нужную информацию.
Почему бы не упростить ему задачу и не рассказать, что оно такое и зачем нужно?
В учебнике и про винду или линукс ничего нет. Это студентам тоже надо объяснять? Когда стоит начать прекращать ему всё разжёвывать? Когда он на пенсию пойдёт?
iig
00.00.0000 00:00В учебнике и про винду или линукс ничего нет.
Не умеешь запускать программы в windows (linux) - не пройдёшь курс по программированию в pascal. Не умеешь в git - ну и ладно, это очень сильно опциональное умение.
Когда стоит начать прекращать ему всё разжёвывать? Когда он на пенсию пойдёт?
Обучение - процесс бесконечный. Если есть возможность какие-то места этого процесса упростить - что в этом плохого?
Kanut
00.00.0000 00:00Не умеешь запускать программы в windows (linux) - не пройдёшь курс по программированию в pascal. Не умеешь в git
Значит не пройдёшь какой-то другой курс. Вообще не вижу разницы.
Обучение - процесс бесконечный. И кто-то должен бесконечно всё разжёвывать? Или стоит всё-таки уметь искать информацию и учиться самостоятельно?
iig
00.00.0000 00:00Значит не пройдёшь какой-то другой курс.
Какой ? ;) Что имеет в зависимостях git?
Kanut
00.00.0000 00:00Подозреваю что какие-то практические работы, которые надо сдавать в таком виде.
То есть не знаю как это выглядит в России в различных ВУЗах, а у нас сейчас так часто делают. И даже проверка частично или полностью автоматизирована.
iig
00.00.0000 00:00Подозреваю что какие-то практические работы, которые надо сдавать в таком виде.
Если есть формализованные требования к практическим работам - где-то рядом есть указания по выполнению этих самых работ ака методичка. И в ней доступным языком изложен необходимый минимум.
Kanut
00.00.0000 00:00И в ней доступным языком изложен необходимый минимум.
Например как правильно включать компьютер и пользоваться мышкой? :)
fobo
00.00.0000 00:00+12Если папка — это то, к чему мы все привыкли как пользователи компьютеров, то репозиторий — это что-то новое, что нужно создать, инициализировать. Сам по себе репозиторий без наших указаний не появляется.
если у вас папки появляются сами по себе, то для вас, скорее всего, есть плохие новости...
petropavel
00.00.0000 00:00+19Заголовок "Советы изучающим git". Содержание — как отличить репозиторий от папки.
Заголовок "Советы начинающим фотографам". Содержание — как отличить фотоаппарат от картошки.
edo1h
00.00.0000 00:00Содержание — как отличить фотоаппарат от картошки
скорее «как отличить пейзаж от фотографии»
понятия «папка» (ИМХО не самый популярное слово для обозначения директорий, во всяком случае среди русскоязычных пользователей git; ну да ладно) и «репозиторий» несколько разноплановые, если вуз учит отвечать на вопрос «я сейчас нахожусь в репозитории или в папке», значит что-то пошло не так
vconst
00.00.0000 00:00+1Понятие «папки» — это что из «русская виндовс». Так что, да — директории,. Хорошо бы ещё с пониманием, что фс это бд и все такое. Тогда и гит будет пониматься лучше
geher
00.00.0000 00:00+1Подкаталоги же! Ну и корневой каталог в нагрузку).
С лругой стороны, все чаще встречаю людей, для которых основной термин - папка (даже среди хороших специалистов). Тотальное длительное доминирование одной операционной системы все-таки сильно влияет на привычки.
И таки да, соглашусь, что студенту стоит понять, что не репозиторий или подкаталог, а репозиторий размещается в подкаталоге файловой системы (по крайней мере локальный).
Но если у студента оно уже "или", то концепция "фс есть специализированная бд" для него будет неподъемно сложной.
vconst
00.00.0000 00:00Если кто-то из студентов называет директории папками — ему надо остаться в академ. Ю нот преперед! /*голосом илидана*/
sergey-kuznetsov
00.00.0000 00:00Уже лет 20 не принято называть каталоги директориями. Используйте устоявшийся перевод, а не эту кальку с английского написания.
Папка — тоже нормальное слово. Его придумали когда появились графические интерфейсы и каталоги реально изображали в виде папок.
vconst
00.00.0000 00:00Графические интерфейсы, подражающие реальным физическим обьектам — придумали для людей максимально далеких от компьютеров.
«Ну вот, смотри, нажимаешь эту клавишу и появляется буква, как на печатающей машинке. А потом кладешь этот „документ“ вот в эту „папочку“. Все почти как ты привык, ничего страшного и сложного»
И перелетающие листочки из одной папочки в другую — тоже из этой оперы
Людям, понимающим происходящее на более низком уровне, эти условности из реальной жизни нафик не нужныKanut
00.00.0000 00:00Это зависит от ситуации. Иногда нажать кнопку или шорткат просто быстрее чем печатать команду.
vconst
00.00.0000 00:00Вы сейчас о чем-то своем поговорили? Тогда, почему в ответе на мой камент?
Kanut
00.00.0000 00:00Ну это же вы написали:
Людям, понимающим происходящее на более низком уровне, эти условности из реальной жизни нафик не нужны
И я с этим не согласен. Иногда и таким людям удобнее с графическим интерфейсом.
Кстати, а вы в интернете с командной строки сидите? Или всё-таки браузером пользуетесь? :)
vconst
00.00.0000 00:00Ну, вы продолжайте сами с собой разговаривать
Мне темы про микропластик было достаточно, чтобы понять — «тут не обьяснить»
saboteur_kiev
00.00.0000 00:00+1папка - нормальное название для GUI
Ибо в консоли ты make directory, а в GUI - create folder.
Вот каталог - это плохойперевод
drdead
00.00.0000 00:00+3А почему "русская виндовс"-то?
https://en.wikipedia.org/wiki/Directory_(computing)#Folder_metaphor
vconst
00.00.0000 00:00Потому что это для тех, кто боится всего непонятного и непривычного. Кому не только гит, а вообще что-то сложнее ворда знать не надо
geher
00.00.0000 00:00что-то сложнее ворда
Ворд - сложная контринтуитивная штука. Гит на порядки проще.
Впрочем, если глубоко не копать, то что гит, что ворд, все не просто, а очень просто. А если хочется совсем упростить, то поставьте tortoisegit, и будет вам счастье безмерной простоты. Или встроенными средствами IDE воспользуйтесь.
Iwanowsky
00.00.0000 00:00Если не создавать себе психологические барьеры в освоении чего-то нового (типа — ничего не понятно, не смогу разобраться, выглядит сложно и т.д.), то всё оказывается простым и понятным.
rutexd
00.00.0000 00:00+3Я извиняюсь, а это точно для студентов? Похоже на вопросы и ответы какого нибудь ученика 9-12 классов.
netricks
00.00.0000 00:00Студент первого курса и ученик выпускного класса — это считай одно и тоже.
Kanut
00.00.0000 00:00+3Вообще-то нет. Потому что далеко не все выпускники школы осиливают поступление в вуз да ещё и на айтишную специальность.
rutexd
00.00.0000 00:00В айтишной области - нет. Минимальное понимание что гит это программа а папка это папка - должно быть. Иначе - грош цена таким студентам.
sshikov
00.00.0000 00:00>Важно! Репозиторий отслеживает изменения во всех вложенных в него папках.
Я вот не уверен, что автор это сам понимает. Вот эта вот фраза из текста явно наводит на мысли, что репозиторий — это что-то активное, то есть в наличии некий сервис или демон, который «отслеживает изменения».
Koval97
00.00.0000 00:00-12Совет №0: Скачайте Кракен и навсегда забудьте про консольный GIT. Намного лет вперёд сэкономите себе кучу времени и нервов - поверьте моему опыту, я этого говна нахлебался, хватило на всю жизнь.
MiraclePtr
00.00.0000 00:00+4О, а вот и рубрика "вредные советы" подъехала. А вы точно разработчик?
Koval97
00.00.0000 00:00-2В отличие от вас системы контроля версий в работе использую для дела, а не для баловства! Консоль оставьте для секты консольщиков, а нормальный человек, зная что можно работать с визуальной формой, где всё наглядно и видно сразу что к чему относится, без всяких веб-форм и прочего говна - не будет в принципе использовать консоль, где и на практике применяются только две операции!
ShashkovS
00.00.0000 00:00+4ИМХО, самый главный совет — в любой непонятной ситуации см. сюда: 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
fobo
00.00.0000 00:00+1тот самый случай, когда комментарий лучше всей статьи. ради него я зашел почитать комментарии!
sergey-kuznetsov
00.00.0000 00:00+4Ключевая ошибка статьи в том, что рабочий каталог репозитория почему-то обозвали репозиторием. Это категорически не так.
Каждому студенту нужно знать чем отличается репозиторий от рабочего каталога. Рабочих каталогов может быть несколько и внутри одного из них может лежать репозиторий.
А бывают репозитории без рабочего каталога вовсе.
Гит на самом деле довольно прост, но к сожалению не интуитивен. Чтобы понять как работает гит, нужно обязательно выучить основные понятия, тогда не будет проблем. А если пытать только запомнить некоторые команды, то у вас ничего не получится. Вы будете как обезьяна вбивать заклинания в командную строку и не понимать что они делают на самом деле.
Andrey_Solomatin
Причина скорее всего в том, что гит это инструмент и с ним нужно учится работать, но в курс обучения это не включают. Вот и получается, решите эту простенькую задачку через два дня и заодно изучити базовый гит и что-нибудь еще.
Мы когда делали обучение, получили фидбэк о проблемах с гитом, поэтому включили в первое занятие небольшую часть по гиту и гитхабу. Правда не уверен, что это сильно помогло.
scoffs
У нас на 2-ом курсе в колледже преподают Git (именно команды, но и интерфейс тоже)
AllexIn
Проблема в том, что гит это мультимегакомбайн. Нужно прочитать книгу, чтобы начать понимать как он работает.
И, это плохой признак. Инструмент задача которого сводится к "принять файлы, отдать файлы" не должен требовать прочтения книги для работы.
funca
Что-то вы слишком упрощаете. Git предлагает решения проблемы управления версиями в распределенной системе. Это довольно навороченная тема даже со стороны науки. Передача файлов лишь технический момент.
PuerteMuerte
Git — это про хранение истории изменений и про синхронизацию совместной работы нескольких человек над одними файлами. Начинать надо с этого, а остальное уже внутренние детали реализации, погружаться в которые надо или не надо в зависимости от специализации.
Точно так же, как рассказывать про телефон надо с того, как по нему звонить, а не с разделения полосы частот и с гостевого регистра абонентов.
AllexIn
"Распределенная" системы с централизованными lfs и lockами.
Система до сих пор поддерживающая патчи передаваемые через email.
Гит это эволюционно разросшийся комбайн обросший костылями, к сожалению.
Гит - порождение unix модели, который противоречит этой модели.
Основа unix идеологии - инструменты должно хоршо делать узкоспециализированную задачу. А гит - монстр, который пытается удовлетворить всех. Из-за этого превратившийся в нечто плохо перевариваемое.
KvanTTT
А что конкретно монструозного есть в гит? По-моему он неплохо справляется со своей задачей и не делает ничего лишнего. Даже наоборот, мог бы побольше фич иметь.
Andrey_Solomatin
lfs это расширение гита, а не сам гит. У меня с ним никаких проблем нет, потому что я им не разу не пользовался.
Поддержка емейлов? Что-то не верится.
Гит это система, а не юникс приложение.
Насколько я знаю первая версия гита была очень сложная и приходилось писать много всего, для простых действий. То что вы видите сейчас это очень значительный прогресс.
Fedorkov
Файлов с diff-ом, не обязательно почтой. https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project#_patches_from_email
vconst
saboteur_kiev
По-моему вы слишком преувеличиваете.
Это достаточно простой инструмент, и совсем не нужно понимать как он работает внутри, чтобы пользоваться.
Если работать с гитом для себя - вообще достаточно получаса, чтобы разобраться.
В команде - подскажут и за день введут в курс.
Если же хочешь разобраться как работают GC, как хранятся объекты и как избегается их дублирование - тут да, надо немного колупнуть и в идеале сравнить с тем, как данные хранятся в CVS/SVN чтобы понимать к чему пришли SVC в принципе на сегодняшний день.
А вообще, было бы неплохо еще понимать разницу между SVC и Code Review, потому что у очень многих, наверное даже большинства, это в голове сливается в одно целое