Это проще, чем вы думаете
Время историй
Мой первый поиск работы был болезненным и утомительным опытом. Даже в технологической отрасли, где кажется, что рынок труда уже почти десятилетие находится на подъеме, пробиться может быть непросто. Я посвятил огромное количество времени ответам на личные и технические вопросы, но все равно не смог ответить на интервью с более чем дюжиной компаний. В одном особенно неловком случае интервьюер спросил, могу ли я назвать 5 команд git и что они делают. Я не мог. В другом интервью меня спросили, как разрешить конфликт слияния, и я снова не знал. Ни одно из интервью не привело к обратному звонку. В то время я был опечален (хотя вы не должны быть огорчены). Однако важно быстро пережить моменты поражения и подготовиться к следующему испытанию с новым опытом.
Если вы новичок в технологиях или уже работаете с git и не знакомы с ним, пожалуйста, не повторяйте моих ошибок. Git — один из самых важных инструментов, которыми располагает разработчик, и его понимание необходимо для любой работы, связанной с написанием кода. Десятки миллионов разработчиков используют его каждый день.
Почему гит?
Когда вы находитесь в академической среде или пришли из нее, может быть трудно понять, как можно использовать git. Когда я получал степень бакалавра, почти все оценки, такие как тесты или проекты по кодированию, были одиночными усилиями, где сотрудничество считалось мошенничеством. Когда я выполнял групповые проекты, кодовые базы были относительно небольшими и простыми, поэтому я и мои товарищи по группе отправляли по электронной почте фрагменты кода, которые мы написали друг другу. Если вы делаете это, пожалуйста, ОСТАНОВИТЕСЬ. Потратив 2 часа на изучение git, вы сэкономите как минимум десятки часов на протяжении всей вашей академической карьеры. Давайте поговорим о некоторых проблемах с отправкой фрагментов кода по электронной почте между соавторами:
1. Два человека не могут одновременно вносить изменения в одни и те же файлы. Вы либо должны по очереди редактировать один файл, либо делать правки на разных компьютерах и как-то вручную их объединять.
2. У вас нет истории вашего кода. Если вы заставите свой проект работать, а затем внесете некоторые изменения и улучшения, и что-то сломается, вы облажались.
3. Нет простого способа сравнить прошлые версии вашего кода с текущей версией.
4. Вы не знаете, кто что написал.
5. Различные версии вашего кода в локальных документах и электронных письмах не организованы и не централизованы в одном месте.
Я мог бы продолжить. Если вы похожи на меня, вы можете подумать что-то вроде Какая разница, если я не знаю, как именно выглядел код? Я написал это один раз, я могу написать это снова или я знаю, кто написал какой код в моем проекте, и если я не знаю, я могу просто спросить всех в моей группе из 4 человек.Эти решения будут работать некоторое время, но не все время. Вы вчера написали свой школьный проект, конечно, вы можете его исправить! Но если я попрошу вас исправить какую-нибудь ошибку в этом проекте через 6 месяцев, сможете ли вы это сделать? Смогли бы вы найти, кто написал строку 196 myFile.py, если бы вы сотрудничали с 500 студентами (включая давно ушедших выпускников!) вместо 4? Конечно, нет! Это нелепые вопросы, но именно для работы над проектами такого масштаба вам нужен git и почему вероятность того, что вас спросят о git на собеседованиях, не равна нулю.
Что такое гит?
Ладно, Рэнт закончился. Git похож на документы Google для кода. Он хранит записи о том, кто что написал, а также записи о состоянии вашего кода для каждой «фиксации», которую вы делаете. Кроме того, вы можете бесплатно опубликовать свой код в Интернете, чтобы ваши соавторы могли легко получить к нему доступ. Просто, верно?
Хотелось бы, чтобы здесь было что написать, чтобы этот раздел не был таким коротким, но идея git действительно так проста. У вас есть онлайн-каталог или «репозиторий», который вы можете редактировать на своем локальном компьютере. Вы вносите изменения в репозиторий и время от времени «фиксируете» свой код в записи коммитов или «журнале». Когда ваш код работает (или нет 😉) и вы готовы опубликовать свои изменения в локальном репозитории, вы «отправляете» их в удаленный репозиторий на GitHub. Теперь ваши изменения доступны онлайн, чтобы ваши соавторы могли видеть и редактировать их сами! Если один из ваших соавторов вносит изменения в онлайн-репозиторий, и вы хотите, чтобы они были на вашем локальном компьютере, вы можете «вытащить» их на свой локальный сервер.
Что вам нужно для выполнения
Вам нужно будет установить git для этого руководства. Я не буду объяснять, как это сделать здесь. Вы можете найти несколько учебных пособий в Интернете. Как только вы инициализируете репозиторий и подключите его к удаленному репозиторию на GitHub, вы будете готовы к моим примерам. Я также использую VSCode. Это необязательно. Вы можете использовать другую IDE или вообще не использовать.
Общие команды с примерами
Для этих примеров я буду использовать несколько файлов JavaScript… Но самое замечательное в этом руководстве то, что если вы хотите следовать ему, вы можете использовать что угодно. Я призываю вас сделать что-то похожее, но не совсем то, что я пишу здесь.
Начинающийся
Во-первых, давайте создадим файл. В VSCode вы можете увидеть свои текущие изменения на вкладке «Управление исходным кодом» на панели навигации. Наши изменения в кодовой базе еще не представлены в удаленном репозитории. Даже записи о них пока нет. Для этого нам нужно сделать коммит.
Во-первых, мы «инсценируем» наши изменения с помощью git add. Мы можем подготовить отдельный файл, указав его имя, или подготовить каждый отредактированный файл, используя точку, как на изображении выше.
Затем мы фиксируем с помощью git commit -m "added advanced string interpretation function" . Всякий раз, когда вы видите тире, думайте об этом как о передаче аргумента функции. Они называются «флаги». Во второй команде мы используем команду commit с флагом -m и аргументом "my first commit". Это зафиксирует ваши изменения с сообщением в качестве аргумента (сообщения необязательны, но важны! Как правило, они должны представлять собой краткое изложение внесенных вами изменений).
Теперь на этот раз сделайте фиксацию самостоятельно. Если вы используете VSCode, найдите минутку, чтобы взглянуть на «управление исходным кодом» и увидеть красивое визуальное представление ваших изменений:
Мы внесли изменения, но их еще нет на GitHub. Опубликуйте их сейчас с git push . Эта команда проста. Он «отправляет» ваши изменения в удаленную ветку, которую вы настроили.
Давайте внесем изменения из другого места (например, в вашем браузере через GitHub), чтобы имитировать соавтора, добавляющего код в репозиторий.
Вернитесь к своему локальному репо. Вы можете проверить, актуален ли ваш код, используя git status :
Черт! Мы позади! Давайте исправим это, вызвав git pull :
Вот о чем я!
Журналы фиксации
Теперь давайте посмотрим на нашу историю коммитов с git log:
Здесь мы видим, что история более или менее похожа на стек, причем самые последние записи появляются первыми. Каждый раз, когда вы делаете коммит, вы кладете его на вершину стека, который является журналом. Если мы хотим искать коммит по сообщению, это также возможно с grep:
Здесь мы видим все коммиты, в которых сообщение содержит строку «интерпретировать».
Если мы решим, что хотим вернуться к предыдущему коммиту, то вызываем reset:
Чтобы вернуться к определенному коммиту, мы передали аргумент SHA. В основе SHA лежит интересная теория, но все, что нам действительно нужно знать, это то, что это длинная чепуха. Каждый коммит имеет SHA, который отображается в журналах. Это уникальный идентификатор, в отличие от сообщений фиксации.
Сброс не удалит все ваши изменения. Он вытолкнет их из журнала и добавит в качестве изменений в репозиторий (по сути, ничего не изменилось. Ваши коммиты только что были преобразованы в правки). Если вы хотите отменить свои коммиты истереть изменения, используйте флаг --hard.
Ветвление
До сих пор мы вносили изменения непосредственно в нашу основную ветку. Однако это не очень хорошая практика, если вы работаете с другими. При добавлении новой функции вы должны создать ветку для этой функции. Филиал — это еще одна версия вашего репо. Вы можете отправлять коммиты в одну ветку без изменения другой. Давайте создадим ветку из нашего основного и назовем ее myNewBranch. Затем переключитесь на ветку с помощью checkout.
Если вы используете git log . Вы увидите, что история коммитов совпадает с вашей основной. Это имеет смысл, потому что вы просто «ответвились» от main без внесения каких-либо изменений. Добавьте функцию сразу после первой в том же файле, что и раньше, а затем зафиксируйте ее.
Чтобы вернуться к нашей основной ветке, мы можем сделать git checkout main . Вы должны заметить, что последнее изменение исчезло.
Вы также можете переключиться на несуществующую ветку, используя флаг -b. Это то же самое, что выполнить git branch myBranch, а затем git checkout myBranch.
Давайте представим, что ваш соавтор добавил коммит в тот же файл и строку, на которые влияет ваша новая функция. Мы можем смоделировать это, внеся изменения и добавив их в ветку main :
Хорошо, теперь давайте вернемся к myNewBranch . Эта ветка пришла из уже устаревшей версии main. Мы можем использовать команду rebase, чтобы обновить его.
Прежде чем мы двинемся дальше, мы должны поговорить о том, как работает rebase, так как это первая рассмотренная нами команда, которая требует некоторой интерпретации. Как упоминалось ранее, когда вы создаете новую ветку, она начинает свою жизнь как копия ветки, в которой вы сейчас находитесь. Как только вы добавляете коммиты к любому из них, они начинают расходиться. Что, если бы мы могли каким-то образом переопределить коммит, в котором происходит «ветвление»? Итак, вместо того, чтобы переходить от устаревшей версии main, мы переходим от самого последнего коммита? Это именно то, что делает rebase! Давайте сделаем это сейчас с git rebase main .
Арх! Что здесь случилось? Что ж, обе ветки имеют коммиты, которые изменяют одни и те же части одного и того же файла. Гит не знает, что делать! Нам нужно внести ваши изменения, изменения вашего соавтора или и то, и другое. Нам нужны обе функции для нашей ветки, поэтому давайте примем оба изменения.
Это результат, который мы получаем. Обратите внимание, что в нем есть синтаксические ошибки. Git иногда немного путается при слиянии кода. Убедитесь, что вы очистили это, и проверьте, что это работает.
Как только с этим разберетесь, добавьте в свои файлы конфликты слияния, а затем выполните git rebase --continue . Промойте и повторяйте, пока перебазирование не закончится.
Теперь, когда наша ветка обновлена до main , как нам объединить наш код? Есть несколько способов. Мы собираемся опубликовать в удаленной ветке, а затем создать запрос на извлечение. Сначала сделайте git push -u myNewBranch . Затем перейдите на GitHub в свой репозиторий, и вы должны увидеть большую кнопку с надписью «создать запрос на включение». Нажмите на нее и добавьте сообщение. Оттуда ваши соавторы могут прокомментировать его, чтобы предложить улучшения, и вы можете объединить его, как только у вас будет время, чтобы просмотреть его с коллегами. Сделанный! Легко, верно?
Большое спасибо за чтение!
