10 полезных Git команд, которые облегчат работу


Оглавление (нажмите, чтобы открыть):

Git для чайника. Команды которые помогут начать работу.

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

С помощью Git Вы сможете размещать свой код на GitHub, BitBucket и Google Code.

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

С чего начать?

Нам понадобиться программа Git Bash, это шелл сделанный на основе Cygwin, поэтому возможно использование Unix-команд, вроде ls, cd, mkdir. Скачать его можно по следующей ссылке http://git-scm.com/.

Настройка Git

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

Также нам нужно настроить параметры установок окончания строк, для Windows мы вводим две команды

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

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

Допустим у нас есть папка с проектом, которую мы хотим разместить на GitHub.

1. Создаем репозиторий на сайте.

2. Инициализируем папку для Git репозитория. Это нужно сделать только один раз для каждого проекта.

3. Связываем папку с удаленным репозиторием

4. Добавляем все новые и измененные файлы

5. Помечаем все новые и измененные файлы сообщением (commit)

— вместо message вписываем сообщение, например Initial Commit. или Bugfix.

6. Закачиваем код на удаленный репозиторий

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

7. Можно посмотреть статус изменений, которые были сделаны.

8. Для скачивания репозитория используется команда

Второй компьютер

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

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

В результате git скачает удаленный репозиторий в новую папку test-project

2. После каких-то изменений в коде, выполняем все те же команды

Откат изменений

1. Полный откат до предыдущего коммита

2. Сброс изменений в файле на версию коммита

3. Откат до установленного тега, например v1

Для более лучшего пониманию лучше ознакомиться с интерактивным туром по Git

Страница поста от канала С# Start 1.0

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме

Пожаловаться

Обращаем внимание, что мы не несем ответственности за содержимое(content) того или иного канала размещенный на нашем сайте так как не мы являемся авторами этой информации и на сайте она размещается в автоматическом режиме

Информационный портал по безопасности

Небольшая шпаргалка для работы с Git, GitHub

Небольшая шпаргалка для работы с Git

Предупреждение по использованию:

Данная публикация является учебной для освоения основ системы контроля версий git, на примере использования GitHub. Это не руководство к действию. Вы должны понимать, то что вы делаете применяя команды и идеи изложенные в публикации. Не спешите применять сказанное к вашим рабочим проектам. Создайте черновой проект, локальный репозиторий. Потренируйтесь на нем. Создайте свой учебный проект на GitHub. Когда вы хорошо будете понимать, что и как работает, только тогда вы сможете применить ваши знания в рабочих проектах.

В данной публикации я рассматриваю в основном работу с сервисом GitHub.

Цель: Коротко рассказать что такое Git.

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

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

Предметная область и основные термины

repository — некоторое хранилище файлов, ссылок на изменения в файлах

commit — отслеживание изменений

HEAD — (специальный указатель) символическая ссылка на последние изменения. Примечание: Не обязательно ссылается на commit. Может указывать на ветвь. Состояние — «Detached HEAD»

HEAD используется репозиторием для определения того, что выбрано с помощью checkout.

Обратите внимание на это различие: «head» (в нижнем регистре) относится к любому из названных заголовков в хранилище; «HEAD» (верхний регистр) относится исключительно к текущему активному заголовку(ссылке). Это различие часто используется в документации Git. HEAD может указывать на именованную вершину какой-либо ветки или на commit.

Объекты Git. Четыре типа объектов: Blob, Tree, Commit и References.


Ветвь определяется не в самом Git, а наследуется от операционной и файловой систем.

git сервисы — сервисы предоставляющие услуги для пользователей git.

working directory — рабочий каталог на вашем компьютере

staging area — область подготовленных файлов или рабочая область

branch — ветка, состоит из набора коммитов, обычно ссылается на последний коммит

merge — слияние, слияние веток в одну

pull — втянуть, взять проект с сервера, получить изменения из удаленного репозитория

push — вытолкнуть, отправить изменения на сервер

# — в данном случае символ комментария

<> — угловые скобки, там где вам нужно вписать нужное исключая эти скобки

$ — приглашение ввода в терминале

Небольшое вступление

Git — одна из систем контроля версий.

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

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

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

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

История создания

Теоретическая часть(коротко)

Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux

Git свободная система и распространяется она под лицензией GNU GPL 2.

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

Какие существуют системы управления версиями:

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

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

Практическая часть

Для использования системы git вам нужно:

1. Установить программу git на вашей системе.

2. Настроить программу и проверить её работоспособность локально

3. Зарегистрировать ваш аккаунт на GitHub

4. Создать локальный репозиторий или копировать репозиторий существующего проекта

5. Написать файл README.MD.

6. В случае, если вы начинаете проект, создать удаленный репозиторий

7. Фиксировать изменения локально

8. Отправлять изменения на GitHub

9. Зарегистрировать аккаунты разработчиков вашего проекта

10. Выдать им ссылку на проект

1. Установка git

1. После установки вы можете кликнуть правой кнопкой мышки на папке в проводнике Windows и выбрать открыть «Git Bash Here». Git Bash Here — означает отрыть терминал git здесь.

В терминале введите команду

проверить версию вашего git.

В Linux,(Ctrl+Alt+T — терминал, если у вас не назначены другие горячие клавиши) откройте терминал и введите

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

2.Настройка программы Git

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

То есть некоторые настройки вы делаете для определенного пользователя операционной системы(не системы git, а операционной системы). Другие настройки вы делаете для всех пользователей операционной системы. Далее вы можете делать настройки для определенной папки(локально). Вы делает настройки для репозитория находящегося на сервере. Эти настройки вы можете не делать, если работаете только со своим локальным репозиторием.

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

Настройка внешнего редактора.

#команда для Linux.

Вы можете выбрать другой текстовый редактор. Например не emacs, a vi или nano или другой на ваше усмотрение.

В Windows, такой командой вы можете задать текстовый редактор, например notepad++.


Для x64 Windows используйте:

git config —global core.editor «‘C:/Program Files (x86)/Notepad++/notepad++.exe’ -multiInst -notabbar -nosession -noPlugin»

Настройки git хранятся в файлах.

Git проверяет 4 места для файла конфигурации(здесь в Linux):

Файл вашего компьютера .gitconfig.

Ваш пользовательский, файл вашего пользователя .gitconfig файл находится в

Второй пользовательский файл конфигурации, расположенный в $ XDG_CONFIG_HOME/git/config или $HOME/.config/git/config.

Конфигурационный файл локального репозитория: .git/config

Каждый файл добавляет или переопределяет параметры git, определенные в файле над ним.

Конфигурация, специфичная для репозитория.

Ссылка на документацию:

Вы можете просмотреть файлы конфигурации

#для системы и всех пользователей

Проверка настроек вашей конфигурации git:

Если список большой, вы можете пролистывать его с помощью стрелок клавиатуры или «pg up», «pg dn». Для выхода клавиша q.

#какая конфигурация, где установлена:

Для чего нужно рассмотреть консольные команды? Ведь существуют UI.

Часто в консоли вы можете сделать, что-то гораздо быстрее. С помощью набора консольных команд вы сами в будущем сможете автоматизировать процесс. Консольные команды более гибкий инструмент. Почему? Да потому что ваш UI может и «не знать» о существовании той или иной команды. На первом этапе консольные команды во многом помогут в общем понимании того как работает система. Все их запоминать нет необходимости. Вы в любой момент сможете найти справку по той или иной команде. Теоретические знания, без которых никуда, лучше усваиваются с применением на практике.

-C — использовать указанную папку репозитория вместо текущей папки;

-c параметр=значение — использовать указанное значение параметра конфигурации;

-p — прокручивать весь вывод с помощью less;

Инициализация локального репозитория.

1. Переходим в папку проекта.

3. #тут мы добавляем все. Папку. Точка после add отделенная пробелом.

Можно добавить отдельный файл

Таким образом мы говорим — отслеживать изменения нашего файла.

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

4. Создание commit

-m «комментарий» #аргумент создания комментария коммиту. Ваши изменения будут уже с осмысленным комментарием.

Вы можете использовать полное имя ключа, вместо его сокращения. К примеру, вместо -m вы можете использовать —message=«комментарий»

Показывает информацию — какая ветка текущая.

Какие файлы изменены и тд. Команда показывает, что находится в рабочей области(в staging area).

Ветка(branch) — ссылка на определенный коммит.

, используйте для имени латинские буквы. Тут есть одно замечание. Когда мы создали ветку с некоторым именем, текущей осталась ветка, которая была выделена до этого. Ну например master. И если после создания ветки мы скажем git commit, то будет продолжена ветка master. Не понимание этого часто приводит к ошибкам.

Совет: Чтобы продолжить новую ветку нужно её создать, потом переключиться на неё и сделать commit.

1. Создаем ветку:

2. Переключаемся на созданную ветку:

3. Делаем commit:

Теперь у нас есть вторая ветка с именем feature.

Объединение веток создает коммит от двух родителей, от текущей ветки и ветки указанной в команде git.

1. Переключаемся на ветку master

2. Сморим какая ветка текущая

3. Объединяем ветки #объединить текущую ветку с веткой feature

Мы можем сделать по другому. Переключиться на ветку feature и объединить её с веткой master

2. , в данном случае feature c веткой master.

Просмотр доступных веток:

stash — стек, временное хранилище

Не путайте со stage, это не одно и то же.

Команда сохраняет все не закомиченные изменения во временное хранилище и сбрасывает состояние ветки до HEAD.

Стеш(stash) предназначит для того, что бы спрятать не нужные на данный момент изменения, потому он и называется stash, в переводе — прятать, припрятывать.

На рисунке показана подготовка папки на локальном компьютере для git.


Добавление в staging area. Добавление изменений в локальный репозиторий(git commit).

Отправка в удаленный репозиторий(git push).

На данной схеме не показана сущьность stash.

Работа с командами:

Очень полезные команды. Рассмотрите их самостоятельно.

Работа с удаленным репозиторием

Далее я перейду к описанию работы с удаленным репозиторием.

Вы можете работать с удаленным репозиторием и вашим проектом через протокол https://,

то есть в вашем браузере(chrome, mozilla, opera и других).

Интерфейс GitHub на английском языке.

Для начала, вам нужно зарегистрироваться на GitHub, если вы этого еще не сделали или

подключить нужную ветку и отправить изменения локального репозитория.

Узнать как зарегистрироваться вы можете на самом сайте GitHub.

Показать какие пути назначены:

#показать какие ветки есть в удаленном репозитории

Обычно там одна ветка origin.

То есть это не сама ветка, а её сокращенное название ассоциированное с репозиторием.

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

Диаграмма показывает отличие работы с локальным репозиторием и с репозиторием на GitHub

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

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

Мастер Йода рекомендует:  Выполнение произвольного кода и отказ в обслуживании в PHP

При желании, вы сможете потом отправить их на сервер.

Взаимодействие с другими системами контроля версий

В стандартной поставке Git поддерживается взаимодействие с CVS (импорт и экспорт, эмуляция CVS-сервера) и Subversion (частичная поддержка импорта и экспорта). Стандартный инструмент импорта и экспорта внутри экосистемы — архивы серий версионированных файлов в форматах .tar.gz и .tar.bz2.
Fork – удаленная копия репозитория на сервере, отличная от оригинала. Это даже не git-концепция, а, скорее, политико-социальная идея. Clone – это не то же самое, что и fork. Клон удаленного репозитория располагается локально. Фактически при клонировании копируются все данные, включая историю коммитов и существующие ветки.

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

Индекс (область подготовленных файлов, staging area) – это один большой бинарный файл .git/index, в котором указаны все файлы текущей ветки, их SHA1, временные метки и имена. Это не отдельная директория с копиями файлов.

Указатель HEAD – это ссылка на последний коммит в текущей извлеченной ветке.

Модели ветвления в Git:

Для чего нужны модели ветвления?

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

Developer Branch Workflow

Feature Branch Workflow

Issue Branch Workflow

Central Workflow (центральный рабочий процесс) в этом контексте определяется как «вы отправляете изменения тому же репо, из которого вы обычно получаете свои последние вышестоящие изменения», независимо от того, используете ли вы rebase или merge. (pull = fetch + merge или fetch + rebase, в зависимости от конфигурации и параметров)

Feature Branching являет логическим расширением Central Workflow (центрального рабочий процесса). Основная идея рабочего процесса Feature Branch: разработка всех функций должна осуществляться в выделенной ветви вместо основной ветви. Главная ветвь никогда не должна содержать неработающий код. Это является большим преимуществом в средах непрерывной интеграции.

Рабочий процесс Gitflow был впервые опубликован в блоге Винсента Дриссена от nvie за 2010 год. Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Этот рабочий процесс не добавляет каких-либо новых концепций или команд помимо того, что требуется для рабочего процесса Feature Branch. Вместо этого он назначает очень конкретные роли различным ветвям и определяет, как и когда они должны взаимодействовать.

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

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

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

Мы с вами рассмотрели работу системы git и работу с удаленными репозиториями.

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

Памятка по основным командам Git

18.03.2014 в 01:17

Команды

git status — пересматриваем изменения

git add . — добавляем изменения

git commit -a -m ‘message’ — подтверждение изменений в текущей ветке

git pull — скачать новые изменения

git push username-project current-branch:remote-branch — запись текущей ветки в удаленный репозиторий

git reset —hard ‘hash code’ — возвращаемся на версию по хеш коду

git branch -a — отобразить все ветки

git branch -D local-branch — удалить локальную ветку


git checkout local-branch — переключится на локальную ветку

git merge local-branch — наложить изменения из локальной ветки в текущую

git checkout -b local-branch remotes/origin/master — скачать ветку с удаленного репозитория и переключиться на нее

git remote add username-project git@github.com:username/project.git — добавление ссылки на удаленный репозиторий

git remote update — обновить информацию о удаленном репозитории

10 — откатить форк на нужное количество коммитов

Подробное введение в работу с Git

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

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

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

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

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

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

16 ноября в 10:00, Воронеж, беcплатно

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

Если вы не знаете, как использовать команду, то можете открыть руководство с помощью git help , а если вам просто нужно напоминание, используйте git -h или git —help ( —help и -h эквивалентны).

Подготовка Git

Установка Git

Пользователи Windows могут скачать его отсюда.

В macOS (OS X) Git поставляется как часть инструментов командной строки XCode, поэтому нужно их установить. Чтобы проверить наличие Git, откройте терминал и введите git —version для проверки версии.

Если вы пользуетесь Linux, то используйте команду sudo apt install git-all (дистрибутивы на основе Debian) или sudo dnf install git-all (на основе RPM).

Настройка конфигурационного файла

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

Вы можете либо напрямую отредактировать файл .gitconfig с помощью текстового редактора, либо с помощью команды git config —global —edit , а также можете отредактировать отдельные поля, используя команду git config —global — нас интересуют поля user.name и user.email .

Также можно настроить текстовый редактор для написания сообщений коммитов, используя поле core.editor . Изначально используется системный редактор по умолчанию, например, vi для Linux/Mac. Поле commit.template позволяет указать шаблон, который будет использоваться при каждом коммите.

Есть множество других полей, однако одно из самых полезных — это alias , которое привязывает команду к псевдониму. Например, git config —global alias.st «status -s» позволяет использовать git st вместо git status -s

Команда git config —list выведет все поля и их значения из конфигурационного файла.

Создаём Git-репозиторий

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

История коммитов в Git

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

Мы можем ссылаться на коммит либо через его контрольную сумму, либо через его позицию относительно HEAD, например HEAD

4 ссылается на коммит, который находится 4 коммитами ранее HEAD.

Файловая система Git

Git отслеживает файлы в трёх основных разделах:

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

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

Просмотр изменений в файловых системах

Команда git status отображает все файлы, которые различаются между тремя разделами. У файлов есть 4 состояния:

  1. Неотслеживаемый (untracked) — находится в рабочей директории, но нет ни одной версии в HEAD или в области подготовленных файлов (Git не знает о файле).
  2. Изменён (modified) — в рабочей директории есть более новая версия по сравнению с хранящейся в HEAD или в области подготовленных файлов (изменения не находятся в следующем коммите).
  3. Подготовлен (staged) — в рабочей директории и области подготовленных файлов есть более новая версия по сравнению с хранящейся в HEAD (готов к коммиту).
  4. Без изменений — одна версия файла во всех разделах, т. е. в последнем коммите содержится актуальная версия.

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

Мы можем использовать опцию -s для команды git status , чтобы получить более компактный вывод (по строке на файл). Если файл не отслеживается, то будет выведено ?? ; если он был изменён, то его имя будет красным, а если подготовлен — зелёным.

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

  • git diff — сравнение рабочей директории с областью подготовленных файлов;
  • git diff —staged — сравнение области подготовленных файлов с HEAD.

Если использовать аргумент , то diff покажет изменения только для указанных файлов/папок, например git diff src/ .

Обновление файловых систем

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

Команда git commit обновляет HEAD новым коммитом, который делает снимки файлов в области подготовленных файлов.


Действие команды git reset состоит из трёх потенциальных шагов:

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

По умолчанию команда git reset выполняет только шаги 1 и 2, однако её поведение можно изменить с помощью опций —soft (только 1 шаг) и —hard (все шаги).

Если передать путь к файлу/папке, то команда будет выполнена только для них, например git reset —soft HEAD

Команда git checkout HEAD приводит к тому же результату, что и git reset —hard HEAD — перезаписывает версию файла в области подготовленных файлов и в рабочей директорией версией из HEAD, то есть отменяет изменения после последнего коммита.

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

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

Игнорирование файлов

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

  • файлы с чувствительной информацией вроде паролей;
  • большие бинарные файлы;
  • файлы сборок, которые генерируются после каждой компиляции;
  • файлы, специфичные для ОС/IDE, например, .DS_Store для macOS или .iml для IntelliJ IDEA — нам нужно, чтобы репозиторий как можно меньше зависел от системы.

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

  • /___ — позволяет избежать рекурсивности — соответствует файлам только в текущей директории;
  • __/ — соответствует всем файлам в указанной директории;
  • *___ — соответствует всем файлам с указанным окончанием;
  • ! — игнорирование файлов, попадающих под указанный шаблон;
  • [__] — соответствует любому символу из указанных в квадратных скобках;
  • ? — соответствует любому символу;
  • /**/ — соответствует вложенным директориям, например a/**/d соответствует a/d , a/b/d , a/b/c/d и т. д.

Мы даже можем использовать шаблоны поиска при указании файла/папки в других командах. Например, git add src/*.css добавит все файлы .css в папке src .

Коммиты

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

Команда git commit откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько распространённых аргументов:

  • -m позволяет написать сообщение вместе с командой, не открывая редактор. Например git commit -m «Пофиксил баг» ;
  • -a переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить git add перед коммитом);
  • —amend заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Несколько советов, к которым стоит прислушаться:

  • Коммитьте часто: вы не сможете откатить изменения, если откатывать не к чему.
  • Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
  • Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу this commit will ___ (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось. Здесь подробно расписано, как писать сообщения для коммитов.
  • (Опционально) Не коммитьте незначительные изменения: в большом репозитории множество небольших коммитов могут засорить историю. Хорошим тоном считается делать такие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

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

Для просмотра истории предыдущих коммитов в обратном хронологическом порядке можно использовать команду git log . Ей можно передать разные опции:

  • -p показывает изменения в каждом коммите;
  • —stat показывает сокращённую статистику для коммитов, например изменённые файлы и количество добавленных/удалённых строк в каждом их них;
  • -n показывает n последних коммитов;
  • —since=___ и —until=___ позволяет отфильтровать коммиты по промежутку времени, например —since=»2020-01-01″ покажет коммиты с 1 января 2020 года;
  • —pretty позволяет указать формат логов (например, —pretty=oneline ), также можно использовать —pretty=format для большей кастомизации, например —pretty=format:»%h %s» ;
  • —grep и -S фильтруют коммиты с сообщениями/изменениями кода, которые содержат указанную строку, например, git log -S имя_функции позволяет посмотреть добавление/удаление функции;
  • —no-merges пропускает коммиты со слиянием веток;
  • ветка1..ветка2 позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток). Например, git log master..test покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).
  • —left-right ветка1. ветка2 показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак обозначает коммиты из ветка1 , а > — из ветка2 . Обратите внимание: используется три точки, а не две;
  • -L принимает аргумент начало,конец:файл или :функция:файл и показывает историю изменений переданного набора строк или функции в файле.
Мастер Йода рекомендует:  6 сервисов для работы с блок-схемами

Другой полезной командой является git blame , которая для каждой строки файла показывает автора и контрольную сумму последнего коммита, который изменил эту строку. -L , позволяет ограничить эту команду заданными строками. Это можно использовать, например, для выяснения того, какой коммит привёл к определённому багу (чтобы можно было его откатить).

Наконец, есть команда git grep , которая ищет по всем файлам в истории коммитов (а не только в рабочей директории, как grep ) по заданному регулярному выражению. Опция -n отображает соответствующий номер строки в файле для каждого совпадения, а —count показывает количество совпадений для каждого файла.

Примечание Не путайте git grep с git log —grep ! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.

Удалённые серверы

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

Команда git remote -v выводит список удалённых репозиториев, которые мы отслеживаем, и имена, которые мы им присвоили.

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

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

  • git remote add — добавляет удалённый репозиторий с заданным именем;
  • git remote remove — удаляет удалённый репозиторий с заданным именем;
  • git remote rename — переименовывает удалённый репозиторий;
  • git remote set-url — присваивает репозиторию с именем новый адрес;
  • git remote show — показывает информацию о репозитории.

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

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

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

Ветвление

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

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

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

  • git branch — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент , то команда выведет список всех локальных веток;
  • git checkout — переключается на эту ветку. Можно передать опцию -b , чтобы создать новую ветку перед переключением;
  • git branch -d — удаляет ветку.

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( git clone привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязывание к удалённой ветке:

  • git branch -u / — привязывает текущую ветку к указанной удалённой ветке;
  • git checkout —track / — аналог предыдущей команды;
  • git checkout -b / — создаёт новую локальную ветку и начинает отслеживать удалённую;
  • git branch —vv — показывает локальные и отслеживаемые удалённые ветки;
  • git checkout — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.


В общем, git checkout связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как git reset перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды git stash . Чтобы вернуть изменения, используйте git stash apply .

Возможно, вместо этого вы захотите стереть все внесённые изменения. В таком случае используйте команду git clean . Опция -d также удалит неотслеживаемые файлы. Совет: добавьте опцию -n , чтобы увидеть, что произойдёт при запуске git clean без непосредственного использования.

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

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

Слияние

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

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

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

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

Перемещение

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

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

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

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

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

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

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

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

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

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

Резюмируем

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

GitHub

GitHub — это платформа, которая хранит Git-репозитории на своих множественных серверах. Как пользователь GitHub вы можете хранить свои удалённые репозитории на их серверах, а также вносить вклад в другие open-source репозитории. GitHub дополняет использование Git некоторыми новыми возможностями.

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

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

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

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

  • status — показывает для каждого файла краткое описание того, что (не)подготовлено;
  • update — подготавливает отслеживаемые файлы;
  • revert — убрать один или несколько файлов из подготовленной области;
  • add untracked — подготавливает неотслеживаемый файл;
  • patch — подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? . Можно ввести ? , чтобы узнать, что делает каждая команда;
  • diff — показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
  • quit — выходит из интерактивной консоли;
  • help — показывает краткое описание каждой команды.

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

Обратите внимание, что создание патчей (подготовка только части файла) доступно не только в интерактивной консоли, но и через команду git add -p .

Продвинутое использование: правим историю

Для большего контроля над историей коммитов локальной ветки можно использовать команду git rebase -i HEAD

n , которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.

Измененяем сообщение коммита/разбиваем коммиты

Для указания коммита, который вы хотите изменить, используется команда edit . Затем, когда Git будет проводить перемещение, он остановится на этом коммите. После этого вы можете использовать git commit —amend , чтобы изменить сообщение или подготовить забытые файлы. Если вы хотите разделить коммит, после остановки введите git reset HEAD^ (в результате HEAD будет перемещён на один коммит назад и все изменённые в этом коммите файлы перейдут в статус неподготовленных). Затем вы сможете зафиксировать файлы в отдельных коммитах обычным образом.

После завершения редактирования введите git rebase —continue .

Перезапись нескольких коммитов

Иногда вам может потребоваться перезаписать несколько коммитов — в таких случаях можно использовать git filter-branch . Например, чтобы удалить случайно зафиксированный файл, можно ввести git filter-branch —tree-filter ‘git rm -f ‘ HEAD . Однако учтите, что при этом вся история перемещается.

Объединение нескольких коммитов

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

Переносим отдельный коммит

Кроме слияния/перемещения всех коммитов в тематической ветке, вас может интересовать только определённый коммит. Допустим, у вас есть локальная ветка drafts, где вы работаете над несколькими потенциальными статьями, но хотите опубликовать только одну из них. Для этого можно использовать команду git cherry-pick . Чтобы получить определённые коммиты, из которых мы хотим выбирать, можно использовать git log .. .

Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние.


Заключение

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

450 страниц) и описывает Git более глубоко.

Хотите копнуть глубже в Git, но вам мало (или наоборот, много) одной большой книги? Тогда вам стоит взглянуть на наш план изучения.

10 полезных Git команд, которые облегчат работу

Шпаргалка по консольным командам Git

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

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

Отслеживаемые файлы могут быть в 3-х состояниях: неизменённые, изменённые, проиндексированные (готовые к коммиту).

Ключ к пониманию

Ключ к пониманию концепции git — знание о «трех деревьях»:

  • Рабочая директория — файловая система проекта (те файлы, с которыми вы работаете).
  • Индекс — список отслеживаемых git-ом файлов и директорий, промежуточное хранилище изменений (редактирование, удаление отслеживаемых файлов).
  • Директория .git/ — все данные контроля версий этого проекта (вся история разработки: коммиты, ветки, теги и пр.).

Коммит — «сохранение» (хранит набор изменений, сделанный в рабочей директории с момента предыдущего коммита). Коммит неизменен, его нельзя отредактировать.

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

Простейший цикл работ

  • Редактирование, добавление, удаление файлов (собственно, работа).
  • Индексация/добавление файлов в индекс (указание для git какие изменения нужно будет закоммитить).
  • Коммит (фиксация изменений).
  • Возврат к шагу 1 или отход ко сну.
  • HEAD — указатель на текущий коммит или на текущую ветку (то есть, в любом случае, на коммит). Указывает на родителя коммита, который будет создан следующим.
  • ORIG_HEAD — указатель на коммит, с которого вы только что переместили HEAD (командой git reset . , например).
  • Ветка ( master , develop etc.) — указатель на коммит. При добавлении коммита, указатель ветки перемещается с родительского коммита на новый.
  • Теги — простые указатели на коммиты. Не перемещаются.

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

Если вы в Windows:

Указание неотслеживаемых файлов

Файлы и директории, которые не нужно включать в репозиторий, указываются в файле .gitignore . Обычно это устанавливаемые зависимости ( node_modules/ , bower_components/ ), готовая сборка build/ или dist/ и подобные, создаваемые при установке или запуске. Каждый файл или директория указываются с новой строки, возможно использование шаблонов.

Длинный вывод в консоли: Vim

Вызов некоторых консольных команд приводит к необходимости очень длинного вывода в консоль (пример: вывод истории всех изменений в файле командой git log -p fileName.txt ). При этом прямо в консоли запускается редактор Vim. Он работает в нескольких режимах, из которых Вас заинтересуют режим вставки (редактирование текста) и нормальный (командный) режим. Чтобы попасть из Vim обратно в консоль, нужно в командном режиме ввести :q . Переход в командный режим из любого другого: Esc .

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

Записки программиста

Моя шпаргалка по работе с Git

28 декабря 2011

Мастер Йода рекомендует:  Kubernetes, анализ данных и бессерверные вычисления команда Яндекс.Облака представила шесть новых

Некоторое время назад я открыл для себя Git. И знаете, я проникся. То есть, по-настоящему проникся. Теперь я использую Git не только на работе (где я с ним, собственно, познакомился), но и для своих проектиков, которые я стал хранить на BitBucket. Последний начал поддерживать Git относительно недавно. В отличие от GitHub, BitBucket позволяет совершенно бесплатно создавать как открытые, так и закрытые репозитории.

В чем состоит отличие Git от Subversion?

Главное отличие Git от Subversion заключается в том, что Git — распределенная система контроля версий. Звучит ужасающе, но на практике это означает очень простую вещь. Каждый разработчик держит у себя на диске отдельный репозиторий. Обратите внимание — не копию репозитория, не некоторые бранчи, а тупо отдельный и при этом абсолютно полноценный репозиторий.

Пока мы работаем в рамках своего репозитория, все происходит в точности, как в Subversion. Мы коммитим и откатываем изменения, создаем, мержим и удаляем бранчи, разрешаем конфликты и тд. Помимо этого, предусмотрены команды для работы с репозиториями на удаленных машинах. Например, «git push» означает мерж локальных изменений в удаленный репозиторий, а «git pull» — наоборот, мерж изменений из удаленного репозитория в локальный. Обмен данными по сети обычно происходит с использованием протокола SSH.

В результате имеем:

  • Git присущи все те же преимущества от использования VCS, что мы получаем в Subversion.
  • Git дает нам нормальное шифрование «из коробки», безо всяких танцев с бубнами, как в случае с Subversion.
  • Если сервер с «главным» репозиторием, куда пушат свои изменения все разработчики (хотя формально в Git нет никакого «главного» репозитория), вдруг прилег — ничего страшного. Делаем коммиты в локальный репозиторий и ждем, когда сервер вернется.
  • Даже если сервер доступен, все равно удобнее сделать пяток локальных коммитов, а затем отправить их на сервер одним пушем.
  • Сервер вообще не нужен. Вы можете использовать Git только локально. И не обязательно для работы с исходниками. Например, можно использовать Git для того, чтобы иметь возможность откатиться к предыдущим версиям файлов (каких-нибудь электронных таблиц) или вернуть случайно удаленные.
  • Git не раскидывает по каталогам служебную информацию (помните «.svn»?) , вместо этого она хранится только в корне репозитория.
  • Git нынче очень моден (хотя это далеко не единственная распределенная система контроля версий, например, есть Mercurial и Darcs), в связи с чем растет число разработчиков, использующих его. Как следствие, используя Git, легче получить помощь на каком-нибудь форуме или собрать команду разработчиков, знакомых с этой VCS.
  • Существует множество полезных утилит для работы с Git — Qgit, gitk, gitweb и другие. «Из коробки» есть импорт и экспорт в/из Subversion/CVS.
  • Git поддерживают многие хостинги репозиториев (GitHub, BitBucket, SourceForge, Google Code, … ) — есть из чего выбрать.
  • Большой популярностью пользуется GitHub. Используя Git, вы увеличиваете вероятность того, что кто-то захочет безвозмездно написать патч для вашего OpenSource проекта.

Пример использования Git

Я использовал Git при написании программы из заметки Генерация почти осмысленных текстов на Haskell, сидя под своей любимой FreeBSD. Вот как примерно выглядела моя работа с Git.

В первую очередь необходимо поставить Git:

Затем создаем пару ssh ключей, если не создавали ее ранее:

10 альтернатив GitHub, который купила Microsoft

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


4 июня состоялась сделка Microsoft по покупке GitHub за 7,5 миллиарда долларов, о чём рассказали в блоге GitHub. GitHub — крупнейший в мире веб-сервис для хостинга и совместной разработки IT-проектов. Его покупка корпорацией Microsoft шокировала многих пользователей, особенно приверженцев и разработчиков Open Source.

У Microsoft есть одна неприятная особенность. Собственные разработки компании хороши, но когда Microsoft покупает какой-нибудь популярный проект вроде Skype, LinkedIn, Nokia или Wunderlist, то в лучшем случае его ожидает стагнация, в худшем — деградация. Пользователи GitHub перевели больше 40 тысяч проектов на другие веб-сервисы. Хештег #movingtogitlab на Twitter использовали почти 3 тысячи раз.

Если вы тоже задумались о «переезде», вот несколько альтернатив.

1. GitLab

GitLab — альтернатива GitHub номер один. GitLab предоставляет не только веб-сервис для совместной работы, но и программное обеспечение с открытым исходным кодом.

Многие проекты с открытым исходным кодом, такие как GNOME и GIMP, используют GitLab.

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

Стоимость

  • Core — бесплатная версия GitLab. Для развёртывания на вашем собственном хостинге или сервере.
  • Starter — 4 доллара в месяц с каждого пользователя. Для небольших команд.
  • Premium — 19 долларов в месяц с каждого пользователя. Для организаций.
  • Ultimate — 99 долларов в месяц с каждого пользователя. Для крупных компаний.

2. BitBucket

BitBucket — это служба хостинга репозиториев и управления версиями от Atlassian. Она тесно интегрирована с другими инструментами Atlassian — Jira, HipChat и Confluence.

Это прекрасный выбор для крупных предприятий. Но и небольшие команды могут использовать BitBucket. Сервис бесплатен для проектов, в команде которых не больше пяти участников. Всё, что вам нужно сделать, — это подать заявку на получение лицензии сообщества в Atlassian.

Вы можете разместить BitBucket на собственном сервере или хостинге, но за это придётся заплатить.

Стоимость

  • Free — бесплатно для команд, в которых не больше пяти разработчиков.
  • Standart — 2 доллара в месяц с пользователя. Для небольших и средних команд. Неограниченное число пользователей.
  • Premium — 5 долларов в месяц. Для больших команд, которым нужны расширенные возможности.

3. SourceForge

SourceForge — ещё одна крупная альтернатива GitHub, сконцентрировавшаяся на Open Source. Многие дистрибутивы и приложения Linux обитают на SourceForge.

В своё время популярность сервиса упала под натиском более простого и интуитивно понятного GitHub. Однако SourceForge переработал свой интерфейс, став гораздо привлекательнее и, главное, удобнее.

Стоимость

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

4. Launchpad

Launchpad — платформа для совместной работы над программным обеспечением от Canonical, компании-разработчика Ubuntu. На ней размещены PPA-репозитории Ubuntu, откуда пользователи загружают приложения и обновления.

Сервис Launchpad существует уже много лет, но он не снискал такой популярности, как GitHub и другие его альтернативы. Однако это хороший выбор для разработчиков Open Source: неважно, создаёте ли вы софт для Ubuntu-подобных систем или других дистрибутивов Linux.

Стоимость

Вы можете размещать или импортировать репозитории Git на Launchpad совершенно бесплатно.

5. Apache Allura

Allura — это бесплатное решение от Apache. Сервис поддерживает отслеживание проблем в коде и комментарии кодов с разметкой. Apache Allura работает с Git, Hg и Subversion (SVN).

С Allura вы легко сможете создавать внутренние вики-страницы для документации.

Стоимость

Бесплатно. Но вам придётся разместить Allura на своём хостинге или сервере.

6. Cloud Source

Cloud Source — средство управления версиями Git от Google. Вы можете создавать любое количество частных репозиториев Git, позволяющих организовать код. Сервис интегрирован с инструментами облачной диагностики Google, такими как отладчик Stackdriver Debugger и Stackdriver Error Reporting. Так что вы без труда сможете отслеживать ошибки в коде.

Cloud Source позволяет подключать репозитории GitHub или Bitbucket. Вы можете использовать код из своих репозиториев в проектах Cloud Platform.

Стоимость

  • Up to 5 Users — 1 доллар в месяц с пользователя. До пяти пользователей в команде.
  • 50 GB Storage — 0,10 доллара в месяц за каждый использованный ГБ. Неограниченное количество пользователей.

7. AWS CodeCommit

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

CodeCommit тесно интегрирован с другими сервисами Amazon, так что, если вы используете инфраструктуру этого облачного гиганта, CodeCommit — ваш выбор.

Стоимость


  • Бесплатно с ограничениями: до пяти активных пользователей, до 50 ГБ хранилища и до 10 000 запросов Git в месяц.
  • Платно — 1 доллар в месяц с каждого пользователя сверх пяти. 10 ГБ хранилища и 2 000 запросов Git в месяц для каждого активного пользователя.

8. FogCreek/DevHub

Платформа для управления кодом, которая основана на языке управления версиями Mercurial, но также поддерживает Git. FogCreek является частью более крупной платформы FogBugz DevHub, включающей в себя распределённый контроль версий и средства отслеживания ошибок и управления проектами.

Стоимость

Зависит от количества разработчиков в команде, начинается с 75 долларов в месяц за пять участников.

9. Beanstalk

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

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

Стоимость

  • Bronze — 15 долларов в месяц, 3 ГБ хранилища, 10 репозиториев, до пяти пользователей.
  • Silver — 25 долларов в месяц, 6 ГБ хранилища, 25 репозиториев, до 20 пользователей.
  • Gold — 12 ГБ хранилища, 50 репозиториев, до 40 пользователей, а также расширенные возможности.
  • Platinum — 24 ГБ хранилища, 120 репозиториев, до 100 пользователей, расширенные возможности.
  • Diamond — 60 ГБ хранилища, 300 репозиториев, до 200 пользователей, расширенные возможности.

10. GitKraken

GitKraken обладает прекрасным интерфейсом. Он ориентирован на скорость и простоту использования Git. Цель платформы — экономить время на сборку и тестирование кода.

С GitKraken работают такие гиганты, как Blizzard, IBM, Google и Microsoft. GitKraken можно установить на компьютерах с Windows, Mac и Linux.

A3.3 Appendix C: Команды Git — Основные команды

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

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

git add

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

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

Знакомство с этой командой происходит в главе Отслеживание новых файлов.

О том как использовать git add для разрешения конфликтов слияния написано в главе Основные конфликты слияния.

В главе Интерактивное индексирование показано как использовать git add для добавления в индекс лишь отдельных частей изменённого файла.

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

git status

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

Мы познакомили вас с этой командой в главе Определение состояния файлов, разобрали стандартный и упрощённый формат вывода. И хотя мы использовали git status повсеместно в этой книге, практически все варианты использования покрыты в указанной главе.

git diff

Команда git diff используется для вычисления разницы между любыми двумя Git деревьями. Это может быть разница между вашей рабочей директорией и индексом (собственно git diff ), разница между индексом и последним коммитом ( git diff —staged ), или между любыми двумя коммитами ( git diff master branchB ).

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

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

Мы показали вам как эффективно сравнивать ветки используя синтаксис git diff A. B в главе Определение применяемых изменений.

В главе Продвинутое слияние показано использование опции -w для скрытия различий в пробельных символах, а также рассказано как сравнивать конфликтующие изменения с опциями —theirs , —ours и —base .

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

git difftool

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

git commit

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

Вы познакомились с основами модели коммитов в главе Коммит изменений. Там же мы продемонстрировали использование опций -a для добавления всех изменений в индекс без использования git add , что может быть удобным в повседневном использовании, и -m для передачи сообщения коммита без запуска полноценного редактора.

В главе Операции отмены мы рассказали об опции —amend , используемой для изменения последнего совершённого коммита.

В главе О ветвлении в двух словах мы более подробно познакомились с тем, что делает команда git commit и почему она делает это именно так.

Мы показали вам как подписывать ваши коммиты, используя опцию -S в главе Подпись коммитов.

И наконец мы заглянули внутрь команды git commit в главе Commit Objects и узнали что она делает за кулисами.

git reset

Команда git reset , как можно догадаться из названия, используется в основном для отмены изменений. Она изменяет указатель HEAD и, опционально, состояние индекса. Также эта команда может изменить файлы в рабочей директории при использовании параметра —hard , что может привести к потере наработок при неправильном использовании, так что убедитесь в серьёзности своих намерений прежде чем использовать его.

Мы рассказали об основах использования git reset в главе Отмена подготовки файла, где эта команда использовалась для удаления файла из индекса, добавленного туда с помощью git add .

В главе Раскрытие тайн reset, полностью посвящённой этой команде, мы разобрались в деталях её использования.

Мы использовали git reset —hard чтобы отменить слияние в главе Прерывание слияния, там же было продемонстрировано использование команды git merge —abort для этих целей, которая работает как обёртка над git reset .

git rm

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

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

Ещё один вариант использования git rm приведён в главе Removing Objects, где мы вкратце объяснили как использовать опцию —ignore-unmatch при выполнении git filter-branch , которая подавляет ошибки удаления несуществующих файлов. Это может быть полезно для автоматически выполняемых скриптов.

git mv

Команда git mv — это всего лишь удобный способ переместить файл, а затем выполнить git add для нового файла и git rm для старого.

Мы лишь вкратце упомянули это команду в главе Перемещение файлов.

git clean

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

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

Памятка по основным командам Git

18.03.2014 в 01:17

Команды

git status — пересматриваем изменения

git add . — добавляем изменения

git commit -a -m ‘message’ — подтверждение изменений в текущей ветке

git pull — скачать новые изменения

git push username-project current-branch:remote-branch — запись текущей ветки в удаленный репозиторий

git reset —hard ‘hash code’ — возвращаемся на версию по хеш коду

git branch -a — отобразить все ветки

git branch -D local-branch — удалить локальную ветку

git checkout local-branch — переключится на локальную ветку

git merge local-branch — наложить изменения из локальной ветки в текущую

git checkout -b local-branch remotes/origin/master — скачать ветку с удаленного репозитория и переключиться на нее

git remote add username-project git@github.com:username/project.git — добавление ссылки на удаленный репозиторий

git remote update — обновить информацию о удаленном репозитории

10 — откатить форк на нужное количество коммитов

Добавить комментарий