Если вы никогда этого не слышали, послушайте сейчас. Когда вы работаете с большими проектами, никто не редактирует непостоянные изменения в ветке Master. Это запрещено (хорошо, может быть, это слишком сложно, но мастер-ветка — это не та ветка, с которой можно играть).
Главная ветвь
Ветка Master представляет собой стабильную версию вашего кода. Ветка Master предназначена для производственной среды; это довольно свято, и если вы сделаете неосторожные изменения в основной ветке; ох! Какой-то конфликт.
Мы говорим о конфликте на ходу.
Этапы Git
Модификация
На этом этапе в файлы вносятся изменения. Каждый раз, когда вы добавляете новые коды и обновляете программу, происходит модификация.
Постановка
Это несбыточная мечта — пытаться выполнить коммит без предварительного добавления в промежуточную область, «git status» показывает, какие файлы были изменены и какие файлы находятся в промежуточной области.
Видеть:
Чтобы добавить в промежуточную область, вы вводите «git add file.html». И да, если вы допустили ошибку, вы также можете удалить файл. См. обе команды:
Одна уместная мысль в голове начинающего разработчика — почему у нас есть плацдарм…
Позвольте мне сказать это так; это дополнительный уровень безопасности, и мы можем просмотреть изменения, прежде чем делать коммиты. Это также позволяет нам эффективно разделить нашу работу на отдельные различные изменения.
Коммиты
Коммит — это моментальный снимок вашего кода в определенный момент времени.
Чтобы зафиксировать, просто введите в своем терминале «git commit -m «мой первый коммит».
Слова в кавычках описывают, что означает конкретная фиксация. Ах да, «-m» — это команда для ввода сообщения. Будьте преднамеренны в своем сообщении; это то, на что вы и ваша команда всегда будете ссылаться при определении деталей каждого коммита.
Вы можете подтвердить правильное выполнение вашего коммита, введя «git log — онлайн».
Отмена
Мы когда-нибудь ошибались, когда совершали коммиты? Что! Конечно… миллиард раз. Есть три разных метода выполнения обрядов «уничтожения». Расскажу о них в порядке опасности от наименее опасного до самого опасного.
Оформить заказ
Эй, Хиро Накамура, такая отмена возвращает вас в прошлое, не нарушая временную шкалу. Вы просто возвращаетесь к коммитам, сделанным в определенный момент времени, и можете просмотреть эти изменения в текстовом редакторе. Вы можете просматривать изменения, но не сможете вмешиваться в ветки в любой форме. Представьте себе, что Флэш не может сделать (я просто должен был😝).
Отменить фиксацию
Что вы думаете? Это помогает нам отменить конкретную фиксацию. Это делает конкретный коммит таким, как будто его никогда не существовало — почти как будто он удаляет его. Но на самом деле он просто создает новую фиксацию, отменяющую ранее сделанную фиксацию.
Сбросить фиксацию
Красные флажки… красные флажки, если вы не знаете, что делаете. Это навсегда возвращает вас во времени к конкретному коммиту. Дело в том, что вы все еще можете видеть свою программу в своей среде IDE, но теперь она не подготовлена. Это не всегда красный флаг, если вы достаточно осторожны перед выполнением этой команды.
Функция
Вы должны знать; вы еще не ощутили силу git, пока не начали иметь дело с ветками.
Ветка Feature — это изолированная среда для опробования новых функций, и если они хорошо работают, мы объединяем эти функции в основную ветку.
Что мы делаем, так это вносим изменения в ветки функций, а затем объединяем эти ветки функций с основной веткой после того, как все коммиты были сделаны. Это простое определение ветвления. Эта функция копирует состояние кода, откуда он был извлечен, выполняются различные коммиты, также выполняются тесты, а затем код сливается обратно в основную ветку.
Еще одно преимущество создания ветвей функций заключается в следующем; если что-то пойдет не так и новые функции кажутся несовместимыми, вы можете легко удалить ветвь функций, не нанося ущерба основной ветке.
Создание функциональной ветки
Создать функциональную ветку так же просто. Звездочка означает, в какой ветке git вы работаете в данный момент. Чтобы переключиться между ветвями, вы оформляете ветку. Ваша IDE показывает вам только изменения, внесенные в вашу текущую рабочую ветку.
Команды «добавить» и «зафиксировать» работают так же, как и в основной ветке. Вернувшись к основной ветке, вы заметите, что изменения и фиксации, сделанные в функциональной ветке, не применяются в основной ветке.
Ветка Master остается стабильной и спокойной. Теперь, если вы недовольны функциями, созданными в вашей ветке функций, вы можете легко удалить их с помощью этой команды.
Хорошей практикой является перечисление веток, которые у вас есть в вашем репозитории git, и определение вашей «официальной» рабочей ветки на данный момент. Эта команда показывает вам все это.
Объединяем
Чтобы объединиться, вы должны изменить свою рабочую ветку на Master. Затем введите в терминале «git merge feature-a». Эта команда берет код из функциональной ветки и объединяет его с основной веткой. При первом слиянии выводится «Fast-forward», потому что мы ранее не вносили изменения в основную ветку.
Впоследствии мы объединяемся с помощью рекурсивной стратегии, потому что основная ветвь изменилась за время удаления функциональной ветви и ее повторного слияния с основной ветвью.
Конфликты
Вы никогда не должны быть этим человеком — инженером DevOps, решившим внести изменения в ветку master. Внесение изменений в ветку master вызывает конфликты слияния. Git (представьте, что она человек) не понимает, каким версиям ветки ей следует доверять, учитывая, что разработчик редактировал выбранный раздел кода в основной ветке, а другой разработчик делает то же самое в функциональной ветке. Конфликт возникает из-за того, что Git не может понять, какую версию коммитов мы хотели бы сохранить. Мы должны принять это решение от ее (Git) имени.
Итак, как исправить конфликты:
Удалите обозначения конфликтов, запустите «git add». и команды «git commit». Вы попадете в среду текстового редактора. Вам не нужно делать многого, просто выйдите из окружения, и вы разрешите конфликт.
Вывод здесь никогда не должен редактироваться в ветке Master.
Я с нетерпением жду ваших мнений и отзывов о Git и культуре совместной работы DevOps. Должен сказать, что мой контент не ограничивается традиционным пространством программного обеспечения, но я также разбиваю мифы и легенды о бизнесе и стратегии и их интеграции с программным обеспечением.
И мой контент всегда интересен как профессионалам, так и новичкам в области программного обеспечения и связанных с ним областей. Так что, если у вас есть какие-либо вопросы, пишите или вы также можете связаться со мной в Твиттере.
Спасибо за чтение.
Пожалуйста, оставьте комментарий, если у вас есть какие-либо мысли по теме — я открыт для обучения и исследования знаний.
