Как создать git репозиторий в windows

Обновлено: 06.07.2024

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

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

• Инициализация нового репозитория Git
• Клонирование существующего репозитория Git
• Коммит измененной версии файла в репозиторий
• Конфигурирование репозитория Git для удаленной совместной работы
• Распространенные команды для управления версиями Git

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

Что такое репозиторий Git?

Репозиторий Git — это виртуальное хранилище проекта. В нем можно хранить версии кода для доступа по мере необходимости.

Инициализация нового репозитория: git init

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

Создание версии существующего проекта с использованием нового репозитория Git

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

Указание в команде git init существующего каталога проекта приведет к исполнению описанной выше инициализации, но только на уровне этого каталога проекта.

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

Клонирование существующего репозитория: git clone

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

Команду git clone выполняют для создания копии (клонирования) удаленного репозитория. В качестве параметра в команду git clone передается URL-адрес репозитория. Git поддерживает несколько различных сетевых протоколов и соответствующих форматов URL-адресов. В этом примере используется SSH-протокол Git. URL-адреса SSH в Git имеют следующий шаблон: git@HOSTNAME:USERNAME/REPONAME.git

После исполнения команды последние версии файлов из главной ветки удаленного репозитория будут загружены и помещены в новый каталог. Имя нового каталога будет соответствовать параметру REPONAME. В данном случае это javascript-data-store . В каталоге будет вся история удаленного репозитория и только что созданная главная ветка.

Дополнительную информацию об использовании команды git clone и поддерживаемых форматах URL-адресов в Git см. на странице git clone.

Сохранение изменений в репозитории: git add и git commit

У вас появился репозиторий, созданный путем клонирования или инициализации. Теперь вы можете выполнять коммиты изменений в версиях файлов. В следующем примере предполагается, что вы настроили проект в каталоге /path/to/project . В этом примере предлагаются следующие шаги.

• Измените каталоги на /path/to/project
• Создайте новый файл CommitTest.txt с текстом

«тест для обучения работе с Git»

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

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

Совместная работа в разных репозиториях: git push

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

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

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

Сравнение чистых и клонированных репозиториев

Если вы использовали команду git init для создания репозитория с нуля, у вас не будет удаленного репозитория, в который можно помещать изменения. Зачастую для инициализации нового репозитория пользователь переходит на сервис Git-хостинга (например, Bitbucket) и создает репозиторий там. Данный сервис предоставит URL-адрес Git, который затем можно добавить в локальный репозиторий Git. После этого можно выполнять команду git push в репозиторий на хостинге. После создания удаленного репозитория на выбранном хостинге вам понадобится обновить локальный репозиторий, выполнив привязку. Этот процесс описывается далее в руководстве по установке и настройке.

Если вы предпочитаете поддерживать собственный удаленный репозиторий, вам нужно создать «чистый репозиторий». Для этого команды git init и git clone принимают аргумент --bare . Наиболее популярная причина использования чистого репозитория — создание удаленного центрального репозитория Git

Конфигурирование и настройка: git config

После настройки удаленного репозитория его URL-адрес нужно добавить в локальный файл git config , а также создать вышестоящую ветку для локальных веток. Такую возможность предоставляет команда git remote .

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

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

Дополнительную информацию о команде git remote см. на странице удаленной работы в Git .

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

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

• Локальный: /.git/config — настройки на уровне репозитория.
• Глобальный: /.gitconfig — настройки на уровне пользователя. Здесь хранятся настройки с флагом --global.
• Системный: $(prefix)/etc/gitconfig — настройки на уровне всей системы.

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

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

Добавление аргумента --local или выполнение команды без параметра уровня конфигурации приведет к установке значения user.name для текущего локального репозитория.

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

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

Так создается команда ci , которую можно использовать как сокращение команды git commit . Подробнее об алиасах в Git см. на странице git config.

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

В текстовом редакторе откройте файл глобальной конфигурации для редактирования вручную. Подробное руководство по настройке текстового редактора для Git см. на странице Git config.

Пояснения

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

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

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

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

Пример

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

Представьтесь репозиторию Git с помощью команды git config

Выберите любимый текстовый редактор

Добавьте алиасы по типу SVN

/.gitconfig , описанный в предыдущем разделе. Подробную информацию о команде git config см. на странице Git config.

Резюме

Мы показали, как создать репозиторий Git двумя способами: git init и git clone. Этим руководством можно пользоваться при необходимости управления исходным кодом ПО или другим контентом, при хранении которого требуется поддерживать версионность. Кроме того, были представлены команды git add, git commit, git push и git remote и показаны простые примеры их использования.

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

Система Git появилась, как средство управления исходными текстами в операционной системе Linux и завоевала множество поклонников в среде Open Source.

Сервис Github предоставляет хостинг (хранение) исходных текстов как на платной, так и на бесплатной основе. Это одна из крупнейших систем, которую любят Open Source пользователи. Основное отличие платной версии — это возможность создания частных репозиториев (хранилищ) исходных текстов и если вам скрывать нечего, то можете спокойно пользоваться бесплатной версией.

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

В этой статье будут описаны базовые сценарии использования систем Git/Github при работе над проектом в среде Linux с помощью командной строки. Все примеры проверялись на системе с Linux Ubuntu 14.04 и Git 1.9.1. Если вы пользуетесь другим дистрибутивом, то возможны отличия.

Создание локального репозитория

Предположим, что ваш проект находится в папке /home/user/project. Перед тем, как сохранять исходники, можно посмотреть, нет ли временных файлов в папке с проектом и по возможности их удалить.

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

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

Переходим в папку с проектом /home/user/project:

И показываем список файлов с расширением .pyc:

Эта команда выведет список всех файлов с расширением .pyc в текущей директории и в ее поддиректориях. Для удаления найденных файлов, достаточно добавить ключ -delete к этой команде:

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

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

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

Добавление файлов в локальный репозиторий

Для добавления файлов используется команда:

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

Добавленные файлы хранятся в папке .git/objects/xx/yyyyyyyy, при этом первые 2 цифры хеша ипользуются для указания директории, а остальное хеш значение является именем файла. Наш добавленный файл будет находится здесь:

Что легко увидеть с помощью команды:

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

Для того, чтобы добавить все файлы из текущей директории введите:

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

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

Например, если в в файл .gitignore добавить следующую строчку *.pyc, то все файлы с расширением .pyc не будут добавляться в репозиторий.

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

Для просмотра текущего состояния можно воспользоваться командой:

После выполнения команды мы увидим, что в stage area находится наш файл:

Если вы продолжите вносить изменения в файл readme, то после вызова команды git status вы увидите две версии файла.

Чтобы добавить новые изменения достаточно повторить команду. Команда git add не только добавляет новые файлы, но и все изменения файлов, которые были добавлены ранее.

Можно отменить добавления файла readme в staging area с помощью команды:

После выполнения команды, файл readme отметится, как неизмененный системой.

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

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

Каждая новая версия сопровождается комментарием.

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

Посмотрим, что внутри:

Ключ -t показывает тип объекта. В результате мы видим:

Для второго объекта:

Для самого первого файла:

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

Ключ --no-edit нужен, чтобы не вводить заново комментарий.

Можно просмотреть изменения, которые вы внесли последним коммитом:

Ключ --name-only нужен, чтобы показывать только имена измененный файлов. Без него по каждому измененнному файлу будет выдан список всех изменений.

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

Для просмотра списка всех коммитов, воспользуйтесь командой:

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

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

Для отмены последнего коммита (кроме самого первого) можно воспользоваться следующей командой:

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

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

После регистрации нажимаем кнопочку "+" и вводим название репозитория. Выбираем тип Public (репозиторий всегда Public для бесплатной версии) и нажимаем Create.

В результате мы создали репозиторий на сайте Github. На экране мы увидим инструкцию, как соединить наш локальный репозиторий со вновь созданным. Часть команд нам уже знакома.

Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (вместо origin можно использовать любое другое имя).

Можем просмотреть результат добавления с помощью команды:

Если все было правильно сделано, то увидим:

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

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

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

Перенос репозитория на другой компьютер

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

Результатом выполнения этой команды будет создание папки project в текущем каталоге. Эта папка также будет содержать локальный репозиторий (то есть папку .git).

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

Работа с одним репозиторием с разных компьютеров

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

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

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

Вместо github подставьте название вашего удаленного репозитория, которое вы зарегистрировали командой git push -u.

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

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

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

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

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

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

• определить соответствующий репозиторий;
• создать вилку репозитория Git в учетной записи GitHub;
• выбрать локальную папку для клонированных файлов;
• клонировать репозиторий на локальный компьютер;
• настроить значение вышестоящего удаленного источника.

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

Общие сведения

Для участия в разработке документации на сайте Майкрософт вы можете локально создавать и редактировать файлы Markdown, клонировав соответствующий репозиторий документации. Чтобы получить разрешения Майкрософт на чтение и запись для соответствующего репозитория, нужно создать его вилку в учетной записи GitHub. Это позволит сохранять предлагаемые изменения. Затем изменения объединяются в центральном общем репозитории, доступном только для чтения, с помощью запросов на вытягивание.

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

Определение репозитория

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

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

Используя соответствующий репозиторий, создайте его вилку в своей учетной записи GitHub на сайте GitHub.

Перейдите в GitHub на страницу главного репозитория, а затем нажмите кнопку Fork (Создать вилку) вверху справа.

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

Выбор локальной папки

Создайте локальную папку для локального хранения копии репозитория. Размер некоторых репозиториев может быть значительным, например до 5 ГБ для azure-docs. Выберите расположение с доступным местом на диске.

Выберите имя папки — оно должно быть простым для запоминания и ввода. Например, можно использовать корневую папку C:\docs\ или создать папку в каталоге профиля пользователя

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

Запустите Git Bash

Расположением по умолчанию, в котором обычно запускается Git Bash, является домашний каталог (

) или /c/users/<Windows-user-account>/ в ОС Windows.

Чтобы определить текущий каталог, ведите pwd в запросе $.

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

Например, cd /c/docs/ или cd

Создание локального клона

С помощью Git Bash подготовьтесь выполнить команду клонирования для вытягивания копии репозитории (вашей вилки) в текущий каталог на устройстве.

Проверка подлинности с использованием Git Credential Manager

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

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

Чтобы получить URL-адрес своей вилки GitHub для команды клонирования, нажмите кнопку Clone or download (Клонировать или скачать) в пользовательском интерфейсе GitHub:

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

При появлении запроса введите учетные данные GitHub.

При появлении запроса введите код двухфакторной проверки подлинности.

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

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

Настройка удаленного вышестоящего подключения

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

Если вы используете Git Credential Manager, выполните следующие команды. Замените заполнители <repo> и <organization> .

Просмотрите настроенные значения и проверьте правильность URL-адресов. Убедитесь, что URL-адреса исходного подключения ведут к вашей персональной вилке. Убедитесь, что URL-адреса вышестоящего подключения ведут к основному репозиторию, например MicrosoftDocs или Azure.

Далее приводится пример выходных данных для подключения к удаленному репозиторию. Здесь вымышленная учетная запись Git с именем MyGitAccount настраивается с личным маркером доступа для обращения к репозиторию azure-docs.

Если вы допустили ошибку, значение удаленного подключения можно очистить. Чтобы удалить значение вышестоящего подключения, выполните команду git remote remove upstream .

В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.

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

Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установить git на свою машину очень просто:

• Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
• Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
• OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

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

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

Командная строка должна вернуть что-то вроде:

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

status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

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

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

Проверим статус снова, на этот раз мы должны получить другой ответ:

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

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

1. Подключение к удаленному репозиторию

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

Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

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

3. Клонирование репозитория

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

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

4. Запрос изменений с сервера

Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.

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

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

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

1. Создание новой ветки

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

3. Слияние веток

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

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

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

[/spoiler]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

2. Возвращение файла к предыдущему состоянию

Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

3. Исправление коммита

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

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

4. Разрешение конфликтов при слиянии

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

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

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

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

5. Настройка .gitignore

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

1. Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
2. Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
3. Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.

Вот хорошие примеры файлов, которые нужно игнорировать:

• Логи
• Артефакты систем сборки
• Папки node_modules в проектах node.js
• Папки, созданные IDE, например, Netbeans или IntelliJ
• Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

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

Читайте также:

  
• Linux firefox файл с настройками
  
• Просмотр логов linux gui
  
• Responder kali linux как пользоваться
  
• Консультант плюс зависает windows 10
  
• Windows research kernel это