Как инженер-программист, один из инструментов, с которым я взаимодействую ежедневно, - это Git. Git - это система контроля версий (VCS). VCS - это просто программа, которая отслеживает изменения в коде разработчиков, позволяя перемещаться вперед и назад по этим изменениям. Существует множество VCS, но самой популярной среди разработчиков является Git.
Каждый день на работе я использую следующие команды Git для выполнения своей работы. Я уверен, что вы уже используете эти команды, а если нет, то можете считать это своим счастливым днем. Добро пожаловать в 13 команд Git, которые я использую ежедневно.
# 1 Инициализация нового репозитория
Я использую эту команду для создания нового репозитория Git. Репозиторий может быть для проекта или пакета Python, над которым я работаю. Как правило, это бэкэнд-проект, над которым я работаю во Flask или Fast API; и если я разрабатываю что-то связанное с интерфейсом, возможно, VueJS или Angular
Прежде чем инициализировать новый репозиторий, сначала перейдите в папку проекта и выполните команду ниже.
git init
git init инициализирует папку вашего проекта как репозиторий Git, создав скрытую папку .git внутри папки проекта. Эта .git папка содержит все необходимое для управления версиями вашего нового проекта.
# 2 Просмотр статуса вашего репозитория
Я использую команду ниже для просмотра состояний файлов моего проекта. Файлы могут находиться в одном из четырех состояний.
- Состояние без отслеживания: это состояние включает в себя все файлы, которые еще не отслеживаются и не управляются моей VCS, то есть Git.
- Измененное состояние: это состояние включает в себя все файлы, которые уже отслеживаются и управляются Git, но были изменены, причем такие изменения еще не были внесены или зафиксированы в Git.
- Поэтапное состояние: это состояние включает измененные файлы, которые готовятся к введению в Git с отложенной фиксацией.
- Зафиксированное состояние: это состояние включает поэтапные файлы, которые были зафиксированы или уже добавлены в Git и могут быть извлечены позже, если возникнет необходимость.
git status
# 3 Размещение и фиксация файлов
Как я сказал в команде №2, мои файлы проекта могут находиться в одном из четырех состояний. Все мои неотслеживаемые и измененные файлы необходимо сначала поместить, а затем зафиксировать в системе контроля версий Git. Эти два действия, постановка и фиксация, достигаются с помощью следующих
Размещение неотслеживаемых и измененных файлов
# Staging all the files in a repo, both untracked and modified files git add <project-name> >> git add . # period here represents the project-name since we've already changed directory into our project-name # Staging a specific untracked or modified file git add <filename> >> git add index.py
Фиксация поэтапных файлов
# This opens an editor to enter the commit message git commit # Commit staged changes without opening an editor git commit -m"<commit-message>" >> git commit -m"this is a commit message"
# 4 Клонирование репозиториев
Я часто посещаю страницы «Обзор» и «Тенденции» на Github, чтобы следить за интересными проектами, над которыми работают другие разработчики. Это один из способов обнаружения концепций и идей, о которых я, возможно, не слышал из первых рук.
Иногда я также получаю просьбы от некоторых из моих друзей-разработчиков и коллег на обзор и критику их проектов и библиотек.
Любая из этих ситуаций требует, чтобы я имел локальную копию проекта или библиотеки для удобного просмотра и внесения изменений и расширений в их проект или библиотеку. И для этого использую git clone
Я использую git clone для создания копии исходного проекта, который в основном будет размещен на Github, Gitlab или какой-либо другой платформе для размещения облачного кода.
# General repository cloning git clone <repository-url> >> git clone https://github.com/ofelix03/my-daily-git-commands.git
# 5 Просмотр истории коммитов
Иногда мне нужно знать, какие изменения я внес в проект, над которым работаю. Иногда это делается для того, чтобы понять, как продвинулся мой проект, или в случае, когда я допустил ошибку, зафиксировав изменения, которые скорее нарушают мой код, я хочу знать, к каким предыдущим зафиксированным изменениям я могу вернуться, чтобы отменить текущие зафиксированные изменения, которые нарушает мой код. Для таких сценариев я обращаюсь к git log.
# Viewing all my commit history for a project. git log # Viewing the commit history from a specific author or committer git log --author <author-name> >> git log --author "Felix Otoo" # Viewing the commit histories having a certain text git log --grep <search-string> >> git log --grep first-commit # Viewing the revision history since a specified date git log --since <date-string> >> git log --since 2020-10-10 # Viewing the revision history after a specified date git log --after <date-string> >> git log --after 2020-10-10 # Viewing revision history between a date range git log --since <date-string> --until <date-string> >> git log --since 2020-10-10 --until 2020-11-10
# 6 Создание, перечисление, переименование и удаление веток
Ветвление позволяет мне исследовать другие способы написания функциональности, не вмешиваясь в основной код, который я уже реализовал или уже внедряю. Это позволяет мне перемещать разработку из одной ветки (которая, если вы еще не создали ни одной ветки, ваше значение по умолчанию уже master или main для любого нового репозитория в 2020 году и позже).
Причина, по которой Github переименовал свою ветку репозитория по умолчанию с master на main, заключалась прежде всего в том, чтобы выразить солидарность с черными людьми и предложить чувство принадлежности к темнокожим людям, которые могут чувствовать себя некомфортно вокруг слова хозяин из-за того, что он давно существует с черным рабством . Кроме того, Уна Кравец изначально призвала разработчиков в Твиттере рассмотреть вопрос о переименовании своей master ветки в main, указав, среди прочего, это может помочь черным разработчикам чувствовать себя более изолированными в технологическом сообществе.
# Creating a new branch git branch <new-branch-name> >> git branch fix-division-by-zero-bug2 >> git branch fix-property-call-on-undefined-object2 # Listing all branches git branch >> git branch # Listing remote branches git branch -a # Renaming an existing branch git branch -m <old-branch-name> <new-branch-name> >> git branch fix-division-by-zero-bug2 fix-division-by-zero-bug >> git branch call-on-undefined-object2 call-on-undefined-object # Deleting an existing branch git branch -d <branch-name> >> git branch fix-division-by-zero # Deleting an existing branch even when the branch has not fully been merged in its upstream branch git branch -D <branch-name> >> git branch -D fix property-call-on-undefined-object
# 8 Проверка филиалов
Извлечение - это термин, который используется, когда мы меняем нашу Git HEAD с одной ветки на другую. Проще говоря, это меняет вашу линию разработки с одной на другую. Он также обновляет ваше рабочее дерево только историей коммитов и изменениями, относящимися к ветке, в которую вы изменили.
Выделение позволяет вам переключать контекст при работе над проектом, с работы над новой функцией на новую ветвь, чтобы исправить критическую производительность, засоряющую ошибку, или, что еще хуже, вызывая спорадические простои вашей производственной службы.
# Checkout from main branch to a feature-branch git checkout <branch-name> >> git checkout feature-branch # Checkout a branch that is non-existent # You can the flag -b on git checkout to checkout from your current # branch into a new branch git checkout -b <new-branch> >> git checkout -b feature-branch-v2
# 9 Неизменные изменения
Иногда я замечаю, что делаю изменения, которые включают изменения из файлов, которые я не готов подготовить. Иногда такое случается, когда я использую git add <glob-pattern> , и я не обращаю внимания на шаблон глобуса, поэтому в итоге я использовал промежуточные файлы, которые не собирался обрабатывать.
Чтобы исправить эту ситуацию и отключить такие файлы, я использую команду git ниже
# Move every staged files back into your working tree git reset # Move only specific staged files back into your working tree git reset <filename>[, <filename2>, <filename3>, ...] # Move only staged files in a given folder git reset <folder-name>
# 10 Сброс истории коммитов
Бывают дни, когда я непреднамеренно готовлю и фиксирую изменения, которые не собираюсь делать. Также я могу понять, что сделанная мной немедленная фиксация вызывает проблемы или ошибки, которые я не могу понять, как исправить с помощью кода. В любой из этих двух ситуаций я прибегаю к использованию git reset с флагом —hard, чтобы отменить немедленную фиксацию.
Эта команда сбрасывает мою историю Git, перемещая мою HEAD из немедленной фиксации в предыдущую фиксацию.
git reset --hard
# 11 Отправка локальных изменений в исходный репозиторий
Время от времени я отправляю свои локальные коммиты в вышестоящий репозиторий. Такие изменения могут быть из ветки main или из любой из веток моих функций, над которыми я работал.
git push <remote> <branch-name> # Push main branch commits to the upstream main branch >> git push origin main
# 12 Получение изменений из апстрима
Я работаю в команде, и поэтому часто бывает, что мой локальный клон расходится или отстает от исходного репозитория в истории коммитов. Без обновления моего локального репозитория новыми коммитами в централизованном восходящем потоке любой запрос на перенос, который я делаю, может привести к конфликту слияния во время слияния в централизованный репозиторий.
Чтобы разрешить любой потенциальный конфликт с моими запросами на перенос, я всегда запускаю git pull для синхронизации моего локального репо с централизованным восходящим потоком.
git pull <remote> <branch-name> # Pull changes from the main branch of the centralized upstream # into my local main branch >> git pull origin main # Pull changes without performing a three way merge # This removes temporarily your local commits, applies any upstream # changes first and then replays your local commits on top # This cleans up your commit history by removing the common [MERGE] # commit message git pull --rebase <remote> <branch-name> >> git pull --rebase origin main # Pull changes from upstream automatically resolving merge issues # 1. Merge conflict favorin changes from upstream git pull -s recursive -X theirs origin main # 2. Merge conflict favoring local changes git pull -s recursive -X ours origin main
# 13 Хранение рабочих изменений
Бывают случаи, когда ваш босс бросает вам задачу, в то время как вы выполняете другую в том же проекте или кодовой базе. Когда возникают такие ситуации, в зависимости от срочности запроса вашего начальника, вам может потребоваться прекратить то, над чем вы работаете, и переключить внимание.
С такими ситуациями приходит git stash, чтобы спасти положение.
Как и название, git stash сохранит ваши изменения в вашем рабочем каталоге и индексе. Как только запрос вашего начальника будет выполнен и не будет обработан, вы можете восстановить свою спрятанную работу, git stash добавив несколько аргументов для восстановления вашего предыдущего рабочего каталога и индекса.
# Stashing your current work away
git stash
# Viewing all your stashed changes
git stash list
# Restore the most recent stashed changes and deleting it from your # stash
git stash pop
# Restore the most recent stashed changes but still keep it in stash
git stash apply
# Restore a specific stash from your stashed list
git stash <stash-name>
>> git stash stash@{0}
# Clear your entire stash of changes
git stash clear
