Знакомимся с Git за 30 минут

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

Зачем это нужно?

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

Недостатки автоматизации

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

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

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

Комментарии

VasyOK 26 февраля 2020 в 0:19

пробовал решить так (не получилось):

git remote rm origin git remote add origin https:// git push -u origin master error: src refspec master does not match any. error: failed to push some refs to »

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

VasyOK 26 февраля 2020 в 1:40

Решил так: стер папку .git в корне

git init git add . git commit -m «first commit» git remote add origin https:// git push -u origin master

Вроде работает правда папка files с картинками почему-то пошла в репу

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

bumble 26 февраля 2020 в 2:31 git init git add git commit -m «first commit» git remote add origin https:///Vasy0K/

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

Его нужно или клонировать тогда, если там есть уже что-то (git clone .).

Или, если удаленный только-что созданный и еще пустой, пушить с указанием своего бранча в качестве цели [флаг —set-upstream или -u] (git push -u origin master), где «origin» — название удаленного репозитория, а «master» — нзвавние ветки.

git remote add .. — для добавления удаленного репозитория в существующий проект.

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

Selpi 26 февраля 2020 в 11:22 1

Прочитай какой-нибудь букварь по гиту, например вот этот:

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

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

VasyOK 26 февраля 2020 в 12:45

Читайте также:  15 Примеров использования в linux команды top

читал

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

bsyomov 26 февраля 2020 в 12:55

Видимо, как-то слишком по диагонали, раз возникают такие вопросы и удивления.

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

Selpi 26 февраля 2020 в 13:16 4

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

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

bsyomov 26 февраля 2020 в 13:03

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

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

VasyOK 26 февраля 2020 в 13:24

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

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

ivnish 26 февраля 2020 в 13:27

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

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

Создание Git-тегов

Создать «легковесный (lightweight)» тег в текущей ветке:

$ git tag <tag_name>

Если вы хотите добавить к тегу описание, используйте опцию -a, чтобы создать «аннотированный (annotated)» тег:

$ git tag <tag_name> -a

Создать «аннотированный» тег с заданным сообщением (вместо интерактивного ввода):

$ git tag <tag_name> -a -m «Message»

Аннотированный vs Легковесный: Git-тег созданный с опцией -a называется «аннотированныйм» тегом. В то время, как тег без сопровождающего описания называется «легковесным» тегом. «Аннотированные» теги следует использовать для обозначения релизов, в то время, как «легковесные» теги должны использоваться для маркировки каких-то частных либо временных объектов. По этой причине некоторые Git-команды для наименования объектов (например git describe), по умолчанию, будут игнорировать «аннотированные» теги.

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

$ git describe v1.0.1 |————— текущий коммит отмечен следующим тегом $ git describe | | |—— хеш коммита | |———— количество коммитов с последнего тега |————— имя последнего тега

По умолчанию, команда git describe игнорирует «легковесные» теги.

Чтобы учитывать все теги, выполните:

$ git describe —tags

Управление удаленным репозиторием в Git

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

Управление удаленным репозиторием в Git

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

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

Читайте также:  10 лучших легких дистрибутивов Linux для старых компьютеров

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

Давайте рассмотрим эту программу в JavaScript. Она выводит на консоль три строки (вывод, который вы можете увидеть в своем браузере или терминале):

(‘Hello, this is a git example!’) (‘And here is another!’) (‘And yet a third’)

git init

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

git add

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

git commit

Далее я наберу git commit -am «Initial commit». git commit — это команда для сохранения версии нашего кода. -am является «флагом» и сигнализирует о том, что существуют необязательные действия, которые мы хотели бы предпринять с этим поручением. Флаг a означает, что мы собираемся сохранить все наши изменения. Флаг m обозначает, что мы предоставим сообщение позже, то есть «Initial commit».

Git ветки (branches)

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

Существует несколько «плюсов» использования веток:

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

Создание новой ветки – git branch

По-умолчанию, в каждом репозитории всегда имеется ветка с названием master. Чтобы создать дополнительные ветки используйте команду git branch <name>

$ git branch amazing_new_feature/span>

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

Переход на ветку – git checkout

С помощью команды git branch, мы можем просмотреть все доступные ветки репозитория.

$ git branch amazing_new_feature * master

Текущей веткой является master. Она помечена символом «*». Однако, если мы решим начать разрабатывать новый функционал, нам будет необходимо переключиться на другую ветвь. Это делается с помощью команды git checkout с указанием имени ветки в параметрах.

$ git checkout amazing_new_feature

Объединение веток – git merge

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

$ git add $ git commit -m «New feature complete.»

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

$ git checkout master

Если сейчас открыть папку проекта в файловом менеджере, мы обнаружим, что файл отсутствует. Дело в том, что мы перешли на ветку, в которой этот файл никогда не создавался. Чтобы перенести его сюда, необходимо объединить 2 эти ветки (git merge). Таким образом, изменения сделанные в ветке amazing_new_feature, будут перенесены в основную ветку проекта.

git merge amazing_new_feature

Теперь обе ветки идентичны. Так как новый функционал добавлен в проект, ветка amazing_new_feature нам больше не нужна. Удалим ее.

git branch -d awesome_new_feature

git остальные команды

  • Вывести имя удаленного репозитория.

    $ git remote origin

  • Вывести информацию об имени по умолчанию удаленного репозитория

    $ git remote show origin

  • Обновление данных об удаленных репозиториях:

    git remote update

  • git show Показывает самые последние коммиты текущей ветки
  • git pull Вытянуть последние изменения (для уже скаченной ветки)
  • git-init Создание локального репозитория
  • git branch Смотрим, какие ветки у нас есть в данный момент в репозитарии. Сразу после клонирования у вас будет видна только одна, активная в данный момент в удалённом репозитарии, ветка (в нашем случае это по умолчанию master, т.к. удалённый репозитарий находится на сервере и в нём ветки никто не переключает). Если в репозитарии есть другие ветки, их можно увидеть, добавив ключ -a (активная ветка обозначена звёздочкой)
  • git status Посмотреть текущее состояние индекса. Можно увидеть какие будут произведены измнения при применении команды commit. Также git status указывает файлы с неразрешенными конфликтами слияния и файлы, игнорируемые git.
  • git log Посмотреть коммиты в текущем репозитории

Ссылки для изучения GIT

  • etckeeper — это инструмент для хранения /etc в репозитории git, mercurial, bzr или darcs.
  • Git бесплатный курс 13 видеоуроков

Метки в Git

Метки позволяют выделять определённые моменты в истории.

$ git tag просмотр меток

$ git tag -l „v.1.*“ поиск меток по шаблону

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

  • Легковесные метки — это указатель на определённый коммит.

  • Аннотированная метка — храниться в базе данных git как объект. (контрольная сумма, комментарий, имя автора метки, дата, email,

$ git tag -a [tag-name] -m „комментарий“ создание аннотированной метки.

$ git show [tag-name] смотрим данные метки вместе с коммитом.

$ git tag [tag-name] создание легковесной метки

Метки можно создавать и позже, нужно только знать к какому коммиту. Для этого нужно указать контрольную сумму или её часть в конце команды создания метки. $ git tag -a [tag-name] [hash-or-pice]

Метками можно обмениваться $git push origin [имя метки]

Переход на метку в действительности не возможен. А что тогда возможно? Создание новой ветки с определённой меткой.

$ git checkout -b [branch-name] [tag-name]