diff --git a/README.md b/README.md index 4c60c59..85b6f4c 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ https://git-scm.com/download/win ## Установка Visual Studio Code Загружаем последнюю версию Git с сайта: https://code.visualstudio.com/download -и устанавливаем с настройками " по умолчанию ". +и устанавливаем с настройками "по умолчанию". ## Настройка Git При первом использовании Git необходимо представиться ``` @@ -22,7 +22,7 @@ git config --global user.name your name git config --global user.email your e-mail ``` ## Создание и инициализация репозитория -*Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жёстком диске.* +*Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определённых папках на жёстком диске.* Для начала нужно создать папку, в которой будут храниться файлы нашего проекта и которую будет отслеживать Git. Затем открыть её, используя меню "Файл". @@ -49,7 +49,7 @@ git add git commit -m "comment" ``` -*По-английски commit значит «фиксировать». Git-коммит — это операция, которая берет все подготовленные изменения и отправляет их в репозиторий как единое целое.* +*По-английски commit значит «фиксировать». Git-коммит — это операция, которая берёт все подготовленные изменения и отправляет их в репозиторий как единое целое.* То есть **_коммит_** — это некое логически завершённое изменение внутри проекта и понятная (в том числе и другим разработчикам) точка, к которой можно вернуться, если возникнут какие-то проблемы. @@ -65,7 +65,7 @@ git show ``` git log ``` -Однако же, стоит заметить, что существует ещё один способ, позволяющий уменьшить количество информации, выдаваемой на экран. С параметром `--oneline` каждый коммит показывается в одну строчку, но в данном случае вы не видим информации о времени и авторе коммитов. +Однако же, стоит заметить, что существует ещё один способ, позволяющий уменьшить количество информации, выдаваемой на экран. С параметром `--oneline` каждый коммит показывается в одну строчку, но в данном случае мы не видим информации о времени и авторе коммитов. *В Git не существует традиционной системы отмены, как в текстовых редакторах. Лучше воздержаться от сопоставления операций Git с какой бы то ни было привычной для нас концепцией отмены изменений. Кроме того, Git имеет собственную систему терминов для операций отмены. В числе таких терминов — `сброс (reset),` `возврат (revert),` `переключение (checkout),` `очистка (clean)` и другие.* @@ -89,14 +89,14 @@ git diff (без параметров) ``` Важно, что в данном случае команда выводит изменения в файлах, которые ещё не были добавлены в индекс. Сравнение происходит с последним коммитом. -Однако, если мы изменили какие-нибудь файлы в вашем рабочем каталоге и добавили один или несколько из них в индекс (`с помощью git add`), то команда `git diff` не покажет изменения в этих файлах. Для того, чтобы показать изменения в наших файлах, включая файлы, которые были добавлены нами в индекс, используется уже известную комманду с ключом +Однако, если вы изменили какие-нибудь файлы в вашем рабочем каталоге и добавили один или несколько из них в индекс (`с помощью git add`), то команда `git diff` не покажет изменения в этих файлах. Для того, чтобы показать изменения в наших файлах, включая файлы, которые были добавлены вами в индекс, используется уже известная команда с ключом ``` git diff --cached ``` ## Игнорирование файлов -Для того, чтобы исключить из отслеживания в репозитории определённый файл (группу файлов и папок).В случае необходимости следует создать там файл `.gitignore` и записать в него их названия или шаблоны, соответствующие таким файлам или папкам. +Для того, чтобы исключить из отслеживания в репозитории определённый файл (группу файлов и папок). В случае необходимости следует создать там файл `.gitignore` и записать в него их названия или шаблоны, соответствующие таким файлам или папкам. -`.gitignore` использует glob шаблоны для сопоставления имен файлов с символами подстановки. Это может напоминать регулярные выражения. Если у нас есть файлы или папки, содержащие шаблон подстановки (например *), вы можете использовать один обратный слеш ( \ *), чтобы экранировать такой символ. +`.gitignore` использует glob шаблоны для сопоставления имён файлов с символами подстановки. Это может напоминать регулярные выражения. Если у вас есть файлы или папки, содержащие шаблон подстановки (например *), вы можете использовать один обратный слеш ( \ *), чтобы экранировать такой символ. Строки, начинающиеся со знака хэша (#), являются комментариями и игнорируются. Пустые строки могут быть использованы для улучшения читабельности файла и группировки связанных строк шаблонов. @@ -105,7 +105,7 @@ git diff --cached Однако, если шаблон не начинается со слэша, он соответствует файлам и каталогам в любом каталоге или подкаталоге. В случае, когда шаблон заканчивается знаком слэш, он соответствует только каталогам. Когда каталог игнорируется, все его файлы и подкаталоги также игнорируются. ## Создание веток в Git -Ветка в Git простой перемещаемый указатель на один из коммитов, обычно последний в цепочке коммитов. По уполчанию, имя овновной ветки в Git - `master`. Создать ветку можно коммандой: +Ветка в Git простой перемещаемый указатель на один из коммитов, обычно последний в цепочке коммитов. По умолчанию, имя основной ветки в Git - `master`. Создать ветку можно командой: ``` git branch <название новой ветки> ``` @@ -118,25 +118,25 @@ git checkout -b <имя новой ветки> **_Ветка_** – независимая последовательность коммитов. -**_Сливаемая ветка_** – ветка, из которой мы берем изменения, чтобы влить их в целевую. +**_Сливаемая ветка_** – ветка, из которой мы берём изменения, чтобы влить их в целевую. **_Целевая ветка_** – ветка, в которую мы сливаем наши изменения. -**_Слияние веток_** – это перенос изменений из одной ветки в другую. При этом слияние не затрагивает сливаемую ветку, то есть она остается в том же состоянии, что позволяет нам потом продолжить работу с ней. +**_Слияние веток_** – это перенос изменений из одной ветки в другую. При этом слияние не затрагивает сливаемую ветку, то есть она остаётся в том же состоянии, что позволяет нам потом продолжить работу с ней. Первоначально мы работаем в основной (целевой) ветке. Она называется master. Целью создания дополнительных веток является проработка отдельных элементов проекта автономно, а затем присоединение их к проекту. В большинстве случаев эти ветки в итоге объединяются с веткой *master*. Процедура объединения веток называется *слиянием (merge)*. -Для слияния текущей ветки с либой дрйгой веткой используем команду: +Для слияния текущей ветки с любой другой веткой используем команду: ``` git merge <имя ветки, которую хотим присоединить> ``` ## Разрешение конфликтов -При слиянии может возникнуть ситуация, когда фрагмент в каком-либо файле проекта в различных ветках отредактирован по разному. Такая ситуация называется конфликт (**_conflict_**). +При слиянии может возникнуть ситуация, когда фрагмент в каком-либо файле проекта в различных ветках отредактирован по-разному. Такая ситуация называется конфликт (**_conflict_**). Иными словами, если мы изменили одну и ту же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить и мы получим сообщение о конфликте слияния. И, следовательно, Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока мы не разрешим конфликт. -Начало конфликтного фрагмента помечается строкой, начинающиеся с символов -< и содержащей имя первой ветки, а заканчивается строкой, начинающиеся с символов > и содержащей имя вливаемой ветки. Версии из каждой ветки разделяются строкой с символами =. Такой файл получает статус не объединенный (**_unmerged_**). +Начало конфликтного фрагмента помечается строкой, начинающейся с символов +< и содержащей имя первой ветки, а заканчивается строкой, начинающейся с символов > и содержащей имя вливаемой ветки. Версии из каждой ветки разделяются строкой с символами =. Такой файл получает статус необъединённый (**_unmerged_**). На выбор мы получаем четыре команды: ``` @@ -146,9 +146,9 @@ accept both changes - принять оба изменения compare changes - сравнить изменения ``` -При возникновении конфликта мы должны в ручном режиме его устранить. После редактирования конфликтной области и сохранения файла, нужно сообщить git о разрешении конфликта с помощью индексирования этого файла (после чего он перейдет в состояние «измененный»). +При возникновении конфликта мы должны в ручном режиме его устранить. После редактирования конфликтной области и сохранения файла, нужно сообщить git о разрешении конфликта с помощью индексирования этого файла (после чего он перейдет в состояние «изменённый»). ## Удаление веток -Для организации разработки различных версий дркумента в Git, как было описано выше, мы используем ветки. Ветки также очень часто используются для разработки какого-либо нового функционала или инструментария. Если разработкой продукта занимается группа, каждый разработчик может работать над своей частью функциональности в отдельной ветке. +Для организации разработки различных версий документа в Git, как было описано выше, мы используем ветки. Ветки также очень часто используются для разработки какого-либо нового функционала или инструментария. Если разработкой продукта занимается группа, каждый разработчик может работать над своей частью функциональности в отдельной ветке. В итоге, когда работы будут завершены, получившуюся ветку мы совмещаем с основной перед этим отправив её на проверку коллегам. При таком типе организации рабочего процесса со временем в нашем репозитории накапливается очень много ненужных или пустых веток, которые надо удалять. @@ -156,27 +156,27 @@ compare changes - сравнить изменения ``` git branch ``` -Данная команда выведет список наших веток, а текущая ветка, в ктороый мы находимся, будет выделена зеленым цветом и звездочкой. +Данная команда выведет список наших веток, а текущая ветка, в которой мы находимся, будет выделена зелёным цветом и звёздочкой. -Для того чтобы удалить ветку необходимо использовать комманду: +Для того чтобы удалить ветку необходимо использовать команду: ``` git branch -d <название ветки> ``` -Если в этой ветке есть не зафиксированные изменения или коммиты, то Git откажется её удалять. Для того чтобы всё же удалить такую ветку используйте комманду: +Если в этой ветке есть незафиксированные изменения или коммиты, то Git откажется её удалять. Для того чтобы всё же удалить такую ветку используйте команду: ``` git branch -D <название ветки> ``` -После этого проверяем список веток коммандой: +После этого проверяем список веток командой: ``` git branch ``` Если всё сделано верно, то удалённой ветки мы не увидим. -## Полезные комманды Git -Обычно, для просмотра лога и коммитов мы используем комманду: +## Полезные команды Git +Обычно, для просмотра лога и коммитов мы используем команду: ``` git log ``` -На выводе мы получаем не очень удобный для чтения ворох данных. Для формирования лога в удобном для чтения и понимания виде предлагаю использовать комманду: +На выводе мы получаем не очень удобный для чтения ворох данных. Для формирования лога в удобном для чтения и понимания виде предлагаю использовать команду: ``` git log --pretty=format:"%H [%cd]: %an - %s" --graph --date=format:%c ``` @@ -187,11 +187,11 @@ git checkout -b ``` **_Пояснение_**: _создать ветку new-branch, начинающуюся с коммита c хешем 5589877 (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита, создать указатель на этот коммит (ветку) с указанным именем)_ ## Работа с удалёнными репозиториями -**_Удалённый репозиторий_** (внешний репозиторий) – представляет собой версии вашего проекта, размещённые на каком-либо удалённом сервере (в нашем случае это GitHub). Доступ к такому репозиторию удалённом сервере может осуществляться по средствам сети интернет или же через локальную сеть. +**_Удалённый репозиторий_** (внешний репозиторий) – представляет собой версии вашего проекта, размещённые на каком-либо удалённом сервере (в нашем случае это GitHub). Доступ к такому репозиторию на удалённом сервере может осуществляться посредством сети интернет или же через локальную сеть. _Удалённый репозиторий_ – это абсолютно полноценный репозиторий, не имеющий никаких отличий от локального: у удалённого репозитория есть собственные ветки, собственный указатель HEAD, своя история коммитов и так далее. ### 1. Регистрация аккаунта на [GitHub](https://github.com/) -Для этого yнеобходимо перейти на [GitHub]( https://github.com/). Далее, находим и нажимаем кнопку «Sign up» (зарегистрироваться). На странице регистрации вам предложат ввести обязательные данные: имя пользователя; адрес электронной почты; пароль. После на указанную ранее почту придёт письмо с просьбой подтвердить электронный адрес. Для завершения регистрации необходимо перейти по полученной ссылке. +Для этого необходимо перейти на [GitHub]( https://github.com/). Далее, находим и нажимаем кнопку «Sign up» (зарегистрироваться). На странице регистрации вам предложат ввести обязательные данные: имя пользователя; адрес электронной почты; пароль. После на указанную ранее почту придёт письмо с просьбой подтвердить электронный адрес. Для завершения регистрации необходимо перейти по полученной ссылке. ### 2. Создаём и связываем локальный и удалённый репозиторий В обычных случаях мы получаем репозиторий Git двумя способами: * Берём локальную папку, которая не находится под контролем (не индексируется), и превращаем её в репозиторий Git: @@ -228,7 +228,7 @@ git fetch <назвение незвание> ``` Эта команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у нас пока ещё нет. После того как мы выполнили команду, у нас должны появиться ссылки на все ветки из этого удалённого проекта, которые мы можем просмотреть или слить в любой момент. -Важно понимать, что когда мы клонировали репозиторий, команда `git clone` автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, `git fetch origin` извлекает все наработки, отправленные на этот сервер после того, как мы его клонировали. принципиальным является то, что команда `git fetch` забирает данные в наш локальный репозиторий, но не сливает их с какими-либо нашими наработками и не модифицирует то, над чем вы работаете в данный момент. После выплнения команды нам необходимо вручную слить эти данные с нашими, когда это потребуется. +Важно понимать, что когда мы клонировали репозиторий, команда `git clone` автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, `git fetch origin` извлекает все наработки, отправленные на этот сервер после того, как мы его клонировали. Принципиальным является то, что команда `git fetch` забирает данные в наш локальный репозиторий, но не сливает их с какими-либо нашими наработками и не модифицирует то, над чем вы работаете в данный момент. После выполнения команды нам необходимо вручную слить эти данные с нашими, когда это потребуется. ### 4. Отправка изменений в удалённый репозиторий В случае, если мы хотим поделиться своими наработками в репозитории, нам необходимо отправить их в удалённый репозиторий. Для этого выполняем команду: ``` @@ -238,7 +238,7 @@ git push ``` git push origin master ``` -### 5. Просмотр удаленного репозитория +### 5. Просмотр удалённого репозитория Для обычного просмотра содержимого удалённого репозитория используем команду: ``` git remote show @@ -260,7 +260,7 @@ remote origin Local ref configured for 'git push': main pushes to main (fast-forwardable) ``` -Команда выдала нам URL удалённого репозитория, а также информацию об отслеживаемых ветках, а так же сообщает, что если мы, находясь на ветке main, выполните `git pull`, ветка main с удалённого сервера будет автоматически влита в нашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок. +Команда выдала нам URL удалённого репозитория, а также информацию об отслеживаемых ветках, а так же сообщает, что если мы, находясь на ветке main, выполним `git pull`, ветка main с удалённого сервера будет автоматически влита в нашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок. ## Работа с `pull request` Находясь в чужом репозитории на [GitHub](https://github.com/), в правом верхнем углу, нажать кнопку `Fork`. ![Fork](1.jpg) @@ -270,9 +270,9 @@ remote origin После этого, копию репозитория клонируем на наш компьютер. Для этого используем команду: ``` -git clone <адрес удалённого репозитория +git clone <адрес удалённого репозитория> ``` -Сейчас, сделав необходимые правки, сделав коммит, сделав commit, загружаем изменения в свой репозиторий на [GitHub](https://github.com/). Для этого используем команды: +Сейчас, сделав необходимые правки, сделав коммит (commit), загружаем изменения в свой репозиторий на [GitHub](https://github.com/). Для этого используем команды: ``` git add git commit -m "Change details" @@ -292,6 +292,6 @@ git push После этого требуется нажать кнопку `«Create pull request»`. ![Create pull request_knopka](5.jpg) -Если есть необходимость, то следует добавить какой-либо комментарий к нашему `pull request`. После этого еще раз нажимаем кнопку `«Create pull request»`. +Если есть необходимость, то следует добавить какой-либо комментарий к нашему `pull request`. После этого ещё раз нажимаем кнопку `«Create pull request»`. -Pull Request отправлен! \ No newline at end of file +Pull Request отправлен!