Git: как правильно использовать?
Vložit
- čas přidán 28. 07. 2024
- Сегодня разберём, как правильно, профессионально использовать GIT.
Курсы для новичков:
JAVA - bit.ly/3eVUaLo
JAVA Start - bit.ly/2AsTY7q
Инструментарий JAVA - bit.ly/3ePZ0tz
Automation QA (Java) - bit.ly/38qW2cK
ANDROID - bit.ly/38qWebY
C#/.NET - bit.ly/3eXZvSg
C# START - bit.ly/3dW2r0C
PYTHON - bit.ly/3dUT5lB
FRONT-END - bit.ly/2ZtXsz6
WORDPRESS Developer - bit.ly/3eVsyWM
SALESFORCE Developer - bit.ly/31DuNKz
UI/UX дизайн - bit.ly/3e1KduN
Project management - bit.ly/38opq3c
Обучение на проекте - bit.ly/3eXFxHp
Продвинутые курсы для состоявшихся девелоперов:
GRASP and GoF Design patterns - bit.ly/2BXZMWQ
Enterprise patterns - bit.ly/2NSLVDQ
Сайт Foxminded: bit.ly/3ijDNuh
Foxminded в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Foxminded в VK: foxminded
Мой Telegram: t.me/nemchinskiyOnBusiness
Мой блог: www.nemchinsky.me
0:00 - приветствие Сергея Немчинского
0:32 - на чем акцентировать внимание новичку при обучении программированию
3:22 - как используются системы контроля версий (и Git, в частности) в реальной работе
6:05 - что действительно важно, стандарты в команде
Мне кажется, название не соответствует содержанию.
Да, у меня тоже есть такое ощущение...
Вам не кажется
А еще он слишком распыляется на "мысли не по теме"
А тут есть содержание? 🤣
как и любой его видос
В случае пожара:
- git commit -a
- git push
- Покинуть помещение
git commit -a -m"#"
😂
git push -f - ибо наше самое важное
А если конфликты будут?
Класс! Распечатаю и повешу в рамочку у входа)
Юзеры: Как пользоваться гитом?
Немчинский: Пользуйтесь как хотите!
Пользуйтесь как хотите! Главное пользуйтесь правильно.
трепло, да и только.
😂
Ожидал, что речь пойдет про практики того как строится сам репозиторий - merge/rebase, правила формирования master/develop/feature/release веток.
...написал я посмотрев 70% видео и понял что об этом и есть оставшиеся 30% :) Было бы интересно послушать о том, как именно эти практики формируются в команде, какие стандарты для каких команд подходят и в каких случаях стоит инициировать изменение этих стандартов в ту или иную сторону (например, в случае когда команда постепенно увеличивается в количестве начиная с 1 человека)
Как скажет начальник так и будет. Если ты будешь начальником, то сам придумаешь эти практики как тебе удобно. Я обычно работаю так: для личных проектов (1 человек -- я) используется одна ветвь. При работе в команде - все текущие коммиты в master pull request'ом из feature branch или личного master'а разработчика, релизы периодически ответвляются от мастера, фиксы в релизные бранчи сначала коммитом в мастер, потом cherry pick. Более сложная структура с stable/developer ветками или более замороченным ветвлением, как показывает мой опыт, ни к чему хорошему не приводит.
@@mormeoi > Если ты будешь начальником, то сам придумаешь эти практики как тебе удобно - так ведь надо придумывать не так чтобы мне было удобно, а так чтобы было удобно всей команде. Я то не начальник, но на одной из прошлых работ была именно такая ситуация, когда я начинал проект один и постепенно размер команды увеличился до 5 человек, и приходилось балансировать между функциональностью и удобством использования стандарта управления ветками
Ох, ë, теперь я окончательно запутался
Ну наконец-то сменили фон! Вот этот очень приятный!)
Согласен) Темный фон просто радость глаз ))
точно, предыдущие два были странными
Этот в цвет кружки просто брали.
и первую фразу складно произнёс 👍🏻
Ни раз не обратил внимание на фон. Мне больше контент интересен. Можно видео выключить оставить звук.
как -то совсем ни о чём... больше поговорили про "при помощи чего коммитить" а не про правильность работы с гитом, как будто "вот вам анонс, а подробнее когда ни будь расскажу"
Есть алгоритмы которые мастхев при командной работе, например: правила коздания рабочих веток что бы потом было меньше конфликтов, когда нужно обновлять рабочую ветку, куда пушить и куда делать ПР и много других мелочей которые многие не делают только по тому что вообще пользуются только мастером, я уже молчу про форки... но Сергей о них даже не заикнулся.
по поводу работы с GITом через IDE: через ИДЕшку удобно коммитить и проверять что именно попадает в коммит, но если нужно сделать что-то больше: например решить кофликт при ребейзе или мерже или ешё что похуже - то ТОЛЬКО КОНСОЛЬ
кому интересно как начать работать с ГИТом есть неплохая серия простых видео czcams.com/video/9d5bJc8o7MA/video.html
@@LeoMrakobes Я сам люблю консольный гит, но резолвить конфликты.. гуи предоставляют шикарный флоу
@@dmytro_dd согласен, в идеи удобный механизм разрешения конфликтов
Вау, вот этот фон супер!
И стол, и кружка на месте - шикардос одним словом)
Фон - check,
Стол - check,
Кружка - check.
И ведущего по-прежнему зовут Сергей Немчинский!
А мне лиса вязаная зашла)))) Помимо всего видоса)))
Скоро появится еще серебряная кнопка на заднем фоне
сегодня фон украли 🙂
Мне показалось, что тема называется не верно. Нужно было назвать как-то так: "Git: какие инструменты использовать". Вы ничего не сказали о том, как правильно использовать Git: не привели ни одного примера. Ожидалось что будет раскрыта тема о том, при каких условиях мерджить в master, какую стратегию использовать при втягивании кода в свою ветку (merge, rebase) и т.п. "Ну Вы поняли" (с) Немчинский ;)
Лисичка hand-made - зачетная ;)
С каждым разом, всё лучше
Спасибо, Сергей!)
Спасибо за контент.
Сергей, всё супер! всё доходчиво объяснил! Как всегда☝️😃
Сделайте пожалуйста видео о требованиях к миддлу на джаве. Какие задачи самостоятельно должен выполнять миддл. Что должен знать. Какой должен быть опыт
Ожидал услышать про Git Flow и другие методологии. Увы =(
Почти 100к подписчиков)
Согласен. Этот фон очень приятный, и картинка хорошая. Просьба рассказать о функциональном программировании в java, stream. Спасибо. Лайк
какую редакцию linux посоветуете для начинающего программиста?
Люблю темную тему)
Я как новичок мало что понимаю в подобных видео, но слушать интересно)
Avazart ;) да спешите все хелловорды на гит выкладывать ;) хотя конечно начало хорошее но человек на начальной стадии не особо понимает зачем ему гит зачем эти лишние действия
@@avazart614 ничего я пока не выкладываю, я слушаю все видео подряд, может что интересное для себя подчеркну из них)
Люди насчет Линукса, не переживайте. Я сейчас пишу эот комментарий сидя на ютубе с Убунту, это не так уж страшно. Графический интерфей беднее Винды, но пользоваться можно. А терминал, так как терминал использует язык bash, большинство комманд для разных Юникс лайк систем похожи, основные команды по типу создания файлов и запуск программ можно освоить меньше чем за час. А всё остальное можно найти в интернете. Просто пишите то что вам надо и делать и приписывайте "терминал Убунту (или другой дистрибутив Линукса" и всё, это не сложно правда. Я Линукс ставил не сам, нам в универе дали ноутбуки где он уже стоял, но уже с этой целью можно обратиться к специалисту, не думаю что это будет стоить много или же попробовать установить самим. А потом вы поймете, что многие вещи реально удобнее устанавливать и выгружать в интернет (допустим в тот же гит) через терминал. Я даже на винде иногда пользуюсь Гит Башем заместо стандартной консоли (Повер шелл) от Винды (Майкрософта)
Набрёл, подписался. Чашка - зачет.
Спасибо за информацию очень интересно и познавательно знать.
Думаю имелось ввиду скорее такие вещи как лучше пушить после каждого коммитам или в конце работы, обязательно ли сквошить коммиты, делать ли ребейз при мерже. Т.е. результат по коду может быть тот же, а история разной и насколько это важно.
Первый раз в жизни я увидел ролик, который автор запилил для людей, которым ютуб подсовывает ролики по ошибке! :))))))))))))))))
Сергей, очень нравятся ваши видео. Спасибо.
Было бы очень интересно ваше мнение о буткемпах. Оправдана ли их стоимость (как правило - это около 10к € за 3 месяца).
Вот такой вопрос, в надежде, что увидите и, может, разберете:
Как перейти из состояния "могу написать код" , в состояние "могу написать приложение"?
В чем суть? Учить архитектуру приложений? Еще что?
Как для примера: изучаю с++, могу открыть main.cрр и алгоритм написать, шахматы какие нибудь и т.д. , решить кодом поставленную задачу, в общем. А открываю установленные на компе игры, приложения- там чето какие то сотни папок, сотни файлов, различных форматов. И ничего не понятно. Нет, ну, то есть, код то понятен, если вчитаться в исходники, но вот сам принцип разбиения на файлы, папки, какого то...построения, архитектуры(?) приложений
Как в этом разобраться?
вроде все понятно, но интересен вот какой вопрос: насколько большими должны быть коммиты, и насколько часто их нужно делать
Добрый день, надеюсь вопросы сюда надо задавать))
Я довольно таки далек от сферы ИТ, и программирования, однако ввиду сложившихся обстоятельств хочу сменить профессию, программирование стало интересно, и я сейчас начал изучать, и немного выработал понимание того что это вообще такое. Вопрос следующий как можно проверить свой скил? На сколько я хороший или плохой программист, что бы для себя понять готов ли я идти и работать программистом?
Здравствуйте, у меня такой интересный вопрос. Я учусь на инженера по автоматизации и у нас в институте очень мало программирования, поэтому я сам занялся этим. Сейчас изучаю основы С++. Я сам читал что автоматизированные системы могут писаться на разных языках, не только на этом, но ещё и на Java, и на Python и на других языках. Так вот, у меня такой вопрос, какие языки чаще всего используются в АСУ ТП и в робототехнике?
C++ основа основ. Выучишь его будешь понимать все остальные языки. Про АСУ: Не совсем понятно что именно ты собираешься программировать в ней. Если АСУ разбить на четыре уровня:
1. Датчики и управляющие устройства (клапана, реле и т.д).
2. Контроллер для сбора и обработки информации с 1го уровня.
3. Сервер где находится логика АСУ
4. ПО для администрирования и диспетчирезации.
Программировать можно 2,3,4 уровень. Если масштаб автоматизации большой, обычно там готовые решения и максимум 4й уровень. Может быть что система нужна уникальная и тогда будет программирование 3го уровня. 2й уровень только на производстве. При малой автоматизации можно все самому. В итоге на 2м уровне зависит от чипа в контроллере. На 3м от операционной системы на сервере (windows, linux). На 4м все на чем можно GUI писать. Тут больше вопрос про протоколы передачи данных. Почитай например про modbus.
Ps. Вообще как по мне все давно уже придумано и в основном все занимаются только интеграцией и настройкой и только на заводе изготавителе програмно-аппартного продукта можно попрограмировать. Сам никогда этим не занимался могу ошибаться :-(
А я уже дошёл до 60 ролика по плэйлисту «Скринкаст по Git», я опоздал с просмотром этогг ролика, вы меня простите, но теперь я терминальщик.
4:45 ну блін мушу з вами не погодитись консоль все ж найкраще буде використовувати.
я не раз фіксив за людьми, то що вони наробили через ide.
проблема в тому, що є багато моментів, які не можливо зробити через ide-плагіни і в нестандартній ситуації людина боїться писати команди через консоль. це по перше.
по друге в розробника, який юзає інтерфейсні речі часто не має розуміння того, що він робить. він натиснув кнопку і відбулась магія (при чому не завжди та яку очікував розробник)
ну і третє через консоль банально швидше (плюс налаштований vim це взагалі просто песня)
і ще один плюс туторіалів і відповідей на stackoverflow і подібних буде в рази більше ніж в будь-якому gui-інструменту
p.s. в самого був випадок, коли вся тіма сиділа через php/webstorm і gui інструментами користувалась. але через деякий час, коли побачили наскільки в консолі зручніше самі перейшли на консоль.
Согласен, ни раз наблюдал, как банальный stash/rebase/merge приводил к тому, как уходил час на решение проблемы, которой бы не было, если бы разработчик выполнил эти операции через консоль.
Люди які використовують консоль частіше роблять помилки. У нас і в мастер пушили і при мержі затирали зміни інших. Просто тому що ти не бачиш що ти робиш, де мастер і що в нього вмержили. Звичайно через пару років кількість помилок зменшується, але вони все одно залишаються
Если у кого-то не хватает понимания что происходит и процесс построен на "и тут дальше магия" то совершенно неважно используется консоль или gui, а если вы верите что магия консоли более могучая, потому что вместо нажатия одной кнопки нужно написать заклинание восьмого уровня в три команды и по семь ключей к каждой, то у меня для вас плохие новости.
В случае с git GUI - это просто надстройка над консолью, если не заниматься мрачным велосипедированием а пилить по гит воркфловам то "стандартных" плагинов для IDE или gui-тулов хватает для примерно 100% кейсов.
@@jirikropocev9911 ну по перше коли я писав gui-інтрументи, то я мав на увазі такі інструменти як SourceTree, TortoiseGit і т.д + палагіни під IDE. git GUI я взагалі не розглядав тому що для мене це "тихий ужас", що дизайн, що функціонал (особиста суб'єктивна думка).
по друге цитую "заклинание восьмого уровня в три команды и по семь ключей к каждой" в такому випадку особливо, якщо я використовую цю команду часто я просто створюю аліас. і взагалі "git checkout dev" це реально довго писати я налаштував аліаси і тепер пишу "git co dev". а можна взагалі ще коротше "gco dev". замість "git log --pretty=format:'%h %ad | %s%d [%an]' --graph --date=short" пишу "git hist".
по третє щодо "IDE или gui-тулов хватает для примерно 100% кейсов", якщо всі ваші дії обмежені лише командами add, commit, checkout, merge, push, pull тоді так справді всі 100% покрито (а ну іще плюс log і diff). але наприклад такі речі як submodule, bundle, multiple merge (останнє використовував лише кілька раз, але всеодно приємно, що можна однією командою зіляти 5-10 віток, хоча можна і більше, замість того, щоб 10 раз зливати по одній вітці) та інші.
ще один випадок був, коли мені потрібно було перевірити коміт і я не мав доступу до компютера, то я зайшов з консолі на андроід і все швидко підправив. так є клієнти для андроід, але мені той додаток був потрібний 1.5 раз за все життя. так навіщо мені розбиратися в тому додатку (дизайні), що й куди, коли можна зайти зі знайомої консолі? питання риторичне.
p.s. я не хейчу gui-інструменти, як те що не потрібно. сам інколи для того, щоб переглянути історію комітів і швидко перейтися по історії використовую GitKraken. але це не є і не буде для мене особисто основним інструментом для роботи.
Белая тема... хоть в чем-то я на Вас похож ))
Минус видео в том что просто вода,если бы вы на практике показывали это было бы замечательно!Спасибо!
вот теперь в кадре всё более менее нормально. а содержание видоса помоему подкачало.. вопрос из заголовка нераскрытым остался.. имхо
скоро 100к подписчиков
Предложение: т.к. в видео упоминается очень много названий программ, предлагаю показать их названия текстом в видео. Я конечно люблю пересматривать Немчинского, но не одну-две секунды по несколько раз))
Хм, а название темы правильно выбрали?
Когда тебе нужно подключиться к удаленной ноде, где есть только шелл, ты тоже будешь через IDEшку гит использовать? Или думаешь, что начинающим программистам это не пригодится?
Вот правильно сказано : есть любимый инструмент, который работает пользуйтесь им!
Так набагато краще. Я про фон :)
Добрый день, а расскажите про текстовые консольные редакторы и что новичку выбрать.....?vim или vi или nano или Emacs???????? Спасибо в интернете почему то не получилось найти толковое объяснение...
а зачем?
@@SergeyNemchinskiy Что бы уметь пользоваться разными инструментами и узнать возможности терминальных редакторов, почему так называються и что могут предостваить они
Здравствуйте. Пожалуйста Сергей, сделайте видео сравнения Java и Go. Да у вас есть видео про Го, но сейчас вы начали делать сравнения, и так как Голэнг кличат убийцей Джава и будущем Серверного программирования, очень интересно было бы послушать ваше мненипе об этом.
Дуже дякую!
ламповость зашкаливает
8 минут звиздобольства ни о чем. Гениально! 🤣
Я думаю, что всё-таки как код пропадает в репозиторий тоже важно. Например мы пришли к выводу, что пропитан комиты мы будем только в свои личные ветки, а в общие, даже и не закрытые всегда через pull request, даже когда не требуется обязательное подтверждение от начальника, сам себя approv-ишь. Есть в pull request-ах что-то дисциплинирующее.
Сделай видео на тему "видеоигры в жизни программиста".
Как буд-то все на виндовсе ... а когда начинаешь с линукса а вин как вспомогательная ... никаких проблем :)
Шикарно, Спасибо)
Эклипс - конечно жесть )))
Лучший вариант вщять линуху и учить первым языком си. Балдеж
Спасибо за видео если можно снимайте видео про мобильную игру под Android и что нужно знать чтобы стать разработчиком мобильных игр под андроид!!!Please!!!
Прямо по Фрейду:
Из видео узнал, что я извращенец - захотел покрыть первичными половыми признаками :)))))
Расскажи про серитификации от оракла по java и SQL. Насколько это сложно, стоит ли усилий относительно прироста к ЗП с них.
Хороший фон
Я правильно понимаю, что git это сторонний сайт в интернете? Т.е. не инструмент, который разворачивается локально?
якщо коротко
git - порно
github - pornhub
4:50- когда пользовался IDE - было дело косячил.
когла TL заставил пересесть на консоль - косячить перестал. Ну и начал понимать работу гита.
Лай конечно. Но всё же, пару примерных схем, для примера, можно бы было и навести. Ну хотя бы, как в вашем Foxminded работают с Гитом.
Линукс поставил только из-за программирования и не мучался совсем, привык к нему быстро, и мне он больше понравился чем виндовс.
а со скольки лет наступает этот "достаточно большой стаж"? :)
Ну как по мне, было бы неплохо знать именно консольные команды гита. Потом можно хоть откуда работать. В идее есть консолька, я обычно ее юзаю для работы с vcs. Может только мержу средствами идеи - там сразу открывается conflict resolver.
Видел на ютубе дофига туториалов по гиту. И чет во всех, которые видел, рассказывают только, грубо говоря, про add, commit, push, clone... Когда на первой работе был гит, то там дофига всего еще было. Как минимум изменение веток - squash коммитов в один, удаление/исправление коммитов и т.д. Плюс еще разрабатывали не через merge, а через rebase. Этого ничего я не знал и приходилось с нуля самому все изучать. Странно, что обычно в туториалах такого не рассказывают.
Потому-что "туторилы" как и впрочем и все 99% обучающие материалы, дают только базу.
Обычно запоминаешь 4-5 основных команд гита, остальное решается распечатыванием и приклеиванием рядом с монитором git cheat sheet
@@mormeoi шпаргалка не нужна по сути. Стоит поюзать 2-3 раза эти команды, и они уже автоматически запоминаются.
туторіал це лише вступ в технологію, основа. хороший туторіал пояснює основні принципи роботи технології. далі документація, статті, форуми кінець кінцем
@@gaben-agent Не запоминаются. Эти редкие команды юзаются 1 раз в месяц, не чаще.
Мне кажется, новичкам не хватает понимания важности описания коммитов, которые должна давать понимание не только что сделано, но и зачем, а для понимания важности этого нужно знать про git blame, например
А почему, всё таки, eclipse??? Понятно, что дело вкуса, но всё таки.
Такие простые истины. Хотя за всем этим скрываются набитые шишки и мудрость. Спасибо вам, благодаря вашим советам я в айти сфере кручусь))))
но если ты только изучаешь гит, то лучше все делать через шелл (как и с изучением ЯП)
Чуть-чуть о том как дествительно "правильно использовать git" начинается здесь 6:20. Остальное - "чистая вкусовщина". И вообще это видео не о git. А о том, что в каждой IDE есть интеграция git.
То есть получается, если я использую теримнальную версию того же Git (которая так и называется) и для работы с БД использую специально для этого созданную професииональную программу, а IDE использую только по назначению (для написания кода естесственно), то я теперь уже "извращенец". И с какого момента все эти стандарты поменялись?
Когда я искал работу, везде и все на всяких семинарах, в один голос твердили "если вы работатете с git из IDE - заканчиваете это дело, работайте только из терминала!". Хороший совет. И что в этом плохого? Лично мне до сих пор стремно сделать коммит или, того хуже, какойнибуть откат из IDE. Набил шишек. Спасибо. Не надо.
Хз....года 4 точно работаю с гитом из идеи. Никаких ситуаций когда бы мне нужно было плотно работать с терминала я не припоминаю. Да и удобно...же...можно легко всякие ветки между собой сравнивать, перетягивать код из одной в другую например....
Ссылаться на Вас?
Ссылка на авторитет не является доказательством
Когда уже сотка подписоты будет, контент уже реально топчик
Рекомендую почитать книги Столярова "Введение в профессию. Азы программирования."
Он же там как раз и предлагает садиться на линукс или забыть, лел
Согласен, книжки Столярова прекрасны. Он постепенно вводит читателя в тему, шаг за шагом так сказать. В первом томе дает всю необходимую информацию по линуксу. ИМХО стоит с линуксом покопаться поглубже и освоить текстовый редактор vim, и можно программировать до посинения.
Я хочу стать инженером кибербезопасности. Какие языки мне учить? Пожалуйста ответьте.
Через две недели у нас будет стрим с руководителем компании по безопасности. Она расскажет
@@SergeyNemchinskiy Спасибо.
Давным давно, когда земной шарик был ещё тепленьким...
Я не понял тезиса, что программа не запускается из-за линукса. Вы там EXE-шники создаете чтоли?
нет пытается записать файл в 'c:\project\com\'
и много другого, например что COn Con CON con это 4 разные файла
Многое узнал из видео. Ещё надо было добавить, что вода мокрая.
Блин, придётся переучиваться на Git GUI
>Управлять гитом через универсальные команды, запомнив 5 слов: clone, push, add commit, checkout - извращение
>Привязывать себя к конкретному ide/плагину с gui для гита - не извращение
Прохраммируете небось тоже мышкой?
У вас много отсылок про то, как может быть в командах, компаниях и т.д., а тут первый раз упоминается, правда вскользь, про собственно командную работу. Это, наверное, для начинающих самая большая проблема - они не знают зачем "так" делать то или иное действие. Для джуна это скорее обряд, непонятные требования или самодурство руководства, нежели осознание что с программным продуктом работают люди. Работают в разных направлениях и с разными аспектами. В этом понимании заключается значимая часть стоимости сотрудника. Да хоть ты победитель всех олимпиад по программированию, я предпочту адекватного человека. Такие дела...
вывод: сириезли братцы юзайте гит. короче ап ту ю пацаны...камон!
а теперь топ команда для джуна (по мнению джуна)
git push --force-with-lease
При ребейсах без форса никуда
Старорежимные програмиисты любят темно синие темы. Тубо си и нортон/волков коммандер были так покрашены
Да!
git и другие системы контроля версий очень важный и, главное, ответсвенный скил
поломать своим комитом код == 99% увольнение для новичка.
если новичок написал плохой код, об этом будет знать толоко code reviewer,
а поломаный комит - будут знать все
Я не очень понял, а каким образом он это сделает, если в нормальных компаниях прямой коммит в master/trunk/etc запрещен и коммит проходит через review request, который сначала проверяется автоматикой, а потом человеком.
@@mormeoi а разве нельзя просто вернуть все "взад" загрузив удачный коммит? Не судите строго, я только учусь:)
Бегите и не оглядывайтесь из компании в которой из-за того что новичёк написал плохой код лёг прод и после этого новичка ещё и наказали хоть как-то, а не то что уволили!!!
@@akkh6971 программа работает с данными. Кривой код может испортить данные. Если вернешь нормальный код, то это не поможет. Надо еще и порядок в данных восстановить. У нас в мире 1С это называлось обработка исправления обработки)
Это бред. Разраб в принципе не должен комитить не то что бы в мастер, даже в девелоп. А в нормальных конторах код который должен попасть в прод еще и тестируется .
WinSCP и PuTTY
Пользуюсь гитом через shell, так сложилось исторически, извращенец, но никому не навязываю))) из плюсов такого подхода - четко понятно что ты делаешь, в IDE не всегда понятно, что она делает если что-то выходит за рамки push/pull
все очень просто.
если человек с консолью на Вы и даже поставить игру в виртуалбокс геморно, то однозначно иде..
если grep, sed, awk, etc, в активном использовании - то консоль. и ничего извращенного в этом нет. каждый работает так как ему удобно. у меня вообще процентов 5 коммитов через веб сделаны. тупо так проще и удобнее было в тот момент.
Я з тех кто поставил себе линукс на домашний комп. В итоге я выучил линукс и теперь у меня стоит винда и купленный сервер на ubuntu =)
+ видео про как использовать гит, а не какими инструментами использовать гит
по моему чаще всего все правила сводятся к тому как называть ветки и коммиты чтоб всем понятно было, т.е. вопрос не "как" пользоваться, а "что" писать.
Git Kraken - ТОП
Сам 90% времени использую гит через GUI по тому, что это удобно.
Почему нужно уметь работать с гитом из консоли:
- доступны все возможности гита, а не только те что реализовали в очередном GUI
- заставляет лучше понимать внутреннее устройство
- порой приходится работать там где нет удобной/привычной/никакой GUi
вкусовщина как по мне абсолютная, мне например неудобно использовать гит не из консоли.
Только что узнал что можно адекватно пользоваться гитом не из консоли...
в консоли он есть на всех платформах, дальше продолжать?..
@@tapin13 Кроме того он при этом имеет один интерфейс, вне зависимости от IDE которая используется
Как же мне нравится такой стиль повествования... Только мата бы побольше, так лучше понимается, правда..
Вообще не согласен, что можно забить на терминальный гит. Живой пример с живого проекта: работа на билд-сервере. Там же развёрнута и репа. Подключаешься терминалом через ssh. И где там взять IDE? А работать надо. Но это только один случае из целой кучи возможных. Нет, человек должен уметь работать с гитом в терминале. Просто потому, что наличие юая не всегда возможно.
Основной Новичковый вопрос не как ГИТ использовать правильно, а как он вообще работает и для чего нужен, а то, что там есть стандарты - Ежу понятно!
А еще раньше ide были тоже темными. Как сейчас.
Виртуал бокс, чтобы игрушку запустить?
Дать бы новичкам Mercurial или SVN для полного счастья)))
Hg - тот же Git, только в профиль (не очень популярная система). SVN - самое то для начинающих, простых случаев и личного пользования :)
Bitvise SSH Client - и терминал и двухпанельный менеджер файлов и авторизация по ключам.
ssh, sshfs, scp в linux
Забыли сказать, что всегда когда вы выбрали не консольный способ использования git, то со всеми своими проблемами обращайтесь к разработчикам того ПО, которое вы используете, т.к. 99% решений для всех проблем с git описаны для случая использования консоли.
Sourcetree
Блин) спасибо, Вы действительно крутой ПРОГРАММИСТ
белая тема топ