Единственное руководство по Git, которое вам понадобится, чтобы освоить управление версиями из командной строки и ускорить свою карьеру в качестве разработчика.
Вы только начали свой первый проект в качестве веб-разработчика и хотите отслеживать множество изменений в своем рабочем каталоге? Наконец-то вас выбрали для прохождения собеседования в качестве младшего инженера данных и вы немного устали в теме контроля версий? Или вы просто работаете в науке о данных и хотите больше узнать о Git и командной строке, чтобы показать своей команде, что вы можете достичь того же результата, вообще не используя графический интерфейс?
Если вы ответили «Да, вот и я!» хотя бы в один из указанных выше профилей, то этот учебник определенно поможет вам узнать больше об управлении версиями через командную строку, и он сделает это быстро!
Как и многие другие аналитики данных и разработчики бизнес-аналитики, я познакомился с управлением версиями через графический интерфейс GitHub. В то время моя компания использовала Looker в качестве инструмента визуализации, и его можно было настроить с помощью удобной интеграции Git для управления версиями файлов в режиме разработки.
Каждый шаг был настолько визуально привлекательным и удобным для пользователя при фиксации и развертывании изменений, что я не узнал об истинном потенциале Git, пока однажды инженер по обработке данных не сказал мне: «Контроль версий? Я всегда использую одни и те же 4–5 команд в своем терминале и работа сделана! Я редко получаю доступ к пользовательскому интерфейсу ».
А потом он просто набрал еще один git push origin master, а я с восхищением смотрел на его ноутбук. И тогда я понял, что следующим шагом для меня было бы изучение командной строки и того, как управлять версиями с помощью Git.
В оставшейся части этого руководства вы найдете 15 команд, которые я использую чаще всего при работе над своими проектами.
Прежде всего, что такое Git?
Git - это инструмент командной строки, используемый для управления версиями, вы можете получить доступ, просто набрав git в оболочке. Первый шаг - создать новый каталог и инициализировать репозиторий:
$ mkdir medium_git $ cd medium_git/
Я создал папку medium_git, которую я буду использовать для остальной части этого руководства и которая будет включать список всех команд, обсуждаемых ниже. Его можно найти в моем репозитории code_tutorials в GitHub.
Объяснение команд Git
1. git init → Эта команда инициализирует репозиторий внутри папки medium_git, что означает, что теперь она будет отслеживать несколько версий файлов в папка. Инициализация репозитория Git также создаст каталог с именем .git внутри папки репозитория. Файлы и папки с префиксом точки (.) Обычно являются личными и не отображаются по умолчанию, когда вы перечисляете файлы в папке, если не используется команда ls -a:
$ git init Initialized empty Git repository in /Users/antonellobenedetto/Documents/medium_git/.git/ $ ls -a . .. .git
Затем давайте создадим файл разметки (.md) с именем git_commands, который включает только краткое описание того, что git init делает, и сохраним его в репозитории medium_git.
2. git add → В git файлы могут находиться в одном из следующих трех состояний: изменено, поставлено, зафиксировано . Если вы готовы зафиксировать файлы, которые вы изменили, вы можете добавить их в область подготовки с помощью git add [file name] command. Затем поэтапные файлы помечаются для включения в следующую фиксацию, но еще не зафиксированы:
$ cat git_commands.md 1. git init <-- initializes a repository inside the folder $ git add git_commands.md
Вы могли бы достичь того же результата с git add . (или используя подстановочный знак git add *). Единственное отличие состоит в том, что таким образом все файлы в репозитории будут размещены одновременно.
3. git config user.name/user.email → Перед первой фиксацией рекомендуется сообщить git, кто вы. Это особенно важно, когда вы работаете в команде, чтобы каждый участник мог определить, кто совершил определенную фиксацию:
$ git config --global user.name ‘anbento’ $ git config --global user.email ‘[email protected]’
Если вы хотите проверить параметры конфигурации, введите git config -l.
4. git commit -m ‘ваше сообщение’ → При коммите сохраняется моментальный снимок файлов в репозитории на определенный момент времени. Создавая историю этих снимков, вы можете вернуться к более раннему моменту времени. Флаг -m указывает, что вы добавляете сообщение, а текст в кавычках, который идет после него, является самим сообщением фиксации. Обычно сообщение фиксации делается информативным, поэтому, если нам действительно нужно перемотать или объединить код, будет очевидно, какие изменения были внесены и когда:
$ git commit -m ‘Adding git_commands.md file’ [master (root-commit) 815d087] Adding git_commands.md file 1 file changed, 3 insertions(+) create mode 100644 git_commands.md
5. git log → Вы можете просмотреть историю коммитов репозитория с помощью этой команды. Каждой фиксации присваивается уникальный идентификатор или хэш длиной 40 символов. Хэши фиксации являются постоянными, что означает, что Git сохраняет их и включает их при передаче между локальным и удаленным репозиториями. Также обратите внимание, как имя и адрес электронной почты автора фиксации отображаются под каждой историей фиксации:
$ git log commit 815d087f132288112b7e427617be0408e6db4974 (HEAD -> master) Author: anbento <[email protected]> Date: Sat Apr 4 08:19:16 2020 +0100 Adding git_commands.md file
6. git remote add [удаленное имя] [удаленный URL-адрес] → В какой-то момент вы можете захотеть отправить свои изменения (например) в репозиторий на GitHub, чтобы вы могли получить доступ к полной истории проекта с других устройств или просто для сотрудничества с вашей командой. Для этого вам сначала нужно создать сам репозиторий, а затем запустить команду в терминале:
$ git remote add origin https://github.com/anbento0490/code_tutorials.git $ git remote -v origin https://github.com/anbento0490/code_tutorials.git (fetch) origin https://github.com/anbento0490/code_tutorials.git (push)
В этом случае сначала я создал репозиторий code_tutorials в своей учетной записи GitHub, а затем добавил его как удаленный под origin псевдоним. Имейте в виду, что «origin» - это просто имя, присвоенное по соглашению, но вы можете назвать пульт по-другому, если хотите. Указав параметр -v, вы можете получить полный удаленный URL-адрес, назначенный каждому псевдониму. Если вы допустили ошибку и хотите удалить пульт, просто запустите git remote remove origin command.
7. git push [удаленное имя] [имя ветки] → После того, как вы внесли изменения в локальную версию репо, вы можете отправить их в удаленное репо, чтобы ваш проект безопасно хранился в облаке со всеми его коммитами история. Это означает, что даже если ваш ноутбук сломается или будет украден, ваша работа не будет потеряна и может быть восстановлена из вашей учетной записи GitHub. Для этого вам нужно отправить основную ветку в удаленное «origin» репозиторий:
$ git push origin master Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 282 bytes | 282.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0)To https://github.com/anbento0490/code_tutorials.git * [new branch] master -> master
Как только вы это сделаете, файлы, которые изначально были доступны только в локальном рабочем каталоге, будут загружены в ваше удаленное репо, а также информация о ваших коммитах:
8. git clone [URL-адрес репозитория] [имя папки] → Если вы или один из ваших коллег хотели загрузить папку проекта на другое устройство, вы могли бы сделать это, клонировав удаленный репозиторий локально. В моем случае я вернулся в домашний каталог и клонировал репозиторий, присвоив исходное имя medium_git:
$ git clone https://github.com/anbento0490/code_tutorials.git medium_git Cloning into ‘medium_git’… remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0Unpacking objects: 100% (3/3), done.
Приведенная выше команда не только создает каталог с именем «medium_git», но также инициализирует внутри него каталог .git, извлекает все данные для этого репозитория и проверяет рабочую копию последней версии. .
В самый первый раз, когда вы попытаетесь клонировать частное репо из удаленного репозитория, вам будет предложено указать имя пользователя и пароль (если вы уже не используете SSH-ключ для подключения к GitHub). Учетные данные могут быть встроены непосредственно в URL-адрес следующим образом:
git clone https://your_username:[email protected]/anbento0490/repo_name.git
После того, как вы один раз выполните аутентификацию, Git кэширует ваши учетные данные в памяти и выдает их по запросу. Если git config credential.helper команда возвращает manager, пароль сохраняется в диспетчере учетных данных Windows, если он возвращает store, пароль сохраняется в .git-credentials файле в папке пользователя, а если он возвращает oskeychain, он хранится в связке ключей.
9. git pull [удаленное имя] [имя ветки] → Когда последняя фиксация в локальном репо старше, чем последняя фиксация в удаленном репо, вы можете использовать git pull для обновления рабочего каталога, чтобы в нем были те же файлы, что и в последней фиксации. В этом руководстве, чтобы смоделировать то, что обычно происходит в среде совместной работы, я отредактировал файл git_commands.md прямо в GitHub, добавив в список дополнительные команды и зафиксировал изменения:
Это действие создало новую фиксацию с уникальным идентификатором. Фиксация и изменения видны только в удаленном репо до выполнения следующей команды:
$ git pull origin master remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), done. From https://github.com/anbento0490/code_tutorials * branch master -> FETCH_HEAD 815d087..b3088e3 master -> origin/master Updating 815d087..b3088e3 Fast-forward git_commands.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
10. git diff [HEAD ~ 1] [HEAD] → Если теперь вы запустите git log после извлечения из удаленного репо, вы увидите две фиксации, одна из которых находится наверху, Самый последний. Чтобы увидеть разницу между двумя коммитами, просто введите:
$ git diff HEAD~1 HEAD diff — git a/git_commands.md b/git_commands.md index ddd61c8..3cb7e12 100644 — — a/git_commands.md +++ b/git_commands.md @@ -1,3 +1,11 @@ +Git 15 Most Used Commands 1. git init ← initializes a repository inside the folder +2. git add +3. git config user.name/user.email +4. git commit -m ‘ your message’ +5. git log +6. git remote add [remote name][remote url] +7. git push [remote name] [branch name] +8. git clone [repository url] [folder name] +9. git pull [remote name] [branch name]
Вместо того, чтобы вводить первые 3–4 символа каждого хэша, вы можете использовать специальную переменную под названием HEAD, которая всегда ссылается на самую последнюю фиксацию в текущей ветке. Вы также можете использовать ярлыки для получения старых хэшей коммитов, где HEAD ~ 1 является вторым самым новым коммитом в локальном репо, HEAD ~ 2 - третьим самым новым коммитом и т. Д.
11. git fetch [удаленное имя] [имя ветки] → Точно так же, как git pull , эта команда используется для загрузки файлов и фиксации из удаленного репозитория в ваше локальное репозиторий. Вы можете рассматривать git fetch более консервативную версию этих двух команд, поскольку она загружает удаленный контент, но не обновляет рабочее состояние вашего локального репозитория, оставляя вашу текущую работу нетронутой. Если у вас есть незавершенные изменения в локальном git fetch , это предотвратит возникновение конфликтов, и это часто используется в совместной среде, чтобы увидеть, над чем работают все остальные, не заставляя вас фактически объединять изменения в ваш репозиторий.
Чтобы показать, насколько полезен git fetch, я добавил еще одну команду в список на GitHub и зафиксировал изменение, так что удаленный репозиторий снова имеет больше коммитов, чем локальный. Третий идентификатор фиксации начинается с 40ae0be, и вы можете проверить это, выполнив следующие 3 команды:
$ git fetch origin master remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), done. From https://github.com/anbento0490/code_tutorials b3088e3..40ae0be master -> origin/master $ git checkout origin/master Note: checking out 'origin/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at 40ae0be... Update git_commands.md $ git log commit 40ae0bebb77b8df716439b94bb5005a65c0e6301 (HEAD, origin/master) Author: AnBento <[email protected]> Date: Sun Apr 5 06:56:07 2020 +0100 Update git_commands.md commit b3088e373b881a526844826a2dade7b1443eefbb (master) Author: AnBento <[email protected]> Date: Sat Apr 4 18:39:48 2020 +0100 Update git_commands.md commit 815d087f132288112b7e427617be0408e6db4974 Author: anbento <[email protected]> Date: Sat Apr 4 08:19:16 2020 +0100 Adding git_commands.md file
Поскольку при выборке новые коммиты не добавляются в локальное репо, следует использовать git checkout origin/master для переключения с локальной ветки (master) на удаленную ветку (origin / master). и войдите в так называемое «состояние отсоединения HEAD». Это позволяет вам исследовать, что было сделано вашими коллегами для удаленного репо, выполнив знакомые команды, такие как git log и git diff .
12. git reset [- flag] [# hash] → Представим, что после получения новых коммитов вы были довольны изменениями, внесенными вашей командой, поэтому вы запускаете git pull , чтобы обновить локальный каталог, но на более позднем этапе вы заметили возникла проблема и вы хотели вернуться к предпоследней фиксации, или вы просто хотели посмотреть, как проект выглядел в более ранний момент времени. В обоих случаях вы можете запустить:
$ git reset — hard HEAD~1 HEAD is now at b3088e3 Update git_commands.md
С помощью этой команды Git снова переключается на фиксацию с этим конкретным хешем. Как уже упоминалось, чтобы ускорить рабочий процесс, вы можете воспользоваться специальной переменной HEAD. Флаг - hard сбрасывает рабочий каталог и историю Git в определенное состояние. Если вы пропустили флаг или использовали вместо него флаг - soft, он пропустит внесение изменений в рабочий каталог и только сбросит историю Git.
13. git branch [имя ветки] / git branch -d [имя ветки] → ветки Git позволяют пользователям создавать несколько разных рабочих областей в одном репо. В профессиональной среде очень распространено создание новой ветки, когда вы хотите внести несколько изменений в проект или исправить ошибку, а затем объединить эту ветвь обратно в основную ветвь, когда мы сделано. Когда вы инициализируете новое локальное репо, Git автоматически создает ветвь master:
$ git branch * master
Для создания новых веток выполните следующую команду:
$ git branch project1/add_commands $ git branch project1/branch_to_delete $ git branch* master project1/add_commands project1/branch_to_delete
Таким образом вы создадите две ветви (project1 / add_commands и project1 / branch_to_delete), которые теперь будут перечислены вместе с главной ветвью. Имя ветки должно быть значимым и ясно показывать причину, по которой она была создана в первую очередь (добавить новую функцию, исправить ошибку, выполнить рутинную работу). Чтобы удалить ветку, используйте git branch delete [branch name] команду:
$ git branch -d branch project1/branch_to_delete Deleted branch project1/branch_to_delete (was b3088e3).
14. git checkout [название ветки] → Чтобы переключиться на новую ветку, выполните следующую команду:
$ git checkout project1/add_commands Switched to branch ‘project1/add_commands’
Распространенным ярлыком было бы использовать git checkout -b [branch name] command, которая создает новую ветку и сразу к ней переключается. После того, как вы создали ветку и добавили фиксацию, вы можете отправить ветку в удаленное репо. Это позволяет другим людям видеть ваши изменения и сотрудничать с вами в этой отдельной рабочей области:
$ git push origin project1/add_commands Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 444 bytes | 444.00 KiB/s, done. Total 3 (delta 1), reused 0 (delta 0) remote: Resolving deltas: 100% (1/1), completed with 1 local object. remote: Create a pull request for ‘project1/add_commands’ on GitHub by visiting: remote:https://github.com/anbento0490/code_tutorials/pull/new/project1/add_commands remote: To https://github.com/anbento0490/code_tutorials.git * [new branch] project1/add_commands -> project1/add_commands
В моем случае я добавил последние 5 команд в список и зафиксировал изменения через ветку project1 / add_commands . В конце концов, я отправил фиксацию в удаленное репо, так что теперь в учетной записи GitHub видны две ветки, причем project1 / add_commands отображает на одну фиксацию больше, чем главное репо:
Вы также можете использовать git branch -r , чтобы показать все ветки на пульте дистанционного управления и подтвердить, что ваша есть там. Напротив, git branch -a покажет все ветки, доступные локально:
$ git branch -r origin/master origin/project1/add_commands $ git branch -a master * project1/add_commands remotes/origin/master remotes/origin/project1/add_commands
15. git merge [new_branch name] → Слияние позволяет разработчикам копировать коммиты из одной ветки в другую. Это обеспечивает совместную работу, поскольку каждый член команды может без конфликтов эффективно разрабатывать функции для проектов в своих собственных ветвях, а затем объединять их в master, чтобы конечные пользователи имели к ним доступ. Чтобы объединить project1 / add_commands в master, зарегистрируйтесь в ветке master, а затем выполните git merge command:
$ git checkout master Switched to branch ‘master’ $ git merge project1/add_commands Updating b3088e3..cdb97d4 Fast-forward git_commands.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) $ git branch -d project1/add_commands Deleted branch project1/add_commands (was cdb97d4).
Чтобы избежать путаницы, после того, как недостающие коммиты были объединены в master ветвь, более новая локальная ветвь часто удаляется.
Заключение
Тем, кому удалось дойти до конца этого урока, я говорю: Отлично сделано! Я надеюсь, что то, чему вы здесь научились, вознаградило вас за ваше терпение. В этом посте я познакомил вас с 15 командами Git, которые нужно освоить, прежде чем вы начнете свой первый проект в веб-разработке или науке о данных, так как контроль версий - это круто и избавит вас от многих головных болей! Если вы хотите узнать больше, обязательно ознакомьтесь с этим отличным Учебником по Git, предоставленным Bitbucket.
