G i t: Git — Downloading Package

что это такое и в чём разница

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

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.

Содержание:

Что такое Git

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

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

Преимущества Git:

• Бесплатный и open-source. Можно бесплатно скачать и вносить любые изменения в исходный код;
• Небольшой и быстрый. Выполняет все операции локально, что увеличивает его скорость. Кроме того, Git локально сохраняет весь репозиторий в небольшой файл без потери качества данных;
• Резервное копирование. Git эффективен в хранении бэкапов, поэтому известно мало случаев, когда кто-то терял данные при использовании Git;
• Простое ветвление. В других системах контроля версий создание веток— утомительная и трудоёмкая задача, так как весь код копируется в новую ветку. В Git управление ветками реализовано гораздо проще и эффективнее.

Теперь пора разобраться, что такое GitHub и как он работает с Git.

Что такое GitHub и чем он отличается от Git

Как мы разобрались выше, Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.

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

Git-репозиторий, загруженный на GitHub, доступен с помощью интерфейса командной строки Git и Git-команд. Также есть и другие функции: документация, запросы на принятие изменений (pull requests), история коммитов, интеграция со множеством популярных сервисов, email-уведомления, эмодзи, графики, вложенные списки задач, система @упоминаний, похожая на ту, что в Twitter, и т.д.

Кроме GitHub есть другие сервисы, которые используют Git, — например, Bitbucket и GitLab. Вы можете разместить Git-репозиторий на любом из них.

Чтобы работать с Git эффективнее, посмотрите подборку шпаргалок: от основ до работы с GitHub.

Что такое система контроля версий

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

Системы контроля версий (СКВ, VCS, Version Control Systems) позволяют разработчикам сохранять все изменения, внесённые в код. При возникновении проблем они могут просто откатить код до рабочего состояния и не тратить часы на поиски ошибок.

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

Типы систем контроля версий

Теперь вы знаете, что такое система контроля версий. Однако они тоже бывают разными. Существует три типа СКВ: локальная, централизованная и распределённая.

Локальные системы контроля версий (ЛСКВ)

Принцип работы локальной системы контроля версий

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

Централизованные системы контроля версий (ЦСКВ)

Принцип работы централизованной системы контроля версий

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

Распределённые системы контроля версий (РСКВ)

Принцип работы распределённой системы контроля версий

Недостаток ЦСКВ был исправлен в РСКВ, клиенты которых не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени), а полностью копируют репозиторий. Это значит, что у каждого клиента есть копия всего исходного кода и внесённых изменений. В этом случае, если один из серверов выйдет из строя, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Ещё одним преимуществом РСКВ является то, что они могут одновременно взаимодействовать с несколькими удалёнными репозиториями. Благодаря этому разработчики могут параллельно работать над несколькими проектами. Именно поэтому Git сейчас так популярен.

Не смешно? А здесь смешно: @ithumor

Написано на основе статьи «Difference Between Git and GitHub»

Git — Викиучебник

Материал из Викиучебника — открытых книг для открытого мира

Это краткий справочник по командам git. Используется договорённость об обязательном использовании rebase при синхронизации с получаемой веткой.

Начальная настройка[править]

• git config —global user. email your.name@domain
• git config —global user.name «Your Name»
• git config —global push.default current
• git clone <url репозитория>

Работа с ветками[править]

• создание ветки
  git branch <имя ветки>
• переключение
  git checkout <имя ветки>
• две операции вместе
  git checkout -b <имя ветки>
• посмотреть ветки в своем репозитории
  git branch
• посмотреть ветки на удаленном репозитории
  git branch -r
• создание удаленной ветки (соответствующей текущей ветке)
  git push -u origin <имя ветки на удаленном репозитории, обычно такое же, как и локальное>
• удаление локальной ветки

1. git branch -d <имя ветки>. Но в этом случае git иногда ноет, что у вас ветка не слита с HEADом или upstream-branch.
2. git branch -D <имя ветки>. Так он удалит в любом случае, вне зависимости от merged status ветки, которую вы хотите удалить.

• cинхронизация с ветками

—взятие, без флага rebase будет выполняться merge, а с этим флагом будет выполняться rebase

1. git pull —rebase
2. git pull без —rebase использовать ЗАПРЕЩЕНО! — это создаст проблемы при последующих rebase и слиянии веток.

Также рекомендуется один раз запустить

git config branch.autosetuprebase always

Это позволит автоматически во время git pull добавлять флаг —rebase

—отправка на сервер. после первого push’a с флагом -u достаточно писать лишь git push

Пример: Cлияние ветки с master через rebase с обновлением ветки master[править]

— обновляем master

git checkout master

git pull —rebase

— ребейзим ветки на master
git checkout <имя ветки>
git rebase master

• master при этом не меняется, то есть если вы хотите просто влить в Вашу ветку общие изменения, на этом надо остановиться.
• Только не забудьте перед следующим git pull —rebase(в своей ветке) сделать git push —force origin <имя ветки>, поскольку из-за ребейза <имя ветки> и origin/<имя ветки> разошлись. Иначе, если сделать pull —rebase то вы снова примените к своей ветке свои коммиты.
• возвращаемся обратно, делаем fast-forward merge и выливаем в репозиторий

git checkout master

git merge <имя бранча> (должно быть написано fast-forward)

git push

Исправления[править]

1. в любимом редакторе
2. git mergetool [—tool=<tool>]
3. сторонние gui git приложения (Валера пользуется smartgit)

• исправление коммитов
• отлично работающая штука, если вы сделали какую-то глупость (например, смерджились случайно c master):

git reflog

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

git reset —hard HEAD@{n}

• слияние коммитов
  git rebase -i <start_point> (внимание, ребейз начинается после start point’a)
• исправление предыдущего коммита
  git commit —amend

откат коммита

git reset HEAD~<n> (сами файлы в working tree останутся)

git reset —hard HEAD~<n> (working tree файлы не останутся)

откат из индекса

git reset <file name>

откат измененного файла

git checkout HEAD <file name>

git checkout — <file name> (2-й способ начиная с версии git 1.6.1)

взятие отдельного коммита в свой бранч

git cherry-pick <commit>

взятие несколько подряд идущих коммитов

git cherry-pick <commit_from>. .<commmit_to>

Удаление ветки на удаленном репозитории[править]

git push origin —delete <имя ветки на удаленном репозитории>

См. также[править]

http://git-scm.com/book

Возможная модель работы с ветками master и develop

Git для новичков (часть 1) / Хабр

Часть 2

Что такое Git и зачем он нужен?

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

С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.

Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.

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

Каждая точка сохранения вашего проекта носит название коммит (commit). У каждого commit-a есть hash (уникальный id) и комментарий. Из таких commit-ов собирается ветка. Ветка — это история изменений. У каждой ветки есть свое название. Репозиторий может содержать в себе несколько веток, которые создаются из других веток или вливаются в них.

Как работает

Если посмотреть на картинку, то становиться чуть проще с пониманием. Каждый кружок, это commit. Стрелочки показывают направление, из какого commit сделан следующий. Например C3 сделан из С2 и т. д. Все эти commit находятся в ветке под названием main. Это основная ветка, чаще всего ее называют master . Прямоугольник main* показывает в каком commit мы сейчас находимся, проще говоря указатель.

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

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

Установка

Основой интерфейс для работы с Git-ом является консоль/терминал. Это не совсем удобно, тем более для новичков, поэтому предлагаю поставить дополнительную программу с графическим интерфейсом (кнопками, графиками и т.д.). О них я расскажу чуть позже.

Но для начала, все же установим сам Git.

• Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.

• Для Mac OS. Открываем терминал и пишем:

#Если установлен Homebrew
brew install git

#Если нет, то вводим эту команду. 
git --version
#После этого появится окно, где предложит установить Command Line Tools (CLT).
#Соглашаемся и ждем установки. Вместе с CLT установиться и git

# Debian или Ubuntu
sudo apt install git

# CentOS
sudo yum install git

Настройка

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

Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.

#Установим имя для вашего пользователя
#Вместо <ваше_имя> можно ввести, например, Grisha_Popov
#Кавычки оставляем
git config --global user.name "<ваше_имя>"

#Теперь установим email. Принцип тот же.
git config --global user.email "<адрес_почты@email.com>"

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

Теперь вы готовы к работе с Git локально на компьютере.

Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.

#Для Linux и MacOS путь может выглядеть так /Users/UserName/Desktop/MyProject
#Для Windows например С://MyProject
cd <путь_к_вашему_проекту>

#Инициализация/создание репозитория
git init

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

#Добавим все файлы проекта в нам будующий commit
git add .
#Или так
git add --all

#Если хотим добавить конкретный файл то можно так
git add <имя_файла> 

#Теперь создаем commit. Обязательно указываем комментарий.
#И не забываем про кавычки
git commit -m "<комментарий>"

Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.

Процесс работы с Git

Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:

• Создан новый функционал

• Добавлен новый блок на верстке

• Исправлены ошибки по коду

• Вы завершили рабочий день и хотите сохранить код

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

Визуальный интерфейс

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

Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:

Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.

Создаем свой первый проект и выкладываем на GitHub

Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).

Перед началом предлагаю зарегистрироваться на GitHub.

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

После открываем VS Code .

1. Установите себе дополнительно анализаторы кода для JavaScript и PHP

2. Откройте вашу папку, которую создали ранее

После этого у вас появится вот такой интерфейс

1. Здесь будут располагаться все файлы вашего проекта

2. Здесь можно работать с Git-ом

3. Кнопка для создания нового файла

4. Кнопка для создания новой папки

Если ваш проект пустой, как у меня, то создайте новый файл и назовите его index. html . После этого откроется окно редактирование этого файла. Напишите в нем ! и нажмите кнопку Tab . Автоматически должен сгенерироваться скелет пустой HTML страницы. Не забудьте нажать ctrl+s чтобы файл сохранился.

Давайте теперь перейдем во вкладу для работы с Git-ом.

Откроется вот такое окно:

1. Кнопка для публикации нашего проекта на GitHub

2. После нажатия на кнопку 1 , появится всплывающее окно. Нужно выбрать второй вариант или там где присутствует фраза ...public repository

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

После того, как выбрали «Опубликовать на GitHub публичный репозиторий» (пункт 2), программа предложит вам выбрать файлы, которые будут входить в первый commit. Проставляем галочки у всех файлов, если не проставлены и жмем ОК . Вас перекинет на сайт GitHub, где нужно будет подтвердить вход в аккаунт.

Вы создали и опубликовали репозиторий на GitHub.

Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.

Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:

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

2. Добавляем наш файл для будущего commit

3. Пишем комментарий

4. Создаем commit

5. Отправляем наш commit в GitHub

Поздравляю, вы научились создавать commit и отправлять его в GitHub!

Итог

Это первая вводная статья по утилите Git. Здесь мы рассмотрели:

• Как его устанавливать

• Как его настраивать

• Как инициализировать репозиторий и создать commit через консоль

• Как на примере VS Code, опубликовать свой код на GitHub

Забегая вперед, советую вам погуглить, как работают следующие команды:

git help # справка по всем командам
git clone
git status
git branch
git checkout
git merge
git remote
git fetch
git push
git pull

P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.

https://learngitbranching.js.org/

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

Интерфейс GIT в Visual Studio | Microsoft Docs

• 
  01/15/2021
• Чтение занимает 9 мин

В этой статье

Теперь GIT является интерфейсом системы управления версиями по умолчанию в Visual Studio 2019.Git is now the default version control experience in Visual Studio 2019. Начиная с версии 16.6 мы работаем над созданием набора функций на основе ваших отзывов.Since version 16.6, we’ve worked on building out the feature set and iterating on it based on your feedback. Новый интерфейс Git по умолчанию включен для всех пользователей, имеющих выпуск версии 16.8.The new Git experience is turned on by default for everyone with the release of version 16.8.

Совет

GIT — это наиболее широко используемая современная система управления версиями, которая может быть полезна как профессиональным разработчиком, так и только начинающим изучать программирование.Git is the most widely used modern version control system, so whether you’re a professional developer or if you’re learning how to code, Git can be very useful to you. Если вы не знакомы с GIT, можно начать с веб-сайта https://git-scm.com/.If you are new to Git, the https://git-scm.com/ website is a good place to start. На нем вы найдете памятки, популярную электронную книгу и видеоматериалы по основам GIT.There, you’ll find cheat sheets, a popular online book, and Git Basics videos.

Использование GIT в Visual StudioHow to use Git in Visual Studio

Мы подробно расскажем вам о том, как использовать новый интерфейс Git в Visual Studio 2019. Однако если вы хотите ознакомиться с кратким обзором, посмотрите следующее видео:We’ll walk you through how to use the new Git experience in Visual Studio 2019, but if you’d like to take a quick tour first, check out the following video:

Длительность видео: 05:27 мин.Video length: 5.27 minutes

Существует три способа начать использование Git в Visual Studio для повышения производительности:There are three ways to start using Git with Visual Studio to be more productive:

Примечание

Начиная с версии 16.8 Visual Studio 2019 включает полностью интегрированный интерфейс для работы с учетными записями GitHub.Starting also with version 16.8, Visual Studio 2019 includes a fully integrated GitHub account experience. Теперь вы можете добавить в цепочку ключей учетные записи GitHub и GitHub Enterprise.You can now add both GitHub and GitHub Enterprise accounts to your keychain. Вы сможете добавлять и использовать их так же, как и учетные записи Майкрософт. Это позволит упростить доступ к ресурсам GitHub в Visual Studio.You’ll be able to add and leverage them just as you do with Microsoft accounts, which means that you’ll have an easier time accessing your GitHub resources across Visual Studio. Дополнительные сведения см. на странице Работа с учетными записями GitHub в Visual Studio.For more information, see the Work with GitHub accounts in Visual Studio page.

Создание репозитория GITCreate a new Git repository

Если ваш код не связан с GIT, можно начать с создания нового репозитория GIT. If your code is not associated with Git, you can start by creating a new Git repository. Для этого в строке меню выберите GIT > Создать репозиторий GIT.To do so, select Git > Create Git Repository from the menu bar. Затем в диалоговом окне Создание репозитория GIT введите свои данные.Then, in the Create a Git repository dialog box, enter your information.

С помощью диалогового окна Создание репозитория GIT можно легко отправить новый репозиторий в GitHub.The Create a Git repository dialog box makes it easy to push your new repository to GitHub. По умолчанию новый репозиторий является частным. Это означает, что доступ к нему есть только у вас.By default, your new repository is private, which means that you are the only one who can access it. Если снять соответствующий флажок, репозиторий будет общедоступным. Это означает, что любой пользователь в GitHub сможет его просмотреть.If you uncheck the box, your repository will be public, which means that anyone on GitHub can view it.

Совет

Независимо от того, является ли репозиторий общедоступным или частным, лучше создать удаленную резервную копию кода, которая будет безопасно храниться в GitHub, даже если вы работаете сами по себе.Whether your repository is public or private, it’s best to have a remote backup of your code stored securely on GitHub even if you are not working with a team. Это также позволит вам получать доступ к коду с любого компьютера.This also makes your code available to you no matter what computer you’re using.

Вы можете создать исключительно локальный репозиторий GIT, выбрав параметр Только локальный.You can choose to create a local-only Git repository by using the Local only option. Вы также можете связать репозиторий с любым существующим пустым удаленным репозиторием, размещенным у любого другого поставщика GIT, с помощью параметра Существующий удаленный. Or, you can link your repository with any existing empty remote repository on any other Git provider by using the Existing remote option.

Клонирование существующего репозитория GITClone an existing Git repository

В Visual Studio процесс клонирования прост.Visual Studio includes a straightforward clone experience. Если вы знаете URL-адрес репозитория, который нужно клонировать, можно вставить его в разделе Расположение репозитория, а затем выбрать место на диске, в которое будет клонирован репозиторий.If you know the URL of the repository that you would like to clone, you can paste the URL in the Repository location section and then choose the disk location you would like Visual Studio to clone to.

Если вы не знаете URL-адрес репозитория, в Visual Studio можно легко перейти к существующему репозиторию GitHub или Azure DevOps и выбрать его.If you don’t know the repository URL, Visual Studio makes it easy to browse to and then clone your existing GitHub or Azure DevOps repository.

Открытие существующего локального репозиторияOpen an existing local repository

После клонирования или создания репозитория GIT Visual Studio обнаружит его и добавит в список Локальные репозитории в меню GIT.After you’ve cloned a repository or created one, Visual Studio detects the Git repository and adds it to your list of Local Repositories in the Git menu. В нем можно быстро открывать репозитории GIT и переключаться между ними.From here, you can quickly access and switch between your Git repositories.

Просмотр файлов в обозревателе решенийView files in Solution Explorer

При клонировании репозитория или открытии локального репозитория Visual Studio переключается в этот контекст GIT, сохраняя и закрывая все ранее открытые решения и проекты.When you clone a repository or open a local repository, Visual Studio switches you into that Git context by saving and closing any previously open solutions and projects. Обозреватель решений загружает папку в корне репозитория GIT и проверяет дерево каталогов на наличие файлов представлений.Solution Explorer loads the folder at the root of the Git repository and scans the directory tree for any View files. К ним относятся такие файлы, как CMakeLists.txt или файлы с расширением SLN.These include files such as CMakeLists.txt or those with the .sln file extension.

Visual Studio настраивает представление в зависимости от файла представления, загруженного в обозревателе решений.Visual Studio adjusts its View based on which View file you load in Solution Explorer:

• При клонировании репозитория, содержащего один SLN-файл, обозреватель решений напрямую загружает это решение.If you clone a repository that contains a single .sln file, then Solution Explorer directly loads that solution for you.
• Если обозреватель решений не обнаруживает файлов SLN в репозитории, по умолчанию он загружает представление папки.If Solution Explorer doesn’t detect any .sln files in your repository, then by default it loads Folder View.
• Если репозиторий содержит несколько файлов SLN, то обозреватель решений выводит список доступных представлений для выбора.If your repository has more than one .sln file, then Solution Explorer shows you the list of available Views for you to choose from.

Переключаться между текущим представлением и списком представлений можно с помощью кнопки Переключить представления на панели инструментов обозревателя решений.You can toggle between the currently open View and the list of Views by using the Switch Views button in the Solution Explorer toolbar.

Окно «Изменения GIT»Git Changes window

GIT отслеживает изменения файлов в репозитории в процессе работы и разделяет файлы на три категории.Git tracks file changes in your repo as you work, and separates the files in your repo into three categories. Это те же изменения, которые отображаются при вводе команды git status в командной строке. These changes are equivalent to what you would see when you enter the git status command in the command line:

• Файлы без изменений: эти файлы не были изменены с момента последней фиксации.Unmodified files: These files haven’t changed since your last commit.
• Измененные файлы: эти файлы изменились с момента последней фиксации, но еще не были подготовлены для следующей фиксации.Modified files: These files have changes since your last commit, but you haven’t yet staged them for the next commit.
• Промежуточные файлы: эти файлы содержат изменения, которые будут добавлены в следующую фиксацию.Staged files: These files have changes that will be added to the next commit.

В процессе работы Visual Studio отслеживает изменения в файлах проекта в разделе Изменения окна Изменения GIT.As you do your work, Visual Studio keeps track of the file changes to your project in the Changes section of the Git Changes window.

Когда вы будете готовы подготовить изменения, нажмите кнопку + (плюс) для каждого из файлов, которые необходимо подготовить, или щелкните файл правой кнопкой мыши и выберите пункт Промежуточно сохранить.When you are ready to stage changes, click the + (plus) button on each file you want to stage, or right-click a file and then select Stage. Можно также подготовить все измененные файлы одним щелчком мыши, используя кнопку «Промежуточно сохранить все» ( + ) в верхней части раздела Изменения.You can also stage all your modified files with one click by using the stage all + (plus) button at the top of the Changes section.

При подготовке изменения Visual Studio создает раздел Подготовленные изменения. When you stage a change, Visual Studio creates a Staged Changes section. Только изменения из раздела Подготовленные изменения добавляются к следующей фиксации, которую можно выполнить, выбрав команду Зафиксировать промежуточные.Only changes in the Staged Changes section are added to the next commit, which you can do by selecting Commit Staged. Эквивалентная команда для этого действия — git commit -m "Your commit message".The equivalent command for this action is git commit -m "Your commit message". Можно также отменить подготовку изменений, нажав кнопку –  (минус).Changes can also be unstaged by clicking the – (minus) button. Эквивалентная команда для этого действия — git reset <file_path> для отмены размещения одного файла или git reset <directory_path> для отмены размещения всех файлов в каталоге.The equivalent command for this action is git reset <file_path> to unstage a single file or git reset <directory_path> to unstage all the files in a directory.

Кроме того, можно отказаться от подготовки измененных файлов, пропустив область подготовки.You can also choose not to stage your modified files by skipping the staging area. В этом случае Visual Studio позволяет зафиксировать изменения напрямую без предварительной подготовки.In this case, Visual Studio allows you to commit your changes directly without having to stage them. Просто введите сообщение о фиксации и выберите Зафиксировать все.Just enter your commit message and then select Commit All. Эквивалентная команда для этого действия — git commit -a.The equivalent command for this action is git commit -a.

Visual Studio также позволяет выполнить фиксацию и синхронизацию одним щелчком мыши с помощью ярлыков Зафиксировать все и отправить и Зафиксировать все и синхронизировать. Visual Studio also makes it easy to commit and sync with one click by using the Commit All and Push and Commit All and Sync shortcuts. Если дважды щелкнуть любой файл в разделе Изменения или Подготовленные изменения, то можно построчно сравнить измененную версию файла с неизмененной.When you double-click any file in the Changes and the Staged changes sections, you can see a line-by-line comparison with the unmodified version of the file.

Совет

Если вы подключены к репозиторию Azure DevOps, вы можете связать рабочий элемент Azure DevOps с фиксацией, используя символ #.You can associate an Azure DevOps work item with a commit by using the «#» character if you are connected to the Azure DevOps repository. Чтобы подключить репозиторий Azure DevOps, выберите Team Explorer > Управление подключениями.You can connect your Azure DevOps repository through Team Explorer > Manage Connections.

Выбор существующей ветвиSelect an existing branch

В Visual Studio текущая ветвь отображается в селекторе в верхней части окна Изменения GIT.Visual Studio displays the current branch in the selector at the top of the Git Changes window.

Текущая ветвь также доступна в строке состояния в правом нижнем углу интегрированной среды разработки Visual Studio.The current branch is also available in the status bar on the bottom-right corner of the Visual Studio IDE.

В обоих местах можно переключаться между имеющимися ветвями.From both locations, you can switch between existing branches.

Создание ветвиCreate a new branch

Можно также создать новую ветвь.You can also create a new branch. Эквивалентная команда для этого действия — git checkout <branchname>.The equivalent command for this action is git checkout <branchname>.

Чтобы создать ветвь, достаточно ввести ее имя и указать существующую ветвь, на основе которой будет создана данная.Creating a new branch is as simple as entering the branch name and basing it off an existing branch.

В качестве базовой можно выбрать существующую локальную или удаленную ветвь.You can choose an existing local or remote branch as the base. Если флажок Извлечь ветвь установлен, вы автоматически переключитесь на новую ветвь после ее создания.The Checkout branch checkbox automatically switches you to the newly created branch. Эквивалентная команда для этого действия — git checkout -b <new-branch><existing-branch>.The equivalent command for this action is git checkout -b <new-branch><existing-branch>.

Окно «Репозиторий GIT»Git Repository window

В Visual Studio имеется новое окно Репозиторий GIT, в котором представлены все сведения о репозитории, включая все ветви, удаленные репозитории и журналы фиксации.Visual Studio has a new Git Repository window, which is a consolidated view of all the details in your repository, including all of the branches, remotes, and commit histories. Открыть это окно можно из меню GIT или Вид либо непосредственно из строки состояния.You can access this window directly from either Git or View on the menu bar or from the status bar.

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

При выборе в меню GIT пункта Управление ветвями отображается древовидное представление ветвей в окне Репозиторий GIT.When you select Manage Branches from the Git menu, you’ll see the branches tree-view in the Git Repository window. В левой области можно использовать контекстное меню для извлечения, создания, объединения ветвей, перемещения изменений из одной ветви в другую, отбора изменений и других действий.From the left pane, you can use the right-click context menu to checkout branches, create new branches, merge, rebase, cherry-pick, and more. Щелкнув ветвь, можно просмотреть ее журнал фиксаций в правой области.When you click the branch, you can see a preview of its commit history in the right pane.

Входящие и исходящие фиксацииIncoming and outgoing commits

При принесении ветви в окне Изменения GIT под раскрывающемся списком ветвей отображается индикатор, который показывает количество фиксаций, которые не были вытянуты из удаленной ветви.When you fetch a branch, the Git Changes window has an indicator under the branch drop-down, which displays the number of unpulled commits from the remote branch. Он также показывает число локальных фиксаций, которые не были отправлены.This indicator also shows you the number of unpushed local commits.

Индикатор также является ссылкой, по которой можно перейти к журналу фиксаций этой ветви в окне Репозиторий GIT.The indicator also functions as a link to take you to the commit history of that branch in the Git Repository window. В начале журнала теперь отображаются сведения об этих входящих и исходящих фиксациях.The top of the history now displays the details of these incoming and outgoing commits. Здесь можно также вытянуть или отправить фиксации.From here, you can also decide to Pull or Push the commits.

Сведения о фиксацииCommit Details

Если дважды щелкнуть фиксацию, в Visual Studio откроются сведения о ней в отдельном окне инструментов.When you double-click a Commit, Visual Studio opens its details in a separate tool window. Здесь можно отменить фиксацию, сбросить ее, исправить сообщение о фиксации или создать тег для нее.From here you can revert the commit, reset the commit, amend the commit message, or create a tag on the commit. Если щелкнуть измененный файл в фиксации, в Visual Studio откроется инструмент сравнения, в котором рядом друг с другом показаны фиксация и ее предок.When you click a changed file in the commit, Visual Studio opens the side-by-side Diff view of the commit and its parent.

Разрешение конфликтов слиянияHandle merge conflicts

Во время слияния могут возникать конфликты, если два разработчика изменяют одни и те же строки в файле и GIT неизвестно, какой вариант правильный.Conflicts can occur during a merge if two developers modify the same lines in a file and Git doesn’t automatically know which is correct. В этом случае GIT прерывает слияние и сообщает о конфликтном состоянии.Git halts the merge and informs you that you are in a conflicted state.

В Visual Studio можно легко выявлять и устранять конфликты слияния.Visual Studio makes it easy to identify and resolve a merge conflict. Во-первых, в верхней части окна Репозиторий GIT имеется золотистая информационная панель.First, the Git Repository window shows a gold info bar at the top of the window.

В окне Изменения GIT также выводится сообщение Слияние выполняется с конфликтами, под которым в отдельном разделе указываются файлы, слияние которых не было выполнено.The Git Changes window also displays a ‘Merge is in progress with conflicts’ message, with the unmerged files in their separate section below it.

Но если ни одно из этих окон не открыто и вы переходите к файлу с конфликтами слияния, вам не придется искать следующий текст:But if you have neither of these windows open, and instead you go to the file that has merge conflicts, you won’t have to search for the following text:

    <<<<<<< HEAD
    =======
    >>>>>>> main

Вместо этого в верхней части страницы в Visual Studio отображается золотистая информационная панель с сообщением о наличии конфликтов в открытом файле.Instead, Visual Studio displays a gold info bar on the top of the page that indicates that the opened file has conflicts. Щелкните ссылку, чтобы открыть редактор слияния.Then, you can click the link to open the Merge Editor.

Редактор слиянияThe Merge Editor

Редактор слияния в Visual Studio позволяет выполнять трехстороннее сравнение: в нем приводятся входящие изменения, текущие изменения и результат слияния.The Merge Editor in Visual Studio is a three-way merge tool that displays the incoming changes, your current changes, and the result of the merge. С помощью панели инструментов вверху редактора слияния можно переходить между конфликтами и просматривать результаты автоматического слияния в файле.You can use the tool bar at the top level of the Merge Editor to navigate between conflicts and auto-merged differences in the file.

Можно также использовать переключатели для отображения и скрытия различий, отображения и скрытия различий в словах и настройки макета.You can also use the toggles to show/hide differences, show/hide word differences, and customize the layout. Вверху с каждой стороны есть флажки, с помощью которых можно перенести все изменения с одной стороны на другую.There are checkboxes on the top of each side that you can use to take all the changes from one side or the other. Чтобы перенести отдельные изменения, можно установить флажки слева от конфликтующих строк с любой стороны.But to take individual changes, you can click the checkboxes to the left of the conflicting lines on either side. Завершив разрешение конфликтов, нажмите в редакторе слияния кнопку Принять слияние.Finally, when you finish resolving the conflicts, you can select the Accept Merge button in the Merge Editor. После этого нужно ввести сообщение о фиксации и зафиксировать изменения, чтобы завершить процесс разрешения.You then write a commit message and commit the changes to complete the resolution.

Настройка параметров GITPersonalize your Git settings

Чтобы настроить параметры GIT на уровне репозитория, а также на глобальном уровне, выберите в строке меню пункты GIT > Параметры или Сервис > Параметры > Управление исходным кодом.To personalize and customize your Git settings at a repository level as well as at a global level, go to either Git > Settings on the menu bar, or to Tools > Options > Source Control on the menu bar. Затем выберите нужные параметры.Then, choose the options you want.

Использование всех возможностей Team Explorer в Visual StudioHow to use the full Team Explorer experience in Visual Studio

Новый интерфейс GIT — это система контроля версий по умолчанию в Visual Studio 2019 начиная с версии 16.8.The new Git experience is the default version control system in Visual Studio 2019 from version 16.8 onwards. Однако при желании этот интерфейс можно отключить.However, if you want to turn it off, you can. Чтобы вернуться в Team Explorer для Git, выберите Средства > Параметры > Среда > Функции предварительной версии и снимите флажок Новый пользовательский интерфейс Git.Go to Tools > Options > Environment > Preview Features and then toggle the New Git user experience checkbox, which will switch you back to Team Explorer for Git.

Что дальше?What’s next

Хотя новый интерфейс GIT теперь включен по умолчанию в Visual Studio 2019 версии 16.8, мы продолжаем добавлять новые функции для его совершенствования.While the new Git experience is now on by default in Visual Studio 2019 version 16.8, we continue to add new features to enhance the experience. Чтобы ознакомиться с новыми обновлениями для интерфейса GIT в предварительной версии, скачайте и установите ее со страницы Visual Studio Preview.If you’d like to check out new updates to the Git experience in a Preview release, you can download and install it from the Visual Studio Preview page.

Важно!

Если у вас есть предложение, отправьте его нам.If you have a suggestion for us, please let us know! Мы будем рады вашему участию в работе над решением на портале Сообщества разработчиков.We appreciate the opportunity to engage with you on design decisions via the Developer Community portal.

См. также разделSee also

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

Перевод статьи
«Git: The Beginner’s Guide to Understanding Core Version Control
Concepts».

Git это жизненно важный инструмент в
арсенале любого разработчика.

Например, буквально на днях этот
инструмент позволил мне исправить
большую ошибку, которую я отправил в
продакшен (исключительно моя вина), и
ушло на это всего 20 минут. Без Git исправление
такой проблемы, вероятно, заняло бы
несколько дней.

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

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

Что такое контроль версий?

Если вы достаточно взрослый человек,
вы, вероятно, помните мир до появления
Google Drive/Docs/Sheets и вам знакомы ситуации
вроде такой, как на картинке:

Group_Paper_All_4_Members_Sections_Included_Final_Draft_Final_3😔.docx

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

Реального способа контролировать
разные версии проекта просто не
существовало. Это был Дикий Запад.

Git решает эту проблему

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

Ладно, а как именно Git может
помочь?

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

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

Как работает Git?

Этот основной функционал Git работает
в два этапа:

1. Добавление измененного кода и
   файлов в зону стейджинга, т. е.,
   подготовка этих файлов к сохранению
   (коммиту)
2. Собственно сохранение подготовленных
   файлов и кода (коммит).

Обязательная аналогия

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

Ну ладно, я не НАСТОЛЬКО стар.

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

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

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

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

Какое это имеет отношение к
Git?

Давайте применим эту аналогию к Git.

• Сам процесс фотосъемки — аналог
  внесения изменений в файлы проекта
  (написание кода, создание или удаление
  файлов).
• Выбор фотографий, которые вы хотите
  поместить в альбом, напоминает добавление
  изменений в зону стейджинга.
• Прикрепление фотографий на страницу
  альбома это коммит — сохранение
  изменений.

Давайте разберем все это подробнее.

Фотосъемка напоминает
изменение файлов проекта

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

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

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

Распечатка (подготовка)
выбранных фотографий напоминает
добавление внесенных в проект изменений
в зону стейджинга

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

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

Прикрепление фотографий на
странице альбома напоминает коммит
кода

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

Если вы будете писать плохие сообщения коммитов, просмотр истории изменений вашего кода будет бесполезен для любого читателя, в том числе и для вас. (Что хорошего в сообщении «Внесены некоторые изменения», если вы понятия не имеете, что это за изменения? Представьте, что вы находите в альбоме фотографию с подписью «Здесь сняты какие-то люди»).

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

Работа с Git

Но достаточно аналогий, идем дальше!

Установка

Во-первых, возможно, что Git у вас уже
установлен. Откройте терминал (командную
строку) и попробуйте запустить команду
git --version. Если высветится номер версии,
пропускайте шаг установки и читайте
дальше. Если ваш терминал не будет знать,
что вы имели в виду под словом «git»,
значит, его еще нужно установить. Для
установки git в вашей операционной системе
следуйте этим
инструкциям.

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

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

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

git init

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

Внесение изменений в проект

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

Основные команды

git status

Это как проверка работоспособности
— помогает понять, что, по мнению Git,
происходит сейчас в проекте. То есть,
какие изменения он заметил, все ли
работает, как должно и т. п.

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

Сейчас я добавлю мой файл README.md и снова
запущу команду git status:

Команда touch это тличный способ быстро создать пустой файл.

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

git add

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

git add README.md
git status

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

Что же я фактически сделал, выполнив
команду git add README.md? Я сказал Git, что хочу
включить в будущий коммит все изменения,
внесенные мной в файл README.md со времени
последнего коммита.

Но вносить файлы по одному неудобно,
особенно если учитывать, что мы часто
работаем одновременно со многими
файлами. Вместо того чтобы запоминать
каждый файл, с которым вы работали, можно
автоматически добавить в стейджинг все
файлы, в которые были внесены изменения.
Я предпочитаю использовать для этого
флаг -А:

git add -A

Флаг -А говорит добавить в стейджинг
все файлы с изменениями.

Примечание. Вы наверняка не раз столкнетесь с рекомендацией использовать git add . с той же целью (добавления всех измененных файлов в стейджинг). Это рабочий метод, но чтобы команда затронула все изменения, вы должны непременно находиться корневой директории проекта (точка означает текущую директорию). Поэтому, если вы перешли в какую-то вложенную директорию, а файл с изменениями находится вне этой директории, выполнив git add ., вы пропустите этот файл. А команда git add -A касается всего проекта, и не важно, в какой именно директории вы находитесь в данный момент.

git commit

Когда вы готовы сохранить свои
изменения, вы делаете это при помощи
команды git commit. Но вы же не забыли, что
нужно добавить сообщение коммита? Если
вы просто запустите git commit и нажмете
Enter, в терминале откроется окно редактора
(например, Vi или Nano), в котором вы сможете
написать сообщение коммита.

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

git commit -m "Added some really important information to the
README"

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

Давайте еще раз посмотрим на весь этот
процесс в гифке:

Примечание: в гифке используется git
add, но мне стоило использовать git add -A для
большей точности. Ну, и сообщения коммитов
должны быть получше, чем у меня!

git log

Вы можете просмотреть историю своих
коммитов, запустив команду git log. Чтобы
перемещаться по логу, используйте
стрелки на клавиатуре. В логе вы можете
видеть даты и сообщения коммитов, а
также авторов (людей, сделавших коммит).
Каждый коммит имеет хэш — длинный
уникальный ID, по которому можно обращаться
к коммиту при необходимости.

Путешествие во времени

«Вы все время говорите, что Git позволяет
перемещаться вперед-назад во времени.
А как именно это происходит?»

git checkout

Термин checkout означает процесс переключения
с одного коммита на другой. Помните, что
каждый коммит имеет уникальный ID (хэш)?
Я могу просмотреть свою историю коммитов,
выбрать один из этих уникальных хэшей
и использовать его с командой git checkout.
Если коммит, который я хочу посмотреть,
имеет хэш а2 (на самом деле хэши гораздо
длиннее, это скорее что-то вроде
0c9b8f7c23dea4cf0a0285f14211124b6d5891e9), я могу запустить
следующую команду:

git checkout a2

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

Вот этот процесс в гифке:

Имейте в виду, что третий коммит и все изменения внутри него находятся в полной сохранности. Вы можете к нему вернуться при помощи команды git checkout a3 или (более распространенный вариант) git checkout master.

Теперь, вернувшись в прошлое, вы увидите
сообщение от Git. Что-то вроде следующего:

Note: checking out 'a2'.
 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 
 HEAD is now at a2 Another Message

На данный момент вы больше не находитесь
в ветке master. Вы можете вносить какие-то
экспериментальные изменения и даже
создавать новые коммиты, и все это не
затронет код в ветке master (в гифке это
коммит с хэшем а3).

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

Заключение

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

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

Это означает, что нужно заставлять
себя делать нечто большее, чем просто
читать статьи в надежде чему-то научиться.
Создайте новый репозиторий в пустой
папке, начните добавлять туда файлы,
почаще используйте git status и git log, чтобы
увидеть, как все будет выглядеть.

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

С чего начинается git

Введение

На днях я получил очередной проект по разработке личного кабинета.Как обычно, я открыл консоль, чтобы посмотреть историю проекта, ветки и все ли правки закомичены (от слова commit — фиксировать). Однако ничего из этого я не узнал — проект не содержал .git репозитория.Эта ситуация в очередной раз заставила задуматься о том, как много разработчиков до сих пор не понимают необходимость контролировать изменения в файлах с исходным кодом. А многие и вовсе не знают что это такое, и как этим пользоваться.

Почему нужно использовать систему контроля версий

Основные преимущества:

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

Что такое git

git — распределенная система контроля версий файлов.«Распределенная» значит, что каждый репозиторий содержит всю историю изменений, и из него можно развернуть полноценную рабочую копию проекта.

Основные термины и понятия при работе с системой Git

Репозиторий — дерево изменений проекта.После создания нового репозитория дерево содержит только одну ветку — master. Ветка состоит из коммитов, расположенных в хронологическом порядке. Как правило, в ветке master находятся проверенные и протестированные изменения.

Ветка — указатель на коммит.  На один коммит может указывать несколько веток. Как правило это случается при создании новой ветки из текущей. Например для реализации в ней новой задачи. По мере добавления коммитов — ветки будут расходится в разные стороны.

Коммит (от слова commit — фиксировать) — логическая единица изменений.Каждый из них имеет историю уникальный ID и цепочку предшествующих коммитов. Можно «откатить» (отменить) изменения любого из коммитов. Для любого коммита из истории можно создать указатель, то есть ветку. 

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

В первое время вам понадобятся только основные команды. Давайте рассмотрим их:

• init — создает новый репозиторий
• status — отображает список измененных, добавленных и удаленных файлов
• branch — отображает список веток и активную среди них
• add — добавляет указанные файлы в индекс
• reset — удаляет указанные файлы из индекса
• commit — фиксирует добавленнные в индекс изменения
• checkout — переключает активную ветку; отменяет не добавленные в индекс изменения
• merge — объединяет указанную ветку с активной
• log — выводит список последних коммитов (можно указать количество и формат)

Примеры команд для работы с Git

Создайте новую папку для тестового проекта. 

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

$ git init

Эта команда создаст новый пустой репозиторий. Проще говоря, появится папка .git с какими-то непонятными файлами. Причем такой репозиторий, который находится в папке проекта, файлы которого вы можете менять — называется «рабочей копией». Существуют еще «внешние копии» или bare-репозитории.

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

Теперь можно вносить изменения.

Список изменений можно увидеть выполнив команду:

$ git status

В консоли появится список измененных файлов.

Добавьте файлы, изменения в которых вы хотите зафиксировать:

$ git add file_name_a.php

Файлы можно указывать через пробел. Все файлы в данной папке и ее подпаках можно добавить командой:

$ git add .

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

Добавить все новые и измененные файлы можно командой:

$ git add -A

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

Если вы добавили файл из другого логического блока, удалите его из индекса командой:

$ git reset file_name_b.php

Зафиксируйте эти изменения в другом коммите. Так будет удобнее при просмотре истории изменений и отмене изменений.

Если вы случайно изменили не тот файл — верните его к последнему зафиксированному состоянию командой:

$ git checkout file_name_c.php

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

$ git checkout -- .

Ненужные новые файлы достаточно просто удалить. Или это можно сделать командой:

$ git reset --hard HEAD

Проект будет полностью приведен к последнему зафиксированному состоянию.

$ git commit

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

fix| order price
now price includes vat

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

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

Теперь можно посмотреть историю изменений, ваш коммит должен в ней отобразиться:

$ git log

Заключение

Как видите, ничего сложного.

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

Новые вопросы с меткой [git]

Git — распределённая система контроля версий файлов. Используйте эту метку для вопросов о git. Вопросы, касающиеся каких-то отдельных команд, дополнительно отмечайте соответствующими метками (git-pull, git-push, git-merge и т.п.).

regex поиск по всей истории git проекта

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

задан 1 час назад

Работа с GitLab

Не работал с GitLab еще пока, но есть задача, порядок реализации которой не могу понять (мануалы читал). Смысл задачи — залить измененные файлы в GitLab.
Необходимо сделать новый проект, т.к. у меня …

задан вчера

Создание бекапов конфликтных файлов при мерже

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

задан 2 дня назад

Minebot

66211 золотой знак55 серебряных знаков1515 бронзовых знаков

Как найти коммиты которые были смерджены мердж коммитом

Как найти коммиты по мердж коммиту которые были смерджены с другого бранча?
На картинке ниже зеленая ветка эта master, у меня есть SHA коммита под номером 1 но нет названия ветки которую вливали а …

задан 16 мар в 7:52

J Mas

1,94455 золотых знаков2121 серебряный знак5454 бронзовых знака

Command failed: heroku login

Начал изучать Django. По ссылке глава на которой застрял: https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Deployment.
Проблема в том, что при выполнении команды ‘heroku create’ …

задан 13 мар в 7:13

не работает ubuntu на virtualBox

с недавнего времени перестал работать ubuntu. Подозреваю, что это связанно с тем, что я установил git и docker. Думаю что проблема в нём. Также скачивал с [https://docs.microsoft.com/ru-ru/windows/wsl/…

задан 9 мар в 14:28

brenin

111 бронзовый знак

не работает npm i после запроса ssh

При попытке выполнить npm i в react-native проекте появляется ошибка

Ilya Shevtsov@DESKTOP-86UQNMD MINGW64 /c/androidprojects/ProjectApp/StudyDesk (master)
$ npm i
npm ERR! code 129
npm ERR! command …

задан 5 мар в 15:52

Отмена git rebase -i

Было у меня 2 комита «Добавлены новые исключения» и «Сменил описание в ReleaseNotes»,

решил их объединить. Они объединились под именем «Добавлены новые исключения». Но в …

задан 5 мар в 15:52

Как удалить git со всей историей в Intelij Idea

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

задан 4 мар в 16:50

Енот

5977 бронзовых знаков

etckeeper и разграничение доступа

У меня есть установленный etckeeper на десяти серверах с Centos 6 и Centos 7.
Он выгружает /etc с сервера в индивидуальный гит-репозиторий (для каждого сервера он свой). Мой гит развернут на основе …

задан 4 мар в 9:51

Git — клиенты графического интерфейса

GitHub для команд · Создавайте как лучшие команды на планете · GitHub

GitHub для команд · Создавайте как лучшие команды на планете · GitHub

GitHub для команд

Благодаря CI / CD, Dependabot и крупнейшему в мире сообществу разработчиков GitHub дает вашей команде все необходимое для более быстрой разработки лучшего программного обеспечения.

Сотрудничество

Управляйте всем в одном месте

Подключите свои любимые инструменты

Создайте способ, который лучше всего подходит для вас, с поддержкой всех ваших интеграций, включая Slack, Jira и другие.

Добавьте свою команду одним щелчком мыши

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

Ускорение проверки кода

Повысьте качество кода с помощью инструментов проверки кода, которые вписываются в ваш рабочий процесс.

Планируйте вместе

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

«Как команда, мы более уверены в том, что мы находимся в гармонии. Мы все можем видеть нашу работу, отзывы и план действий через GitHub ».

Ли Адкинс, руководитель отдела разработки

Пик денег

Автоматизация

Создавайте рабочие процессы CI / CD, которые работают на вас

Оптимизируйте свой CI / CD

Создавайте, тестируйте и развертывайте проекты в любой ОС, языке или облаке.

Выберите из тысяч действий

Найдите созданные сообществом рабочие процессы GitHub Actions на GitHub Marketplace или создайте свои собственные.

Ответить на события GitHub

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

Совместная работа над рабочими процессами

Создавайте, делитесь, улучшайте и повторно используйте действия точно так же, как код.

Изучите действия GitHub

«С GitHub Actions развертывание происходит на 75 процентов быстрее — это занимает около 10 минут по сравнению с 40 минутами, которые требовались, когда они выполнялись вручную.”

Пьер Лорак, технический руководитель

Переднее приложение

Дом мировых команд разработчиков программного обеспечения

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

Готовы начать свою команду

?

Команда GitHub

Расширенное сотрудничество и
поддержка команд

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

Enterprise · Более разумный способ совместной работы · GitHub

Enterprise · Более разумный способ совместной работы · GitHub

GitHub для предприятий

• Увеличьте скорость проявителя.

• Защищайте каждый шаг.

• Автоматизируйте все рабочие процессы.

• Новое определение сотрудничества.

• Нам доверяют более 50 миллионов разработчиков.

Связаться с отделом продаж

Начать бесплатную пробную версию

Расширьте возможности своей команды.

Преобразуйте свой бизнес.

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

Подключиться

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

Познакомьтесь с нашим сообществом

Оставайтесь на связи

Поднимите свой профиль в качестве лидера в области открытого исходного кода — и помогите своей команде работать над открытым исходным кодом, который им важен.

Проверьте GitHub Connect

GitHub помогает нам всегда быть в курсе лучших в отрасли инструментов. Мы хотим, чтобы новые сотрудники знали, что GitHub входит в нашу цепочку инструментов, и они рады присоединиться к нам.

Руководитель отдела новых технологий

Американские авиалинии

Обучение под руководством разработчиков

Помогите своей команде повысить уровень своих навыков там же, где они пишут.

Изучите Learning Lab

40%

Сокращение времени адаптации разработчиков *

639%

Возврат инвестиций за 3 года *

45

Минут, сэкономленных на разработчика, в день *

* Результаты основаны на объединенной организации из 1800 разработчиков, использующих GitHub в течение трех лет.

100 млн +

Частные и публичные репозитории

1000 с

Сообщества с открытым исходным кодом

60%

Компании из списка Fortune 500

GitHub Enterprise

Необходимая безопасность, автоматизация и совместная работа для ваших команд.

$ 21

На пользователя / в месяц

• Единый вход SAML

• 50 000 минут действий в месяц
  Бесплатно для публичных репозиториев

• 50 ГБ хранилища GitHub Packages
  Бесплатно для публичных репозиториев

• Расширенный аудит

Начать бесплатную пробную версию

Новый

GitHub One

Универсальная платформа для инноваций
на предприятии.

• Все, что входит в Enterprise

• Безопасность на уровне сообщества

• 24/7 поддержка

• Непрерывное обучение

Связаться с отделом продаж

Ознакомьтесь со всеми нашими планами и функциями

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

Что такое Git: станьте профессионалом в Git с этим руководством

На сегодняшний день наиболее широко используемой современной системой управления версиями в мире является Git. Git — зрелый, активно поддерживаемый проект с открытым исходным кодом, первоначально разработанный в 2005 году Линусом Торвальдсом, известным создателем ядра операционной системы Linux.Огромное количество программных проектов полагается на Git для контроля версий, включая коммерческие проекты, а также проекты с открытым исходным кодом. Разработчики, которые работали с Git, хорошо представлены в пуле доступных специалистов по разработке программного обеспечения, и он хорошо работает с широким спектром операционных систем и IDE (интегрированных сред разработки).

Имея распределенную архитектуру, Git является примером DVCS (отсюда и распределенная система контроля версий). Вместо того, чтобы иметь только одно место для полной истории версий программного обеспечения, как это часто бывает в некогда популярных системах контроля версий, таких как CVS или Subversion (также известная как SVN), в Git рабочая копия кода каждого разработчика также является репозиторием. который может содержать полную историю всех изменений.

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

Производительность

Необработанные характеристики производительности Git очень сильны по сравнению со многими альтернативами. Фиксация новых изменений, ветвление, слияние и сравнение прошлых версий оптимизированы для повышения производительности. Алгоритмы, реализованные внутри Git, используют глубокие знания об общих атрибутах реальных файловых деревьев исходного кода, о том, как они обычно меняются с течением времени и каковы шаблоны доступа.

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

Распространение также дает значительные преимущества в производительности.

Например, скажем, разработчик, Алиса, вносит изменения в исходный код, добавляя функцию для предстоящего выпуска 2.0, а затем фиксирует эти изменения с описательными сообщениями. Затем она работает над второй функцией и тоже фиксирует эти изменения. Естественно, они хранятся как отдельные части работы в истории версий. Затем Алиса переключается на ветвь версии 1.3 того же программного обеспечения, чтобы исправить ошибку, которая затрагивает только эту старую версию. Это сделано для того, чтобы дать возможность команде Алисы выпустить версию 1 с исправлением ошибок.3.1, до того, как будет готова версия 2.0. Затем Алиса может вернуться в ветвь 2.0, чтобы продолжить работу над новыми функциями для 2.0, и все это может происходить без какого-либо доступа к сети и, следовательно, быстро и надежно. Она могла сделать это даже в самолете. Когда она будет готова отправить все индивидуально зафиксированные изменения в удаленный репозиторий, Алиса может «протолкнуть» их одной командой.

Безопасность

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

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

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

Гибкость

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

Git был разработан для поддержки ветвления и тегирования как первоклассных граждан (в отличие от SVN), и операции, которые влияют на ветки и теги (например, слияние или возврат), также сохраняются как часть истории изменений. Не все системы контроля версий поддерживают этот уровень отслеживания.

Контроль версий с помощью Git

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

Git хорош

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

Git — стандарт де-факто

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

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

В дополнение к преимуществам большого кадрового резерва преобладание Git также означает, что многие сторонние программные инструменты и службы уже интегрированы с Git, включая IDE, и наши собственные инструменты, такие как клиент DVCS для настольных ПК Sourcetree, программное обеспечение для отслеживания проблем и проектов, Jira и служба хостинга кода Bitbucket.

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

Git — качественный проект с открытым исходным кодом

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

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

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

Критика Git

Git часто критикуют за то, что его сложно изучить.Некоторая терминология в Git будет новой для новичков и для пользователей других систем, терминология Git может быть другой, например, revert в Git имеет другое значение, чем в SVN или CVS. Тем не менее, Git очень эффективен и предоставляет огромные возможности своим пользователям. Чтобы научиться использовать эту силу, может потребоваться некоторое время, однако, как только она будет изучена, команда может использовать эту силу для увеличения скорости своего развития.

Для тех команд, которые поступают из нераспределенной VCS, наличие центрального репозитория может показаться хорошей вещью, которую они не хотят терять.Однако, хотя Git был разработан как распределенная система контроля версий (DVCS), с Git вы все равно можете иметь официальный канонический репозиторий, в котором должны храниться все изменения в программном обеспечении. Благодаря Git, поскольку репозиторий каждого разработчика завершен, их работа не должна ограничиваться доступностью и производительностью «центрального» сервера. Во время простоев или в автономном режиме разработчики по-прежнему могут просматривать полную историю проекта. Поскольку Git является гибким и распространяемым, вы можете работать так, как вы привыкли, но получить дополнительные преимущества Git, некоторые из которых вы можете даже не осознавать, что вам не хватает.

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

что это такое и как им пользоваться

Git — это распределенная система управления версиями с открытым исходным кодом . Теперь это много слов, чтобы дать определение Git.

Позвольте мне разбить его и пояснить формулировку:

• Система управления: Это в основном означает, что Git — это средство отслеживания контента.Таким образом, Git можно использовать для хранения контента — он в основном используется для хранения кода из-за других функций, которые он предоставляет.
• Система контроля версий : Код, который хранится в Git, постоянно меняется по мере добавления нового кода. Кроме того, многие разработчики могут добавлять код параллельно. Таким образом, система контроля версий помогает справиться с этим, сохраняя историю произошедших изменений. Кроме того, Git предоставляет такие функции, как ветки и слияния, о которых я расскажу позже.
• Распределенная система контроля версий : Git имеет удаленный репозиторий, который хранится на сервере, и локальный репозиторий, который хранится на компьютере каждого разработчика.Это означает, что код не просто хранится на центральном сервере, но полная копия кода присутствует на всех компьютерах разработчиков. Git — это распределенная система контроля версий, поскольку код присутствует на каждом компьютере разработчика. Позже в этой статье я объясню концепцию удаленных и локальных репозиториев.

Зачем нужна система контроля версий, такая как Git

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

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

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

Давайте приступим к использованию Git сейчас

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

Загрузить git

По этой ссылке подробно описано, как установить Git в нескольких операционных системах:
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

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

  git --version  

Создайте локальный репозиторий Git

Создайте на своем компьютере папку для вашего проекта. Назовем папку проекта simple-git-demo .

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

  cd simple-git-demo
git init  

Команда git init добавляет в проект локальный репозиторий Git.

Давайте добавим небольшой код сейчас

Создайте файл с именем demo.txt в папке проекта и добавьте в него следующий текст:

  Исходное содержимое  

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

Размещение и фиксация кода

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

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

Staging

Используйте следующую команду для размещения файла:

  git add demo.txt  

Если вы хотите добавить несколько файлов, вы можете использовать:

git add file1 file2 file3

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

  git add. 

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

Фиксация

Используйте следующую команду для фиксации файла:

  git commit -m «Начальная фиксация»  

«Первоначальная фиксация» — это сообщение фиксации здесь. Введите соответствующее сообщение фиксации, чтобы указать, какие изменения кода были сделаны в этой конкретной фиксации.

Git Status и Git Log

Теперь измените файл demo.txt и добавьте следующий фрагмент:

  Начальное содержимое Добавление дополнительного содержимого  

Status

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

Используйте следующую команду для просмотра статуса:

  git status  

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

Теперь давайте добавим demo.txt в область подготовки и зафиксируем его, используя следующие команды:

  git add demo.txt git commit -m "файл demo.txt изменен"  

Log

Use git log , чтобы распечатать все сделанные до сих пор коммиты.

Для этого используется следующая команда:
git log

В журнале отображается автор каждой фиксации, дата фиксации и сообщение фиксации.

Филиалы

До сих пор мы не создавали никаких веток в Git. По умолчанию коммиты Git попадают в ветку master .

Что такое филиал?

Ветвь — это не что иное, как указатель на последний коммит в репозитории Git. Итак, в настоящее время наша основная ветвь является указателем на вторую демонстрацию фиксации «.txt изменен ».

Зачем нужно несколько филиалов?

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

Изначально фиксация 1 и фиксация 2 выполнялись в главной ветке. После фиксации 2 создается новая ветка с именем «Test», и в тестовую ветвь добавляются фиксация 3 и фиксация 4.

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

Здесь тестовая ветвь и основная ветвь разошлись и имеют разный код — код из тестовой ветки можно объединить с главной ветвью с помощью git merge . Это будет рассмотрено позже.

Создать новую ветвь на локальном компьютере

Создайте новую ветку с именем test , используя следующую команду:

  git branch test  

Эта команда создает ветвь test .

Мы все еще находимся в контексте ветки master.Для перехода на тестируйте ветку . используйте следующую команду:

  git checkout test  

Теперь мы находимся в ветке test .

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

  git branch  

Сделайте некоторые коммиты в новой ветке

Измените demo.txt , добавив следующий фрагмент:

  Исходное содержимое Добавление дополнительного содержимого Добавление содержимого из тестовой ветви  

Теперь выполните этап и выполните фиксацию, используя следующие команды:

  git add demo.txt git commit -m "Test Branch Commit"  

Эта фиксация была сделана в тестовой ветке, и теперь тестовая ветвь опережает Master Branch на 1 фиксацию, поскольку тестовая ветвь также включает 2 фиксации из основной ветки.

Вы можете проверить историю фиксации в Test Branch, используя:

  git log  

Merging

В настоящее время Test Branch опережает Master на 1 фиксацию. Допустим, теперь мы хотим, чтобы весь код из тестовой ветви был возвращен в главную ветвь.Здесь очень полезен git merge .

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

Сначала вернитесь в главную ветку:

  git checkout master  

Затем запустите команду merge :

  git merge test  

После выполнения этих двух команд слияние должно быть успешным. В этом примере нет конфликтов.

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

Теперь запустите git log , и вы заметите, что мастер также имеет 3 фиксации.

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

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

Отображение удаленных и локальных репозиториев

GitHub

Здесь мы будем использовать GitHub для удаленного репозитория.

Перейдите на https://github.com/ и создайте учетную запись.

После регистрации на домашней странице GitHub щелкните Start a Project , чтобы создать новый репозиторий Git. Дайте репозиторию имя и нажмите «Создать репозиторий».

Введите имя как git-blog-demo .

Это создаст удаленный репозиторий в GitHub, и когда вы откроете репозиторий, откроется страница, подобная изображению ниже:

URL-адрес репозитория — это выделенная часть https: // github.com / aditya-sridhar / git-blog-demo.git

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

  git remote add origin [url репозитория]  

Git Push

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

  git push -u origin master  

Это подталкивает код из главной ветки в локальном репозитории в главная ветка в удаленном репозитории.

Дополнительные команды

Git Pull

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

  git pull origin master  

Git Clone

git clone используется для клонирования существующего удаленного репозитория на ваш компьютер. Для этого используется следующая команда:

  git clone [URL-адрес репозитория]  

Поздравляю

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

Я скоро опубликую еще одну статью о более сложных концепциях Git.Будьте на связи!

Об авторе

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

Не стесняйтесь связаться со мной в моей учетной записи LinkdIn https://www.linkedin.com/in/aditya1811/

Вы также можете подписаться на меня в Twitter https://twitter.com/adityasridhar18

Мой веб-сайт: https : //adityasridhar.com/

Другие мои сообщения

Как эффективно использовать Git

Введение в Git и GitHub для начинающих (Учебник)

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

Шаг 0: Установите git и создайте учетную запись GitHub

Первые две вещи, которые вам нужно сделать, это установить git и создать бесплатную учетную запись GitHub.

Следуйте инструкциям здесь, чтобы установить git (если он еще не установлен). Обратите внимание, что в этом руководстве мы будем использовать git только в командной строке. Хотя есть несколько отличных графических интерфейсов пользователя git (графические пользовательские интерфейсы), я думаю, что проще сначала изучить git, используя специфические для git команды, а затем опробовать графический интерфейс git, как только вы освоитесь с этой командой.Примечание: 95% других онлайн-ресурсов и обсуждений git также предназначены для интерфейса командной строки.

Как только вы это сделаете, создайте здесь учетную запись GitHub.

Git и GitHub

Небольшое отступление: git и GitHub — это , а не . Git — это инструмент управления версиями с открытым исходным кодом, созданный в 2005 году разработчиками, работающими над операционной системой Linux; GitHub — компания, основанная в 2008 году, которая производит инструменты, которые интегрируются с git. Вам не нужен GitHub для использования git, но вы не можете использовать GitHub без использования git.Есть много других альтернатив GitHub, таких как GitLab, BitBucket, и решения для самостоятельного размещения, такие как gogs и gittea. Все они называются в git-speak «пультами» и не являются обязательными. Вам не нужно использовать пульт для использования git, но это упростит обмен вашим кодом с другими.

Шаг 1. Создайте локальный репозиторий git

При создании нового проекта на локальном компьютере с помощью git вы сначала создаете новый репозиторий (или, часто, для краткости, «репо»).

Для использования git мы будем использовать терминал. Если у вас нет большого опыта работы с терминалом и основными командами, ознакомьтесь с этим руководством (если вы не хотите / не нуждаетесь в коротком уроке истории, перейдите к шагу 3).

Для начала откройте терминал и перейдите туда, где вы хотите разместить проект на локальном компьютере, с помощью команды cd (сменить каталог). Например, если у вас есть папка «проекты» на рабочем столе, введите что-то вроде:

Чтобы инициализировать репозиторий git в корне папки, выполните команду git init:

Шаг 2. Добавьте новый файл в репо

Добавьте новый файл в проект с помощью любого текстового редактора, который вам нравится, или с помощью сенсорной команды.`touch newfile.txt` просто создает и сохраняет пустой файл с именем newfile.txt.

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

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

По сути, здесь говорится: «Эй, мы заметили, что вы создали новый файл с именем mnelson.txt, но, если вы не используете команду ‘git add’, мы не собираемся ничего с ним делать».

Интерлюдия: промежуточная среда, фиксация и вы

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

Коммит — это запись того, какие изменения вы внесли с момента последнего коммита.По сути, вы вносите изменения в свое репо (например, добавляете файл или изменяете его), а затем говорите git, чтобы эти изменения были внесены в коммит.

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

Итак, как сказать git, какие файлы нужно поместить в коммит? Именно здесь на помощь приходит промежуточная среда или индекс. Как видно на шаге 2, когда вы вносите изменения в свое репо, git замечает, что файл был изменен, но не будет с ним ничего делать (например, добавляя его в коммит).

Чтобы добавить файл в коммит, вам сначала нужно добавить его в промежуточную среду. Для этого вы можете использовать команду git add (см. Шаг 3 ниже).

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

Примечание. Промежуточная среда, также называемая «промежуточная», является новым предпочтительным термином для этого, но вы также можете видеть, что она называется «индекс».

Шаг 3. Добавьте файл в промежуточную среду

Добавьте файл в промежуточную среду с помощью команды git add.

Если вы повторно запустите команду git status, вы увидите, что git добавил файл в промежуточную среду (обратите внимание на строку «Изменения, которые необходимо зафиксировать»).

Повторяю, в файле , а не , которые еще были добавлены в коммит, но вот-вот добавятся.

Шаг 4. Создайте фиксацию

Пора создать свой первый коммит!

Выполните команду git commit -m «Ваше сообщение о фиксации»

Сообщение в конце фиксации должно быть связано с тем, что она содержит — может быть, это новая функция, может быть исправление ошибки, может быть, просто исправление опечатки.Не помещайте сообщения типа «asdfadsf» или «foobar». Это огорчает других людей, которые видят ваш коммит. Очень очень печально. Коммиты живут вечно в репозитории (технически вы можете удалить их, если вам действительно, действительно нужно, но это беспорядочно), поэтому, если вы оставите четкое объяснение своих изменений, это может быть чрезвычайно полезно для будущих программистов (возможно, в будущем!) которые пытаются понять, почему через годы произошли некоторые изменения.

Шаг 5: Создайте новую ветку

Теперь, когда вы сделали новую фиксацию, давайте попробуем что-нибудь более продвинутое.

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

Ветви позволяют вам перемещаться между «состояниями» проекта. Официальные документы git описывают ветки следующим образом: «Ветвь в Git — это просто легкий подвижный указатель на один из этих коммитов». Например, если вы хотите добавить новую страницу на свой веб-сайт, вы можете создать новую ветку только для этой страницы. не затрагивая основную часть проекта.Как только вы закончите со страницей, вы можете объединить свои изменения из своей ветки в основную ветку. Когда вы создаете новую ветку, Git отслеживает, от какого коммита ваша ветка «ответвлена», поэтому он знает историю всех файлов.

Допустим, вы находитесь в основной ветке и хотите создать новую ветку для разработки своей веб-страницы. Вот что вы сделаете: Запустите git checkout -b <имя моей ветки>. Эта команда автоматически создаст новую ветку, а затем «проверит вас», что означает, что git переместит вас в эту ветку за пределы основной ветки.

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

Имя ветки со звездочкой рядом с ней указывает, в какой ветке вы находитесь в данный момент.

Примечание к названиям филиалов

По умолчанию первая ветвь каждого репозитория git называется `master` (и обычно используется в качестве основной ветки в проекте). В рамках общей работы по борьбе с расизмом в технической индустрии некоторые группы начали использовать альтернативные имена для ветки по умолчанию (например, в этом руководстве мы используем «первичный»).В другой документации и обсуждениях вы можете встретить «главный» или другие термины, используемые для обозначения основной ветви. Независимо от названия, просто имейте в виду, что почти у каждого репозитория есть основная ветка, которую можно рассматривать как официальную версию репозитория. Если это веб-сайт, то основная ветвь — это версия, которую видят пользователи. Если это приложение, то основная ветвь — это версия, которую загружают пользователи. Это не технически (git не обрабатывает какие-либо ветки иначе, чем другие ветки), но это то, как git традиционно используется в проекте.

Если вам интересно решение использовать другие имена веток по умолчанию, на GitHub есть объяснение их изменения здесь: https://github.com/github/renaming

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

Шаг 6. Создайте новый репозиторий на GitHub

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

Чтобы создать новое репо на GitHub, войдите в систему и перейдите на домашнюю страницу GitHub. Вы можете найти опцию «Новый репозиторий» под знаком «+» рядом с изображением вашего профиля в правом верхнем углу панели навигации:

После нажатия кнопки GitHub попросит вас назвать свое репо и предоставить краткое описание:

Когда вы закончите заполнение информации, нажмите кнопку «Создать репозиторий», чтобы создать новое репозиторий.

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

(Вы захотите изменить URL-адрес в первой командной строке на то, что GitHub перечисляет в этом разделе, поскольку ваше имя пользователя GitHub и имя репо отличаются.)

Шаг 7. Отправьте ветку на GitHub

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

Чтобы отправить изменения в новую ветку на GitHub, вам нужно запустить git push origin yourbranchname. GitHub автоматически создаст для вас ветку в удаленном репозитории:

Вам может быть интересно, что означает это слово «origin» в приведенной выше команде. Когда вы клонируете удаленный репозиторий на локальный компьютер, git создает для вас псевдоним.Почти во всех случаях этот псевдоним называется «происхождение». По сути, это сокращение для URL-адреса удаленного репозитория. Итак, чтобы отправить свои изменения в удаленный репозиторий, вы могли бы использовать любую команду: git push [email protected]: git / git.git yourbranchname или git push origin yourbranchname

(Если вы впервые используете GitHub локально, вам может быть предложено войти в систему с вашим именем пользователя и паролем GitHub.)

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

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

Шаг 8. Создайте запрос на вытягивание (PR)

Запрос на вытягивание (или PR) — это способ предупредить владельцев репо о том, что вы хотите внести некоторые изменения в их код. Это позволяет им просмотреть код и убедиться, что он хорошо выглядит, прежде чем вносить изменения в основную ветку.

Вот как выглядит PR-страница до того, как вы ее отправили:

И вот как это выглядит после того, как вы отправили PR-запрос:

Вы можете увидеть большую зеленую кнопку внизу с надписью «Merge pull request».Нажав на эту кнопку, вы внесете свои изменения в основную ветку.

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

Шаг 9: Объедините PR

Нажмите зеленую кнопку «Объединить запрос на извлечение». Это объединит ваши изменения в основную ветку.

Когда вы закончите, я рекомендую удалить вашу ветку (слишком много веток могут стать беспорядочными), поэтому также нажмите серую кнопку «Удалить ветку».

Вы можете дважды проверить, что ваши коммиты были объединены, щелкнув ссылку «Коммиты» на первой странице вашего нового репо.

Это покажет вам список всех коммитов в этой ветке. Вы можете увидеть тот, который я только что слил, вверху (запрос на слияние №1).

Вы также можете увидеть хэш-код фиксации справа.Хэш-код — это уникальный идентификатор для этой конкретной фиксации. Это полезно для ссылки на определенные коммиты и при отмене изменений (используйте команду git revert для возврата).

Шаг 10. Получите изменения на GitHub обратно на свой компьютер

Прямо сейчас репозиторий на GitHub выглядит немного иначе, чем на вашем локальном компьютере. Например, фиксация, которую вы сделали в своей ветке и слила с основной веткой, не существует в основной ветке на вашем локальном компьютере.

Чтобы получить самые последние изменения, которые вы или другие пользователи объединили на GitHub, используйте команду git pull origin master (при работе с основной веткой). В большинстве случаев это можно сократить до «git pull».

Здесь показаны все файлы, которые были изменены, и как они изменились.

Теперь мы можем снова использовать команду git log, чтобы увидеть все новые коммиты.

(Возможно, вам потребуется переключить ветки обратно на основную ветвь. Это можно сделать с помощью команды git checkout master.)

Шаг 11. Погрейтесь в своей мерзкой славе

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

• https://training.github.com/
  Официальные шпаргалки Github по git! Удобно запоминать повседневные команды, которые вы будете использовать.
• https://learngitbranching.js.org/
  Смущены или заинтригованы системой веток git? Это просто означает, что ты человек! Это одна из самых глубоких частей git, но, возможно, и самая мощная.Понимание модели ветвей дает вам суперсилы git, и это руководство дает вам способ изучить ветки git визуальным и интуитивно понятным способом.
• https://git-school.github.io/visualizing-git
  Еще один инструмент для визуального изучения git. Это больше похоже на открытую песочницу, чем на Learngitbranching.js.org

.

• https://github.com/jlord/git-it-electron
  Настольное приложение, которое поможет вам изучить git через проблемы, которые вам нужно решить. Он состоит из нескольких уровней, каждый из которых требует от вас использования команд git для получения правильного ответа.
• https://github.com/Gazler/githug
  Если вам понравился git-it, Githug — это еще один учебник на основе головоломок, разработанный, чтобы дать вам практический способ изучения git.

Я также рекомендую найти время, чтобы поработать с вашей командой над моделированием небольшого группового проекта, как мы это сделали здесь. Попросите вашу команду создать новую папку с названием вашей команды и добавить в нее несколько файлов с текстом. Затем попробуйте отправить эти изменения в это удаленное репо. Таким образом, ваша команда сможет начать вносить изменения в файлы, которые они изначально не создавали, и практиковаться в использовании функции PR.Кроме того, используйте инструменты git blame и git history на GitHub, чтобы узнать, какие изменения были внесены в файл и кто эти изменения внес.

Чем больше вы используете git, тем удобнее вам … работать с ним. (Я не удержался.)

* Этот пост был первоначально опубликован в октябре 2015 года Меган Нельсон, в то время старшим инженером-программистом в HubSpot. С тех пор он был обновлен командой продукта HubSpot.

Заинтересованы в работе в группе разработчиков, которая ценит автономность и прозрачность? Ознакомьтесь с нашими открытыми вакансиями и подайте заявку.

Git — ArchWiki

«Я встречал людей, которые думали, что git — это интерфейс для GitHub. Они ошибались, git — это интерфейс для AUR». — Линус Т.

Git — это система контроля версий (VCS), разработанная Линусом Торвальдсом, создателем ядра Linux. Git теперь используется для поддержки пакетов AUR, а также многих других проектов, включая исходные коды ядра Linux.

Установка

Установите пакет git.Для версии для разработки установите пакет git-git ^AUR . Проверьте дополнительные зависимости при использовании таких инструментов, как git svn , git gui и gitk .

Графические интерфейсы

См. Также git GUI Clients.

• Giggle — Интерфейс GTK для git.

https://wiki.gnome.org/Apps/giggle/ || giggle

• GitAhead — Графический клиент git, включая встроенный инструмент слияния.

https://gitahead.github.io/gitahead.com/ || gitahead ^AUR

• Git Cola — Элегантный и мощный графический пользовательский интерфейс для Git, написанный на Python.

https://git-cola.github.io/ || git-cola ^AUR

• Git Extensions — Графический пользовательский интерфейс для Git, позволяющий управлять Git без использования командной строки.

https: // gitextensions.github.io/ || gitextensions ^AUR

• gitg — клиент графического интерфейса GNOME для просмотра репозиториев git.

https://wiki.gnome.org/Apps/Gitg || gitg

• git-gui — портативный графический интерфейс на основе Tcl / Tk для Git.

https://git-scm.com/docs/git-gui || git + tk

• GitHub Desktop — Электронный графический пользовательский интерфейс, созданный командой GitHub.

https://github.com/desktop/desktop || github-desktop ^AUR github-desktop-bin ^AUR

• gitk — браузер репозитория Git на основе Tcl / Tk.

https://git-scm.com/docs/gitk || git + tk

• Гитара — клиент графического интерфейса Git.

https://github.com/soramimi/Guitar || гитара ^AUR

• QGit — программа просмотра графического интерфейса пользователя Git для просмотра истории изменений, содержимого исправлений и измененных файлов, графически отслеживая различные ветки разработки.

https://github.com/tibirna/qgit || qgit

• RabbitVCS — Набор графических инструментов, предназначенных для обеспечения простого и понятного доступа к используемым вами системам контроля версий.

http://rabbitvcs.org/ || rabbitvcs ^AUR

• Sublime Merge — Клиент Git от создателей Sublime Text.

https://www.sublimemerge.com/ || sublime-merge ^AUR

• Tig — интерфейс текстового режима на основе ncurses для git.

https://jonas.github.io/tig/ || tig

• ungit — обеспечивает удобство использования git без ущерба для его универсальности.

https://github.com/FredrikNoren/ungit || nodejs-ungit ^AUR

Конфигурация

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

 $ git config --global user.name " John Doe "
$ git config --global user.электронная почта " [email protected] "
 

См. Начало работы — Первоначальная установка Git.

Дополнительные настройки см. В разделе # Советы и приемы.

Использование

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

См. Начало работы — Основы Git.

Получение репозитория Git

git init , см. Git-init (1)

• Клонировать существующий репозиторий

git clone репозиторий , см. Git-clone (1) (также объясняет URL-адреса Git)

Запись изменений

У проектов

Git есть промежуточная область, которая представляет собой индексный файл в вашем каталоге Git, в котором хранятся изменения, которые войдут в вашу следующую фиксацию.Поэтому, чтобы записать измененный файл, вам сначала нужно добавить его в индекс (подготовить его). Затем команда git commit сохраняет текущий индекс в новом коммите.

Изменения стадии

• Добавить изменения рабочего дерева в индекс

git add pathspec , см. Git-add (1)

• Удалить изменения из индекса

git reset pathspec git-reset (1)

• Показать изменения, которые необходимо зафиксировать, неустановленные изменения и неотслеживаемые файлы

git status , см. git-status (1)

Вы можете указать Git игнорировать некоторые неотслеживаемые файлы, используя .gitignore , см. gitignore (5).

Git не отслеживает перемещение файлов. Обнаружение перемещения во время слияния основано только на сходстве содержимого. Команда git mv существует только для удобства и эквивалентна:

 $ mv -i foo bar
$ git reset - foo
$ git add bar
 

Подтверждение изменений

Команда git commit записывает поэтапные изменения в репозиторий, см. Git-commit (1).

• -m — предоставить сообщение фиксации в качестве аргумента вместо того, чтобы составлять его в текстовом редакторе по умолчанию
• -a — автоматически помещать файлы, которые были изменены или удалены (не добавляет неотслеживаемые файлы)
• --amend — повторить последнюю фиксацию, изменив сообщение фиксации или зафиксированные файлы.

Совет: Всегда фиксируйте небольшие изменения часто и с осмысленными сообщениями.

Выбор редакции

Git предлагает несколько способов указать редакции, см. Gitrevisions (7) и Revision Selection.

Многие команды Git принимают исправления в качестве аргументов. Фиксацию можно идентифицировать по любому из следующих факторов:

• SHA-1 хэш коммита (первых 7 цифр обычно достаточно для его однозначной идентификации)
• Любая метка фиксации, такая как имя ветки или тега
• Метка HEAD всегда относится к текущему извлеченному коммиту (обычно это голова ветки, если вы не использовали git checkout для возврата в истории к старой фиксации)
• Любой из вышеперечисленных плюс ~ для ссылки на предыдущие коммиты.Например, HEAD ~ относится к одной фиксации перед HEAD и HEAD ~ 5 относится к пяти фиксациям перед HEAD .

Просмотр изменений

Показать различия между коммитами:

 $ git diff HEAD HEAD ~ 3
 

или между площадкой подготовки и рабочим деревом:

 $ git diff
 

Просмотреть историю изменений (где « -N » — количество последних коммитов):

 $ git log -p  (-N) 
 

Отмена действий

Эти, наряду с некоторыми другими, дополнительно объясняются при отмене изменений.

Для более сложных модификаций истории, таких как git commit --amend и git rebase , см., Например, rewriting-history. Настоятельно рекомендуется не использовать такие перезаписи для коммитов, которые выполнялись совместно с другими пользователями. Или, по крайней мере, заранее тщательно скоординируйте это.

Ответвление

Эту статью или раздел нужно расширить.

Причина: Добавьте ссылки для некоторых распространенных моделей ветвления. (Обсудить в Обсуждении: Git #)

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

Создайте ветку, название которой точно отражает ее назначение:

 $ git branch  добавление раздела справки 
 

Список ветвей:

 $ ветка git
 

Переключатель филиалов:

 $ git checkout  ветка 
 

Создание и переключение:

 $ git checkout -b  ветка 
 

Слить ветку с основной веткой:

 $ git checkout master
$ git merge  ветка 
 

Изменения будут объединены, если они не конфликтуют.В противном случае Git напечатает сообщение об ошибке и аннотирует файлы в рабочем дереве для записи конфликтов. Аннотации могут отображаться с помощью git diff . Конфликты разрешаются путем редактирования файлов для удаления аннотаций и фиксации окончательной версии. См. Раздел # Работа со слияниями ниже.

Когда закончите с веткой, удалите ее с помощью:

 $ git branch -d  branch 
 

Сотрудничество

Типичный рабочий процесс Git:

1. Создайте новый репозиторий или клонируйте удаленный.
2. Создайте ветку для внесения изменений; затем зафиксируйте эти изменения.
3. Объединяйте коммиты для лучшей организации / понимания.
4. Слияние возвращается в основную ветку.
5. (Необязательно) Отправьте изменения на удаленный сервер.

Запросы на вытяжку

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

Тянуть:

 $ git pull  расположение  master
 

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

В качестве альтернативы первоначальный автор может выбрать изменения, которые необходимо включить. Используя опцию fetch (и опцию log со специальным символом FETCH_HEAD ), содержимое запроса на вытягивание можно просмотреть, прежде чем решить, что делать:

 $ git fetch  расположение  master
$ git log -p HEAD..FETCH_HEAD
$ git merge  расположение мастера 
 

Использование пультов

Remote — это псевдонимы для отслеживаемых удаленных репозиториев.Ярлык создается, определяя местоположение. Эти метки используются для идентификации часто используемых репозиториев.

Создать пульт:

 $ git remote добавить  метка   расположение 
 

Получить пульт:

 $ git fetch  метка 
 

Показать различия между мастером и удаленным мастером:

 $ git log -p master ..  метка  / master
 

Просмотр пультов для текущего репозитория:

 $ git удаленный -v
 

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

Перенести в репозиторий

После того, как первоначальные авторы предоставили права, внесите изменения с помощью:

 $ git push  расположение   ветка 
 

Когда выполняется git clone , он записывает исходное местоположение и дает ему удаленное имя origin .

Итак, что обычно делает так:

 $ git push origin master
 

Если используется опция -u ( --set-upstream ), местоположение записывается, поэтому в следующий раз потребуется просто git push .

Работа со слияниями

См. Основные конфликты слияния в книге Git для подробного объяснения того, как разрешать конфликты слияния. Слияния обычно обратимы. Если вы хотите отказаться от слияния, обычно можно использовать команду --abort (например, git merge --abort или git pull --abort ).

История и версия

Поиск в истории

git log предоставит историю с контрольной суммой фиксации, автором, датой и коротким сообщением.Контрольная сумма — это «имя объекта» объекта фиксации, обычно это 40-символьный хэш SHA-1.

Для истории с длинным сообщением (где « контрольная сумма » может быть усечена, если она уникальна):

 $ git show ( контрольная сумма )
 

Искать шаблон в отслеживаемых файлах:

 $ git grep  шаблон 
 

Искать в файлах .c и .h :

 $ git grep  шаблон  - '*.[ch] '
 

Маркировка

Тег коммитов для управления версиями:

 $ git tag 2.14  контрольная сумма 
 

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

Отметьте текущую фиксацию с помощью:

 $ git tag -a 2.14 -m "Версия 2.14"
 

Список тегов:

 $ git tag -l
 

Удалить тег:

 $ git tag -d 2.08
 

Обновить удаленные теги:

 $ git push - теги
 

Организационные обязательства

Перед отправкой запроса на вытягивание может быть желательно объединить / организовать коммиты. Это делается с помощью опции git rebase --interactive :

 $ git rebase -i  контрольная сумма 
 

Откроется редактор со сводкой всех коммитов в указанном диапазоне; в этом случае включая самую новую ( HEAD ) обратно, но исключая, фиксирует контрольную сумму .Или, чтобы использовать числовую нотацию, используйте, например, HEAD ~ 3 , который перебазирует последние три коммита:

 pick d146cc7 Mountpoint test.
pick 4f47712 Объясните опцию -o в readme.
pick 8a4d479 Переименовать документацию.
 

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

• pick — применить эту фиксацию как есть (по умолчанию).
• edit — Редактировать файлы и / или коммитить сообщение.
• reword — Редактировать сообщение фиксации.
• squash — Слияние / сворачивание с предыдущей фиксацией.
• fixup — Слияние / сворачивание с предыдущим коммитом, отбрасывая его сообщение.

Коммиты могут быть переупорядочены или удалены из истории (но будьте очень осторожны с этим). После редактирования файла Git выполнит указанные действия; если будет предложено решить проблемы слияния, исправьте их и продолжите с помощью команды git rebase --continue или вернитесь назад с помощью команды git rebase --abort .

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

Советы и хитрости

Использование git-config

Git считывает свою конфигурацию из четырех файлов конфигурации INI-типа:

• / etc / gitconfig для общесистемных значений по умолчанию
• ~ / .gitconfig и ~ / .config / git / config (с версии 1.7.12) для пользовательской конфигурации
• .git / config для конфигурации, специфичной для репозитория

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

Список текущих установленных переменных:

 $ git config {--local, - global, - system} --list
 

Установите редактор по умолчанию с vim на nano:

 $ git config --global core.editor "nano -w"
 

Установить действие по умолчанию:

 $ git config --global push.по умолчанию простой
 

Установите другой инструмент для git difftool (по умолчанию meld ):

 $ git config --global diff.tool vimdiff
 

Дополнительные сведения см. В git-config (1) и Git Configuration.

Соблюдайте правила этикета

• Рассматривая возможность участия в существующем проекте, прочтите и поймите его лицензию, так как она может чрезмерно ограничить вашу способность изменять код. Некоторые лицензии могут вызывать споры по поводу права собственности на код.
• Подумайте о сообществе проекта и о том, насколько хорошо вы можете в него вписаться. Чтобы получить представление о направлении проекта, прочтите любую документацию и даже журнал репозитория.
• При запросе на извлечение фиксации или отправку патча держите его маленьким и хорошо документированным; это поможет сопровождающим понять ваши изменения и решить, объединить ли их или попросить вас внести некоторые поправки.
• Если вклад отклонен, не расстраивайтесь, в конце концов, это их проект.Если это важно, обсудите аргументы в пользу вклада как можно яснее и терпеливее: при таком подходе в конечном итоге может стать возможным решение.

Ускорение аутентификации

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

Протокол по умолчанию

Если вы используете мультиплексное соединение SSH, как показано выше, Git over SSH может быть быстрее, чем HTTPS. Кроме того, некоторые серверы (например, AUR) разрешают отправку только через SSH.Например, следующая конфигурация установит Git через SSH для любого репозитория, размещенного на AUR.

 ~ / .gitconfig 

 [url "ssh: //[email protected]/"]
вместо этогоOf = https://aur.archlinux.org/
вместо этогоOf = http://aur.archlinux.org/
вместо этогоOf = git: //aur.archlinux.org/
 

Завершение Bash

Чтобы включить завершение Bash, укажите источник /usr/share/git/completion/git-completion.bash в файле запуска Bash. В качестве альтернативы установите bash-Completion.

Подсказка Git

Пакет Git поставляется со сценарием приглашения. Чтобы включить его, укажите источник /usr/share/git/completion/git-prompt.sh и установите настраиваемое приглашение с параметром % s :

• Для Bash: PS1 = '[\ u @ \ h \ W $ (__ git_ps1 "(% s)")] \ $'
• Для zsh: setopt PROMPT_SUBST; PS1 = '[% n @% m% c $ (__ git_ps1 "(% s)")] \ $'

Обратите внимание, что подстановка команд должна быть экранирована, подробности см. В разделе Настройка Bash / Приглашения # Встраивание команд.См. Раздел Оболочка командной строки # Файлы конфигурации для постоянной конфигурации.

При переходе в каталог репозитория Git в подсказке отображается имя ветки. Дополнительные сведения могут быть отображены в подсказке:

GIT_PS1_SHOWUPSTREAM необходимо установить на auto , чтобы изменения вступили в силу.

Примечание: Если вы заметили, что $ (__ git_ps1) возвращает ((неизвестно)) , тогда существует .git в вашем текущем каталоге, который не содержит репозитория, поэтому Git не распознает его. Это может, например, произойти, если вы ошибочно приняли файл конфигурации Git как ~ / .git / config вместо ~ / .gitconfig .

В качестве альтернативы вы можете использовать один из пакетов настройки приглашения оболочки git из AUR, например bash-git-prompt ^AUR или gittify ^AUR .

Визуальное представление

Чтобы получить представление об объеме проделанной работы:

 $ git diff --stat
 

git log с представлением разветвления:

 $ git log --graph --oneline --decorate
 

git log псевдоним графика (т.е.

Если адрес репозитория изменится, его удаленное местоположение необходимо будет обновить:

 $ git удаленный источник set-url git @  адрес :  пользователь / репо  .git
 

Подписанное добавление строки (подпись имени и адреса электронной почты добавляется к фиксации, которая требуется для некоторых проектов):

 $ git commit -s
 

Signed-off-by автоматически добавляется к исправлениям (при использовании git format-patch commit ):

 $ git config --local format.подписание верно
 

Зафиксируйте определенные части файлов, которые были изменены. Это полезно, если сделано большое количество изменений, которые лучше всего разбить на несколько коммитов:

 $ git add -p
 

Подписание коммитов

Git позволяет подписывать коммиты и теги с помощью GnuPG, см. Подпись вашей работы.

Примечание: Чтобы использовать проклятия pinentry для подписи GPG, убедитесь, что export GPG_TTY = $ (tty) (в качестве альтернативы используйте pinentry-tty), в противном случае шаг подписания не удастся, если GPG в настоящее время находится в заблокированном состоянии (поскольку он не может запрашивать штырь).

Чтобы настроить Git для автоматической подписи коммитов:

 $ git config --global commit.gpgSign true
 

Работа с неосновной веткой

Иногда сопровождающий просит проделать работу над веткой. Эти ветви часто называют devel или test . Начните с клонирования репозитория.

Чтобы ввести другую ветку рядом с master ( git clone показывает только master ветку, но другие все еще существуют, git branch -a для отображения):

 $ git checkout -b  ветка  origin /  ветка 
 

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

 $ git pull - все
$ git push - все
 

Непосредственная отправка исправлений в список рассылки

Если вы хотите отправлять исправления непосредственно в список рассылки, вам необходимо установить следующие пакеты: perl-authen-sasl, perl-net-smtp-ssl и perl-mime-tools.

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

Настройте параметры электронной почты:

 $ git config --global sendemail.smtpserver  smtp.example.com 
$ git config --global sendemail.smtpserverport 587 
$ git config --global sendemail.smtpencryption  tls 
$ git config --global sendemail.smtpuser  [email protected] 
 

Теперь вы можете отправить патч в список рассылки (см. Также OpenEmbedded: Как отправить патч в OpenEmbedded # Отправка патчей):

 $ git add  имя_файла 
$ git commit -s
$ git send-email --to =  openembedded-core @ lists.openembedded.org  --confirm = всегда -M -1
 

Когда удаленное репо огромное

Эта статья или раздел требует улучшения языка, синтаксиса вики или стиля. См. Справку: Стиль.

Причина: Использует неформальный язык, сокращения, HTML-теги вместо шаблонов кода и не использует межвики-ссылки. (Обсудить в Обсуждении: Git #)

Когда удаленное репо огромно, можно использовать следующие решения. Примеры взяты из ядра Linux.

Самый простой способ: получить все репо

Вы можете получить весь репозиторий по

 $ git clone git: //git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
 

Примечание: git clone не может быть возобновлен в случае прерывания.

Вы можете обновить свое репо с помощью команды git pull .

Частичная выборка

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

 $ git clone --shallow-exclude v4.13 git: //git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git # Вы получите v4.14 и новее, но не v4.13 и старше.
 

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

 $ git clone --depth 1 git: //git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
 

Позже вы сможете получить более старые коммиты, например,

 $ git fetch --tags --shallow-exclude v4.1 # Получить коммиты после v4.1.
$ git fetch --tags --shallow-с 01.01.2016
 

Без --tags теги не будут извлечены.

Получить другие отделения

Ваше локальное репо отслеживает, в приведенном выше примере, только основное ядро, то есть в котором выполняется последняя разработка . Предположим, вам нужна последняя версия LTS , например, последняя версия 4.14. Вы можете получить это:

 $ git удаленный набор веток --add origin linux-4.17.y
$ git fetch
$ git branch --track linux-4.17.y происхождение / linux-4.17.y
 

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