Git - распределенная система управления версиями. Эта технология редко встречается в любительской практике или учебе, но наличие пометки о владении ею, хотя бы на базовом уровне, в резюме джуна является мощным аргументом в его пользу.
Сразу оговорюсь: на хабре уже имеется статья и она максимально полная, в связи с чем длинная. Я же постараюсь изложить самые основы в максимально коротком формате.
Итак начнем:
Пункт 1: "Что это за зверь и что он нам дает?"
Git позволяет работать над кодом одновременно нескольким участникам проекта и иметь постоянно наиболее актуальную его версию. Также она дает возможность проследить, кем, когда и какие изменения были сделаны в проекте.
Кроме того данная технология позволяет делать ветвистую структуру проекта. Как правило, никогда напрямую не редактируется головная ветка проекта, а каждый разработчик(как-вариант группа) имеет личную ветку, которая впоследствии вливается в основную.
Описывать установку или настройку Git не вижу смысла, ибо на эту тему уже есть множество гайдов, инструкций и пр. Следовательно, переходим сразу к использованию установленной версии.
Пункт 2: "А как этим вообще пользоваться?"
Лично я использую консольную версию, так как ней я привык. Поэтому я буду писать именно про нее, но если вы разберетесь, то вам не составит труда разобраться и в GUI версии.
Первая (и самая главная) команда, которую необходимо знать :
git help
Что-то мне кажется, что она в представлении не нуждается, но на всякий случай оговорюсь, что она выводит список всех команд с кратким описанием.
Для получения справки по определенной команде необходимо ввести ее после git help, то есть команда
git help push
открывает в браузере страницу с полной информацией по команде push.
Для создания локального репозитория используется следующая связка команд:
cd <путь в вашу рабочую папку>
git init
С подключением к удаленному репозиторию сложнее. Разберем для примера случай с GitHub. Синтаксис команды следующий:
git clone <адрес репозитория>
Получить адрес репозитория можно по большой зеленой кнопке Code непосредственно на странице репозитория на GitaHub.
Для обновления всех веток репозитория сразу используется:
git pull
А при необходимости обновить определенную ветку :
git pull origin <название ветки>
Ветка создаётся командой:
git branch <название ветки>
Для переключения между ними используется:
git checkout <название ветки>
Отлично, теперь вы знаете, как подключится к репозиторию, создать ветку, подгрузить актуальную версию репозитория. Осталось разобраться, как загружать в него собственный код.
Для этого необходимо, чтобы вы находились в папке проекта. Если это не так, то исправляем:
cd <путь в вашу рабочую папку>
Далее готовим содержимое к команде commit:
git add .
" . " в данном случае обозначает, что мы добавляем все содержимое папки.
И, наконец, создаем commit :
git commit -m "<обязательно комментарий>"
Важная оговорка: commit не надо проводить после каждой написанной строчки кода, а только если:
вы добавили новую фичу
вы исправили ошибку
вы завершаете рабочий день и хотите сохранить код
Пункт 3: Заключение
В данной статье я попытался передать основную часть практической стороны Git.Для более полного ознакомления оставляю ссылки на упомянутую выше статью:
Буду рад любой конструктивной критике. Спасибо за прочтение.
Комментарии (26)
lesskop
06.11.2021 00:55+2Ярослав, посмотрите, как выглядит картинка статьи. Я не думаю, что вы хотели сделать именно так.
По поводу статьи - слабо, очень мало информации даже для выжимки по основам.
Junecat
06.11.2021 01:28+18Для тех, кто знает git хотя бы на уровне элементарного использования - в этой статье нет ничего нового, и им она не нужна. Для тех, кто гит не знает или не понимает - она ничего не объясняет
SergeiMinaev
06.11.2021 05:21+10данная технология позволяет делать ветвистую структуру проекта
Это когда файл лежит в каталоге, который в каталоге, который в каталоге? Но чем тут поможет git?
Для создания локального репозитория используется следующая связка команд
А что такое репозиторий?
Для обновления всех веток репозитория сразу используется:
И что такое ветки?
И, наконец, создаем commit :
Что за commit? Я вообще ничего не понял!
Мне кажется, примерно такие вопросы возникнут после прочтения у того, кто не знаком с гитом. А тому, кто уже знаком, это всё уже известно. Думаю, если укладывать всё в 5 минут, то можно было бы вкратце объяснить принцип работы VCS. Потому что без его понимания, команды git-а ни о чём не говорят.
Stanger2021 Автор
06.11.2021 18:30Постараюсь в ближайшее время подправить.Я и сам увидел что статья в ни о чём.Но это мой первый опыт. Спасибо.
unsignedchar
06.11.2021 08:54+8Эта технология редко встречается в любительской практике или учебе
Это письмо из 2000 года? ;) В 2021 году всё немного иначе.
pOmelchenko
07.11.2021 18:48Вы плохо знаете любителей. Среди тех кто вкатывается в профессию гит редко используется для всех проектов. Те кто уже получил коммерческий опыт тоже не редко встречаются те кто гит использует не как систему контроля, а как помойку.
RealBeria
06.11.2021 11:12Я не специалист в этой области, и мне непонятно почему так отминусили эту статью, даже после прочтения всех комментов. Можете, пожалуйста, коротко объяснить?
unsignedchar
06.11.2021 12:10+8Ок. Вы, например, поняли о чем статья? Она помогла вам разобраться в предмете?
RealBeria
06.11.2021 14:36-4Спасибо все минусятарам которые даже начали сливать мне карму за мой нубский вопрос. Что вами движет, ненависть, эгоцентризм, менторство? Честно - я не понимаю что происходит, я действительно был не в теме, мое внимание к этой статье привлек (я не знаю как это правильно называется ... очень большое количество минусов), и сработал наверно обратный эффект: меня заинтересовал этот Git, а вернее вся концепция дистрибуции версий ПО (охренеть, я это сам написал и ни куда не подглядывал! хотя я до сих пор очень далек от разработки ПО). Хочу поддержать автора этой статьи, мой лайк конечно теряется на общем фоне, но пусть он знает что как минимум один человек прочитал, заинтересовался, и благодаря его Труду изучил более углубленно это тему! Бобра наверно на всех не хватит, кто успеет - ловите! :-)
BasicWolf
06.11.2021 14:54+5Там в том то и суть, что человек который начинается заниматься разработкой ПО, очень скоро сталкивается с вопросом "Как это всё хранить" и "Как этим управлять". И тут на сцену выходят системы контроля версий,
в том числе иGit. И в интернете полно качественнейшего материала на эту тему.
Aвтор пишет статью для людей, вроде бы не знакомых с понятием "Системы контроля версий", но при этом пытается уместить всё в формат универской методички, на которую пожалели бумаги.
Автор не раскрывает ни "Что такое распределённые системы контроля версий", ни "Что такое Гит?", ни "Почему Гит, а не XYZ?", ни "Как им пользоваться?".
Вот и летят минусы, чтобы это поскорее исчезло и не добавляло лишней энтропии Вселенной.
dimaaannn
06.11.2021 16:39+3Отвечая на комментарий вы случайно забыли ответить на ключевой вопрос )
Вы, например, поняли о чем статья?
Если да - расскажите своими словами что именно. Если нет - то какие претензии к минусам?
Я с таким же успехом могу скинуть фотографию осциллографа, написав что он нужен чтобы наблюдать и измерять изменения электрических сигналов.RealBeria
07.11.2021 12:54ну из данной статьи я узнал про существование Git, и рамочно - для чего он нужен. Шпаргалка по командам спорна, в моем случае она мало информативна, в вашем - бесполезна, наверно вы и так знаете эти команды. Ну и после прочтения у меня наверно возник самый большой вопрос, где здесь GitHub, про который я был наслышан, как про систему хранения кода, документации и т.д . Статья послужила мне толчком для изучения (естественно из других источников) этого инструмента и теперь я имею ясное представление что это и для чего это. А еще что среди людей разбирающихся в этой теме очень большой процент токсиков. p.s А по минусам к статье - у меня не было претензий, у меня был вопрос - почему.
romwhite
07.11.2021 21:19+4Такова специфика русскоязычного IT-сообщества. Можете открыть ЛоР или OpenNet и увидеть под каждой новостью из мира OpenSource потоки... Ненавистью это не назовёшь, скорее неприятия, противопоставления себя и окружающим. То есть представляете, OpenSource это зачастую люди, которые в своё собственное время что-то делают, отдают это в общее пользование бесплатно, а большинство комментариев - лютый негатив.
К примеру. Состоялся релиз дистрибутива Fedora 35. Открываем OpenNet, первый комментарий в новости:
>>> Единственный ненормальный дистрибутив, которым ни один нормальный человек никогда пользоваться не будет.
Открываем сообщество GNU/Linux на Reddit, второй комментарий (первый - технический):
>>> The performance improvements in gnome 41 are really nice!
У меня есть идеи, почему так, но это только домыслы. Но если хотите более, скажем так, позитивной реакции в целом (я, лично, устаю от негатива по жизни) - можно читать и писать в Reddit, HackerNews и т.п. На английском.
RealBeria
08.11.2021 12:58спасибо тебе добрый человек за нормальный ответ, без кислоты и пинков! как глоток свежего воздуха в спертой атмосфере!
Adler_lug
06.11.2021 14:24+2Я тоже не специалист в этой области, но после прочтения статьи я ни на йоту не приблизился к тому, что бы им стать.
При этом в конце ссылки на другие статьи аналогичного содержания, которые куда информативнее и объемнее.
playermet
06.11.2021 17:40+2Как минимум за то, что вводных в Git статей на хабре уже наверное за сотню. Зачем еще одна, в которой нет ничего нового?
shortolonger
06.11.2021 18:24+1Получить адрес репозитория можно по большой зеленой кнопке Code непосредственно на странице репозитория на GitaHub.
Скриншоты?.. Не, не слышал.
«GitaHub”... ????
Joker2147
06.11.2021 18:25+2Для обновления всех веток репозитория сразу используется:
git pullОбновляет только удалённые ветки, не локальные.
А при необходимости обновить определенную ветку :
git pull origin <название ветки>Нет, эта команда немножко не для этого.
MyraJKee
07.11.2021 14:52Годы летят... Я застал еще CSV и помню то время когда GIT был новинкой. Сейчас те кто не использует какой-либо контроль версий, выглядят просто дикарями. )
romwhite
07.11.2021 21:01Если хотите написать годную статью по основам Git и системам контроля версий в целом, то могу вам предложить идею, как сделать такую статью полезной и интересной. Представьте себя преподавателем в ВУЗе, которому на первом курсе ИВТ поручили вести предмет "Введение в профессию" и предоставили возможность самому выбрать, какие темы дать студентам.
Вы обоснованно решили, что навыки работы с системами контроля версий - жизненно необходимы будущим специалистам. При этом студенты ещё не проходили программирование, алгоритмы и т.п. Тогда как им дать представление о том, что Git - это нужно, важно и полезно, чтобы с первых лабораторных по программированию они уже пользовались Git (тогда преподаватель сможет просто посмотреть историю коммитов и понять, как разворачивался творческий процесс)?
Думаю, нужно объяснять принципы его работы не на примере кода, а на примере стихов или рассказов. К примеру, Маша и Вася решили написать поэму в соавторстве. Каждый пишет по одному четверостишью. Потом к ним присоединился Серёжа, который начинает вносить в проект весомый вклад, но вместе с тем и смуту, поскольку ему не нравится стиль Васи. Было бы интересно.
SergeyNV
09.11.2021 01:14Согласен статья о git так себе. Кто уже работает с git, даже на уровне пользователя, и так знает всё, что тут написано. Для новичка, слишком сумбурно и мало объяснено. Новичкам, которые хотят познакомиться с git, лучше почитать документацию, которая есть на русском языке. Там достаточно понятно всё написано. И да, самый лучший вариант изучения, это самому поковыряться в git.
0xC0CAC01A
https://habr.com/ru/post/175943/
AVI-crak
Было-бы неплохо дополнить статью с учётом новой двухфактовой аутентификации на гитхабе, для кнопконажимателей из мира винды.