Руководство по командной разработке с Git


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

.3 Введение — Основы Git

Основы Git

Так что же такое Git в двух словах? Эту часть важно усвоить, поскольку если вы поймёте, что такое Git, и каковы принципы его работы, вам будет гораздо проще пользоваться им эффективно. Изучая Git, постарайтесь освободиться от всего, что вы знали о других СКВ, таких как Subversion или Perforce. В Git’е совсем не такие понятия об информации и работе с ней как в других системах, хотя пользовательский интерфейс очень похож. Знание этих различий защитит вас от путаницы при использовании Git’а.

Слепки вместо патчей

Главное отличие Git’а от любых других СКВ (например, Subversion и ей подобных) — это то, как Git смотрит на свои данные. В принципе, большинство других систем хранит информацию как список изменений (патчей) для файлов. Эти системы (CVS, Subversion, Perforce, Bazaar и другие) относятся к хранимым данным как к набору файлов и изменений, сделанных для каждого из этих файлов во времени, как показано на рисунке 1-4.

Рисунок 1-4. Другие системы хранят данные как изменения к базовой версии для каждого файла.

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

Рисунок 1-5. Git хранит данные как слепки состояний проекта во времени.

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

Почти все операции — локальные

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

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

Кроме того, работа локально означает, что мало чего нельзя сделать без доступа к Сети или VPN. Если вы в самолёте или в поезде и хотите немного поработать, можно спокойно делать коммиты, а затем отправить их, как только станет доступна сеть. Если вы пришли домой, а VPN-клиент не работает, всё равно можно продолжать работать. Во многих других системах это невозможно или же крайне неудобно. Например, используя Perforce, вы мало что можете сделать без соединения с сервером. Работая с Subversion и CVS, вы можете редактировать файлы, но сохранить изменения в вашу базу данных нельзя (потому что она отключена от репозитория). Вроде ничего серьёзного, но потом вы удивитесь, насколько это меняет дело.

Git следит за целостностью данных

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

Механизм, используемый Git’ом для вычисления контрольных сумм, называется SHA-1 хешем. Это строка из 40 шестнадцатеричных символов (0-9 и a-f), вычисляемая в Git’е на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:

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

Чаще всего данные в Git только добавляются

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

Поэтому пользоваться Git’ом — удовольствие, потому что можно экспериментировать, не боясь что-то серьёзно поломать. Чтобы узнать подробнее о том, как Git хранит свои данные и как восстановить то, что кажется уже потерянным, читайте главу 9.

Три состояния

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

Таким образом, в проектах, использующих Git, есть три части: каталог Git’а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area).

Рисунок 1-6. Рабочий каталог, область подготовленных файлов, каталог Git’а.

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

Рабочий каталог — это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git’а и помещаются на диск для того, чтобы вы их просматривали и редактировали.

Область подготовленных файлов — это обычный файл, обычно хранящийся в каталоге Git’а, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area).

Стандартный рабочий процесс с использованием Git’а выглядит примерно так:

  1. Вы вносите изменения в файлы в своём рабочем каталоге.
  2. Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.
  3. Делаете коммит, который берёт подготовленные файлы из индекса и помещает их в каталог Git’а на постоянное хранение.

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

GIT и BitBucket: Командная разработка кода

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

Интерфейс BitBacket изменился после написания статьи. Смотрите как работать с BitBucket в новой версии в уроке курса Linux/GIT.

Как управлять различными версиями кода

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

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

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

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

Система управления версиями кода поможет исправить ситуацию

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

Рассмотрим работу систем управления версиями кода на примере программы GIT.

Возможности системы GIT.

Скачайте саму программу по этой ссылке:

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

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

При правильном соблюдении последовательности действий, у вас будут установлены две программы: git Bash и еще Git GUI. Стартовые ярлыки программ находятся в папках установки.

Работа с git

Что такое репозитарий git и как его создать.

Репозиторий git выполняет функции хранилища кода. В нем находятся служебные файлы git.

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

После пуска программы, можно наблюдать такой результат:

Найдите каталог проекта. Там и будет создаваться репозиторий GIT.

Вот пример возможного пути к каталогу сайта:

Для осуществления перехода между папками дается команда cd.

Наберите в командной строке:

попав в каталог проекта, запускаем git репозиторий.

С этой целью введите команду:

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

Initialized empty Git repository in c:/xampp/htdocs/fructcode/.git/

Она и означает успешное создание репозитария GIT.

В корневой папке каталога проекта, можно увидеть появление новой директории каталога git.

Добавление в репозиторий GIT файлов составляющих проект

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

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

При использовании команды git add * происходит загрузка всех файлов проекта. Далее будут рассмотрены усложненные настройки этой программы.

Команда GIT COMMIT

Поместив файловые данные в репозиторий, переходим к созданию Commit.

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

Вы можете увидеть такое сообщение:

Fix bug No342 in header

Это сообщение обозначает, что нужно задать имя пользователя и email пользователя GIT.

Вначале задается глобальное имя пользователя, а также email пользователя GIT. Затем идет сам Commit.

Команды, служащие в этих целях:

git config —global user.email [email protected] – команда задающая значение email пользователя.

git config —global user.name «your name» — команда задающая значение имени пользователя.

Создадим первый commit.

Здесь применяется команда:

git commit -m «init project»

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

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

Команда GIT PUSH

Итак, репозиторий вами подготовлен. На следующем этапе решается задача внесения изменений в виртуальный репозиторий BitBucket, созданный вами ранее. Изменения вносятся при помощи команды git push.

Далее нужно войти в свой аккаунт BitBucket. Выберете ранее созданный репозиторий. Там вы найдете адрес репозитория устанавливаемого на удаленный сервер. Его можно увидеть вверху справа на панели управления программой.

Скопировав адрес, запустите команду:

git remote add origin https://[email protected]/YOURUSER/YOURREP.git

Получив запрос от репозитория bitbucket, далее нужно ввести пароль.

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

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

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

Работа в команде с использованием Git¶

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

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


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

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

возможность работы с бинарными файлами большого объёма

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

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

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

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

По завершении некоторого логического этапа работы возникает необходимость фиксации изменений (коммит) и/или синхронизации с коллегами.

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

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

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

Перед выполнением команд необходимо перейти в репозиторий, например:

Индивидуальные настройки¶

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

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

Проверка статуса¶

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

Проверить статус можно командой:

Результат команды git status , если все коммиты проведены и нет новых файлов:

Возможный результат команды git status , если имеются изменения. Например, файлы apps_dev/firstperson/firstperson.js и doc_src/git_short_manual.rst изменены, и создан новый файл 123.txt :

Мастер Йода рекомендует:  Стоит ли будущему программисту идти на стажировку после 1-го курса

Перед коммитом¶

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

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

Проверить, что изменилось, во всей директории:

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

Возможный результат команды git diff для текстового файла:

Восстановление файлов¶

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

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

Посторонние файлы¶

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

Подготовка к коммиту¶

Добавление файлов¶

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

Снова проверить статус:

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

Видно, что для коммита добавлены файлы apps_dev/firstperson/firstperson.js и 123.txt , а файл doc_src/git_short_manual.rst остался недобавленным. Для упрощения работы рекомендуется либо добавлять такие файлы для коммита, либо отбрасывать их изменения командой git checkout .

Удаление файлов¶

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

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

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

Коммит¶

Выполнить коммит командой:

Появится окно текстового редактора (например, nano или vim), в котором нужно ввести комментарий к коммиту на английском языке.

Сохранить изменения и выйти из редактора (в nano Ctrl+O, затем Ctrl+X; в vim ZZ, или ESC :wq).

После совершения коммита рекомендуется снова проверить статус. Коммит совершен правильно, если команда git status отображает nothing to commit, working directory clean .

Синхронизация между репозиториями¶

Из удаленного — в локальный¶

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

Результат команды git pull , если в удаленном репозитории нет изменений:

Результат команды git pull , если в удаленном репозитории были изменения, и синхронизация прошла успешно:

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

Параметр этой команды — в данном случае dbf3877..9f9700c — указывает, между какими именно коммитами просматриваются изменения. Этот параметр удобно выделить в результатах команды git pull и вставить щелчком мыши (средняя кнопка) в консоли в нужном месте.

Также можно просмотреть лог изменений:

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

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

Из локального — в удаленный¶

Затем нужно загрузить изменения из локального репозитория в удаленный (“общий”), чтобы локальные изменения стали доступными для коллег.

Результат команды git push , если в удаленном репозитории уже есть все локальные изменения:

Результат команды git push , если синхронизация прошла успешно:

Результат команды git push , если синхронизация не прошла, потому что сначала не была выполнена команда git pull :

Необходимо выполнить команду git pull .

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

Разрешение конфликтов¶

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

Конфликты синхронизации происходят, если выполнены оба условия

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

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

бинарный файл (текстура, blend-файл) независимо изменен двумя участниками разработки

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

один участник разработки изменил файл, а другой — переместил его и т.п.

Хотя конфликты синхронизации — нормальное явление, слишком частое их возникновение замедляет работу. Рекомендуется ставить коллег в известность о начале работ с общими бинарными файлами, а также чаще проводить синхронизацию. Необходимо эффективно распределять работу между участниками разработки, чтобы таких общих файлов было как можно меньше. Этого можно добиться, в частности, подключением всех ресурсов сцены (linking) из отдельных blend-файлов в один мастер-файл.

Порядок действий¶

Не рекомендуется производить какие-либо действия с файлами (изменять, удалять), пока репозиторий находится в конфликтном состоянии.

Первое что необходимо сделать — выполнить команду git status .

Список конфликтующих файлов отображен в разделе Unmerged paths .

Дальнейший порядок действий различен для бинарных и текстовых файлов.

Бинарные файлы¶

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

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

Выбрать локальную версию файла (— -ours). Его можно открыть и убедиться в этом.

Выбрать удаленную версию файла (— -theirs). Его можно открыть и убедиться в этом.

Снова выбрать локальную версию файла (— -ours).

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

Текстовые файлы¶

На данном этапе в конфликтующие текстовые файлы Git’ом вносятся как локальные, так и удаленные изменения одновременно, в особом формате. Такие текстовые файлы как правило, не работоспособны.

Пример. Один участник разработки изменил имя сцены с “Blue Lizard” на “Green Lizard” в файле приложения и загрузил изменения в центральный репозиторий. Другой участник разработки изменил в той же строке “Blue Lizard” на “Red Lizard”, совершил коммит и выполнил команду git pull . В результате именно на этого участника ложится ответственность по разрешению конфликта. В его файле приложения будут находиться строки:

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

Корректирующий коммит¶

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

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

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


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

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

Просмотреть список тэгов:

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

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

Доброго дня всем!

В Сети много ссылок на настройку GIT, как локально, так и с онлайн-хранилищами. Но я нигде не нашёл рекомендаций по правильной организации такого хранилища. Итак, имеем небольшую (3-5 человек) команду разработчиков (на C++/Qt). На компьютерах настроена переменная окружения (например, prog_root), внутри которой есть:

  1. Папки разработчиков (bill,bob,john), внутри которых каждый разработчик хранит свои программы (папка разработчика является корневой для проектов Qt Creator).
  2. Папка include, в которой хранятся заголовочные файлы (и .cpp) для совместно используемых программных модулей. Внутри неё тоже есть папки (common, math, exceptions etc.), в которых хранятся , относящиеся к соответствующей предметной области.
  3. Папка lib, в которую складываются сгенерированные статические библиотеки.
  4. Папка build, в которой генерятся исполняемые файлы.
  5. Папка doc, в которой хранится документация
  6. Прочее.

Каждый разработчик пишет как отдельные программы (обменивающиеся информацией по TCP/IP, через разделяемую память, через перенаправление потоков ввода-вывода или ещё как), так и библиотеки, используемые другими программистами. Исходники библиотек хранятся в include и могут включаться в несколько проектов сразу.

В настоящее время обмен свежими версиями происходит так: выпустив важное изменение и отладив на своей машине, разработчик говорит остальным: «заберите у меня такой-то файл», те забирают и копируют на свои машины. Иногда, когда отладка возможна только на специфических данных или оборудовании, доступных только на объекте, разработчик едет на объект, отлаживается и привозит обратно отлаженную версию, которую раскидывает себе и предлагает забрать другим разработчикам. Синхронизация версий, например, на рабочем компе и на ноутбуке (поработать на дому) осуществляется собственными силами, нецентрализованно. Разработка кросплатформенная, поэтому у некоторых разработчиков есть копии prog_root под Windows, Linux и QNX.

Соответственно, есть желание настроить GIT для того, чтобы свести «размазанную по компьютерам разработчиков» актуальную версию в единое хранилище. Что включать в проект GIT? Если делать по отдельному проекту на программу, библиотеки будут дублироваться, и при переключении на другой проект можно «засосать» устаревшую версию, выложенную при очередном коммите другим разработчиком. Если по проекту GIT на смысловую единицу, то в одну программу будет входить несколько GIT-проектов. Это правильно? Или надо вообще объединить всё в единой единице GIT?

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

Простое руководство по работе с git

Руководство по работе с git

Установка

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

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

git init

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

Создать локальную рабочую копию репозитория можно командой

git clone /путь/к/репозиторию

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

git clone юзер@хост:/путь/к/репозиторию

Рабочий процесс

Ваш локальный git репозиторий состоит из трех «сущностей». Рабочий каталог (Working Directory) содержит файлы. Индекс (Index) или область подготовленных файлов (Staging Area), содержит информацию о том, что должно войти в следующий коммит и HEAD указывает на последний коммит что вы сделали.

Подготовка и коммит

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

git add
git add *

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

git commit -m «Описание коммита»

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

Отправка изменений

Чтобы отправить эти изменения в ваш удаленный репозиторий, выполните

git push origin master

Можно изменить master на любую другую ветвь, чтобы отправить изменения на неё.

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

git remote add origin

Теперь вы можете отправлять изменения на удаленный репозиторий

Ветвление

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

Создать новую ветку с названием «feature_x» и переключиться на неё можно командой
git checkout -b feature_x
переключиться обратно на master
git checkout master
удалить ветку
git branch -d feature_x
ветка не будет доступна тем, кто пользуется с вами удаленным репозиторием, пока вы не отправите её туда
git push origin

Обновление и слияние

Обновить ваш локальный репозиторий можно командой
git pull
которая заберет изменения из удаленного репозитория и проведет слияние с активной веткой.
Для того чтобы слить другую ветку с активной (например master), используйте команду
git merge
В обоих случаях git пытается автоматически слить изменения. К сожалению, это не всегда возможно и результатом станет конфликт. Вы ответственны за разрешение возникших конфликтов, путем ручного редактирования файлов, указанных git. После изменений вам надо пометить их как слитые
git add
перед слиянием вы можете предварительно посмотреть на изменения
git diff

Метки

Рекомендуется использовать метки для закрепления момента выпуска версий. Это популярная практика, которая также используется в SVN. Создать новую метку с именем 1.0.0 можно, выполнив
git tag 1.0.0 1b2e1d63ff
1b2e1d63ff это первые десять цифр уникального идентификатора (id), с которым будет связана метка. Чтобы посмотреть идентификаторы коммитов, выполните
git log
Можно использовать меньшее количество символов в качестве идентификатора, с учетом того, что он является уникальным.

Замена локальных изменений

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

Если же вы хотите удалить все ваши локальные изменения и коммиты, получите (fetch) последние изменения с сервера и укажите локальной ветке master на них вот так
git fetch origin
git reset —hard origin/master

Основные GIT Команды

Введение

Когда дело доходит до систем контроля версий, очень немногие могут затмить GIT в актуальности, производительности и распространенности. GIT был разработан Линусом Торвальдсом в 2005 году, и сегодня, миллионы компаний используют его для эффективного управления кодом и контроля над версиями своих проектов. Программное обеспечение с открытым исходным кодом может быть загружено для различных платформ, таких как Linux, Windows, Solaris и Mac; больше информации об основах GIT можно получить здесь. В этом руководстве вы узнаете основные GIT команды.

Что вам понадобится

Перед тем, как вы начнете это руководство, вам понадобится следующее:

  • GIT установленный на вашей системе

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

  • git config

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

Эта команда используется для создания GIT репозитория. Пример использования:

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

Команда git clone используется для клонирования репозитория. Если репозиторий находится на удаленном сервере, используется команда такого рода:

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

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

Команда git status отображает список измененных файлов, вместе с файлами, которые еще не были добавлены в индекс или ожидают коммита. Применение:

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

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

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

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

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

Команда git branch может быть использована для отображения, создания или удаления веток. Для отображения всех существующих веток в репозитории введите:

Для удаления ветки:

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

Команда git merge используется для объединения ветки в активную ветвь. Применение:

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

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

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

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

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

Команда git reset используется для сброса индекса и рабочего каталога до последнего состояния коммита. Применение:

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

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

Для просмотра информации о любом git объекте используйте команду git show. Для примера:

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

Команда git ls-tree используется для просмотра дерева объекта вместе с названием, режимом каждого предмета и значением SHA-1. К примеру:

Используйте команду git cat-file, чтобы просмотреть тип объекта с помощью SHA-1 значения. Например:

git grep позволяет пользователю проводить поиск фраз и слов в содержимом деревьев. К примеру, для поиска www.hostinger.ru во всех файлах используйте эту команду:

gitk – это графический интерфейс локального репозитория. Вызвать его можно выполнив данную команду:

С помощью команды git instaweb можно запустить веб-сервер, связанный с локальным репозиторием. Браузер также автоматически будет перенаправляться на него. Например:

Для оптимизации репозитория используйте команду git gc. Она поможет удалить и оптимизировать ненужные файлы:

Мастер Йода рекомендует:  Подписываюсь подборка интересных образовательных каналов в Telegram


Команда git archive позволяет пользователю создать .zip или .tar файл содержащий компоненты одного из деревьев репозитория. Например:

С помощью команды git prune удаляются объекты, не имеющие никаких входящих указателей. Применение:

Чтобы выполнить проверку целостности файловой системы git, используйте команду git fsck, при этом будут идентифицированы все поврежденные объекты:

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

Заключение

В данном руководстве вы узнали основные GIT команды и познакомились с примерами их использования. Обязательно посетите наше руководство об основах 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 — инструкция по работе. Команды. Совместная работа.

      Что такое коммит?

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

      Как видно из иллюстрации, проект может разветвляться, например если два разработчика параллельно работают и каждый создаёт свои коммиты. Чтобы не возникало полного хаоса и можно было ориентироваться в происходящем вводят понятие ветки
      Ветка — по большому счёту просто именованная ссылка на некий коммит, указывающая на конец очередного ответвления от главной центральной ветки (по умолчанию она зовётся master). Как правило, репозиторий работает в привязке к какой-то ветке и при создании нового коммита, он присоединяется к тому, на который ссылается ветка, и ветка начинает указывать на новый коммит. На картинке выше помимо master есть ветки Little Feature и Big Feature.

      Установка

      Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.

      Настройка

      git config —global user.name «My Name»
      git config —global user.email myEmail@example.com

      Репозиторий

      git clone username@host:/path/to/repository

      git clone —branch=branch-name https://whatever.git

      git clone —depth=1 —branch=branch-name https://whatever.git

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

      Ветвление

      Обязательно нужно делать пуш изменений в общий репозиторий:

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

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

      git pull [ветка] — например origin master

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

      Ветки можно сравнить:

      git tag [tag] [первые_десять_символов_соответствующего_коммита]

      git fetch origin git reset —hard origin/master

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

      git merge 1_branch
      Auto-merging print_array.js
      CONFLICT (content): Merge conflict in print_array.js
      Automatic merge failed; fix conflicts and then commit the result.

      git add -A
      git commit -m «Array printing conflict resolved.»

      Короткая и простая история коммитов.

      git checkout -b iss53

      Создание новой ветки / указателя.

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

      Ветка iss53 передвинулась вперёд во время работы.

      Создание хот-фикса:
      git checkout master
      git checkout -b hotfix

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

      Слияние веток:
      git checkout master
      git merge hotfix
      git merge iss53

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

      Настройка .gitignore

      *.log
      build/
      node_modules/
      .idea/
      my_notes.txt

      Удачная модель ветвления для Git

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

      • master — создаётся при инициализации репозитория, считаем ветку origin/master главной.
      • develop — ветвь origin/develop мы считаем главной ветвью для разработки.

      Вспомогательные ветви

      • Ветви функциональностей (Feature branches)
      • Ветви релизов (Release branches)
      • Ветви исправлений (Hotfix branches)

      Ветви функциональностей (feature branches)Могут порождаться от: develop
      Должны вливаться в: develop
      Соглашение о наименовании: всё, за исключением master, develop, release-* или hotfix-*

      При начале работы над новой функциональностью делается ответвление от ветви разработки (develop).

      git checkout -b myfeature develop

      Ветви релизов (release branches)
      Могут порождаться от: develop
      Должны вливаться в: develop и master
      Соглашение о наименовании: release-*

      Ветвь релиза создаётся из ветви разработки (develop).
      Закрытие ветви релиза
      Когда мы решаем, что ветвь релиза (release branch) окончательно готова для выпуска, нужно проделать несколько действий. В первую очередь ветвь релиза вливается в главную ветвь (напоминаю, каждый коммит в master — это по определению новый релиз). Далее, этот коммит в master должен быть помечен тегом, чтобы в дальнейшем можно было легко обратиться к любой существовавшей версии продукта. И наконец, изменения, сделанные в ветви релиза (release branch), должны быть добавлены обратно в разработку (ветвь develop), чтобы будущие релизы также содержали внесённые исправления багов.

      Switched to branch ‘master’
      git merge —no-ff release-1.2
      Merge made by recursive.
      (Отчёт об изменениях)

      git tag -a 1.2

      Теперь релиз издан и помечен тегом.

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

      Switched to branch ‘develop’

      git merge —no-ff release-1.2

      Merge made by recursive.
      (Отчёт об изменениях)

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


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

      Deleted branch release-1.2 (was ff452fe).

      Ветви исправлений (hotfix branches)
      Могут порождаться от: master
      Должны вливаться в: develop и master
      Соглашение о наименовании: hotfix-*

      Ветви исправлений (hotfix branches) создаются из главной (master) ветви.

      Заключение

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

      Краткая справка команд:

      git pull — обновить данные из серверного репозитория
      git add — добавить в список «на коммит»
      git commit — создание пакета (коммита) с изменениями
      git push — залить за серверный (удалённый) репозиторий
      git merge BRANCH — слияние ветки в который ты находишься, с веткой BRANCH

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

      Ответ:
      Ты делаешь комит и когда пытается сделать пуш, гит говорит, что надо сначала стянуть изменения. Когда стягиваешь изменения, они автоматом мержатся со своими изменениями и потом уже можешь сделать свой пуш.
      Если правите разные файлы или разные строчки в одном и том же файле, то гит смержит изменения автоматически.

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

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

      твои_изменения
      ==========

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

      Потом сделать:
      git add .
      git commit
      (в комите можно написать комментарий типа «фикс конфликтов»)
      git push

      После этого ваши изменения будут залиты.

      Комментарии:

      Отправитель: anonymous git reset —hard HEAD — сброс незакоммиченных изменений

      Основные GIT Команды

      Введение

      Когда дело доходит до систем контроля версий, очень немногие могут затмить GIT в актуальности, производительности и распространенности. GIT был разработан Линусом Торвальдсом в 2005 году, и сегодня, миллионы компаний используют его для эффективного управления кодом и контроля над версиями своих проектов. Программное обеспечение с открытым исходным кодом может быть загружено для различных платформ, таких как Linux, Windows, Solaris и Mac; больше информации об основах GIT можно получить здесь. В этом руководстве вы узнаете основные GIT команды.

      Что вам понадобится

      Перед тем, как вы начнете это руководство, вам понадобится следующее:

      • GIT установленный на вашей системе

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

      • git config

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

      Эта команда используется для создания GIT репозитория. Пример использования:

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

      Команда git clone используется для клонирования репозитория. Если репозиторий находится на удаленном сервере, используется команда такого рода:

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

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

      Команда git status отображает список измененных файлов, вместе с файлами, которые еще не были добавлены в индекс или ожидают коммита. Применение:

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

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

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

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

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

      Команда git branch может быть использована для отображения, создания или удаления веток. Для отображения всех существующих веток в репозитории введите:

      Для удаления ветки:

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

      Команда git merge используется для объединения ветки в активную ветвь. Применение:

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

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

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

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

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

      Команда git reset используется для сброса индекса и рабочего каталога до последнего состояния коммита. Применение:

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

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

      Для просмотра информации о любом git объекте используйте команду git show. Для примера:

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

      Команда git ls-tree используется для просмотра дерева объекта вместе с названием, режимом каждого предмета и значением SHA-1. К примеру:

      Используйте команду git cat-file, чтобы просмотреть тип объекта с помощью SHA-1 значения. Например:

      git grep позволяет пользователю проводить поиск фраз и слов в содержимом деревьев. К примеру, для поиска www.hostinger.ru во всех файлах используйте эту команду:

      gitk – это графический интерфейс локального репозитория. Вызвать его можно выполнив данную команду:

      С помощью команды git instaweb можно запустить веб-сервер, связанный с локальным репозиторием. Браузер также автоматически будет перенаправляться на него. Например:

      Для оптимизации репозитория используйте команду git gc. Она поможет удалить и оптимизировать ненужные файлы:

      Команда git archive позволяет пользователю создать .zip или .tar файл содержащий компоненты одного из деревьев репозитория. Например:

      С помощью команды git prune удаляются объекты, не имеющие никаких входящих указателей. Применение:

      Чтобы выполнить проверку целостности файловой системы git, используйте команду git fsck, при этом будут идентифицированы все поврежденные объекты:

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

      Заключение

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

      Простое руководство по работе с git

      Руководство по работе с git

      Установка

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

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

      git init

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

      Создать локальную рабочую копию репозитория можно командой

      git clone /путь/к/репозиторию

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

      git clone юзер@хост:/путь/к/репозиторию

      Рабочий процесс

      Ваш локальный git репозиторий состоит из трех «сущностей». Рабочий каталог (Working Directory) содержит файлы. Индекс (Index) или область подготовленных файлов (Staging Area), содержит информацию о том, что должно войти в следующий коммит и HEAD указывает на последний коммит что вы сделали.

      Подготовка и коммит

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

      git add
      git add *

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

      git commit -m «Описание коммита»

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

      Отправка изменений

      Чтобы отправить эти изменения в ваш удаленный репозиторий, выполните

      git push origin master

      Можно изменить master на любую другую ветвь, чтобы отправить изменения на неё.

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

      git remote add origin

      Теперь вы можете отправлять изменения на удаленный репозиторий

      Ветвление

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

      Создать новую ветку с названием «feature_x» и переключиться на неё можно командой
      git checkout -b feature_x
      переключиться обратно на master
      git checkout master
      удалить ветку
      git branch -d feature_x
      ветка не будет доступна тем, кто пользуется с вами удаленным репозиторием, пока вы не отправите её туда
      git push origin

      Обновление и слияние

      Обновить ваш локальный репозиторий можно командой
      git pull
      которая заберет изменения из удаленного репозитория и проведет слияние с активной веткой.
      Для того чтобы слить другую ветку с активной (например master), используйте команду
      git merge
      В обоих случаях git пытается автоматически слить изменения. К сожалению, это не всегда возможно и результатом станет конфликт. Вы ответственны за разрешение возникших конфликтов, путем ручного редактирования файлов, указанных git. После изменений вам надо пометить их как слитые
      git add
      перед слиянием вы можете предварительно посмотреть на изменения
      git diff

      Метки

      Рекомендуется использовать метки для закрепления момента выпуска версий. Это популярная практика, которая также используется в SVN. Создать новую метку с именем 1.0.0 можно, выполнив
      git tag 1.0.0 1b2e1d63ff
      1b2e1d63ff это первые десять цифр уникального идентификатора (id), с которым будет связана метка. Чтобы посмотреть идентификаторы коммитов, выполните
      git log
      Можно использовать меньшее количество символов в качестве идентификатора, с учетом того, что он является уникальным.

      Замена локальных изменений

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

      Если же вы хотите удалить все ваши локальные изменения и коммиты, получите (fetch) последние изменения с сервера и укажите локальной ветке master на них вот так
      git fetch origin
      git reset —hard origin/master

      Мастер Йода рекомендует:  Президент РФ предлагает направить инвестиции в Рунет.
  • Добавить комментарий