Инструкция: заливаем проект на github без командной строки

Введение

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

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

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

Изменение старых или нескольких коммитов

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

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

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

Изменение файлов после коммита

Во время операции rebase команда редактирования (edit, или) остановит процесс на указанном коммите и позволит вам внести дополнительные изменения с помощью команды . Git прервет работу и выведет следующее сообщение:

Несколько комментариев

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

• Опция reword, или r, остановит операцию rebase и позволит переписать отдельный комментарий к коммиту.
• Опция squash, или s, приостановит операцию rebase для любых коммитов, отмеченных символом , и вам будет предложено ввести один общий комментарий вместо нескольких отдельных. Подробнее об этом можно узнать в разделе о склеивании коммитов ниже.
• Опция fixup, или f, позволяет объединить комментарии, как и squash. При этом, в отличие от squash, опция fixup не прерывает операцию rebase с открытием редактора для объединения комментариев к коммитам. В коммитах, отмеченных символом f, комментарии будут сброшены и заменены комментарием предыдущего коммита.

Склеивайте коммиты для поддержания чистой истории

Команда склеивания () позволяет в полной мере понять смысл rebase. Склеивание дает возможность указать коммиты, которые нужно объединить в предыдущие коммиты. Таким образом создается «чистая история». Во время перебазирования Git будет исполнять указанную команду rebase для каждого коммита. В случае склеенных коммитов Git откроет выбранный текстовый редактор и предложит объединить комментарии к указанным коммитам. Этот процесс можно представить следующим образом:

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

Современные решения для хостинга Git (например, Bitbucket) предоставляют возможности «автосклеивания» при слиянии. Это позволяет автоматически выполнять rebase и склеивать коммиты ветки при использовании интерфейса решений для хостинга. Дополнительную информацию см. в разделе «Склеивание коммитов при слиянии ветки Git в Bitbucket».

Команда git rebase позволяет изменять историю, а выполнение интерактивной операции rebase «подчищает» за вами следы. Теперь вы можете совершать и исправлять ошибки, оттачивая свою работу и сохраняя чистую, линейную историю проекта.

Легкий тег

Как только вы достигнете определенного этапа в написании проекта, вы захотите отметить его, чтобы в случае чего вернуться к нему позднее. Вы можете делать релизы и частое версионирование вашего проекта. Это называется легкий тег в Git. Тег представляет собой статический снимок хранилища в данный конкретный момент времени, на который ссылается имя. Есть два типа тегов. Один из них — легкий, метка для указателя в вашей истории коммитов, другой — это аннотированный тег, который содержит больше информации, включая информацию о том, кто был первым создателем этого тега, дату создания и короткое сообщение с аннотацией.

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

$ git tag release-1.0.0.0

Это имя нашего тега с параметром release-1.0.0.0.

Чтобы создать новый аннотированный тег, мы просто добавляем флаг -a и флаг -m, чтобы применить короткую аннотацию:

$ git tag -a release-1.0.0.0 -m "First full public release"

Чтобы просмотреть все наши теги в хранилище, мы запускаем:

$ git tag

Если вы хотите просмотреть больше информации о конкретном теге, используйте с параметром :

$ git show release-1.0.0.0

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

Удалённые репозитории

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

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

Наиболее употребляемые команды:

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

Следующие команды работают с удалёнными ветками:

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

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

GitHub

GitHub — это платформа, которая хранит Git-репозитории на своих серверах, и основы распределенной системы управления версиями Git подразумевает умение с ней работать. Вы можете хранить свои удалённые репозитории или участвовать в Open Source проектах на GitHub.

Да, есть и другие платформы, но GitHub идеален для введения в Git и дополняет VCS новыми возможностями.

Например, вы можете сделать форк удалённого репозитория, то есть создать свою копию репозитория на севере GitHub. Это полезно в тех случаях, когда у вас нет прав на создание ветки в оригинальном репозитории. Когда вы воспользуетесь командой , ваш локальный репозиторий будет отслеживать удалённый форк как origin, а оригинальный репозиторий как upstream.

После этого вам может понадобиться слить тематическую ветку вашего удалённого репозитория в основную ветку оригинального. Для этого вы можете создать новый Pull Request — запрос на внесение изменений, где GitHub проверяет наличие конфликтов прежде чем повзолить вам провести слияние. Зачастую существуют и другие проверки перед слиянием, например просмотр и одобрение кода или даже запуск тестов. В запросе можно обсудить код, а все коммиты, которые вы отправляете в удалённую тематическую ветку, будут автоматически добавлены в запрос, даже если он был создан до этих коммитов.

DevOps: автоматизация инфраструктуры на примере Terraform, docker, bash, prometheus exporters, Gitlab и WireGuard

• Из песочницы

Всем привет.

Есть такие люди, которые работают с облачной инфраструктурой и не используют автоматизацию, потому что это долго, нужно вникать, а им надо фичи пилить. Накликали что-то там в UI, подключились по ssh, поставили всякого с помощью apt и т.д. и конфигурационные файлы ещё вручную поменяли. Документации конечно же написать времени не хватило или в ней много разных хитрых шагов и повторить настройку этой инфраструктуры в точности уже нельзя или очень сложно, а сервисы крутятся в проде. А потом человек забыл что и как делал в точности или вообще уволился.

Хочу показать на небольшом примере, что автоматизировать инфраструктуру, например в AWS, может быть достаточно просто и приятно, а получившийся результат достаточно прозрачен и сам по себе является документацией, т.к. это инфраструктура как код. Если конечно есть знания Terraform или желание его немного изучить.

Git remote commands

The command is one of many Git commands that takes additional appended ‘subcommands’. Below is an examination of the commonly used subcommands.

Adds a record to for remote named at the repository url .

Accepts a option, that will immediately after the remote record is created.

Accepts a option, that will immediately and import every tag from the remote repository.

Updates to rename the record to . All remote-tracking branches and configuration settings for the remote are updated.

Modifies and removes the remote named . All remote-tracking branches and configuration settings for the remote are removed.

Outputs the URLs for a remote record.

Accepts , push URLs are queried rather than fetch URLs.

With , all URLs for the remote will be listed.

Outputs high-level information about the remote .

Deletes any local branches for that are not present on the remote repository.

Accepts a option which will list what branches are set to be pruned, but will not actually prune them.

Как пользоваться Git?

Дальше я буду предполагать, что вы выполнили установку и базовую настройку git. Кроме установки, вам нужно указать правильный адрес электронной почты и имя пользователя для доступа к серверу Git, например, на GitHub. Если вы этого еще не сделали смотрите инструкцию установка Git в Ubuntu 16.04.

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

Создание проекта

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

Эта команда создаст нужную структуру папок и переводит текущий каталог в только что созданный. Теперь создадим первый файл нашего проекта:

Проект готов, но система контроля версий git еще не знает об этом.

Настройка проекта в git

Перед тем как git начнет отслеживать изменения, нужно подготовить все необходимые конфигурационные файлы. Сначала инициализируем пустой репозиторий в нашей папке:

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

Если все прошло хорошо, то команда ничего не выведет.

Фиксация изменений

Изменения тоже автоматически не отслеживаются. Фиксация изменений выполняется с помощью команды commit. Вам нужно указать что было изменено с помощью небольшого комментария, буквально в несколько предложений. Хорошая практика выполнять фиксацию перед каждым серьезным изменением.

Таким образом, вы будете хранить все версии проекта, от самой первой и до текущей, а также сможете знать что, когда и где было изменено. Чтобы создать свой первый коммит выполните:

Команде необходимо передать два параметра, первый — это -m, ваш комментарий, второй -a, означает, что нужно применить действие ко всем измененным файлам. Для первого раза используется этот параметр, но обычно вам нужно указать измененные файлы или каталоги. Например, можно делать так:

Отправка изменений

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

Сначала нужно добавить удаленный репозиторий с помощью команды remote. Для этого нужно передать ей URL:

Затем можно посмотреть список удаленных репозиториев:

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

Команда push указывает, что нужно отправить данные в удаленный репозиторий, origin — наш настроенный репозиторий, а master — ветвь.

Управление ветвями

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

Опция -a указывает что нужно вывести все ветви, даже не синхронизированные. Звездочка указывает на активную ветвь. Теперь создадим ветвь для разработки с помощью команды checkout:

Переключаться между ветвями можно тоже с помощью той же команды:

Теперь создадим еще один файл:

И добавим его в нашу новую ветвь develop:

Сделаем коммит для внесенных изменений:

Дальше проверим существует ли этот файл в основной ветке master или только в дополнительной. Смотрим текущую ветку:

Затем переключаемся на ветку master и снова смотрим:

Здесь файла нет, так и должно быть. В git есть такая полезная вещь, как слияние. С помощью нее вы можете объединить две ветви. Например, переместить код из рабочей ветки в стабильную. Для этого достаточно выполнить команду merge:

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

DevOps with GitHub

Continuous integration with CircleCI

Learn how to automatically test changes made to your project, freeing you up to write more amazing code.

Continuous Integration

Continuous integration with Travis CI

Learn about the principles of continuous integration with GitHub and Travis CI.

continuous integration (CI)

test-driven development (TDD)

YAML

protected branches

commit status

Getting started with GitHub Apps

Add your own GitHub feature, automate workflows, and more with GitHub Apps.

webhooks

API

GitHub Apps

Probot

Installing

CodeQL U-Boot Challenge (C/C++)

Learn to use CodeQL, a query language that helps find bugs in source code. Find 9 remote code execution vulnerabilities in the open-source project Das U-Boot, and join the growing community of security researchers using CodeQL.

Step 9: Merge a PR

Go ahead and click the green ‘Merge pull request’ button. This will merge your changes into the primary branch.

When you’re done, I recommend deleting your branch (too many branches can become messy), so hit that grey ‘Delete branch’ button as well.

You can double check that your commits were merged by clicking on the ‘Commits’ link on the first page of your new repo.

This will show you a list of all the commits in that branch. You can see the one I just merged right up top (Merge pull request #1).

You can also see the hash code of the commit on the right hand side. A hash code is a unique identifier for that specific commit. It’s useful for referring to specific commits and when undoing changes (use the git revert <hash code number> command to backtrack).

Our most popular courses

Introduction to GitHub

If you are looking for a quick and fun introduction to GitHub, you’ve found it. This class will get you started using GitHub in less than an hour.

Git

GitHub Pages

Branches

Commits

Pull Requests

Create a GitHub Action and use it in a workflow.

GitHub Actions

Workflows

Hello World

Communicating using Markdown

This course will walk you through everything you need to start organizing ideas and collaborating using Markdown, a lightweight language for text formatting.

GitHub

Markdown

Learning should be fun

There are no simulations or boring tutorials here, just hands-on lessons created with by the GitHub community and taught by the friendly Learning Lab bot.

Step 7: Push a branch to GitHub

Now we’ll push the commit in your branch to your new GitHub repo. This allows other people to see the changes you’ve made. If they’re approved by the repository’s owner, the changes can then be merged into the primary branch.

To push changes onto a new branch on GitHub, you’ll want to run git push origin yourbranchname. GitHub will automatically create the branch for you on the remote repository:

You might be wondering what that «origin» word means in the command above. What happens is that when you clone a remote repository to your local machine, git creates an alias for you. In nearly all cases this alias is called «origin.» It’s essentially shorthand for the remote repository’s URL. So, to push your changes to the remote repository, you could’ve used either the command: git push git@github.com:git/git.git yourbranchname or git push origin yourbranchname

(If this is your first time using GitHub locally, it might prompt you to log in with your GitHub username and password.)

If you refresh the GitHub page, you’ll see note saying a branch with your name has just been pushed into the repository. You can also click the ‘branches’ link to see your branch listed there.

Now click the green button in the screenshot above. We’re going to make a pull request!

Ummmmm … что? Могу ли я сделать это на сайте?

Вы можете!

GIF черезGIPHY

Один из способов сделать это — просто проверить кнопку, о которой мы упоминали ранее, когда редактировали файл README. Супер просто!

Вы также можете в любое время создать новую ветку прямо на веб-сайте, перейдя в свой репозиторий, щелкнув раскрывающееся меню в левой и средней части экрана с надписью «Branch: master», введя имя ветви и выбрав Ссылка «Создать ветку» (или нажмите Enter на клавиатуре). Теперь у вас есть две ветви, которые выглядят одинаково! Это отличное место для внесения изменений и их тестирования, прежде чем вы захотите, чтобы они повлияли на основную ветку.

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

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

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

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

• Нажмите вкладку запроса на извлечение рядом с верхним центром экрана.
• Нажмите зеленую кнопку «Новый запрос на извлечение»
• Перейдите в поле «Примеры сравнений» и выберите ветку, которую вы сделали, чтобы сравнить с исходной веткой.
• Посмотрите свои изменения, чтобы убедиться, что они действительно то, что вы хотите зафиксировать.
• Затем нажмите большую зеленую кнопку «Создать запрос на извлечение». Дайте ему название и напишите краткое описание ваших изменений. Затем нажмите «Создать запрос на извлечение!»

Новый запрос на извлечение
Создать пул-запрос

Теперь, если это ваш репозиторий, вы можете объединить ваш запрос на извлечение, нажав зеленую кнопку «Слить запрос на извлечение», чтобы объединить изменения в мастер. Нажмите «Подтвердить слияние», затем удалите ветвь после того, как ваша ветвь была включена с помощью кнопки «Удалить ветвь» в фиолетовом поле.

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

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

Устанавливаем SSH-ключи

Git установлен, профиль на GitHub создан. Осталось добавить SSH-ключ и можно приступать к работе с проектом.

Что такое SSH-ключ и зачем он нужен?

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

Каждый SSH-ключ содержит пару: открытый (публичный) и закрытый (приватный) ключ. Открытый ключ отправляется на сервер, его можно не прятать от всех и не переживать, что кто-то его увидит и украдёт. Он бесполезен без своей пары — закрытого ключа. А вот закрытый ключ — секретная часть. Доступ к нему должен быть только у вас.

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

Чтобы пройти авторизацию по SSH-ключу, его надо сгенерировать или найти уже ранее созданный ключ на своём компьютере.

Сначала проверим, есть ли уже на компьютере ключ. По умолчанию SSH-ключи хранятся в каталоге , поэтому нужно проверить содержимое этого каталога.

1. Открываем консоль.

2. Вводим , чтобы перейти в нужный каталог.

   Переходим в нужную директорию.

3. Используем , чтобы увидеть список всех файлов в каталоге.

   Открываем список файлов в директории.

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

   • Открываем консоль и вводим команду:

     ssh-keygen -t rsa -b 4096 -C "your_mail@example.com"

     Указываем тот адрес электронной почты, который вводили при регистрации на GitHub.

     Генерируем ключ.

   • Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.

   • Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите.

     Указываем расположение ключа и вводим пароль.

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

   Добавляем ключ в shh-agent. Несколько важных примечаний:

   • Если вы захотите переименовать ключ, могут возникнуть проблемы. Их можно решить, добавив в связь ключа с доменом.
   • Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой . Может появиться такое сообщение об ошибке:
     «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

     В Сmder для запуска можно использовать команду .

     Если проблема осталась, рекомендуем работать в Git Bash.

   • Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш файл, чтобы автоматически загрузить ключи в и хранить пароли.

     Host *
      AddKeysToAgent yes
      UseKeychain yes
      IdentityFile ~/.ssh/id_rsa

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

   • Если у вас Linux, может понадобится переназначить для ~/.ssh права доступа командой
5. После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
   • Если вы на Windows
   • Для пользователей macOS
   • На Linux используйте , чтобы установить необходимый для копирования пакет , а затем введите

   Можно пойти другим путём, открыть файл прямо в папке и просто скопировать содержимое оттуда.

6. Переходим на страницу для работы с ключами в вашем профиле на GitHub.

   Страница с настройками ключей в вашем профиле.

   Нажимаем кнопку New SSH key (новый SSH-ключ). Вводим имя ключа (можно придумать абсолютно любое) в поле Title (название), а в Key (ключ) вставляем сам ключ из буфера обмена. Теперь нажимаем Add SSH key (добавить SSH-ключ).

   Добавляем в свой профиль SSH-ключ.

   Если всё сделано верно, в списке появится новый ключ.

   Успешно добавленный ключ.

Теперь, наконец-то, мы можем начать работу с самим проектом.

Как работает 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

Спасибо за внимание

Шаг 1: Зарегистрируйтесь и установите!

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

Теперь зайдите в свой терминал и представьтесь Git! Чтобы установить ваше имя пользователя длякаждый репозиторийна вашем компьютере введите

git config --global user.name "<your_name_here>"

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

Теперь вы можете указать Git свой адрес электронной почты и убедиться, что это тот же адрес электронной почты, который вы использовали при регистрации в GitHub.

git config --global user.email "<>"

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

Теперь вы готовы начать использовать Git на своем компьютере!

фотоМэтти АдамнаUnsplash

Для начала вы можете создать новый репозиторий на сайте GitHub или выполнитьсоздать новый репозиторий из каталога вашего проекта.

Хранилище состоит из трех «деревьев». Во-первых, эторабочий каталог, который содержит актуальные файлы. Второй являетсяпоказательили область подготовки. Тогда естьголова, который указывает на последний сделанный вами коммит.

Совмещение веток

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

Слияние

Оно включает в себя создание нового коммита, который основан на общем коммите-предке двух ветвей и указывает на оба HEAD в качестве предыдущих коммитов. Для слияния мы переходим на основную ветку и используем команду .

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

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

<<<<<<< HEAD:index.html
Everything above the ==== is the version in master.
=======
Everything below the ==== is the version in the test branch.
>>>>>>> test:index.html

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

Перемещение

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

Для перемещения используется команда , которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

После слияния лог с историей может выглядеть довольно беспорядочно. С другой стороны, перемещение позволяет переписать историю в нормальной, последовательной форме.

Так зачем нужно слияние, если можно всё время пользоваться перемещением? К сожалению, перемещение не панацея от запутанных логов, так как перемещённые коммиты на самом деле отличаются от оригинальных, хотя и имеют одного и того же автора, сообщение и изменения.

Представим сценарий:

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

Поэтому вот совет:

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

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

Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!