Git branch - работа с ветками
HTML-код
- Опубликовано: 21 сен 2024
- 🎓 Бесплатный курс по языку Ruby: rubyrush.ru
💬 Чат для изучающих Ruby: t-do.ru/rubyrush
🚀 Интенсив по Ruby on Rails: bit.ly/2wr88QT
#Хороший_Программист_МК
------
git,
git ветки,
git работа с ветками,
git branch,
git merge,
git checkout,
git уроки
Крутое видео. Самое простое и доступное, что я видел.
До этого я познакомился с практикой на видосах Проргамысли Видеоуроки, а здесь отлично показана теория.
Уверен такое уже писали в комментариях но это самое понятное объяснение у вас дар объяснять, спасибо за урок
Вы молодцы парни. Четко и по делу
Вы вот прям просто охуенно объяснили то, что я не мог понять долгое время. Спасибо за крутой контент!
Спасибо за отзыв! :)
Лайк, интересный подход, мне по нрав))
Спасибо!
Лучшее объяснение! Спасибо ребят!
Лучшее видео по Git, что я видел за пару лет.
Спасибо, от души!
Парни у вас талант - очень понятно и легко объясняете
Спасибо за нетривиальное объяснение, чуть дополнил картину
пожалуй лучшее разъяснение из всех и уж тем более всяких лофтблогов и прочего г
Спасибо!
Объясняете понятно но вот музыка все портит. Зачем такой бит, мы же не на дискотеке)
ну раньше мне нравилось ))
Да, согласен. Отвлекает очень
Кто разбирается в githube / помогите пожалуйста мне. Мой вк - vk.com/faust231
Норм музыка
Да, а если в 1,5 слушать то вообще сложно всерьёз воспринимать)
Вообще под капотом git хранит полную версию файлового дерева в коммитах, а не "изменения". В видео распространенное заблуждение. На работу не влияет, но профессиональным разработчикам хорошо бы понимать.
Отчасти вы правы. Тут уже было в соседней ветке такое обсуждение. Не все так однозначно, гит очень хитро хранит свои данные.
Но для понимания новичка важно усвоить принцип "дельты" - изменения, которое накатывается каждым комитом.
@@goodprogrammer как раз новичку нужно как можно раньше осознать что коммит это не дельта, а слепок, иначе вам придется очень долго придумывать дельтой между чем и чем является merge-коммиты (в том числе merge-коммиты с более чем двумя родительскими коммитами).
best explanation ever! Biggest thank you guys!
Красавцы. Всё понятно и по полочкам
Смотрю урок и танцую под музыку)) класс
Когда ты Василий и не можешь перестать смеяться при просмотре этого видео.
Полезная информация. Спасибо!
Кто разбирается в githube / помогите пожалуйста мне. Мой вк - vk.com/faust231
Отличное видео! Спасибоу)
Спасибо за коммент!
Молодцы, спасибо вам за видео.
спс!
Спасибо, зачетное видео. Лайк, подписка.
Отличнейший урок. Правильная последовательность подачи материала.
Вообще по гиту какая-то засада. Очень трудно найти правильную последовательность изложения. Этот урок одна из жемчужин среди ... понятно чего :)
тут на канале много жемчужин ;)
Жемчужина, но с душком :)
@хороший программист, отличный курс! А можно вот в таком же формате, но про DevOps хотя бы с программистской точки зрения. Плачу деньги :-)
Отличный ролик, спасибо!
Спасибо 🙏
Спасибо вам за инфу, было всё понятно, только вставки из мультика подбешивали.
Крутой формат!
Очень понятно - безо всякой там хрени теоретической! Лайк)
Спасибо- очень хорошо и понятно объяснили
Спасибо!
Спасибо за видео.
Пожалуйста!
Спасибо
5:00
То ли я не понял автора, то ли автор не знает, что в гите нет никаких дельт патчей и прочего. Гит все хранит на уровне файлов. Если в файле изменяется хотя бы один байт, а файл весит 100 мегабайт, то в комит пойдут все 100 мегабайт. И размер репозитраия вырастит ровно на 100 мегабайт минус обьем который удастся сжать. В этом легко убедиться заглянув в саму папку .git
Это поведение и отличает гит от прочих систем управления версий. Гит простой как три копейки. Он не хранит никаких инкрементных патчей, а хранит сжатые файлы в элементарной структуре позволяющей на момент фиксации извлечь из нее те самые файлы. И все. Именно поэтому гит подходит только для работы с файлами которые хорошо жмуться. И не подходит совершенно для любой работы где присутствуют бинарные данные, которые должны лежать в репозитраии.
Только недавно стали появляться расширения, которые пытаются прикрутить к гиту функционал решающий эту проблему. Только это становится уже не гит, а как раз типичная система управления версиями типа сабверсион или меркуриал.
Популярность гита как раз была обеспечена его предельной простотой. Фактически гит, это просто утилита для снятия снапшотов вашей структуры файлов, с возможностью смешивать между собой эти снепшоты.
тоже хотел об этом написать, но затем решил проверить комментарии и увидел ваш. Вам +
Отлично. Я специально остановил видео на этом месте, чтобы почитать в комментариях, а увидел ли кто-нибудь этот сивокобылический бред автора?
+
@@-unity- Вот и как после такого можно дальше продолжать смотреть, а вдруг автор и дальше будет пургу гнать? Часто такое замечаю. Всё таки перед записью ролика нужно авторам лучше изучать мат-часть.
@@LyubichevAlex Ну вот потому я и не стал смотреть дальше. Поставил диз и написал комментарий.
ору с Василия)
Супер!
Спасибо, очень помогло
качественно
Лайк за попугая! ))
в консоли Git Bash (папки с репозиторием клонированным), выполнили команду vi pick_a_card.rb - появилось окно с типом карт, далее было не понятно как вбить команду git branch потому что в окне "utf 8" 1.2.3.4.5 - не давало возможности перейти на новую строку, все заканчивалось строкой: pick_a_card.rb [dos] (01:43 02/09/2019), почему так?
Потому что vi pick_a_card.rb -- открыть файл для редактриования в консольном редакторе vim. Не надо так, пользуйтесь другим консольным редактором из проводника. А потом продолжайте в консоли с того шага, как мы заканчиваем редактирование файла.
ОТЛИЧНО!
спс
Классное видео! Но насчёт консоли/gui - код всё равно пишется редактируется в IDE, неужели консоль без визуализации будет удобнее иде-шной надстройки для работы с гитом?
Кому как. Мне так уж точно консоль удобнее всего (Вадик).
супер!
Прекрасное видео.
Большое спасибо.
Но не слишком ли самонадеянно утверждать, что "опытные разработчики ВСЕГДА пользуются в GIt'e консолью"
Чем плох, по-вашему, плагин к Git'у в IDEA?
Или вы призываете пользоваться консолью Git'а непосредственно в IDEA?
Нет, не слишком, это факты.
Плагин ничем не плох.
Мы ни к чему не призываем, мы делимся опытом, а вы свой путь сами выбирайте ;)
@@goodprogrammer если используешь idea (или android studio) ее плагином git не стоит пользоваться? я только начинаю изучать.
@@s.n.9855 лучше в консоли освоить базовые команды сперва, а потом пользуйтесь чем хотите
Совет начинающим: поработайте в консоли, поймите, что к чему, потом если захотите, будете из интерфейса работать
@@goodprogrammer Спасибо за ответ! Еще интересно узнать Ваше мнение про выбор модели ветвления Git. Как правило я встречал описания для командной работы. Но даже там описывают, что существует миллион стратегий использования... Конечно, если ты в команде тебе "старшие товарищи" всегда подскажут какие у них там традиции ветвления Git. А вот что делать если человек индивидуально для себя что-то делает или учится изучая новое? В этой ситуации только после множества ошибок появится лучшая стратегия использования Git. По этой причине интересно, а есть ли что-то полезное на эту тему? если над проектом работает один человек. Какие практики ветвления, сохранения? Что не желательно делать? и т.д.
вот что первое вспомнил "о себе" (жизнь без Git, но надо менять!)
1) сейчас я ключевые версии храню в отдельных папках и это неправильно ;). Можно заменить коммитами в Git, тут вроде ясно. Всегда был страх нарушить то, что уже заработало перед внесением нового.
2) в основном коде я люблю пробовать небольшие кусочки кода. Часто бывает нашел полезное решение в интернете или хочется попробовать, понять новую функцию. Буквально 2-5-10 строк. Когда все заработало, выкидывать уже жалко. Еще думаешь, что забудешь про эту интересную фишку. Превращаешь этот фрагмент в комментарий. Пускай висит и напоминает, что можно так сделать. Плавно основной код обрастает такими "комментариями" которые нарушают читаемость и написание кода. Становится неудобно писать, просто каша из комментариев которые не по делу. и выкинуть жалко.
Как лучше организовать с точки зрения стратегии ветвления Git? Что делают профи в такой ситуации? Ясно что это все связано с ветками в Git. Но как лучше организовать? или это вообще неправильная стратегия разработки, и подобный код следует рубить? как тогда не забывать интересные приемы которые пригодятся в других случаях? Возможно есть трюки о которых я даже не догадываюсь.
PS. Прошу прощения за возможно глупые вопросы, программирование просто хобби. Наверное, тут надо целое видео снимать для таких как я )))
Отрывок из мультика прям огонь)))
:)
вижу название станции - ставлю лайк )
!понятно
Простите, я немного не понял ...
Вот я удалил в Git-е тестовую ветку. Она мне более не нужна. Далее, я прописываю команду:
$git push
Git выдаёт мне сообщение: Everything up-to-date
Ну, думаю окей. Захожу в GitHub, а моя тестовая ветка всё ещё существует.
Так и должно быть?
GitHub не удалит ветку, которая была удалена на локальном Git-е?
Спасибо!
GitHub ничего сам не удаляет, либо удалите её в веб-интерфейсе, либо напишите в локальной консоли (подключенной к github) так:
git push origin :branch_i_want_to_delete
Добрый день! 2:33 хотела узнать если хотим мержить feat на мастер,и если в это время кто то внес изменения в master,сначала мы должны актуализировать ветку feat с master?
А не должно ли быть конфликта при мердже? - у нас же изменения на обоих ветках были
Некоторые "конфликты" git сам разруливает, некоторые приходится руками
Отличное видео! А когда и зачем мержить из мастера в другую ветку?
Ну если в мастере что-то изменилось и вы хотите убедиться, что ваши изменения (в ветке) совместимы с мастером.
Если я сделал какой то шаблонный проект, от которого потом уже форкнулись целевые проекты... А потом, в этом корневом шаблонном проекте, я обнаруживаю какие то ошибки, недочеты, оптимизирую функционал..., то получается все ветки которые были созданы на раннем этапе, унаследовали набор багов первой версии шаблонного проекта.
Как исправить ситуацию?Закоммитить в корневом шаблоне исправления, а потом каждый форк смерджить с новой версией шаблона?
погуглите про git cherry pick
Сделать коммит в "корневом шаблоне", а потом утащить этот коммит во все другие ветки командой, про которую сказал Миша
полезное видео
А если я не хочу мержить. Создал новый бранч и работаю с ним день за днем, как же его, именно новый бранч, запушить на bitbucket или github ?
git push origin my_awesome_branch
Спасибо !!!
решать конфликт из консоли то еще удовольствие
главное, понимать, как это делать, а уж из консоли или нет -- кому как удобнее
А если при слиянии в ветку мастер побочной ветки в мастере были сделаны изменения, которых нет в побочной , например var = 1, а в побочной var =2, и оба эти изменения попали в мастер. Не будет ли это ломать прогу?
То будет конфликт и git не сделает коммит слияния, пока его не разрулить. Будет ли после этого работать программа, зависит отразработчика, который будет конфликт разуруливать. Если правильно разрулит, то должна.
в чем отличие git commit -am
git commit -m ? заранее спасибо
если файл уже ранее был добавлен в индекс и его снова изменили, то можно не писать git add file, можно написать git commit -am "Commit", для git commit -m "Commit", надо перед этим добавить индекс git add file
@@AleksandrGurin понял, спсибо
топ!
ruclips.net/video/SZARWakrCro/видео.html
Заметил ошибку. Гит не хранит дельты (патчи), гит хранит слепки.
git-scm.com/book/ru/v1/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git#Слепки-вместо-патчей
Вадим, спасибо за уточнение, в книге, которую Вы процитировали, во введении 9-й главы есть такие слова:
Так или иначе, в данной главе рассматриваются внутренние процессы Git'а и особенности его реализации. На мой взгляд, изучение этих вещей - это основа понимания того, насколько Git полезный и мощный инструмент. Хотя некоторые утверждают, что изложение этого материала может сбить новичков с толку и оказаться для них неоправданно сложным.
Вот и мы решили, что дотошно рассказывать, что на самом деле git хранит в коммитах слепки ВСЕЙ системы, но содержание только изменных файлов (с кучей огворок) - не самая лучшая идея. Мы сознательно упрощаем модели того, о чем рассказываем, чтобы новички могли их понять и не запутались.
Спасибо за объяснения, я заметил, что Михаил намеренно упрощает речь и говорит безграмотно, очевидно для упрощения понимания аудитории.
Я тоже не знаю стоит ли рассказывать новичкам всю правду про гит в рамках учебного курса, или давать ложную инфомрацию в виде упрощенной модели для понимания. С одной стороны жмут сроки на курсе, с другой стороны выпускник может остаться в неведении и наломать дров в будущем из-за неправильной модели. И исправлять ошибки новичка придется более опытному товарищу.
Видимо меня сильно задела ложь про способ хранения, из-за моего предыдущего опыта, много раз приходилось переубеждать коллег в способе хранения объктов и вытекающих из этого выводов. Вот и написал свой комментарий. В целом это видео годное для показа новичкам.
Вы тоже не до конца точны здесь.
stackoverflow.com/questions/8198105/how-does-git-store-files
Гит физически хранит дельты, но концептуально каждый комит хранит и указатели на весь текущий набор данных (слепок) и копии измененных файлов.
Ваши намеки на безграмотность тут неуместны. Конечно упрощаем для новичков, иногда очень сильно.
По поводу грамотности спорить не буду.
Но по поводу способа хранения гитом объектов вы ошибаетесь.
Цитирую:
Главное отличие Git'а от любых других СКВ (например, Subversion и ей подобных) - это то, как Git смотрит на свои данные. В принципе, большинство других систем хранит информацию как список изменений (патчей) для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени, как показано на рисунке 1-4. Git не хранит свои данные в таком виде (). Вместо этого Git считает хранимые данные набором слепков небольшой файловой системы. Каждый раз, когда вы фиксируете текущую версию проекта, Git, по сути, сохраняет слепок того, как выглядят все файлы проекта на текущий момент. Ради эффективности, если файл не менялся, Git не сохраняет файл снова, а делает ссылку на ранее сохранённый файл. То, как Git подходит к хранению данных, похоже на рисунок 1-5.
Вот здесь написано: git-scm.com/book/ru/v1/%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5-%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-Git
Вы опять про логический уровень.
В любом случае, нам кажется понятнее и удобнее для новичка именно показанная нами абстракция.
Так проще далее понять чери-пики и другие более сложные операции с ветками.
какая функция у DEV бранча... по моему он нафиг не нужен..
А почему клонировали не сам репозиторий, а его форк?
Потому что в общем случае вы не состоите в команде разработчиков на github и можете вносить правки только в fork на своё аккаунте
@@goodprogrammer То есть это для того, чтобы и мы могли повторять за Вами?
Консоль пугает начинающих разработчиков))
"Консоли бояться -- программированием не заниматься" с.
Сколько видел начинающих разработчиков (спойлер: сотни), никого консоль не пугала.
Люблю видосы без лишних отвлекающих кадров, где много инфы в единицу времени. Это видео не такое ((
Покажите пример "такого", будем знать к чему стремиться.
Что значит "взял коммит"?
Нельзя просто так взять и взять коммит!
пацаны а вирусы писать тяжело или в чём там особенность? Хотелось бы на эту тему что нибудь...
Не в курсе. А зачем Вам это? Неужели на вирусах можно много заработать? Поделитесь цифрами. Или Вам просто ради искусства?
Хороший программист Ради искусства,учу щас 3 языка,Pascall,Paython,C++.Проблемы только с JAVA.Такой мудрённый он.А про вирусологию почти ничего нет.Хотелось бы узнать как их код определяют анивирусы,на чём их строят вообще.
Музыка мешает реально. А так всё по теме, спасибо!
ну музыку не убрать уже
@@goodprogrammer возможно, совет пригодится для будущих видео)
@@lermos а в каких последних видео на канале мызука громко?
@@installero ну это первое видео, которое увидел на вашем канале, думаю, что дальше всё ок с этим ;)
👍
почему бы не пользоваться smart git?
Сами смотрите, но консолькой тоже надо уметь
@@goodprogrammer А то окна отключат? Зачем именно уметь? Вы же через консоль код не пишите и через консоль не компилируете? Почему в случае с Git все делать желательно через консоль?
Лол, лицо похож на игоря линка
это Игорь похож на Мишу, в лучшем случае
Ку
А ты не брат Игоря Линка случайно?
Кто такой Игорь Линк? :)
@@goodprogrammer ruclips.net/user/WorldGamesVK
псковский туториал
чего, простите? :)
4 дня смотрю видео про git, читаю мануал и всё равно ничего не понимаю
Как это ничего. Уверен, что-то же поняли? Поймите, что вы поняли и тогда станет ясно, что именно не понимаете. И напишите тут.
Музыка мешает(
По поводу консоли не согласен. Это полный бред. Давайте тогда и код писать и компилировать в консоли! А чё, удобней и быстрее же. А вот проблема отсутствия нормального GUI это действительно проблема.
А вы думаете, код в консоли никто не компилирует и не пишет?
@@goodprogrammer тоже больше консоль понравилась, хотя для поверхностной работы "лижбы было" установила soursetree, потом стала git разбирать и вот куда интереснее и понятнее сразу что куда зачем.
Я пишу код в nvim, намного удобнее любых gui редакторов.
Дело вкуса, не нужно навязывать или критиковать, не подумав о других братьях-разработчиках :)
Как же мерзко слышать этот англицизм.
Хоть кто-то написал! Согласен. Смёржить бранчи, пофиксить баг, задеплоить фичу... ужас! Есть же для всего этого русские слова. Причём автор их знает, потому что иногда у него пробивается русский текст.
Очень плахая музыка
:))))
все четко и ясно, но музыка будто тебя в 90-ые кидает, кажется ща кто то тиктоник начнет танцевать
Музон кромковато
мы больше так не будем )
Ребят, музыка сильно мешает-вообще ничего воспринимать так не могу
Угу, в комментариях уже сказали. Сделать потише после залития ролика на youtube увы, нельзя.
Спасибо, очень помогло
Спасибо
Ку
Отличное видео! Спасибо!
Пожалуйста!