Введение в git

Step 10: Get changes on GitHub back to your computer

Right now, the repo on GitHub looks a little different than what you have on your local machine. For example, the commit you made in your branch and merged into the primary branch doesn’t exist in the primary branch on your local machine.

In order to get the most recent changes that you or others have merged on GitHub, use the git pull origin master command (when working on the primary branch). In most cases, this can be shortened to “git pull”.

This shows you all the files that have changed and how they’ve changed.

Now we can use the git log command again to see all new commits.

(You may need to switch branches back to the primary branch. You can do that using the git checkout master command.)

Как работает GitHub

Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.

Принципы работы с репозиторием GitHub

1. С помощью клиента копируем весь репозиторий на свой компьютер (pull).
2. Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
3. Просим клиента внести изменённые файлы в репозиторий. Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit).
4. После коммита версия вашего локального репозитория изменилась.
5. На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция «синхронизация репозиториев» (push).
6. Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.

Такая стандартная схема применима, когда над проектом работает один человек. Если над одним файлом проекта одновременно работает несколько человек, тут не обойтись без конфликтов, слияний, ручных разрешений конфликтов.

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (pull) с GitHub с дополнительной версией этого файла. При копировании произойдет конфликт.

На самом деле сильно конфликтов бояться не надо, при работе в большой команде их не избежать, это становится привычной рутиной.

Способы решения конфликта:

1. Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
2. Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

Ветки — это своеобразные папки со всеми файлами проекта. Ветка Master — это самая главная папка вашего проекта, она всегда существует. Дополнительные ветки создаются под всякие дополнительные нужды.

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development — ветка для непосредственной разработки; dev-adaptive — ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

GitHub поток

Допустим, у вас есть проект, и у вас может быть много разных идей и возможностей в любой момент времени. Некоторые функции могут быть готовы к работе, а некоторые нет. Может быть, вы работаете с другими людьми, которые все делают свое дело. Вот где начинается ветвление!

Филиал — это отдельное пространство, где вы можете опробовать новые идеи. Если вы что-то измените в ветке, это не повлияет на основную ветку, пока вы этого не захотите. Это означает, что вы можете делать с этой веткой все, что захотите, пока не решите, что пришло время объединить ее.

Единственная ветвь, которая собирается навсегда изменить вещи, является основной ветвью. Если вы не хотите, чтобы ваши изменения были развернуты немедленно, внесите их в отдельную ветку и объедините их с основной веткой, когда будете готовы.

Если вы работаете с другими и хотите вносить изменения самостоятельно, или если вы работаете самостоятельно и хотите вносить изменения, не затрагивая основную ветку, вам нужна отдельная ветка. Вы можете создать новую ветку в любое время.

Также довольно просто создать ветку с именем «new_feature» в вашем терминале и переключиться на нее с помощью

git checkout -b new_feature

Как только вы создадите ветку, вы можете внести изменения в эту ветку. Это позволяет легко увидеть, что вы изменили и почему вы это изменили. Каждый раз, когда вы фиксируете свои изменения, вы добавляете сообщение, которое вы можете использовать для описания того, что вы сделали.

Давайте поговорим об оформлении заказа!

git checkout

позволяет проверить хранилище, в котором вы в данный момент не находитесь. Вы можете проверить мастер ветку с

git checkout master

или посмотрите на ветку «new_feature» с

git checkout new_feature

Когда вы закончили работу с веткой, вы можете объединить все свои изменения обратно, чтобы они были видны всем.

git merge new_feature

возьмет все изменения, которые вы внесли в ветку «new_feature», и добавит их в мастер.

Чтобы создать восходящую ветвь, чтобы вы могли отправить свои изменения и установить удаленную ветвь как восходящую, вы добавите свою функцию, запустив

git push --set-upstream origin new_feature

После того, как вы внесете некоторые изменения и решите, что они вам нравятся, вы открываете запрос на включение. Если вы в команде, это когда другие люди в вашей команде могут начать проверять ваши изменения и обсуждать их. Вы можете открыть запрос на удаление в любой момент, будь то, чтобы люди просмотрели ваши окончательные изменения или попросили о помощи, потому что вы застряли на чем-то.

О чём речь

Гит — это такой способ хранения файлов и их версий. Гит позволяет смотреть историю изменений файлов, кто какие дополнения и когда вносил, как развивался проект, кто что в него добавлял и почему.

Главная особенность гита — он помнит всё, что вы в него внесли, и может показать, какие именно строчки вы правили несколько лет назад, когда чинили ошибку авторизации, например.

На базе гита есть сервис «Гитхаб». Работает так:

• все рабочие файлы проекта синхронизируюся между облаком и вашим компьютером;
• такая синхронизация происходит у каждого участника проекта;
• можно настроить автоматическую синхронизацию, а можно отправлять изменения вручную;
• можно отправить на сервер изменения, которые сделали вы на своём компьютере, а можно наоборот — скачать себе те, которые внесли в проект другие программисты.

Это полезно, например, когда несколько человек параллельно пилят совместный проект. Каждый работает над своим файлом или даже своим куском одного файла. Всю работу авторы синхронизируют между собой: чтобы не было ситуации, что два человека редактируют один и тот же файл, а потом затирают результаты работы друг друга, сами того не зная. 

Это если вкратце. Теперь будут подробности.

Как работать с Git?

В Git имеется много команд, поэтому разобьём их по теме и причине использования. Но начнём с того, что рассмотрим работу Git на локальной машине, ведь большая часть операций происходит именно там. После этого перейдём к многопользовательскому формату.

Вообще, с Git можно работать и через графический интерфейс (например, GitHub Desktop), и через командную строку. Командную строку изучить необходимо хотя бы потому, что она предоставляет больше возможностей, чем некоторые инструменты с интерфейсом.

Обычно, команды Git имеют следующий вид:

git <команда> <аргументы>

В качестве аргумента может быть путь к файлу. Также у команд бывают опции, обозначаемые —<опция> либо -<однобуквенная опция>. Они обеспечивают более детальную настройку действия команды. В нашем материале команды будут представлены в общем виде, а значит всё, что будет в <>, вы можете менять на собственные значения.

Кстати, если возникают затруднения с использованием той либо иной команды, рекомендуется открыть руководство посредством git help <команда>. Если просто нужно напоминание, применяйте git <команда> -h либо git <команда> —help (в Git -h и —help имеют одинаковое значение).

Install Git on Mac OS X

There are several ways to install Git on a Mac. In fact, if you’ve installed XCode (or it’s Command Line Tools), Git may already be installed. To find out, open a terminal and enter .

Apple actually maintain and ship their own fork of Git, but it tends to lag behind mainstream Git by several major versions. You may want to install a newer version of Git using one of the methods below:

Git for Mac Installer

The easiest way to install Git on a Mac is via the stand-alone installer:

1. Download the latest Git for Mac installer.

2. Follow the prompts to install Git.

3. Open a terminal and verify the installation was successful by typing :

4. (Optional) To make Git remember your username and password when working with HTTPS repositories, .

Install Git with Homebrew

If you have installed Homebrew to manage packages on OS X, you can follow these instructions to install Git:

1. Open your terminal and install Git using Homebrew:

2. Verify the installation was successful by typing which :

3. (Optional) To make Git remember your username and password when working with HTTPS repositories, install the .

Install Git with MacPorts

If you have installed MacPorts to manage packages on OS X, you can follow these instructions to install Git:

1. Open your terminal and update MacPorts:

2. Search for the latest available Git ports and variants:

3. Install Git with bash completion, the OS X keychain helper, and the docs:

4. (Optional) To make Git remember your username and password when working with HTTPS repositories, configure the git-credential-osxkeychain helper.

Install the git-credential-osxkeychain helper

Bitbucket supports pushing and pulling your Git repositories over both SSH and HTTPS. To work with a private repository over HTTPS, you must supply a username and password each time you push or pull. The git-credential-osxkeychain helper allows you to cache your username and password in the OSX keychain, so you don’t have to retype it each time.

1. If you followed the MacPorts or Homebrew instructions above, the helper should already be installed. Otherwise you’ll need to download and install it. Open a terminal window and check:

   If you receive a usage statement, skip to step 4. If the helper is not installed, go to step 2.

2. Use curl to download git-credential-osxkeychain (or download it via your browser) and move it to :

3. Make the file an executable:

4. Configure git to use the osxkeychain credential helper.

   The next time Git prompts you for a username and password, it will cache them in your keychain for future use.

Install Git with Atlassian Sourcetree

Sourcetree, a free visual Git client for Mac, comes with its own bundled version of Git. You can download Sourcetree here.

To learn how to use Git with Sourcetree (and how to host your Git repositories on Bitbucket) you can follow our comprehensive Git tutorial with Bitbucket and Sourcetree.

Build Git from source on OS X

Building Git can be a little tricky on Mac due to certain libraries moving around between OS X releases. On El Capitan (OS X 10.11), follow these instructions to build Git:

1. From your terminal install XCode’s Command Line Tools (if you haven’t already):

2. Install Homebrew.

3. Using Homebrew, install openssl:

4. Clone the Git source (or if you don’t yet have a version of Git installed, download and extract it):

5. To build Git run make with the following flags:

Эмммм… это делается через сайт?

Да, все это делается с сайта GitHub.

Pull request создается по нажатию одноименной кнопки, о которой мы говорили ранее при редактировании README-файла. Элементарно!

А еще вы можете создать отдельную ветку на сайте через сам репозиторий. Перейдите в репозиторий и кликните по выпадающему меню в левой части экрана. Там еще написано Branch: master. Задайте имя новой ветки и выберите Create branch (либо нажмите на клавиатуре). Теперь у вас есть две одинаковые ветки. Это отличное место для внесения изменений и тестирования их до слияния с .

Создание ветки

Если вы работаете в отдельной ветке, то изменения затронут только ее.

Если вас устраивают внесенные изменения вы и хотите слить их с основной веткой, создайте Pull request. При коллективной работе вы можете предложить свои изменения через Pull request и попросить проверить их или слить их с нужными ветками.

Pull request можно открыть сразу при создании коммита, даже если вы все еще работаете с кодом. Делается это с сайта GitHub. Допустим, вы внесли изменения в ветку и хотите слить их с . Тогда:

• Кликните по вкладке Pull request вверху экрана.
• Нажмите зеленую кнопку New pull request.
• Перейдите в поле Example Comparisons. Выберите ветку, которую хотите сравнить с .
• Еще раз просмотрите все изменения, убедитесь, что они готовы для коммита.
• Нажмите большую зеленую кнопку New pull request. Напишите заголовок запроса, дайте краткое описание изменений. Нажмите Create pull request.

Новый Pull request

Создание pull request

Если это ваш репозиторий, то слить изменения с можно через зеленую кнопку Merge pull request. Нажмите Confirm merge. Сразу после объединения нужной ветки с нажмите Delete branch в фиолетовом боксе.

Если вы участвуете в чужом проекте, то у участников команды (или проверяющего коммиты) могут возникнуть вопросы или замечания. Хотите внести какие-то изменения? Сейчас — самое время. Сразу по завершению изменений участники проекта смогут развертывать эти изменения напрямую из ветки и проводить конечное тестирование до слияния с . Вы также сможете произвести развертку изменений для проверки их в рабочей среде.

После утверждения изменений необходимо произвести слияние вашего кода с веткой . В Pull request хранится запись о ваших изменениях. Таким образом, вы всегда сможете открыть этот запрос и понять, какие изменения были сделаны и почему.

Как просматривать изменения в файловых системах?

Для этого используют команду git status. Она отображает все файлы, которые различаются между 3-мя отделами. Файлы имеют четыре состояния:
1) untracked (неотслеживаемый). Находится в рабочей директории, но его нет ни в HEAD, ни в области подготовленных файлов. Можно сказать, что Git о нём не знает;
2) modified (изменён). В рабочей директории находится его более новая версия по сравнению с той, которая хранится в HEAD либо в области подготовленных файлов (при этом изменения не находятся в следующем коммите);
3) staged (подготовлен). В области подготовленных файлов и в рабочей директории есть более новая версия, если сравнивать с хранящейся в HEAD, но файл уже готов к коммиту;
4) без изменений. Во всех разделах содержится одна версия файла, то есть в последнем коммите находится актуальная версия.

Чтобы посмотреть не изменённые файлы, а непосредственно изменения, можно использовать:
— git diff — для сравнения рабочей директории с областью подготовленных файлов;
— git diff —staged — для сравнения области подготовленных файлов с HEAD.

В случае применения аргумента <файл/папка> diff покажет изменения лишь для указанных вами папок или файлов, к примеру:

git diff src/

Install Git on Windows

1. Navigate to the latest Git for Windows installer and download the latest version.
2. Once the installer has started, follow the instructions as provided in the Git Setup wizard screen until the installation is complete.
3. Open the windows command prompt (or Git Bash if you selected not to use the standard Git Windows Command Prompt during the Git installation).
4. Type to verify Git was installed.

Note: is a popular and recommended resource for downloading Git for Windows. The advantage of downloading Git from is that your download automatically starts with the latest version of Git included with the recommended command prompt, . The download source is the same Git for Windows installer as referenced in the steps above.

Install Git on Linux

Debian / Ubuntu (apt-get)

Git packages are available via apt:

1. From your shell, install Git using apt-get:

2. Verify the installation was successful by typing :

Fedora (dnf/yum)

Git packages are available via both yum and dnf:

1. From your shell, install Git using dnf (or yum, on older versions of Fedora):

   or

2. Verify the installation was successful by typing :

Build Git from source on Linux

Debian / Ubuntu

Git requires the several dependencies to build on Linux. These are available via apt:

1. From your shell, install the necessary dependencies using apt-get:

2. Clone the Git source (or if you don’t yet have a version of Git installed, download and extract it):

3. To build Git and install it under , run :

Fedora

Git requires the several dependencies to build on Linux. These are available via both yum and dnf:

1. From your shell, install the necessary build dependencies using dnf (or yum, on older versions of Fedora):

   or using yum. For yum, you may need to install the Extra Packages for Enterprise Linux (EPEL) repository first:

2. Symlink docbook2X to the filename that the Git build expects:

3. Clone the Git source (or if you don’t yet have a version of Git installed, download and extract it):

4. To build Git and install it under , run :

Ветки (Branches)

Посмотреть какая ветка сейчас активна

$ git branch

* master

Прежде чем создавать новую ветку нужно убедиться в том, что
в старой нет несохранённых изменений.

$ git status

On branch master
nothing to commit, working tree clean

Создать новую ветку

$ git branch new-branch

Проверить появилась ли она в списке

$ git branch

* master
new-branch

Перейти в новую ветку

$ git checkout new-branch

Switched to branch ‘new-branch’

Вернуться в ветку master

$ git checkout master

Если Вы сделали в ветке new-branch какие-то изменения, закоммитили из и теперь хотите,
добавить эти изменения в ветку master нужно выполнить команду merge

$ git merge new-branch

Updating f521fc5..fe7276a
Fast-forward
index.html | 3 &plus;&plus;-
1 file changed, 2 insertions(+), 1 deletion(-)

Создать новую ветку и сразу перейти в неё можно одной командой

$ git checkout -b new-branch-2

Удалить ветку

Удалить локальную ветку

git branch -d branchName

Deleted branch branchName (was 1ce400ce6).

Удалить внешнюю ветку

git push origin —delete remoteBranchName

Качаем и устанавливаем софт

1. msysgit – качаем Git For Windows
2. TortoiseGit. На момент написания статьи последней была версия (19.6 MB). Новые версии Вы можете найти также по приведенной ссылке.

Получается, что скачать нам надо чуть больше 30 Mb.
Теперь устанавливаем скачанные программы.

Вначале ставим msysgit, а потом TortoiseGit.

При установке msysgit настройки по умолчанию можно не изменять.
При установке TortoiseGit выбираем в окне “Choose SSH Client” второе значение:
После успешной установки обоих продуктов работу над первым этапом можно считать завершенной. Приступим ко второму – получение доступа к репозиторию Git.

Скрывайте локальные изменения, когда не хотите их «вливать»

А теперь про то, когда Вы не хотите чтобы отслеживались изменённые файлы. Яркий пример: очень многие, особенно долгоживущие репозитории, хранят в себе ряд конфигов. Часто они служат для обеспечения единообразия настроек (к примеру, ) или тасков сборки/линтинга (). И иногда так случается, что хочется их как-то изменить, но возможность разделения конфигов на «общие» и «пользовательские» отсутствует.

Есть административный вариант решения проблемы: вынести все конфиги в отдельную папку, из которой каждый будет сам копировать конфиги в нужные места. И есть путь одиночки возможность заоверрайдить на месте и пометить файл как неизменённый:

С этих пор он «пропадает с радаров» даже если Вы продолжите его изменять. Если во время -а приходят новые изменения в этом же файле — в этом случае он будет продолжать считаться неизменённым, но легко смержиться Вам не даст. Чтобы вернуть всё как было, надо снять флаг, добавив :

Как бороться с конфликтом Git Merge

Когда несколько человек работают с одними и теми же файлами, вы столкнетесь с конфликтами слияния. Когда возникает конфликт, Git изменяет ваши локальные файлы, и вы можете вручную исправить файлы с конфликтами.

Совет: Используйте команду git status, чтобы увидеть статус и информацию о конфликте слияния.

Откройте файл с конфликтом, чтобы начать исправление ошибок. В приведенном ниже примере файла у нас был текстовый файл с одной строкой текста, а в локальный репозиторий мы добавили в файл текст «update1». Однако в то же время файл удаленного репозитория был изменен и добавлен «update2» в файл в той же строке. Git помечает конфликты как «<<<<<< >>>>>> <hash>» для обозначения конца конфликта.

 Еще один файл, который загружается между ними. <<<<<< >>>>>> 62ee0eeba2e5b94d10574c1a6a68216e9b392e4c 

Чтобы разрешить этот конфликт слияния, нам нужно решить, какой текст мы хотим сохранить, обновить или удалить. В этом примере мы хотим сохранить «update1» и «update2» в том порядке, в котором они перечислены, поэтому нам нужно всего лишь удалить маркировку Git, чтобы файл напоминал следующий пример.

 Еще один файл, который загружается между ними. обновление1 обновление2 

Примечание. Если вы работаете с большим файлом, рекомендуется выполнить поиск по слову «HEAD», поскольку возможно, что конфликт может быть более одного.

После внесения изменений в файл мы можем сохранить файл и затем выполнить следующие команды git для обновления исправлений.

 мерзавец добавить. 

 git commit -m "Исправлен конфликт слияния" 

 мастер происхождения git push 

Пример, приведенный в этом конфликте слияния, является очень простым примером. При работе с файлом, который содержит более нескольких строк текста или содержит большие разделы кода, конфликтующие с конфликтом слияния могут стать намного более запутанными. Чтобы упростить обработку конфликтов слияния, вы можете использовать команду git mergetool, чтобы использовать инструмент слияния, такой как WinMerge или другой популярный инструмент слияния.

Размещение кода в облаке

Теперь, когда вы узнали, как управлять кодом в вашей системе, пришло время разместить код в облаке.

Поскольку Git не имеет центрального сервера как Subversion, вам нужно добавить каждый источник для взаимодействия с другими. Вот тут возникает понятие remote. remote означает удаленную версию вашего репозитория.

Если вы хотите разместить код в облаке, вы можете создать проект на GitHub, GitLab или BitBucket и поместить уже существующий код в репозиторий.

В этом случае удаленный репозиторий в облаке будет выступать в роли удаленного для вашего локального репозитория. Для удобства, удаленный репозиторий, в котором у вас есть доступ на запись, называется origin.

После того, как вы создадите удаленный репозиторий, у вас появится возможность добавить удаленный origin и затем поместить код в origin:

git remote add origin https://github.com/sdaityari/my_git_project.git
git push -u origin master

Install Git on Mac

Most versions of MacOS will already have installed, and you can activate it through the terminal with . However, if you don’t have Git installed for whatever reason, you can install the latest version of Git using one of several popular methods as listed below:

Install Git From an Installer

1. Navigate to the latest macOS Git Installer and download the latest version.
2. Once the installer has started, follow the instructions as provided until the installation is complete.
3. Open the command prompt «terminal» and type to verify Git was installed.

Note: is a popular and recommended resource for downloading Git on a Mac. The advantage of downloading Git from is that your download automatically starts with the latest version of Git. The download source is the same macOS Git Installer as referenced in the steps above.

Install Git from Homebrew

Homebrew is a popular package manager for macOS. If you already have Homwbrew installed, you can follow the below steps to install Git:

1. Open up a terminal window and install Git using the following command: .
2. Once the command output has completed, you can verify the installation by typing: .

Создаём новый репозиторий

Создаём у себя на компьютере (например, на диске C:) папку projects, где локально будут храниться все наши репозитории.

Переходим в Github Desktop, нажимаем на начальном экране “Create a New Repository on your hard drive…“ или File > New Repository

В открывшемся окне в поле Name пишем название репозитория. В поле Description — описание репозитория, если необходимо. В Local Path выбираем созданную на диске C: папку projects, остальное оставляем по-умолчанию и нажимаем “Create repository”

В папке projects появился репозиторий Project-1

В репозитории Project-1 на данный момент находятся только необходимые служебные файлы Git.

На данный момент репозиторий расположен только локально на компьютере в папке Project-1. Чтобы репозиторий появился в аккаунте GitHub и хранился там, нажимаем “Publish repository”

В появившемся окне оставляем все по-умолчанию. Пункт “Keep this code private” оставляем отмеченным, чтобы репозиторий, пока что, был виден только нам, потом в любой момент репозиторий можно будет сделать открытым, чтобы его видели другие пользователи GitHub. Нажимаем “Publish repository”

Теперь репозиторий скопирован в аккаунт GitHub. Переходим в браузере на GitHub. Сверху справа нажимаем на круглую иконку аккаунта и выбираем пункт “Your repositories”

На странице наших репозиториев появился созданный репозиторий Project-1

Откроем страницу репозитория, нажав на название репозитория в списке. На данный момент в репозитории только служебные файлы.

Создадим на компьютере в папке Project-1 файл index.html и напишем в нем минимальную разметку.

На данный момент файл index.html расположен только локально в папке Project-1. Локальная система Git, которая была создана вместе с репозиторием, об этом файле ничего не знает.

Чтобы Git узнала, что в репозиторий добавился файл, необходимо сообщить это через команду Commit.

Commit — фиксирование текущего состояния файлов, звучит как коммит.

Коммитам необходимо давать названия.

Откроем Github Desktop. Во вкладке Changes видим созданный index.html.

Вводим в поле ниже название коммита — . Затем нажимаем “Commit to main”, чтобы зафиксировать данное состояние файлов в локальную систему Git. (На данный момент не будем углубляться в ветвление Git)

На данный момент мы зафиксировали файлы в текущем состоянии и сделали запись об этом в локальную систему Git.

Далее, чтобы передать изменения в репозиторий на GitHub, нажимаем “Push origin”

Переходим в наш репозиторий на GitHub и убеждаемся, что файл index.html был добавлен

Далее внесем изменения в файл index.html — добавим заголовок

Переходим в GitHub Desktop, видим что index.html был изменен, вводим название нового коммита — и нажимаем “Commit to main”

И снова передаем изменения в репозиторий на GitHub — нажимаем “Push origin”

Видим, что index.html был изменен при коммите

Нажав на название файла index.html, убеждаемся что заголовок добавлен

На данный момент умеем создать репозиторий, делать коммиты, и передавать на GitHub

Далее рассмотрим работу с GitHub Desktop с нескольких рабочих мест

Step 5: Create a new branch

Now that you’ve made a new commit, let’s try something a little more advanced.

Say you want to make a new feature but are worried about making changes to the main project while developing the feature. This is where git branches come in. 

Branches allow you to move back and forth between ‘states’ of a project. Official git docs describe branches this way: ‘A branch in Git is simply a lightweight movable pointer to one of these commits.’ For instance, if you want to add a new page to your website you can create a new branch just for that page without affecting the main part of the project. Once you’re done with the page, you can merge your changes from your branch into the primary branch. When you create a new branch, Git keeps track of which commit your branch ‘branched’ off of, so it knows the history behind all the files. 

Let’s say you are on the primary branch and want to create a new branch to develop your web page. Here’s what you’ll do: Run git checkout -b <my branch name>. This command will automatically create a new branch and then ‘check you out’ on it, meaning git will move you to that branch, off of the primary branch.

After running the above command, you can use the git branch command to confirm that your branch was created:

The branch name with the asterisk next to it indicates which branch you’re on at that given time. 

Рабочий процесс на GitHub

Допустим, у вас есть проект с кучей разных идей и возможностей для дальнейшей реализации. Что-то из этого уже готово, а над чем-то еще стоит потрудиться. Вполне возможно, что вы сотрудничаете с другими пользователями, которые работают над чем-то своим. Здесь и пригодится ветвление!

Ветка — это отдельное место для реализации новых идей. Изменения в ветке не затронут основную ветку до тех пор, пока вы сами этого не захотите. То есть с отдельной веткой вы делаете что угодно, а затем просто сливаете эти изменения с основной веткой .

Единственная ветка, которая может изменять проект, — это . Если вы не хотите вносить изменения сразу, то выделите их отдельной веткой, а затем сливайте с .

Если вы работаете с другими и хотите внести собственные изменения либо работаете над проектом и хотите изменить что-то, не затрагивая , то создавайте отдельную ветку. Сделать это можно в любое время.

Очень удобно создавать в терминале ветку с названием (новая опция) и переходить в нее по команде:

git checkout -b new_feature

Вносить изменения в ветку можно сразу после ее создания. Использование отдельных веток с подходящими названиями позволяет сразу понять, что именно изменялось и почему. Каждый новый коммит следует снабжать комментарием, описывающим суть изменений.

Теперь поговорим о переключении между ветками:

git checkout

Команда позволяет «заглянуть» в репозиторий, который в данный момент не открыт. Например, вы можете перейти в ветку :

git checkout master

или открыть ветку :

git checkout new_feature

По завершению работы с веткой можно слить эти изменения с , чтобы их увидели другие.

git merge new_feature

Эта команда берет все изменения в ветке и добавляет их в ветку .

Вы можете отправить изменения в репозиторий и установить удаленную ветку (например, ) в качестве «отслеживаемой»:

git push — set-upstream origin new_feature

Допустим, вы внесли какие-то изменения. Эти изменения вас устраивают, и вы хотите создать запрос на принятие изменений (Pull request). В Pull request ваши коллеги смогут проверить внесенные изменения и обсудить их. Pull request можно создавать по любому поводу, будь то внесение конечных изменений или просьба о помощи в решении какой-либо проблемы.