Здравствуйте, LaptevVV, Вы писали:
LVV>https://githowto.com/ru LVV>Рекомендую. LVV>С самого начала.
А еще есть такая штука как Sourcetree или TortoiseGit или GitHub Client — которые избавляют ваш разум от необходимости держать в голове лишний мусор в виде консольных команд. Просто сидишь и на кнопочки нажимаешь вместо этого.
DP>А чем она хорошо? Почему именно ее? Какие плюсы в сравнении с оригинальным handbook-ом (https://git-scm.com/book/en/v2/)? Почему именно на русском?
Студентов учить.
1-2 курс, первый раз в первый класс...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
S>А еще есть такая штука как Sourcetree или TortoiseGit или GitHub Client — которые избавляют ваш разум от необходимости держать в голове лишний мусор в виде консольных команд. Просто сидишь и на кнопочки нажимаешь вместо этого.
Командная строка — для настоящих программистов...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
LVV>> Командная строка — для настоящих программистов ЭФ>Это догматизм. Нейроимпланты — вот передний край науки.
Это не догматизм, а славные традиции пионеров программирования!
Понимать надо!
Программирование — не наука.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
DP>>А чем она хорошо? Почему именно ее? Какие плюсы в сравнении с оригинальным handbook-ом (https://git-scm.com/book/en/v2/)? Почему именно на русском? LVV>Студентов учить. LVV>1-2 курс, первый раз в первый класс...
Так а чего там учить-то? 1 лекция + 1, ну максимум 2 практических занятия за глаза хватит:
— рассказать что такое система контроля версий и зачем нужна
— какие бывают
— основные команды гита
По любому для начала даже работы хватит понимая базовых вещей:
— три состояния
— локальный/удаленный репозитории
— пулл/пуш
— коммит/чекаут
— ребейз
— MR/PR
— поработать с GitLab+GitHub (ну ладно-ладно, тут как раз второе практическое занятие подойдет)
(опционально и полезно)
— git flow vs. GitHub flow vs. GitLab flow (супер статья, которой к сожалению не осталось на оф. сайте, но вот завалялась тут https://gitlab.cn/docs/14.0/ee/topics/gitlab_flow.html)
— правила оформления коммитов – вот это я бы обязательно каждому студенту, который планирует заниматься разработкой, показывал и заставлял как минимум прочитать, а лучше сразу же начать применять (https://cbea.ms/git-commit/)
— такое еще можно, но это прям advanced (https://www.conventionalcommits.org/en/v1.0.0/)
LVV>>Студентов учить. LVV>>1-2 курс, первый раз в первый класс... M>Учат ли студентов другим системам контроля версий (или хотя бы истории их развития)?
К сожалению, на первом курсе сейчас не учат
Но на 2-м вот прямо сейчас все лабы в гитхабе.
И соответственно, отвечаем на все вопросы по гиту и гитхабу.
И нужные книжки/сайты показываем.
Но специальных лекций не ведем. Видосы есть в сети.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
DP>>>А чем она хорошо? Почему именно ее? Какие плюсы в сравнении с оригинальным handbook-ом (https://git-scm.com/book/en/v2/)? Почему именно на русском? LVV>>Студентов учить. LVV>>1-2 курс, первый раз в первый класс... DP>Так а чего там учить-то? 1 лекция + 1, ну максимум 2 практических занятия за глаза хватит:
Не судите по себе.
Студенты разные.
Например, один перец сегодня вопрос задал: а нафига из командлной строки, если можно по кнопочкам жать ?
Лекции мы не читаем.
Для этого есть как раз githowto
И видосы в сети.
А лабы все в гитхабе.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Shmj, Вы писали:
S>А еще есть такая штука как Sourcetree или TortoiseGit или GitHub Client — которые избавляют ваш разум от необходимости держать в голове лишний мусор в виде консольных команд. Просто сидишь и на кнопочки нажимаешь вместо этого.
А потом у тебя ломается репа, и ты бежишь за помощью к тому, кто освоил командную строку...
Здравствуйте, DiPaolo, Вы писали:
DP>- правила оформления коммитов – вот это я бы обязательно каждому студенту, который планирует заниматься разработкой, показывал и заставлял как минимум прочитать, а лучше сразу же начать применять (https://cbea.ms/git-commit/)
Оформлению научить легко, а вот научить членораздельно описывать что и зачем сделано — уже намного сложнее. На практике с этим бывают проблымы и у программистов с солидным опытом. Наверное, это какой-то совершенно отдельный навык.
DP>— такое еще можно, но это прям advanced (https://www.conventionalcommits.org/en/v1.0.0/)
В корне не согласен. Scope должен описывать логическую единуцу в проекте, чтобы релевантные коммиты легче искать было ("LibA", "CMake", "CI"). Префиксы в виде fix или feature вообще никак не помогает при решении проблем с использованием истории, т.к. при просмотре истории не важно как автор классифицировал изменение (отсутствие какой-то фичи это баг или нет?). Ссылка на bug, feature request, task или что-то подобное в любом случае должно быть или в PR или в коммите.
Здравствуйте, DiPaolo, Вы писали:
LVV>>https://githowto.com/ru LVV>>Рекомендую. LVV>>С самого начала.
DP>А чем она хорошо? Почему именно ее? Какие плюсы в сравнении с оригинальным handbook-ом (https://git-scm.com/book/en/v2/)?
Я учился на этом оригинальном handbook'е, он ужасен.
Впрочем, https://githowto.com/ru тоже не прекрасен, в частности мало иллюстраций объясняющих происходящие.
DP>Почему именно на русском?
А школьники нынче легко читают на английском?
Pzz>А потом у тебя ломается репа, и ты бежишь за помощью к тому, кто освоил командную строку...
Но ведь разрабочики вполне работают с другими VCS (subversion например) через GUI, и ничего обычно не ломается, да ещё так чтобы только из командной строки можно было поправить.
В чем причина? Git плохой, GUI плохой?
