Git — Git create mode 10064


Содержание

Git — создание ветвей (branch)

September 04, 2014

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

Слово магия здесь применено не случайно — не иначе, как магией возможности Git\GitHub не назовешь. По крайней мере, я впечатлен этими возможностями. Другое дело, что процесс изучения Git у меня лично идет как-то тяжеловато. Ну, это не страшно — главное, не останавливаться!

В этом разделе я попытаюсь осветить для себя (и возможно, для вас, уважаемый читатель) вопрос создания ветвей (branches) в Git, перемещение между ветвями (branches), слияние (merge) ветвей. Этот вопрос очень подробно и хорошо описан на странице официальной документации — “Git Branching — Basic Branching and Merging”. Здесь я попробую самостоятельно описать данный вопрос.

Инициализация Git-репозитория

Создаю тестовую директорию , в которой будут производиться эксперименты по созданию ветвей в Git. Внутри этой директории создаю два файла — индексный файл и файл таблиц стилей. А затем инициализирую Git-репозиторий, добавляю созданные файлы под версионный контроль Git:

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

Итак, мы уже кое-что узнали. А именно — при инициализации Git-репозитория была автоматически создана ветвь (branch) по имени . И на данный момент мы находимся в этой ветви.

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

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

Git — создание новой ветви (branch)

В системе Git (как уже упоминалось ранее) имеется механизм ветвления (branches). Попробую на словах объяснить, что он из себя представляет.

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

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

Строка услужливо информирует, что меня автоматически “перебросило” во вновь ветвь . Можно проверить себя, набрав в консоли:

Строка говорит сама за себя.

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

Не забуду также проиндексировать и зафиксировать внесенные изменения. Обратите внимание на вид команды — . Эта команда является сокращенным вариантом двух команд: и . Применяется, когда нужно “проскочить” этап индексирования и сразу зафиксировать изменения.

Смотрим, что у нас получилось в окне браузера — то, что и ожидалось:

Git — переключение между ветвями (branches)

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

Оп! Мы видим старую картину — Git “запечатлел” тот момент, когда мы совершили переход из ветви в ветвь . Другими словами, мы вернулись в последнее зафиксированное состояние ветви :

Если я снова вернусь в ветку и запущу команду просмотра логов Git, то коммитов окажется больше:

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

Git — слияние ветвей (branches)

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

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

Команда слияния проста — я просто указываю имя той ветки (branch), которую хочу слить (merge) с текущей, в которой я нахожусь на данный момент.

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

Давайте снова “заглянем” в окно браузера — что он нам интересного покажет?

Показал он то, что и следовало показать — результат объединения двух ветвей и .

Git — графическое представление ветвей (branches)

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

Это можно сделать, набрав в консоли команду:

На Stack Overflow я нашел примеры красивых изображений консоли с псевдографическим выводом команды :

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


Помимо псевдографики, ветви в Git можно визуализировать с помощью настоящего графического приложения. Под Mac OS X и Linux имеется достаточно большое количество таких приложений. Например, под Mac OS X это GitX, под Linux — Gitk или Gitg:

Git — удаление ветви (branch)

В разделе слияния ветвей в Git я научился процессу объединения двух ветвей в одну. Такой процесс в Git имеет название (слияние). Теперь ветвь имеет в себе все, что есть и в ветви . Поэтому ветвь можно удалить.

Выполняется это командой:

Посмотрим на вывод команды :

У меня осталась одна ветвь — .

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

Денис Туляков wiki

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

Основная настройка имя и почта

Псевдонимы (Алиасы) задаются следующим образом

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

Теперь вывод лога в графическом виде делается командой git l

Пример работы

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

Смотрим статус локального репозитория сокращённый вариант

Смотрим статус локального репозитория сокращённый вариант

Добавляем файл порекомендации

Проверяем теперь статус

Комитим (закрепляем изменения)

И ещё раз проверяем статус

Подключаем удалённый репозиторий

Вытягиваем все изменения которые уже есть на удалённом репозитории ЭТО НАДО ДЕЛАТЬ ВСЕГДА.

При этом он автоматом смёржился без канфликтов т.к. небыло одинаковых файлов с разным содержимым

Получается что мёрж это отдельный коммит

Что бы не чесать репу и разбирать ошибки почему не запушилось я делаю так

Смотрим что там поменялось

Псевдо графика показывает, что мы смёржиди две ветки в одну

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

Смотрим в какой мы ветке и какие есть вообще

Переключаемся в новую ветку

Теперь проверим где мы

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

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

А вдруг гит нас обманул и мы не в мастере


Всё нормально можно мёржить

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

Ну а желающему можно просто пульнуть всё

Или только ту ветку которая нужна

Но создать её всё равно надо через команду branch или другой вариант (создание ветки и переключение в неё)

Для добавления ещё одного репозитория

Смотрим сколько репозиториев есть

Для того, что бы вытолкнуть в репозиорий remotename или в origin надо указать куда

Понятно что если делать так

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

Например поправил файл и создал новый

Хочу отменить все изменения а новый не добавлять в не пушить его. Отменяем свои изменения.

Пока файл не добавлен через add он не будет отслеждиваться.

Удалить файл из гит но оставить локально

Если сделать это без —cache то файл удалится локально и из индекса

Есть ещё stash но о нём чуть позже

Для того что бы «склеить» коммиты можно воспользоваться такоим приёмом

В редакторе напротив коммитов которые оставляем не трогаем ничего, там уже указано pick , а те которые надо «склеить» пишем squash

jenyay.net

Софт, исходники и фото

Использование Git. Параметр AutoCRLF

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

Настройка AutoCRLF

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

Как известно, в разных операционных системах приняты разные символы для перевода строк, в Windows — это два символа \r\n (или CR и LF, код 0D0A в 16-ричной системе счисления), в *nix — просто \n (LF, код 0A), а в Mac — \r (CR, код 0D). Настройка core.autocrlf предназначена для того, чтобы в главном репозитории все переводы строк текстовых файлах были одинаковы.

Работает эта настройка так. Пусть для репозитория настройка core.autocrlf установлена в значение true следующей командой

git config core.autocrlf true

Тогда при коммитах (или, если более строго, при чтении файлов из файловой системы) все переводы строк при хранении будут приведены к виду \n, как в *nix, а при записи в файлы будут преобразованы к виду \r\n, как в Windows.

Давайте проведем несколько экспериментов в этим параметром.

Так как по крайней мере в Windows значение core.autocrlf по умолчанию установлено в true, то для чистоты эксперимента установим значение этого параметра явно в конфиге пользователя:

git config —global core.autocrlf true

Эксперимент первый

Создадим два файла с одинаковым с виду содержимым:

Первый файл с именем crlf.txt будет содержать этот текст с переводами строк \r\n:

А второй, с именем lf.txt будет содержать переводы строк \n:

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


После этого добавим файлы к коммиту:

При этой операции мы получим следующее предупреждение:

warning: LF will be replaced by CRLF in lf.txt

Git предупреждает о том, что переводы строк в файле lf.txt будут заменены на \r\n. Нам отступать некуда, поэтому все-таки выполняем коммит:

git commit -m «commit comment»

Git еще раз выведет то же самое предупреждение, но коммит сделает:

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

Если теперь посмотрим на файлы клона в 16-ричном редакторе, то увидим, что оба файла crlf.txt и lf.txt имеют переводы строк \r\n. Получилось, что файлы lf.txt в исходном репозитории и в клоне стали разные, хотя git их считает идентичными. Это произошло из-за того, что в самом начале мы установили значение core.autocrlf в true в конфиге пользователя, поэтому такое значение и будет применяться для только что созданного репозитория по умолчанию, то есть это значение установлено в true для обоих репозиториев.

Давайте теперь изменим файл lf.txt в клоне, добавив еще одну строку, причем переводы строк оставим как \r\n:

Сделаем коммит и отправим изменения обратно в главный репозиторий:

Цукерберг рекомендует:  Вакансии BODYSITE

Напомню, что параметр -a у команды git commit указывает, что к коммиту нужно добавить все измененные файлы, которые уже есть в репозитории (но не новые).

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

Смотрим что стало с содержимым файла lf.txt в шестнадцатеричном редакторе и видим:

В нем переводы строк тоже поменялись на \r\n, теперь в файле lf.txt в обоих репозиториях находятся файлы с одинаковыми переводами строк.

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

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

Возьмем все тот же исходный файл lf.txt с переводом строк \n:

Создадим репозиторий в папке с этими файлами:

Установим значение параметра core.autocrlf в false:

git config core.autocrlf false

Глобальное значение этого параметра по-прежнему остается true, но для данного репозитория это уже не играет роли.

Теперь добавим файл к коммиту:

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

git commit -m «Commit comment»

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

А теперь создадим клон этого репозитория:

Дело в том, что для этого нового репозитория-клона файл конфига не будет содержать параметра core.autocrlf, поэтому по умолчанию будет использоваться то значение, которое мы установили в самом начале, то есть true. А раз этот параметр установлен в true, то при создании файлов переводы строк будут преобразованы в \r\n, что мы и увидим в файле lf.txt:

Эксперимент третий

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

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

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

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

0. Глобальное значение параметра core.autocrlf должно быть true.

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

2. Устанавливаем для него параметр core.autocrlf в false.

3. Создаем файл с переводами строк \r\n.


4. Добавляем файл к коммиту.

5. Выполняем коммит.

6. Создаем клон этого репозитория

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

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

Таким образом, такая ситуация возникает с файлами, у которых окончания строк \r\n (для файлов с окончаниями строк \n такая последовательность действий проблем не воссоздает), если у клона и главного репозитория разные значения параметра core.autocrlf.

Решение проблемы пришло неожиданно во время экспериментов. Оказывается, что достаточно после возникновения такой ситуации установить значение параметра core.autocrlf в false. Даже если затем значение этого параметра снова установить в true, то файл будет считаться неизмененным. Все это показано на следующем логе работы:

Заключение

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

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

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

Также хотелось бы обратить ваше внимание на параметр core.safecrlf, который тесно связан с core.autocrlf, но который мы также не рассматривали.

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

Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.

Основные Git команды: шпаргалка

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

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

С этими задачами призваны справляться системы контроля версий. И одной из них является продукт под названием Git.

Системы контроля версий: немного теории

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

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

  • локальные;
  • централизованные;
  • распределенные.

Виды систем контроля версий

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

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

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

Git: описание и особенности системы

Система контроля версий Git обладает своими особенностями. Большинство систем хранит файлы, изменяя их в соответствии с инструкциями в проекте. То есть, к примеру, версия текущей разработки под номером 3 может содержать данные об изменениях в файле А и Б. А уже версия 4 будет иметь в себе А, Б и В. Таким образом, файлы меняются по необходимости.

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

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

Для сохранения целостности данных применяется метод хеширования каждого изменённого файла методом SHA-1. Это позволяет системе контроля версий точно знать, где, кто и когда изменил файл.

Git: установка

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

Версию для Windows можно скачать по адресу: git-for-windows.github.io. После загрузки программу нужно установить. Инсталлятор простой, так что эта процедура не должна вызвать проблем.

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


Первые команды

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

  • git config —global user.name »Имя»;
  • git config —global user.mail »Адрес электронной почты».

На этом же этапе необходимо настроить метод окончания строк с помощью двух команд:

  • git config —global core.autocrlf true;
  • git config —global core.safecrlf false.

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

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

  • Init: данная команда создаёт новый репозиторий.

Пример использования: init имя проекта.

  • Clone. Производит копирование существующего репозитория с удалённого источника.

Вот так используется команда git clone: clone git://github.com/путь к репозиторию.

  • Add. Наиболее часто используемая команда в системе контроля версий Git. Она выполняет простую задачу — добавляет указанные файлы в особую область, именуемую индексом или сценой. В неё можно перенести несколько файлов или папок, которые необходимо будет впоследствии добавить в репозиторий или, выражаясь на языке Git, «закоммитить».

Пример использования этой Git команды выглядит так: add некий_файл.txt.

  • Status. Позволяет просмотреть список файлов, которые присутствуют в индексе и рабочей папке. Служит для контроля и просмотра готовых к коммиту данных или их изменённых, но не внесённых версий в сцену.
  • Diff. Показывает разницу состояний. Например, с помощью этой Git команды можно определить, есть ли изменения между папкой с проектом и индексом.
  • Commit. Выполняет сохранение слепка всего того, что находилось в индексе непосредственно в базу данных. В результате работы Git команды на экране отобразится текстовый файл, в котором можно указать, какие именно изменения были произведены. А также будет выведена информация о том, сколько файлов подверглись коммиту, и его контрольная сумма. Главное — не забывать о том, что после изменения в базу попадут только те данные, которые были занесены в индекс командой git add.

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

  • Reset. О функциях этой команды говорит ее название. Она просто выбрасывает из специальной промежуточной области — индекса, указанный файл, помещённый туда по случайности. Стоит осторожно обращаться с reset при использовании команды с ключом — — hard, так как это затронет и файлы в рабочей папке, что может привести к непредвиденным последствиям.
  • Rm. Наиболее точно эту команду можно описать как обратную git add, так как она удаляет файлы из индекса. Правда, при этом ещё и из рабочей папки.

Пример использования: git rm некий_файл.txt.

  • Mv. Служит для перемещения файла.
  • Clean. Предназначена для очистки папки проекта от ненужных файлов.

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

Работа с ветками репозиториев в Git


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

  • Branch. У этой команды имеется в наличии несколько ключей, используя которые можно гибко управлять ветками в проекте. Branch представляет собой некий многопрофильный инструмент для полноценного контроля за состоянием репозитория. Простой вызов git branch выдаст перечень всех имеющихся веток хранилища. Ключ -v добавленный к команде отобразит какие коммиты были зафиксированы за последнее время. А использование -d приведёт к удалению указанной ветки. Branch умеет не только удалять, но и создавать. Выполнение git branch имя_ветки приведёт к организации новой ветки в проекте. Стоит учесть, что при этом указатель текущего рабочего положения бывает иным. К примеру, создав имя_ветки, можно на самом деле находится в ветке master.
  • Чтобы переместиться в нужный пункт, существует команда Git checkout нужная_ветка, которая переставит указатель в необходимую ветку.
  • Checkout. Как уже говорилось выше, выполняет переключение.
  • Merge. Данная команда позволяет производить слияние нескольких веток воедино.
  • Log. Функция отображает все изменения от начала проекта и до последнего коммита. Использование разнообразных ключей совместно с вызовом команды позволяет расширить ее функционал. Например, вызов git log -p -2 позволит просмотреть подробную информацию об изменениях в каждом коммите. Второй ключ -2 говорит о том, что нужно показать лишь 2 последних изменения. Аргумент —stat, добавленный к вызову git log, выполнит практически то же самое, что и -р, но в более подробной и при этом компактной форме. Также с помощью git log можно выводить информацию об изменениях, создав собственный формат отображения, используя опции format ключа pretty. Для придания особого вида нужно использовать некое подобие регулярных выражений. Например, такая запись get log —pretty=format »%h, %an, %ar, %s» выведет краткий хэш коммита, затем его автора, дату и комментарий изменения. Это очень удобно использовать при просмотре большого количества коммитов.
Цукерберг рекомендует:  Книги - Посоветуйте книги по Android

Команды для распределенной работы в системе

  • Fetch. При вводе данной команды git консоль выполнит перенос всех изменений с удалённого хранилища в локальное.
  • Pull. Команда git pull представляет собой симбиоз двух перечисленных выше — git fetch и git merge. То есть она сначала получает сведения из удалённого репозитория, а затем выполняет слияние с использующейся в данный момент веткой.
  • Push. Именно от названия этой команды в среде пользователей появилось выражение «запушить», что означает соединение с удаленным репозиторием и передачу туда изменений из локального.

Команды удаленного управления

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

Как использовать данную шпаргалку

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

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

Руководство по Git. Создание удалённого репозитория

В этой статье мы рассмотрим процесс создания удалённого репозитория Git

1. Создание удалённого репозитория

Для начала создадим репозиторий. Для этого нам прежде всего необходимо перейти на сайт https://github.com/

После регистрации нам необходимо перейти в свой профиль и создать новый репозиторий.

В моём случае я создал репозиторий с именем GitTutorial, который имеет следующую URL:

2. Инициализация Git в проекте

Для начала создадим простой Java проект. Я создал консольное Java приложение с именем GitTutorial.

Теперь нам необходимо инициализировать Git с помощью команды:

3. Добавление удалённого репозитория

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

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

Теперь нам осталось только “залить” проект на удалённый репозиторий:

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

На этом мы заканчиваем рассмотрение процесса создания удалённого репозитория в Git.
В следующей статье мы рассмотрим операцию Clone.

Ошибка при git push?

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

На клиенте делаю следующие шаги:

Соответственно, после git reset —hard, ошибка остается прежней.
Впервые столкнулся с git, прошу совета, что я делаю не так?


  • Вопрос задан более трёх лет назад
  • 8030 просмотров

Ошибка из-за того, что Git по умолчанию не разрешает обновлять текущую ветку не bare-хранилища посредством push.

На сервере либо инициализируем хранилище так:
git init —bare
Это создаст хранилище без рабочей копии (bare хранилище)

Либо задаём в конфиге хранилища:
[receive]
denyCurrentBranch = ignore (или warn)
Чтобы можно было пушить в текущую ветку не bare хранилища.

Второй способ не рекомендуется, так как может привести к конфликтному состоянию рабочей копии.

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

Prgm / Scripts

Начинаем работать с Git — первые шаги

Для чего нужен GIT

Git — система управления контроля версиями, репозитории Git содержат файлы, историю, конфигурации управляемые Git. Данные могут отправляться из локальной папки в Git репозиторий и обратно, локальное состояние подразумевает рабочую папку которая содержит измененные файлы готовые для помещения в .git каталог, при помещении в данный каталог — Commit, указываются комментарии к данному коммиту, что по факту является историей, удаленный репозиторий содержит ветки Branches, основная ветка называется Master, данные могут отправляться как в Master, так и другие ветки (ответвления) проекта.

Команды GIT

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

  • История команд
  • По командам можно найти обширную информацию в интернете
  • Командная строка представляет более полный контроль
  • Команды одинаково работают в любых ОС / дистрибутивах

В Linux (CentOS / Fedora) устновка Git достаточно проста:

Git для начинающих. Часть 5. Создание репозитория и первый коммит

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

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

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

Теперь перейдем в этот каталог.

Создадим в нем пустой git репозиторий.

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

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

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

Создадим в нашем каталоге пустой файл.

Теперь, если мы выполним команду git status , то увидим, что в нашем каталоге появился один неотслеживаемый файл: README.md .

Добавим, созданный файл в stage . Stage (или cache ) – это хранилище для файлов с изменениями, информация о которых попадет в единый коммит. Stage является элементом архитектуры трех деревьев, на базе которой построен git , более подробно смотрите здесь. Для добавления файла README.md в stage необходимо воспользоваться командой git add .

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

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

Как видно, в stage был добавлен один файл с именем README.md и теперь представленный набор изменений готов к отправке в репозиторий – т.е. к коммиту. Сделаем это.

Проверим статус каталога.

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

Теперь взглянем на список коммитов.


Из приведенной информации видно, что был отправлен один коммит, который имеет ID : 500067cc0b80643d38e2a24e9e0699031ada6be3, более подробно об идентификаторах будет рассказано в следующих уроках. Автор данного коммита Writer , он (коммит) был создан Mon Feb 12 22:51:14 2020 +0500, с сообщением: [create repository] . Это довольно подробная информация, когда коммитов станет много, такой формат вывода будет не очень удобным, сокращенный вариант выглядит так.

Подведем небольшое резюме вышесказанному.

Создание пустого репозитория.

Добавление файлов в stage .

Просмотр статуса каталога.

Просмотр коммитов в репозитории.

Просмотр коммитов в репозитории с сокращенным выводом информации.

Отличный курс по git делают ребята из GeekBrains , найдите в разделе “Курсы” курс “Git. Быстрый старт” , он бесплатный!

Работа с Git через консоль

Итак, вы получили задание: сделать форк вашего репозитория в GitHub, создать ветку и начать работу.

Когда получил непонятное задание.

Что за GitHub, какие команды, зачем, а главное, как всем этим пользоваться? Давайте разбираться.

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

Для начала определим, что такое система контроля версий.

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

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

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

В Windows их две: PowerShell и cmd.exe. В Ubuntu это Terminal. Самая популярная программа на macOS тоже называется Terminal. Если вам не подходит встроенная в систему программа для работы с командной строкой, вы можете поставить свою. Например, написанную на JavaScript программу Hyper, которая работает на любой операционной системе. На Windows популярны программы Cmder и Git Bash, а на macOS — iTerm.

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

Устанавливаем Git

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

Установка в Linux

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

  • Если у вас 21 или более ранняя версия Fedora, используйте yum install git .
  • Для 22 и последующих версий Fedora вводите dnf install git .
  • Для дистрибутивов, основанных на Debian, например, Ubuntu, используйте apt-get: sudo apt-get install git .

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

Установка на macOS

  1. Скачиваем Git со страницы проекта.
  2. Запускаем загруженный файл.
  3. Система может показать окно с ошибкой, где будет написано, что файл скачан с неавторизованного сайта и инсталлятор не может быть запущен. В таком случае нужно зайти в «Системные настройки» — «Безопасность» (Security and Privacy), в появившемся окне будет сообщение об ошибке и кнопка Open anyway (Всё равно открыть). Нажимаем.
  4. Система покажет окно, уточняющее хотите ли вы запустить установку. Подтверждаем действие.
  5. Установщик проведёт через все необходимые шаги.

Установка в Windows

Скачайте exe-файл инсталлятора с сайта Git и запустите его. Это Git для Windows, он называется msysGit. Установщик спросит добавлять ли в меню проводника возможность запуска файлов с помощью Git Bash (консольная версия) и GUI (графическая версия). Подтвердите действие, чтобы далее вести работу через консоль в Git Bash. Остальные пункты можно оставить по умолчанию.


Проверим, что Git установлен

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

Настройка Git

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

Откройте терминал и используйте следующую команду, чтобы добавить своё имя: git config —global user.name «ваше имя»

Для добавления почтового адреса вводите: git config —global user.email адрес

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

Регистрация на GitHub

Что такое GitHub?

GitHub — веб-сервис, который основан на системе Git. Это такая социальная сеть для разработчиков, которая помогает удобно вести коллективную разработку IT-проектов. Здесь можно публиковать и редактировать свой код, комментировать чужие наработки, следить за новостями других пользователей. Именно в GitHub работаем мы, команда Академии, и студенты интенсивов.

Чтобы начать работу с GitHub, нужно зарегистрироваться на сайте, если вы ещё этого не сделали. За дело.

  1. Переходим на сайт GitHub. Cтартовая страница GitHub.
  2. Есть два варианта начала регистрации:
    • Нажимаем кнопку Sign up (зарегистрироваться), попадаем на страницу регистрации, где вводим обязательные данные: имя пользователя, адрес электронной почты и пароль. После заполнения полей нажимаем Create an account (создать аккаунт).
    • Cразу вводим имя, почту и пароль на главной странице GitHub и нажимаем Sign up for GitHub (зарегистрироваться на GitHub).

    Первый шаг регистрации профиля на стартовой странице GitHub.

  3. На втором этапе нужно выбрать тарифный план. GitHub — бесплатный сервис, но предоставляет некоторые платные возможности. Выбираем тарифный план и продолжаем регистрацию. Выбор тарифа на втором шаге регистрации.
  4. Третий шаг — небольшой опрос от GitHub, который вы можете пройти, заполнив все поля и нажать Submit или пропустить, нажав skip this step. Опрос на третьем шаге регистрации.
  5. После прохождения всех этапов на сайте, на указанный при регистрации ящик вам придёт письмо от GitHub. Откройте его и подтвердите свой почтовый адрес, нажав Verify email address (подтвердить электронный адрес) или скопируйте вспомогательную ссылку из письма и вставьте её в адресную строку браузера. Переход в ваш профиль.

Так выглядит ваш профиль после регистрации.

Теперь у вас есть профиль на GitHub.

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

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

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

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

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

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

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

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

/.ssh , поэтому нужно проверить содержимое этого каталога.

  1. Открываем консоль.
  2. Вводим cd

/.ssh , чтобы перейти в нужный каталог. Переходим в нужную директорию.

  • Используем ls , чтобы увидеть список всех файлов в каталоге. Открываем список файлов в директории. Ищем пару файлов с названиями вида имя и имя.pub . Обычно имя — id_rsa , id_dsa , id_ecdsa или id_ed25519 . Файл с расширением .pub — ваш публичный ключ, а второй — ваш приватный, секретный ключ. Если таких файлов или даже каталога .ssh у вас нет, вы можете их сгенерировать. Для этого делаем следующее.
    • Открываем консоль и вводим команду: Указываем тот адрес электронной почты, который вводили при регистрации на GitHub. Генерируем ключ.
    • Далее нужно указать расположение файла для сохранения ключа. Если вы не введёте путь до файла и просто нажмёте Enter, ключ сохранится в файле, указанном в скобках.
    • Теперь нужно установить пароль к вашему ключу и дважды ввести его. Если вы не хотите вводить пароль каждый раз, когда используете ключ, пропустите этот шаг, нажав «Enter», и ничего не вводите. Указываем расположение ключа и вводим пароль.
  • Добавляем ключ в ssh-agent (сгенерированный или уже существующий). Проверяем доступность ключа командой eval «$(ssh-agent -s)» и добавляем с помощью ssh-add

    /.ssh/your_key_name , где указываем верный путь до файла с ключом и его имя. Добавляем ключ в shh-agent. Несколько важных примечаний:

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

    /.ssh/config связь ключа с доменом.
    Если у вас Windows и вы пользуетесь программой Cmder, возможны проблемы с командой eval «$(ssh-agent -s)» . Может появиться такое сообщение об ошибке: «eval не является внутренней или внешней командой, исполняемой программой или пакетным файлом».

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

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

    Если у вас macOS Sierra версии 10.12.2 и выше, нужно изменить ваш

    /.ssh/config файл, чтобы автоматически загрузить ключи в ssh-agent и хранить пароли.

    Вы можете добавить свой приватный ключ в ssh-agent и сохранить пароль к нему с помощью команды ssh-add -K

    /.ssh/id_rsa . Если у вашего ключа другое имя, не забудьте заменить id_rsa в команде на правильное название.

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

    /.ssh права доступа командой chmod 700

    /.ssh/

  • После того как создан ключ, его нужно добавить на GitHub. Для этого копируем его содержимое с помощью одной из следующих команд:
    • Если вы на Windows clip .
    • Для пользователей macOS pbcopy .
    • На Linux используйте sudo apt-get install xclip , чтобы установить необходимый для копирования пакет xclip , а затем введите xclip -sel clip . Или введите команду cat

      /.ssh/id_rsa.pub , контент документа появится прямо в консоли и вы сможете скопировать ключ оттуда.

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

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

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

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

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

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

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

      Работа с репозиториями

      Для начала определим, что такое репозиторий. Это рабочая директория с вашим проектом. По сути, это та же папка с HTML, CSS, JavaScript и прочими файлами, что хранится у вас на компьютере, но находится на сервере GitHub. Поэтому вы можете работать с проектом удалённо на любой машине, не переживая, что какие-то из ваших файлов потеряются — все данные будут в репозитории при условии, что вы их туда отправите. Но об этом позже.

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

      Как сделать форк мастер-репозитория?

      Заходим в нужный репозиторий, нажимаем на «вилку» с надписью fork. Форк репозитория создан и находится в вашем профиле на GitHub.

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

      Открываем консоль, переходим в директорию, где хотим сохранить папку с проектом, и вводим команду:

      Если вы правильно настроили SSH-ключи, Git начнёт процесс копирования репозитория на ваш компьютер. Если вы видите ошибку, в которой написано Error: Permission denied (publickey) , скорее всего, вы ошиблись где-то при выполнении инструкции по настройке SSH-ключа. Вернитесь на несколько абзацев ранее и попробуйте повторить процесс настройки.

      Если вы не хотите вручную вводить адрес репозитория, вы можете зайти на страницу проекта, нажать зелёную кнопку Clone or download (клонировать или скачать), выбрать Clone with SSH (клонировать по SSH) и скопировать адрес, который находится в текстовом поле. Этот адрес вы можете вставить в команду git clone .

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

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

      Чтобы начать работу с проектом, надо оказаться в его директории. Для этого используем команду cd , после которой указываем название проекта на вашем компьютере: cd your-project

      Сделали копию репозитория.

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

      Создадим новую ветку. Открываем терминал, вводим команду git branch . Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую. Если мы находимся в master создаём новую ветку: git checkout -b имя-новой-ветки .

      Если текущая ветка не master , сначала переключимся в основную ветку: git checkout master . Мы делаем это, чтобы новая ветка содержала свежую, на момент создания, рабочую версию проекта.

      Эта команда позволяет переключаться между существующими ветками в проекте, после git checkout надо указать название нужной ветки.

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

      Если вы ошиблись в названии, например, допустили опечатку, вы можете изменить название ветки с помощью команды: git branch -m старое-имя-ветки новое-имя-ветки .

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

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

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

      Если вы хотите сохранить все изменения разом, вводите git add -A .

      Теперь мы можем сделать коммит, то есть зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды git commit -m «ваше сообщение» . Текст сообщения должен быть лаконичным и в то же время сообщать о том, что делает коммит (внесённые изменения). Например, «добавляет имя наставника в Readme», «вводит функцию сортировки изображений», «правит ошибку в поиске городов на карте».

      Сохранения зафиксированы, всё? Они теперь в репозитории и видны коллегам? Пока нет. Те изменения, которые мы внести и сохранили, пока локальны. Их нужно послать на GitHub.

      Чтобы отправить свои изменения (коммиты) в репозиторий на GitHub, введите команду git push origin название-текущей-ветки , где origin означает репозиторий, который был склонирован на компьютер, то есть ваш форк.

      Теперь заходим на страницу нашего форка и создаём пулреквест, чтобы слить свой код с данными в мастер-репозитории. Что такое пулреквест? Это предложение изменить код в репозитории.

      Любое предложение можно принять или отвергнуть. Так же и с пулреквестом. После его создания, он должен получить ревью и одобрение так называемого коллаборатора — пользователя GitHub, который имеет права администратора в мастер-репозитории. Им может быть ваш коллега-разработчик, техлид, наставник. Если к вашему коду нет вопросов, пулреквест принимается и изменения из вашей ветки попадают в master главного репозитория. Если в код нужно внести изменения, пулреквест отклоняется, и вам нужно снова пройти по цепочке локальные изменения — сохранение — коммит — пуш, только пулреквест заново делать не нужно. Если вы продолжаете вести работу в той же ветке и пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки .

      Вы исправили код, наставник или техлид одобрил ваши правки и принял пулреквест. Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.

      1. В локальном репозитории вводим команду git checkout master , переходим в master .
      2. Теперь забираем (подтягиваем) изменения из ветки master мастер-репозитория git pull academy master . Academy здесь — сокращённое название мастер-репозитория, такое имя используется в проектах студентов Академии, вы можете выбрать любое другое название. Забираем изменения из мастер-репозитория. Если консоль выдаёт ошибку и говорит, что не знает директории с таким именем, нужно добавить ссылку на этот репозиторий: Вместо academy указывайте своё название и оно закрепится за этим репозиторием.
      3. Теперь отправьте изменения уже из своей ветки master в ваш форк на GitHub с помощью команды git push origin master . Отправляем изменения в форк.

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

      Git: работа с тегами (метками)

      Документация тут>>> , ниже примеры работы с тегами.

      Кратко о метках в примерах.

      Создаём каталог для тестового репозитория:

      Инициализируем пустой репозиторий:

      Создаём тестовый файл:

      Добавление тегов

      Теги в Git есть двух основных типов:

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

      Для добавления тега с аннотацией — используем -a или —annotate :

      Для добавления легковесного тега — просто пропускаем -a и -m :

      Можно добавить тег на старые коммиты.

      Проверяем историю коммитов:

      Добавляем тег на предыдущий коммит — 96012d8d14f80695339a3d215b2c1f5f2475f040:

      Просмотр тегов

      Что бы получить список всех тегов — просто вызываем tag без аргументов:

      Для просмотра информации о теге — show :

      И просмотр легковесной метки:

      В случае легковесного тега сохраняется информация только о самом коммите, но нет ничего об авторе тега.

      push тегов в репозиторий

      Что бы сохранить теги в удалённый репозиторий — их необходимо пушить отдельно от коммитов.

      Клоним тестовый репозиторий с Гитхаба:

      Добавляем файлик, коммитим, добавляем тег:

      Если выполнить git push сейчас без указания тега — он в Gihub не добавится.

      А теперь повторяем push , но указываем origin и тег:

      Цукерберг рекомендует:  Cmd - CMD или Powershall
  • Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих