Если вы читаете это, скорее всего, вы новичок-программист, изо всех сил пытающийся разобраться во всей этой штуке с контролем версий, или, может быть, вы опытный ветеринар, который выполнял контроль версий в SVN и других устаревших версиях. управляющее программное обеспечение и просто хотите попробовать Git. Независимо от того, к какому концу спектра вы принадлежите, вы находитесь в нужном месте. Сегодня я расскажу вам об основах Git и расскажу, как вы можете улучшить свои знания Git после прочтения этой статьи. Я предполагаю, что у вас есть базовые знания об использовании командной строки Linux / UNIX. Если вы этого не сделаете, не волнуйтесь, вы все равно можете следовать указаниям, но, возможно, вам придется поискать в Google. В любом случае, прежде чем мы углубимся в Git, давайте кратко рассмотрим, что такое контроль версий. Эта статья будет довольно длинной. Необязательно читать все сразу. Не стесняйтесь оставлять его на паузу и возвращаться позже, когда вам будет удобно.
Контроль версий? Все дело в управлении кодом.
Допустим, вы работаете над каким-то сольным сайд-проектом и хотите добавить новые функции. Вы записали схему своей базы данных, нарисовали потоки страниц, разработали алгоритм и все остальное, и теперь у вас все готово, чтобы испачкать руки с кодом. После написания нескольких строк кода в вашей любимой среде IDE (или текстовом редакторе) вы, наконец, готовы его скомпилировать! Но подождите, это выдало какое-то странное сообщение об ошибке, и вы не совсем уверены, что пошло не так. Что ж, ничего страшного, вы можете просто стереть все, что вы сделали, и начать сначала, верно? Но что, если вы все равно получаете ошибки даже после всей работы, которую вы только что стерли? Что теперь? Как вернуться к тому, когда все работало? Здесь на помощь приходит контроль версий.
Это был очень простой и упрощенный пример того, почему нам, программистам, нужен контроль версий в нашей жизни. Для больших проектов в крупных компаниях требуется контроль версий из-за сложности проектов. Потеря работы на месяц только из-за того, что кто-то в команде обнаружил странную ошибку, на самом деле не вариант.
Итак, что такое Git и как он контролирует версии?
Хороший вопрос. Я рада, что вы спросили. Git - одна из многих существующих систем контроля версий. Популярность Git резко возросла с момента его создания. Причина, по которой она так популярна и считается превосходящей по сравнению со многими другими системами контроля версий, заключается в ее дизайне и подходе к управлению версиями. Я не собираюсь вдаваться в кровавые подробности того, как это работает под капотом, потому что в этом нет необходимости.
Итак, как мне начать?
Отлично. Теперь, когда у нас есть теория, теперь мы можем запачкать руки и выполнить фактический контроль версий с помощью Git. Сначала вам нужно будет установить Git в вашей системе. Большинство дистрибутивов Linux поставляются с предустановленным Git. Однако, если вы состоите в браке с каким-то архаичным дистрибутивом Linux, в котором не установлен Git, вам придется искать, как установить Git в вашем конкретном дистрибутиве Linux. Пользователи Windows могут скачать клиент Git со своего веб-сайта. Я рекомендую загрузить клиент оболочки вместо графического интерфейса пользователя, потому что мы будем использовать именно его.
После того, как вы все настроили, откройте оболочку Git в той папке, в которой вы планируете управлять версиями. Для этого урока я буду использовать папку под названием example. Затем выполните следующую команду.
git init
Что мы только что сделали? Мы просто инициализировали папку как репозиторий Git. Это означает, что отныне все, что вы делаете в этой папке (добавление / редактирование / удаление файлов и т. Д.), Git будет отслеживать это. Он создает каталог с именем .git, в котором хранится вся необходимая информация, необходимая для отслеживания всех ваших изменений.
Очевидно, что мы не можем много контролировать версии с пустой папкой, поэтому давайте начнем добавлять файлы. Для простоты я буду использовать простые текстовые файлы. Имейте в виду, что контроль версий возможен только с текстовыми файлами. Таким образом, любые скрипты на любом языке программирования, текстовые файлы и т. Д. Могут контролироваться по версиям. Но вы не можете этого сделать с такими файлами, как PDF, JPEG, PNG и т. Д.
Итак, давайте создадим текстовый файл.
vim helloworld.txt
Я использую vim в качестве текстового редактора, но не стесняйтесь использовать все, что вам удобно. Теперь добавьте в файл какой-нибудь бессмысленный текст и сохраните его. Затем запустите следующую команду
git status
Вы должны увидеть что-то вроде этого
On branch master Initial commit Untracked files: (use "git add <file>..." to include in what will be committed) helloworld.txt nothing added to commit but untracked files present (use "git add" to track)
Что только что произошло? Помните, как инициализировали папку как репозиторий Git? Мы дали Git разрешение отслеживать все изменения в нашей папке, что он и делает. Приведенная выше команда показывает все изменения, обнаруженные Git. Мы сделали файл, добавили в него кое-что и сохранили. Итак, мы внесли изменения!
Прохладный. И что теперь?
Прежде чем мы продолжим, мы должны понять, что такое трехуровневая архитектура Git, которая отличает его от всех других систем контроля версий. Давайте посмотрим на следующую диаграмму
Это три этапа или уровня (как бы вы их ни называли), на которых будут находиться ваши файлы, когда вы выполняете с ними контроль версий. Самый нижний, ваш Локальный каталог - это то место, где изначально находятся ваши файлы. Ваша цель - отправить их на верхний уровень или в репозиторий.
В настоящий момент ваш файл helloworld.txt находится в вашем локальном каталоге. Следующий шаг - переместить его в Промежуточный индекс. Это также называется постановкой. Мы достигаем этого, выполняя следующую команду
git add helloworld.txt
Еще раз проверьте свой статус. Вы должны увидеть что-то вроде этого
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: helloworld.txt
Теперь последний шаг. Вам необходимо переместить файл из Промежуточного индекса в Репозиторий. Это называется совершением фиксации. Итак, мы делаем следующее
git commit -m "initial commit"
Если вы не получали сообщений об ошибках, поздравляем! вы только что сделали свой первый коммит! «Начальная фиксация» - это просто сообщение, прикрепленное к вашей фиксации. Это помогает отслеживать, какой коммит что делает.
Ваш файл helloworld.txt сейчас находится в репозитории. Вот и все! Готово!
Ну не совсем. Но в основном это то, что вы будете делать при управлении версиями с помощью Git.
Итак, вы зашли довольно далеко. Похлопайте себя по спине и сделайте перерыв. Нам есть еще много чего рассказать.
Теперь мы рассмотрим концепцию удаленного репозитория. Все это время мы занимались контролем версий локально. Но что, если вы работаете над проектом со своими друзьями и всем вам нужно общее место, где все вы можете поделиться своим кодом? Здесь на помощь приходит удаленный репозиторий. Думайте о нем как о дополнительном уровне или уровне на уже существующей архитектуре, которую вы только что видели недавно.
Технически удаленный репозиторий может быть чем угодно. Это может быть флэш-накопитель, компьютер вашего друга, ваш телефон и т. Д. Но настройка сервера Git для этих целей может быть довольно болезненной, поэтому есть службы, которые уже делают это за вас. Самый популярный - GitHub. Правильно, если вы еще этого не осознали, GitHub сам по себе НЕ является системой контроля версий! Это просто служба, которая предоставляет вам удаленные репозитории. Думайте об этом как об удаленном компьютере с установленным на нем сервером Git. Поэтому в следующий раз, когда вас спросят, какое программное обеспечение для контроля версий вы используете, скажите Git, а не GitHub. Шутки в сторону.
Есть также другие варианты, такие как Bitbucket и GitLab, но для этого урока мы будем использовать GitHub.
Итак, первое, что вам нужно сделать, это создать учетную запись GitHub и создать репозиторий. Затем скопируйте URL-адрес вашего репозитория и вернитесь в свой терминал. Убедитесь, что все зафиксировано, и выполните следующую команду
git remote add origin <url>
Мы только что добавили удаленный объект с именем origin, что подводит меня к концепции пультов. Remote похож на мост к вашему удаленному репозиторию, и вы можете называть его как угодно. Традиционно мы называем его origin. Итак, вместо предыдущей команды вы можете сделать
git remote add <name of your remote> <url>
Этот пульт - ваше соединение с вашим удаленным репозиторием в GitHub. Вы можете добавить столько пультов, сколько захотите.
Теперь, когда мы связали наш локальный репозиторий с нашим удаленным, мы готовы продвигать наш код. Но сначала нам нужно добавить ветки. Пока не беспокойтесь о том, что это за ветки, мы рассмотрим их чуть позже. Просто знайте, что когда вы создавали свой репозиторий GitHub, он по умолчанию добавлял ветку с именем master. Теперь на вашем локальном компьютере будут две версии всех ваших веток, удаленная и локальная. На вашем локальном компьютере Git по умолчанию создал ветку с именем master, поэтому нам придется вытащить удаленную ветвь master, созданную для нас в нашем удаленном репозитории. Так что продолжайте и выполните следующую команду
git pull origin master
Мы только что вытащили новую ветку под названием master. Теперь, когда у нас есть готовые ветки, мы можем отправить наш код в удаленный репозиторий. Идите вперед и запустите следующее
git push origin master
Вам будет предложено ввести ваши учетные данные GitHub, пока Git отправляет ваш код. После этого перейдите на GitHub, чтобы проверить, есть ли там ваш код.
Здорово! Вы сделали это! Наконец-то вы отправили свой код на GitHub. Ура!
Но подождите, нам еще нужно знать, что такое ветки. Правильно. По сути, вы можете думать о ветке как о параллельной вселенной. Допустим, вы хотите опробовать новую функцию в своем крутом мобильном приложении, но не хотите испортить уже проделанную работу. В этом сценарии вы можете создать отдельную ветку и сделать это. Если что-то пойдет не так, вы можете выбросить всю эту ветку и вернуться к исходной ветке, как будто ничего не произошло. Но если вы чувствуете, что новая функция станет отличным дополнением к приложению, вы можете объединить эту новую ветку с исходной. По умолчанию Git называет свою основную ветвь как master. Он не может управлять версиями без основной ветки. Итак, давайте создадим и удалим несколько веток, не так ли?
Чтобы создать новую ветку, вам нужно решить, из какой текущей ветки вы хотите разделить новую ветку. Поскольку мы работаем только с master, у нас нет выбора. Так что продолжайте и выполните следующую команду (убедитесь, что у вас нет неустановленных изменений)
git branch test_branch
Мы только что создали новую ветку под названием test_branch. Я мог бы назвать его как угодно, поэтому подойдет любое другое имя. Теперь перейдем к нашей недавно созданной ветке
git checkout -- test_branch
Это заставляет Git переключиться на нашу новую ветку. Но что это на самом деле означает? Давайте посмотрим на рисунок ниже, чтобы увидеть, что происходит.
Я буду использовать некоторые термины теории графов, чтобы описать это. Если вы не знакомы с графиками или деревьями, не волнуйтесь, вы все равно можете следовать за ними. Граф - это просто набор узлов и ребер. Эти круги являются нашими узлами, а соединяющие их линии - нашими вершинами или ребрами. Каждый узел здесь представляет собой фиксацию. Ветвь с точки зрения теории графов - это путь, который образует линейный граф. Другими словами, любая последовательность узлов от начала до того, на который указывает HEAD. Итак, что это за HEAD вещь? Это способ Git отслеживать последний коммит в ветке. Указатель HEAD или HEAD указывает на наконечник текущей ветки, которая является последней фиксацией. Я использовал оранжевый для обозначения test_branch и красный для обозначения master. Поскольку наша текущая ветка - test_branch, HEAD указывает на наконечник test_branch. Чтобы по-настоящему понять силу ветвей, сделайте коммит. Откройте helloworld.txt, добавьте еще одну строку бессмысленного текста, внесите изменения и зафиксируйте их. График должен выглядеть примерно так
Теперь закройте helloworld.txt и вернитесь к master. Откройте helloworld.txt и посмотрите, есть ли там только что внесенные вами изменения? Ого! что случилось? Магия, правда? Каждый раз, когда вы меняете ветку, Git выполняет переключение контекста. Таким образом, вся ваша работа в ваших ветках остается изолированной друг от друга. Теперь, когда вы снова переключились на master, график должен выглядеть примерно так
Надеюсь, диаграммы помогут вам понять, как именно работают ветки в Git. Теперь мы рассмотрим еще одну важную концепцию, связанную с ветвями, которая называется слияние. Это именно то, как это звучит, мы объединяем две ветки. Итак, давайте продолжим и выполним слияние. Однако будьте осторожны с тем, с какой ветвью вы сливаетесь. Поскольку мы собираемся объединить master с test_branch, нам нужно убедиться, что наша текущая ветка - master. После этого запустите следующий
git merge test_merge
Если конфликтов нет, вы должны увидеть что-то вроде этого
Updating f4ace54..12d7e99 Fast-forward helloworld.txt | 1 + 1 file changed, 1 insertion(+)
После слияния график должен выглядеть следующим образом. Все, что делает merge, - это добавляет дополнительные коммиты ветки, с которой вы пытаетесь объединить текущую ветку.
Теперь у нас остались удаленные ветки. Удаленный репозиторий, который мы создали в GitHub, поддерживает собственный набор веток. Чтобы быть в курсе последних событий, наш локальный репозиторий поддерживает удаленную версию всех локальных веток. Идите вперед и запустите следующую команду в своем терминале
git branch --all
Вы должны увидеть что-то вроде этого
* master test_branch remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/test_branch
Как видите, каждая локальная ветка имеет удаленную версию, которая носит имя origin/<nameofthebranch>. Думайте об этом как о параллельной ветке, которую Git поддерживает, чтобы поддерживать ваши локальные ветки в актуальном состоянии. * представляет текущую ветку, в которой вы находитесь, как вы, возможно, уже догадались.
Есть две важные команды Git, которые вам нужно понять, когда дело касается удаленных веток, потому что вы будете использовать их довольно часто. Это pull и fetch. Некоторое время назад мы использовали pull, помните? По сути, они делают то же самое, но с небольшой разницей. Когда вы делаете fetch, Git обновляет origin/master (или любую другую удаленную ветку, которую вы загружаете). Но когда вы делаете pull, Git обновляет origin/master и объединяет master с ним.
Это был очень простой урок о том, как начать работу с Git. Если вы хотите глубже понять, как работает Git, эта статья, которую я нашел, - отличный ресурс. Вот список вещей, на которые вы можете посмотреть в свободное время и стать лучше в Git.
- Незапланированные изменения
- Удаление веток
- Сброс
HEAD - Проверка журнала фиксации
- Понимание значений SHA
- Создание
.gitignoreфайла - Внесение изменений в коммиты
- Клонирование удаленного репозитория
И это все! Блин, это был длинный пост. Если вы дожили до этого места, поздравляю! Я надеюсь, что это помогло вам начать работу с Git, и теперь вы можете продолжить свою жизнь и строить все больше и больше!
