Гайды по работе с Git


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

Как пользоваться GIT – разбираемся за 30 минут

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

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

Основы основ работы с GIT

GIT — это определённый набор утилит командной строки, отслеживающих и записывающих изменения в файлах. При помощи его, возможно, восстанавливать предыдущие версии ваших программ, сравнивать, анализировать, совмещать изменения и многое другое. Такой процесс принято называть контроль версий. На сегодняшний день есть много систем контроля версий, выполняющих такую же работу. Вы могли уже слышать ранее о некоторых из них – SVN, Mercurial, Perforce, CVS, Bitkeeper.

GIT децентрализован, что означает его независимость от центрального сервера для сохранения старых версий ваших файлов. Он работает полностью локально, сохраняя данные в виде папки на вашем жестком диске, которая называется репозиторием. Но вы можете хранить копию репозитория так же и в «облаке» для взаимодействия между несколькими людьми, работающих над одним кодом. Как раз для таких целей используют GitHub и BitBucket .

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

Установить GIT на ваш компьютер несложно:

  • Linux – просто откройте терминал и установите GIT через менеджер пакетов вашего дистрибутива. Команда для Ubuntu: sudo apt-get install git ;
  • Windows – можно воспользоваться установщиком на официально сайте или более лучший вариант GIT для Windows , так как он включает и графический клиент (GUI client), и эмулятор командной строки BASH;
  • OS X – легче всего воспользоваться homebrew и ввести команду brew install git в вашем терминале.

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

2. Первоначальная настройка GIT

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

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

3. Создание нового репозитория – git init

Как упоминалось ранее, GIT хранит свои файлы и историю непосредственно как папка в вашем проекте. Чтобы создать новый репозиторий, откройте терминал, укажите адрес директории проекта и введите команду git init . Тем самым вы позволите GIT создать скрытый директорий .git для этой конкретной папки, в котором будут храниться история и конфигурация.

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

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

Это означает, что репозиторий успешно создан, но всё ещё пуст. А теперь создайте простой текстовый файл hello.txt и сохраните в папку git_exersice.

4. Проверка статуса – git status

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

Полученное сообщение показывает, что файл hello.txt не отслеживается. Это означает, что файл новый, и GIT ещё не знает, должен ли отслеживать вносимые в него изменения или же игнорировать. Для подтверждения файла следует его добавить в индекс.

5. Индексирование – git add

У GIT есть понятие «области индексирования». Его можно представить себе, как пустой холст для хранения изменений, которые вы хотели бы зафиксировать. Изначально область появляется пустой, но вы можете добавлять к ней файлы (или даже отдельные строки и части файлов) с помощью команды git add и, наконец, всё сохранить (создать своеобразный «скриншот») с помощью git commit .

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

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

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

Файл готов для сохранения (создания коммита)! Это сообщение о статусе также говорит нам, что было изменено в отношении файлов в области индексирования, в данном случае о появлении нового файла (new file), но файл может показываться как modified или deleted, в зависимости от действий с ним с момента прошлой команды git add .

6. Сохранение изменений – git commit

Зафиксированные изменения показывают состояние репозитория в определённый момент времени. Как скриншот, с помощью которого мы просматриваем состояние вещей в прошлом.

Для создания новой сохранённой версии файлов нам нужно добавить как минимум одно изменение в область индексирования (мы только что это сделали с git add ) и ввести следующую команду:

Эта команда создаст новый «скриншот» со всеми сделанными изменениями (включая hello.txt). Часть -m «Initial commmit» – это краткий комментарий, написанный пользователем, к данной версии файлов. Хорошая привычка – регулярно фиксировать и всегда писать внятный комментарий.

Удалённые репозитории и GIT

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

1. Подключение к удалённому репозиторию – git remote add

Для того чтобы загрузить что-то в удалённый репозиторий, для начала нам нужно установить соединение с ним. Для этого урока наш адрес репозитория будет https://github.com/tutorialzine/awesome-project. Конечно лучше самому создать собственный пустой репозиторий на GitHub , BitBucket или другом сервисе. Регистрация и установка могут занять время, но все сервисы предлагают пошаговые инструкции в помощь вам.

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

Один проект может иметь несколько удалённых репозиториев одновременно. Для их разделения нужно дать им разные имена. Традиционно основной удалённый GIT-репозиторий называют origin.

2. Загрузка на сервер – git push

Настало время для перемещения наших локальных GIT-записей на сервер. Этот процесс называется push, и он выполняется каждый раз, когда мы хотим обновить удалённый репозиторий.

Команда GIT для push, git push , имеет два параметра – имя удалённого репозитория (мы назвали наш origin) и ветка для отправки (ветка по умолчанию для каждого удалённого репозитория – master).

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

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

После клонирования другие люди смогут увидеть и изучить ваш удалённый репозиторий на GitHub. Также будет возможно загрузить его локально и иметь полную рабочую копию вашего проекта с командой git clone :

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

4. Получение изменений с сервера – git pull

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

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

Ветви в GIT

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

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

1. Создание новых ветвей – git branch

Ветвь по умолчанию для каждого репозитория называется master. Для создания другой используйте команду git branch .

Тем самым вы создаёте новую ветвь, на данном этапе одинаковую с master.

2. Смена ветвей – git checkout

Теперь, когда мы выполнили команду git branch , мы получили доступ к двум опциям:

Master – текущая ветвь и помечена звёздочкой. Однако мы хотим работать над новыми замечательными версиями программы, поэтому нам нужно переключиться на другую ветвь. Это делается командой git checkout с указанием одного параметра – ветвь для переключения.

3. Объединение ветвей – git merge

Наша «новая версия» будет просто другим текстовым файлом под названием feature.txt. Мы создадим его, добавим и зафиксируем.

Далее мы вернемся в ветвь master.

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

Ветвь master обновлена, а ветвь awesome_new_feature branch больше не нужна и мы можем её удалить.

Продвинутый уровень GIT, ещё больше полезных команд

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

1. Просмотр отличий между сохранёнными версиями

Каждая зафиксированная версия программы имеет уникальный идентификационный номер в формате строки из чисел и символов. Для просмотра списка коммитов (сохранённых версий) с их идефикаторами мы можем использовать команду git log :

Как видите, >git show [commit] :

Просмотреть отличия двух любых коммитов можно с помощью команды git diff с указанием на требуемые версии: [commit-from]..[commit-to].

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

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

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

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

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

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

Для корректировок потруднее, которые должны быть не в последней версии (или вы уже успели отправить свои изменения на сервер), используйте команду git revert . Она отменит все изменения в этой фиксации и создаст новую, которая будет полностью противоположна исходной.

Ей может быть присвоено имя HEAD.

В подобных случаях лучше всего использовать id-номер.

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

4. Разрешение конфликтов объединения

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

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

Джон использует цикл for:

Тим же предпочёл forEach:

Они оба фиксируют свой код на собственных ветвях. Теперь, если они попытаются объединить эти две ветви, то увидят следующее сообщение об ошибке:

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

Выше черты из знаков «равно» мы видим текущую фиксацию HEAD и ниже -конфликтующую. Таким образом, мы можем четко видеть различия и решить, какая версия лучше, или же вовсе написать новую. В данной ситуации мы пойдём до последнего и перепишем все это, удаляя маркеры, чтобы GIT знал, что мы закончили.

Как только всё будет отлажено, должна появиться объединённая фиксация.

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

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

Во многих проектах присутствуют файлы или папки, которые мы не хотим фиксировать. Мы можем «железно» заблокировать их включение в наш git add –A созданием файла .gitignore:

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

Хорошие примеры игнорируемых файлов:

  • лог-файлы;
  • сборщик задач;
  • папка node_modules в проектах node.js;
  • папки, созданные такими IDE (интегрированные среды разработки), как Netbeans и IntelliJ;
  • личные примечания разработчика.

Файл .gitignore блокирует всё вышеуказанное примерно подобным образом:

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

Заключение

Наш урок на тему того, как пользоваться GIT, подходит к концу. Мы старались преподнести вам лишь самую важную информацию так коротко и чётко, как это возможно.

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

  • Официальная документация GIT, включая полную книгу и видеоуроки ;
  • Получение прав GIT– коллекция уроков и статей Atlassian ;
  • Список графических клиентов ;
  • Памятка о GIT (PDF) ;
  • Создать .gitignore файл онлайн .

Гайды по работе с Git

/Maks/android-kernel-zzz
git init — инициализируем репозиторий
git add . — помечаем для выгрузки все файлы в

/Maks/android-kernel-zzz
git commit -m «first commit» — коммитим изменения, вместо first commit можно написать, что угодно.
git remote add origin https://github.com/твой_ник/имя_репозитория.git
git push -u origin master — после ввода команды попросит пароль.

Тема в стадии развития!

Сообщение отредактировал AndrewP_1 — 29.04.19, 12:01

Предложу альтернативу. :wink_kind:

Создаём новый пустой репозиторий с помощью командной строки:

Интеграция чужих наработок в свой репозиторий

  • git remote add name [url репозитория]
  • git fetch name
  • git cherry-pick [id коммита]

Где name это условное имя ветки (может быть каким угодно)

  • Git или Гит — система контроля и управления версиями файлов.
  • GitHub или Гитхаб — веб-сервис для размещения репозиториев и совместной разработки проектов.
  • Репозиторий Git — каталог файловой системы, в котором находятся: файлы конфигурации, файлы журналов операций, выполняемых над репозиторием, индекс расположения файлов и хранилище, содержащее сами контролируемые файлы.
  • Локальный репозиторий — репозиторий, расположенный на локальном компьютере разработчика в каталоге. Именно в нём происходит разработка и фиксация изменений, которые отправляются на удалённый репозиторий.
  • Удалённый репозиторий — репозиторий, находящийся на удалённом сервере. Это общий репозиторий, в который приходят все изменения и из которого забираются все обновления.
  • Форк (Fork) — копия репозитория. Его также можно рассматривать как внешнюю ветку для текущего репозитория. Копия вашего открытого репозитория на Гитхабе может быть сделана любым пользователем, после чего он может прислать изменения в ваш репозиторий через пулреквест.
  • Обновиться из апстрима — обновить свою локальную версию форка до последней версии основного репозитория, от которого сделан форк.
  • Обновиться из ориджина — обновить свою локальную версию репозитория до последней удалённой версии этого репозитория.
  • Клонирование (Clone) — скачивание репозитория с удалённого сервера на локальный компьютер в определённый каталог для дальнейшей работы с этим каталогом как с репозиторием.
  • Ветка (Branch) — это параллельная версия репозитория. Она включена в этот репозиторий, но не влияет на главную версию, тем самым позволяя свободно работать в параллельной. Когда вы внесли нужные изменения, то вы можете объединить их с главной версией.
  • Мастер (Master) — главная или основная ветка репозитория.
  • Коммит (Commit) — фиксация изменений или запись изменений в репозиторий. Коммит происходит на локальной машине.
  • Пул (Pull) — получение последних изменений с удалённого сервера репозитория.
  • Пуш (Push) — отправка всех неотправленных коммитов на удалённый сервер репозитория.
  • Пулреквест (Pull Request) — запрос на слияние форка репозитория с основным репозиторием. Пулреквест может быть принят или отклонён вами, как владельцем репозитория.
  • Мёрдж (Merge) — слияние изменений из какой-либо ветки репозитория с любой веткой этого же репозитория. Чаще всего слияние изменений из ветки репозитория с основной веткой репозитория.
  • Кодревью — процесс проверки кода на соответствие определённым требованиям, задачам и внешнему виду.

Введение в GitHub: как начать пользоваться?

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

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

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

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

Наверное, все когда-нибудь сохраняли 2 версии файла с небольшими отличиями под разными именами? К примеру, научка-вер1.txt и научка-вер1-проверил_Пушкин.txt. Первый файл вы отправили своему научному руководителю, он его проверил, внёс свои изменения и отравил вам второй файл. Такое может повторять вплоть до бесконечности, плодя множество файлов, названия которых ставятся все более и более странными. А ваша папка с версиями с «научкой» становится похожа на что-то дикое и сложное в понимании, и найти промежуточную версию становится очень и очень сложно.

Такой способ совершенно не приемлем* в мире разработки, особенно, если над проектом трудится много человек одновременно. И вот почему:

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

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

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

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

Цель такой системы — поддержание актуальной версии проекта у всех ее пользователей.

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

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

Централизованная.

  1. Существует только один репозиторий.
  2. Простые номера версий файлов (1, 2, 3 и т.д.).
  3. У пользователей хранится только текущая версия проекта.
  4. Требуется подключение к интернету.
  5. Просто, но медленно.
  6. Сложности в одновременной работе над одним файлом.

Распределенная.

На один проект приходится много репозиториев.

  1. Каждый пользователь создает локальную копию всего репозитория на основе главного облачного.
  2. Номера версий сложные.
  3. Возможность работать офлайн.
  4. Работать быстро и удобно.
  5. Требуется синхронизация репозиториев, так как проект — один.

Теперь можно дать определение и слову Git.

Git — это инструмент для реализации работы распределённой системы контроля версий.

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

Как работает GitHub

Для работы с GitHub нам потребуется установить клиент контроля версий (в GitHub, это GitHub Desktop ) и создать репозиторий. Репозиторий можно создать, как через веб-сайт, так и через клиент.

Принципы работы с репозиторием GitHub


  1. С помощью клиента копируем весь репозиторий на свой компьютер (pull).
  2. Вносим различные правки, сохраняем, вносим правки и т.д. в различные файлы репозитория.
  3. Просим клиента внести изменённые файлы в репозиторий.
    Внесение измененных файлов в репозиторий называется фиксацией изменений или «коммитом» (commit).
  4. После коммита версия вашего локального репозитория изменилась.
  5. На данный момент изменения фиксированы только на локальном репозитории, чтобы они отобразились на сайте GitHub, требуется еще одна функция «синхронизация репозиториев» (push).
  6. Теперь ваш главный репозиторий, расположенный в GitHub, такой же, как на вашем компьютере.

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

Слияние, конфликт, разрешение конфликта

Для понимая нужен пример. Влад и Артем сделали копию репозитория (pull) с фалом версии 1 с GitHub, внесли разные изменения в этот файл, оба зафиксировали изменения (commit) → версии фала в локальных репозиториев изменились, у Влада версия 2, у Артем 2А. И затем Влад запушил (синхронизировал репозитории- push). Теперь на GitHub добавилась версия файла 2. Артем тоже решил запушить свои изменения, т. к. на GitHub есть версия которой нет у Артема (у него нет версии 2), система откажется принимать его репозиторий для сохранения версии 2.

Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (pull) с GitHub с дополнительной версией этого файла. При копировании произойдет конфликт.

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

Способы решения конфликта:

  1. Автоматическое слияние. Сравнивая построчно код Влада и Артема, GitHub может решить совместить куски кода в файле, при этой получится новая версия файла. При таком подходе в репозитории будут находиться версии 1, 2, 2А, и 3, а Артем теперь может запушить все отсутствующие версии файла.
  2. Разрешение конфликта вручную. Git пометит, какой код конфликтует, и вам нужно будет решить, какой вариант оставить или вообще внести третий. Создается версия 3, и Артем может запушить отсутствующие версии файла.

Master / не master, Fork, Pull request

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

Пример модели работы с ветками:

В Master лежит последняя стабильная версия, где вы можете вносить незначительные изменения; development — ветка для непосредственной разработки; dev-adaptive — ветка разработки, связанная с планируемым расширением функционала.

Что такое Fork? К примеру, на GitHub вам понравился какой-то проект, но вы заметили в нем ошибку и знаете, как ее решить, но доступа к редактированию чужого проекта у вас нет. Для этого вам нужно создать fokr. Теперь у вас есть доступ для редактирования файлов проекта. Вы справились с багом, но ваши труду пропадут даром т. к. изменения не отобразится в master ветке проекта. Чтобы такого не произошло и создан Pull request.

Pull request — это обращение к владельцам проекта с предложением внести в главную ветку ваши изменения.

На этом небольшое введение походит к концу. Не мучайтесь с допотопной системой версий, переходите на GitHub. Спасибо за внимание.

Начинаем работу github

Сразу скажу, что эта «статья» больше для новичков чем для старожил и я буду рад если дадут дельный совет.

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

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

Нам нужно установить git. Мануал курить отсюда

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

Потом необходимо создать репозиторий

После успешного создания репозитория вам выдадут адрес репозитория. Сохраните его.

Учтите что мы создали пустой репозиторий без файлов.

Далее заходите в терминал (*nix системы) или в коммандную строку Windows.

Переходите в директорию где бы вы хотели клонировать наш репозиторий к себе локально.

А потом выполняйте команду

и создайте там пустой файл. Мы создадим файл README.md — это файл описания нашего проекта

И добавим его в отслеживание git`ом введя команду в терминале

Теперь этот файл у нас будет отслеживатся git`ом и его изменения будут фиксироваться с помощью git`a

Далее нам нужно наш локальный репозиторий «подружить» с нашим удаленным.

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

Адрес репозитория, само собой, меняйте на свой.

Мастер Йода рекомендует:  Вложенные комментарии в WordPress

Что-бы удостовериться что вы правильно «соединили» локальный репозиторий с удаленным введите команду

Теперь нам нужно закоммитить (проще говоря — зафиксировать) наши изменения (добавление файла README.md в репозиторий).

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

У вас должно запросить логин и пароль к github как на скрине выше (при вводе пароля будет казаться что вы ничего не вводите — но это всё вранье)

Теперь давайте перейдем в наш репозиторий через браузер и посмотрим — есть ли там наш файл

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

Спасибо всем кто заинтерисовался.

Если будет интересно то в следующий раз опишу как сделать так чтобы composer видел ваш githubовский репозиторий.

P. S. Конструктивная критикая, советы приветствуются

Git для начинающих

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

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

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

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

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

Установка Git

На официальном сайте Git есть детальная информация об его установке на Linux, Mac и Windows. В нашем случае, мы будем использовать в целях демонстрации Ubuntu 13.04 , где установим Git с помощью apt-get:

Начальная настройка

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

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

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

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

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

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

Подготовка файлов для коммита

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

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

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

Добавление файлов в Git для отслеживания

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

Добавляем файлы при помощи команды add :

Снова проверив состояние репозитория, мы увидим, что был добавлен один файл:

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

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

Если вы будете использовать команду add рекурсивно, она добавит все такие файлы, если они существуют в вашем репозитории.

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

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

Но выполнение простой команды git rm удалит файл не только из Git , но также и из вашей локальной файловой системы! Чтобы

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

Коммит изменений

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

Вы можете привязывать к каждому коммиту сообщение, которое добавляется при помощи префикса -m :

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

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

Хорошей практикой является использование имени ветки или имени функции в качестве префикса к сообщению коммита. Например, « Управление активами: добавлена функция для генерации PDF файлов активов » — это содержательное сообщение.

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

Обратите внимание, что на скриншоте наш первый коммит определяется кодом 8dd76fc .

Дальнейшие коммиты

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

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

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

Вы можете избежать использования этой команды, воспользовавшись префиксом -a для команды git commit , который добавит все изменения в отслеживаемые файлы.

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

Если вы избирательно размещаете файлы, то заметите изменения в каждом файле. Но если вы добавите префикс -a к вашему коммиту, все файлы будут закоммичены, и вы не сможете выявить возможные ошибки.

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

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

Управление проектом

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

Так будет показана вся история проекта, которая представляет собой список всех коммитов и информации по ним. Информация о коммите включает в себя хеш-код коммита, автора, время и сообщение коммита. Есть различные варианты git log , которые вы можете изучить, как только освоите понятие ветки (англ. branch) в Git .

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

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

Размещение кода в облаке

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

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

Если вы хотите разместить код в облаке, вы можете создать проект на GitHub , GitLab или BitBucket и поместить уже существующий код в репозиторий.

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

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

Заключение

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

Данная публикация представляет собой перевод статьи « Git for Beginners » , подготовленной дружной командой проекта Интернет-технологии.ру

Работа с 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 . Отправляем изменения в форк.

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

      2. Основы работы с Git¶

      Введение¶

      Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

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

      Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

      Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

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

      git clone — создание копии (удаленного) репозитория¶

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

      Клонируем репозиторий, используя протокол http:

      Клонируем репозиторий с той же машины в директорию myrepo :

      Клонируем репозиторий, используя безопасный протокол ssh:

      У git имеется и собственный протокол:

      Импортируем svn репозиторий, используя протокол http:

      -s – понимать стандартные папки SVN (trunk, branches, tags)

      git fetch и git pull — забираем изменения из центрального репозитория¶

      Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

      git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

      git fetch /home/username/project — забрать изменения из определенного репозитория.

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

      git fetch username-project — забрать изменения по адресу, определяемому синонимом.

      Естественно, что после оценки изменений, например, командой git diff , надо создать коммит слияния с основной:

      Команда git pull сразу забирает изменения и проводит слияние с активной веткой.

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

      Забрать изменения и метки из определенного репозитория:

      Как правило, используется сразу команда git pull .

      git push — вносим изменения в удаленный репозиторий¶

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

      Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

      Отправить изменения из ветки master в ветку experimental удаленного репозитория:

      В удаленном репозитории origin удалить ветку experimental:

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

      Отправить метки в удаленную ветку master репозитория origin:

      Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

      Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

      Работа с локальным репозиторием¶

      Базовые команды¶

      git init — создание репозитория

      Команда git init создает в директории пустой репозиторий в виде директории .git , где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

      git add и git rm — индексация изменений

      Следующее, что нужно знать — команда git add . Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры использования:

      индексация измененного файла, либо оповещение о создании нового:

      внести в индекс все изменения, включая новые файлы:

      Из индекса и дерева проекта одновременно файл можно удалить командой git rm :

      хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

      внести в индекс все удаленные файлы:

      Сбросить весь индекс или удалить из него изменения определенного файла можно
      командой git reset :

      сбросить весь индекс:

      удалить из индекса конкретный файл:

      Команда git reset используется не только для сбрасывания индекса, поэтому дальше
      ей будет уделено гораздо больше внимания.

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

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

      Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и
      файлы, игнорируемые git.

      git commit — совершение коммита

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

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

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

      git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

      Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

      «Мягкий» (с ключом —soft ) резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

      1. git commit — некорректный коммит
      2. git reset —soft HEAD^ — переходим к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы
      3. edit WRONGFILE
      4. edit ANOTHERWRONGFILE
      5. git add .
      6. git commit -c ORIG_HEAD — вернуться к последнему коммиту, будет предложено редактировать его сообщение. Если сообщение оставить прежним, то достаточно изменить регистр ключа -с:

      Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

      Естественно, можно вернуться и на большую глубину коммитов,

      «Жесткий» резет (ключ —hard ) — команда, которую следует использовать с
      осторожностью. git reset —hard вернет дерево проекта и индекс в состояние,
      соответствующее указанному коммиту, удалив изменения последующих коммитов:

      Если команда достигнет точки ветвления, удаления коммита не произойдет.

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

      git revert — отмена изменений, произведенных в прошлом отдельным коммитом

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

      Отменяем коммит, помеченный тегом:

      Отменяем коммит, используя его хэш:

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

      git log — разнообразная информация о коммитах в целом

      Иногда требуется получить информацию об истории коммитов; коммитах, изменивших
      отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих
      целей используется команда git log .

      Простейший пример использования, в котором приводится короткая справка по всем
      коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении
      подробно узнать можно ниже, в разделе «Ветвления и слияния»):

      Получить подробную информацию о каждом в виде патчей по файлам из коммитов
      можно, добавив ключ -p (или -u):

      Статистика изменения файлов, вроде числа измененных файлов, внесенных в них
      строк, удаленных файлов вызывается ключом —stat :

      За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
      —summary :

      Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра
      его имя (кстати, в моей старой версии git этот способ не срабатывает,
      обязательно добавлять » — » перед «README»):

      или, если версия git не совсем свежая:

      Далее будет приводится только более современный вариант синтаксиса. Возможно
      указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
      и так далее):

      изменения, касающиеся отдельной папки:

      Можно отталкиваться от тегов.

      Все коммиты, начиная с тега v1:

      Все коммиты, включающие изменения файла README, начиная с тега v1:

      Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

      Интересные возможности по формату вывода команды предоставляет ключ —pretty .

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

      Лаконичная информация о коммитах, приводятся только автор и комментарий:

      Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

      В принципе, формат вывода можно определить самостоятельно:

      Определение формата можно поискать в разделе по git log из Git Community Book
      или справке. Красивый ASCII-граф коммитов выводится с использованием ключа
      —graph .

      git diff — отличия между деревьями проекта, коммитами и т.д.

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

      Показать изменения, не внесенные в индекс:

      Изменения, внесенные в индекс:

      Изменения в проекте по сравнению с последним коммитом:

      Можно сравнивать «головы» веток:

      или активную ветку с какой-либо:

      git show — показать изменения, внесенные отдельным коммитом

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

      git blame и git annotate — команды, помогающие отслеживать изменения файлов

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

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

      Аналогично работает команда git annotate , выводящая и строки, и информацию о
      коммитах, их коснувшихся:

      git grep — поиск слов по проекту, состоянию проекта в прошлом

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

      Поиск слова tst в проекте:

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

      Поиск в старой версии проекта:

      Команда позволяет использовать логическое И и ИЛИ.

      Найти строки, где упоминаются и первое слово, и второе:

      Найти строки, где встречается хотя бы одно из слов:

      Ветвление¶

      git branch — создание, перечисление и удаление веток

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

      Просто перечислить существующие ветки, отметив активную:

      Создать новую ветку new-branch:

      Удалить ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

      Удалить ветку в любом случае:

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

      git checkout — переключение между ветками, извлечение файлов

      Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

      Создаст ветку, в которую и произойдет переключение

      Если в текущей ветке были какие-то изменения по сравнению с последним коммитом в ветке(HEAD), то команда откажется производить переключение, дабы не потерять произведенную работу. Проигнорировать этот факт позволяет ключ -f :

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

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

      Вернуть somefile к состоянию последнего коммита:

      Вернуть somefile к состоянию на два коммита назад по ветке:

      git merge — слияние веток (разрешение возможных конфликтов)

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

      Попробовать объединить текующую ветку и ветку new-feature:

      В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.

      Например, конфликт возник в файле TROUBLE , что можно увидеть в git status .

      Произошла неудачная попытка слияния:

      Смотрим на проблемные места:

      Индексируем наши изменения, тем самым снимая метки:

      Совершаем коммит слияния:

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

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

      git rebase — построение ровной линии коммитов

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

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

      Предположим, имеется две ветки, master и topic, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

      Вариант, в котором явно указывается, что и куда накладывается:

      на master накладывается активная в настоящий момент ветка:

      После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой git rebase —continue . Альтернативными выходами будут команды git rebase —skip (пропустить наложение коммита и перейти к следующему) или git rebase —abort (отмена работы команды и всех внесенных изменений).

      С ключом -i ( —interactive ) команда будет работать в интерактивном режиме. Пользователю будет предоставлена возможность определить порядок внесения изменений, автоматически будет вызывать редактор для разрешения конфликтов и так далее.

      git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

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

      Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:

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

      Прочие команды и необходимые возможности¶

      Хэш — уникальная идентификация объектов

      В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.

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

      найти разницу текущего состояния проекта и коммита за номером… сами видите, каким:

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

      Иногда хватает и четырех символов:

      Читаем лог с коммита по коммит:

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

      git tag — тэги как способ пометить уникальный коммит

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

      Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

      Создать «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

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

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

      После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff , git log и так далее:

      Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

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

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

      Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

      Относительная адресация

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

      Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

      найти изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки:

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

      что привнес «дедушка» нынешнего коммита:

      Обозначения можно объединять, чтобы добраться до нужного коммита:

      файл .gitignore — объясняем git, какие файлы следует игнорировать

      Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status . Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

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

      Пример содержимого такого файла:

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

      Серверные команды репозитория¶

      ; git update-server-info : Команда создает вспомогательные файлы для dumb-сервера в $GIT_DIR/info и $GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки и пакеты есть на сервере.

      ; git count-objects : Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
      ; git gc : Переупаковка локального репозитория.

      Рецепты¶

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

      Импорт svn репозитория на Git-сервер

      2. Основы работы с Git¶

      Введение¶

      Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

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

      Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

      Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

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

      git clone — создание копии (удаленного) репозитория¶

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

      Клонируем репозиторий, используя протокол http:

      Клонируем репозиторий с той же машины в директорию myrepo :

      Клонируем репозиторий, используя безопасный протокол ssh:

      У git имеется и собственный протокол:

      Импортируем svn репозиторий, используя протокол http:

      -s – понимать стандартные папки SVN (trunk, branches, tags)

      git fetch и git pull — забираем изменения из центрального репозитория¶

      Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

      git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

      git fetch /home/username/project — забрать изменения из определенного репозитория.

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

      git fetch username-project — забрать изменения по адресу, определяемому синонимом.

      Естественно, что после оценки изменений, например, командой git diff , надо создать коммит слияния с основной:

      Команда git pull сразу забирает изменения и проводит слияние с активной веткой.

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

      Забрать изменения и метки из определенного репозитория:

      Как правило, используется сразу команда git pull .

      git push — вносим изменения в удаленный репозиторий¶

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

      Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

      Отправить изменения из ветки master в ветку experimental удаленного репозитория:

      В удаленном репозитории origin удалить ветку experimental:

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

      Отправить метки в удаленную ветку master репозитория origin:

      Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

      Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

      Работа с локальным репозиторием¶

      Базовые команды¶

      git init — создание репозитория

      Команда git init создает в директории пустой репозиторий в виде директории .git , где и будет в дальнейшем храниться вся информация об истории коммитов, тегах — о ходе разработки проекта:

      git add и git rm — индексация изменений

      Следующее, что нужно знать — команда git add . Она позволяет внести в индекс — временное хранилище — изменения, которые затем войдут в коммит. Примеры использования:

      индексация измененного файла, либо оповещение о создании нового:

      внести в индекс все изменения, включая новые файлы:

      Из индекса и дерева проекта одновременно файл можно удалить командой git rm :

      хороший пример удаления из документации к git, удаляются сразу все файлы txt из папки:

      внести в индекс все удаленные файлы:

      Сбросить весь индекс или удалить из него изменения определенного файла можно
      командой git reset :

      сбросить весь индекс:

      удалить из индекса конкретный файл:

      Команда git reset используется не только для сбрасывания индекса, поэтому дальше
      ей будет уделено гораздо больше внимания.

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

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

      Кроме того, git status указывает на файлы с неразрешенными конфликтами слияния и
      файлы, игнорируемые git.

      git commit — совершение коммита

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

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

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

      git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»

      Помимо работы с индексом (см. выше), git reset позволяет сбросить состояние проекта до какого-либо коммита в истории. В git данное действие может быть двух видов: «мягкого»(soft reset) и «жесткого» (hard reset).

      «Мягкий» (с ключом —soft ) резет оставит нетронутыми ваши индекс и все дерево файлов и директорий проекта, вернется к работе с указанным коммитом. Иными словами, если вы обнаруживаете ошибку в только что совершенном коммите или комментарии к нему, то легко можно исправить ситуацию:

      1. git commit — некорректный коммит
      2. git reset —soft HEAD^ — переходим к работе над уже совершенным коммитом, сохраняя все состояние проекта и проиндексированные файлы
      3. edit WRONGFILE
      4. edit ANOTHERWRONGFILE
      5. git add .
      6. git commit -c ORIG_HEAD — вернуться к последнему коммиту, будет предложено редактировать его сообщение. Если сообщение оставить прежним, то достаточно изменить регистр ключа -с:

      Обратите внимание на обозначение HEAD^, оно означает «обратиться к предку последнего коммита». Подробней описан синтаксис такой относительной адресации будет ниже, в разделе «Хэши, тэги, относительная адресация». Соответственно, HEAD — ссылка на последний коммит. Ссылка ORIG_HEAD после «мягкого» резета указывает на оригинальный коммит.

      Естественно, можно вернуться и на большую глубину коммитов,

      «Жесткий» резет (ключ —hard ) — команда, которую следует использовать с
      осторожностью. git reset —hard вернет дерево проекта и индекс в состояние,
      соответствующее указанному коммиту, удалив изменения последующих коммитов:

      Если команда достигнет точки ветвления, удаления коммита не произойдет.

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

      git revert — отмена изменений, произведенных в прошлом отдельным коммитом

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

      Отменяем коммит, помеченный тегом:

      Отменяем коммит, используя его хэш:

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

      git log — разнообразная информация о коммитах в целом

      Иногда требуется получить информацию об истории коммитов; коммитах, изменивших
      отдельный файл; коммитах за определенный отрезок времени и так далее. Для этих
      целей используется команда git log .

      Простейший пример использования, в котором приводится короткая справка по всем
      коммитам, коснувшимся активной в настоящий момент ветки (о ветках и ветвлении
      подробно узнать можно ниже, в разделе «Ветвления и слияния»):

      Получить подробную информацию о каждом в виде патчей по файлам из коммитов
      можно, добавив ключ -p (или -u):

      Статистика изменения файлов, вроде числа измененных файлов, внесенных в них
      строк, удаленных файлов вызывается ключом —stat :

      За информацию по созданиям, переименованиям и правам доступа файлов отвечает ключ
      —summary :

      Чтобы просмотреть историю отдельного файла, достаточно указать в виде параметра
      его имя (кстати, в моей старой версии git этот способ не срабатывает,
      обязательно добавлять » — » перед «README»):

      или, если версия git не совсем свежая:

      Далее будет приводится только более современный вариант синтаксиса. Возможно
      указывать время, начиная в определенного момента («weeks», «days», «hours», «s»
      и так далее):

      изменения, касающиеся отдельной папки:

      Можно отталкиваться от тегов.

      Все коммиты, начиная с тега v1:

      Все коммиты, включающие изменения файла README, начиная с тега v1:

      Все коммиты, включающие изменения файла README, начиная с тега v1 и заканчивая тегом v2:

      Интересные возможности по формату вывода команды предоставляет ключ —pretty .

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

      Лаконичная информация о коммитах, приводятся только автор и комментарий:

      Более полная информация о коммитах, с именем автора, комментарием, датой создания и внесения коммита:

      В принципе, формат вывода можно определить самостоятельно:

      Определение формата можно поискать в разделе по git log из Git Community Book
      или справке. Красивый ASCII-граф коммитов выводится с использованием ключа
      —graph .

      git diff — отличия между деревьями проекта, коммитами и т.д.

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

      Показать изменения, не внесенные в индекс:

      Изменения, внесенные в индекс:

      Изменения в проекте по сравнению с последним коммитом:

      Можно сравнивать «головы» веток:

      или активную ветку с какой-либо:

      git show — показать изменения, внесенные отдельным коммитом

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

      git blame и git annotate — команды, помогающие отслеживать изменения файлов

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

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

      Аналогично работает команда git annotate , выводящая и строки, и информацию о
      коммитах, их коснувшихся:

      git grep — поиск слов по проекту, состоянию проекта в прошлом

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

      Поиск слова tst в проекте:

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

      Поиск в старой версии проекта:

      Команда позволяет использовать логическое И и ИЛИ.

      Найти строки, где упоминаются и первое слово, и второе:

      Найти строки, где встречается хотя бы одно из слов:

      Ветвление¶

      git branch — создание, перечисление и удаление веток

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

      Просто перечислить существующие ветки, отметив активную:

      Создать новую ветку new-branch:

      Удалить ветку, если та была залита (merged) с разрешением возможных конфликтов в текущую:

      Удалить ветку в любом случае:

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

      git checkout — переключение между ветками, извлечение файлов

      Команда git checkout позволяет переключаться между последними коммитами (если упрощенно) веток:

      Создаст ветку, в которую и произойдет переключение

      Если в текущей ветке были какие-то изменения по сравнению с последним коммитом в ветке(HEAD), то команда откажется производить переключение, дабы не потерять произведенную работу. Проигнорировать этот факт позволяет ключ -f :

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

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

      Вернуть somefile к состоянию последнего коммита:

      Вернуть somefile к состоянию на два коммита назад по ветке:

      git merge — слияние веток (разрешение возможных конфликтов)

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

      Попробовать объединить текующую ветку и ветку new-feature:

      В случае возникновения конфликтов коммита не происходит, а по проблемным файлам расставляются специальные метки а-ля svn; сами же файлы отмечаются в индексе как «не соединенные» (unmerged). До тех пор пока проблемы не будут решены, коммит совершить будет нельзя.

      Например, конфликт возник в файле TROUBLE , что можно увидеть в git status .

      Произошла неудачная попытка слияния:

      Смотрим на проблемные места:

      Индексируем наши изменения, тем самым снимая метки:

      Совершаем коммит слияния:

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

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

      git rebase — построение ровной линии коммитов

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

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

      Предположим, имеется две ветки, master и topic, в каждой из которых было совершенно несколько коммитов начиная с момента ветвления. Команда git rebase берет коммиты из ветки topic и накладывает их на последний коммит ветки master.

      Вариант, в котором явно указывается, что и куда накладывается:

      на master накладывается активная в настоящий момент ветка:

      После использования команды история становится линейной. При возникновении конфликтов при поочередном накладывании коммитов работа команды будет останавливаться, а в проблемные местах файлов появятся соответствующие метки. После редактирования — разрешения конфликтов — файлы следует внести в индекс командой git add и продолжить наложение следующих коммитов командой git rebase —continue . Альтернативными выходами будут команды git rebase —skip (пропустить наложение коммита и перейти к следующему) или git rebase —abort (отмена работы команды и всех внесенных изменений).

      С ключом -i ( —interactive ) команда будет работать в интерактивном режиме. Пользователю будет предоставлена возможность определить порядок внесения изменений, автоматически будет вызывать редактор для разрешения конфликтов и так далее.

      git cherry-pick — применение к дереву проекта изменений, внесенных отдельным коммитом

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

      Изменения, внесенные указанным коммитом будут применены к дереву, автоматически проиндексированы и станут коммитом в активной ветке:

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

      Прочие команды и необходимые возможности¶

      Хэш — уникальная идентификация объектов

      В git для идентификации любых объектов используется уникальный (то есть с огромной вероятностью уникальный) хэш из 40 символов, который определяется хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты, файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла, то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки в сорок символов.

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

      найти разницу текущего состояния проекта и коммита за номером… сами видите, каким:

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

      Иногда хватает и четырех символов:

      Читаем лог с коммита по коммит:

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

      git tag — тэги как способ пометить уникальный коммит

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

      Кроме этого в git представленные так называемые «легковесные тэги» (lightweight tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило, используются для упрощения навигации по дереву истории; создать их очень легко.

      Создать «легковесный» тэг, связанный с последним коммитом; если тэг уже есть, то еще один создан не будет:

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

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

      После создания тэга его имя можно использовать вместо хэша в любых командах вроде git diff , git log и так далее:

      Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо информации, вроде номера версии и комментария к нему. Иными словами, если в комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

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

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

      Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от команд для «легковесных» тэгов.

      Относительная адресация

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

      Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам коммитов слияния:

      найти изменения по сравнению со вторым предком последнего коммита в master; HEAD здесь — указатель на последний коммит активной ветки:

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

      что привнес «дедушка» нынешнего коммита:

      Обозначения можно объединять, чтобы добраться до нужного коммита:

      файл .gitignore — объясняем git, какие файлы следует игнорировать

      Иногда по директориям проекта встречаются файлы, которые не хочется постоянно видеть в сводке git status . Например, вспомогательные файлы текстовых редакторов, временные файлы и прочий мусор.

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

      Пример содержимого такого файла:

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

      Серверные команды репозитория¶

      ; git update-server-info : Команда создает вспомогательные файлы для dumb-сервера в $GIT_DIR/info и $GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки и пакеты есть на сервере.

      ; git count-objects : Проверка, сколько объектов будет потеряно и объём освобождаемого места при перепаковке репозитория.
      ; git gc : Переупаковка локального репозитория.

      Рецепты¶

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

      Импорт svn репозитория на Git-сервер

      Git Начало работы с Git

      замечания

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

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

      Git имеет 3 разных «области» для вашего кода:

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

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

      Самое большое изменение для людей, которые привыкли к CVS или Subversion, состоит в том, что каждая проверка содержит не только исходное дерево, но и всю историю проекта. Обычные операции, такие как изменение версий, проверка старых версий, фиксация (для вашей локальной истории), создание ветки, проверка другой ветви, объединение ветвей или файлов патчей, могут выполняться локально без необходимости связываться с центральным сервером. Таким образом, самый большой источник латентности и ненадежности удаляется. Общение с репозиторией «вверх по течению» необходимо только для получения последних изменений и публикации локальных изменений для других разработчиков. Это превращает то, что ранее было техническим ограничением (кто имеет репозиторий владеет проектом) в организационный выбор (ваш «вверх по течению» — это тот, с кем вы хотите синхронизировать).

      Версии

      Версия Дата выхода
      2,13 2020-05-10
      2,12 2020-02-24
      2.11.1 2020-02-02
      2,11 2020-11-29
      2.10.2 2020-10-28
      2,10 2020-09-02
      2,9 2020-06-13
      2,8 2020-03-28
      2,7 2015-10-04
      2,6 2015-09-28
      2.5 2015-07-27
      2,4 2015-04-30
      2,3 2015-02-05
      2,2 2014-11-26
      2,1 2014-08-16
      2,0 2014-05-28
      1,9 2014-02-14
      1.8.3 2013-05-24
      1,8 2012-10-21
      1.7.10 2012-04-06
      1,7 2010-02-13
      1.6.5 2009-10-10
      1.6.3 2009-05-07
      1,6 2008-08-17
      1.5.3 2007-09-02
      1,5 2007-02-14
      1.4 2006-06-10
      1,3 2006-04-18
      1.2 2006-02-12
      1,1 2006-01-08
      1,0 2005-12-21
      0,99 2005-07-11

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

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

      Во всех операционных системах:

      В UNIX-подобных операционных системах:

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

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

      После установки Git перейдите в каталог, который вы хотите разместить под управлением версии, и создайте пустой репозиторий Git:

      Это создает скрытую папку .git , которая содержит сантехнику, необходимую для работы Git.

      Затем проверьте, какие файлы Git добавит в ваш новый репозиторий; этот шаг стоит особого внимания:

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

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

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

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

      Зафиксируйте все файлы, которые были добавлены, вместе с сообщением фиксации:

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

      Чтобы добавить новый удаленный доступ, используйте команду git remote add на терминале, в каталоге, в котором хранится ваш репозиторий.

      Команда git remote add принимает два аргумента:

      1. Удаленное имя, например, origin
      2. Удаленный URL-адрес, например https:// /user/repo.git

      ПРИМЕЧАНИЕ. Перед добавлением удаленного вам необходимо создать необходимый репозиторий в своей службе git, после добавления пульта вы сможете нажать / вытащить фиксации.

      Клонировать хранилище

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

      Например, чтобы клонировать проект GitHub:

      Чтобы клонировать проект BitBucket:

      Это создает каталог под названием projectname на локальном компьютере, содержащий все файлы в удаленном репозитории Git. Сюда входят исходные файлы для проекта, а также подкаталог .git который содержит всю историю и конфигурацию для проекта.

      Чтобы указать другое имя каталога, например MyFolder :

      Или клонировать в текущем каталоге:

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

      Вы также можете использовать команду ssh для команды:

      Версия https версия ssh эквивалентны. Однако некоторые сервисы хостинга, такие как GitHub, рекомендуют использовать https вместо ssh .

      Установка Git

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

      Установка из источника

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

      Чтобы установить Git, вам нужно иметь следующие библиотеки, которые Git зависит от: curl, zlib, openssl, expat и libiconv. Например, если вы используете систему с yum (например, Fedora) или apt-get (например, на основе Debian), вы можете использовать одну из этих команд для установки всех зависимостей:

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

      https://git-scm.com/download Затем скомпилируйте и установите:

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

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

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

      Или, если вы используете дистрибутив на базе Debian, например Ubuntu, попробуйте apt-get:

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

      Существует три простых способа установки Git на Mac. Самый простой способ — использовать графический установщик Git, который вы можете загрузить со страницы SourceForge.

      Рисунок 1-7. Установка Git OS X. Другой важный способ — установить Git через MacPorts ( https://www.macports.org) . Если у вас установлен MacPorts, установите Git через

      Вам не нужно добавлять все дополнительные функции, но вы, вероятно, захотите включить + svn, если вам когда-либо понадобится использовать Git с репозиториями Subversion (см. Главу 8).

      Homebrew ( https://brew.sh/) — еще одна альтернатива установке Git. Если у вас установлен Homebrew, установите Git через

      Установка в Windows

      Установка Git на Windows очень проста. Проект msysGit имеет одну из более простых процедур установки. Просто загрузите exe-файл установщика с страницы GitHub и запустите его:

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

      Примечание по использованию Windows: вы должны использовать Git с установленной оболочкой msysGit (стиль Unix), она позволяет использовать сложные строки команды, приведенные в этой книге. Если вам по какой-то причине необходимо использовать родную консоль командной строки Windows / командной строки, вам нужно использовать двойные кавычки вместо одиночных кавычек (для параметров с пробелами в них), и вы должны указать параметры, заканчивающиеся на circumflex accent (^ ), если они являются последними в строке, так как это символ продолжения в Windows.

      Изучение команды

      Чтобы получить дополнительную информацию о любой команде git, то есть о том, что делает команда, доступных опциях и другой документации, используйте параметр —help или команду help .

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

      Аналогично, чтобы получить всю доступную информацию о команде status , используйте:

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

      Настройка SSH для Git

      Если вы используете Windows, открываете Git Bash . Если вы используете Mac или Linux, откройте свой терминал.

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

      Перечислите содержимое вашего каталога

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

      Если вы видите существующую пару открытых и закрытых ключей, которые вы хотели бы использовать на своей учетной записи Bitbucket, GitHub (или аналогичной), вы можете скопировать содержимое файла id_*.pub .

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

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

      Убедитесь, что ваш SSH-ключ добавлен в ssh-agent. Запустите ssh-agent в фоновом режиме, если он еще не запущен:

      Добавьте ключ SSH к агенту ssh. Обратите внимание, что вам нужно, чтобы te заменил id_rsa в команде именем вашего файла закрытого ключа :

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

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

      Настройка удаленного пула

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

      Сначала проверьте удаленные имена:

      Если upstream уже есть (в некоторых версиях Git), вам нужно установить URL-адрес (в настоящее время он пуст):

      Если выше не существует, или если вы хотите добавить друг / вилку коллег ( в настоящее время они не существуют):

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

      Это не имеет ничего общего с аутентификацией при нажатии в удаленный репозиторий (например, при нажатии в удаленный репозиторий с использованием вашей учетной записи GitHub, BitBucket или GitLab)

      Чтобы объявить этот идентификатор для всех репозиториев, используйте git config —global
      Это сохранит настройку в файле .gitconfig вашего пользователя: например $HOME/.gitconfig или для Windows, %USERPROFILE%\.gitconfig .

      Чтобы объявить идентификатор для одного репозитория, используйте git config внутри репо.
      Это сохранит параметр внутри отдельного репозитория, в файле $GIT_DIR/config . например /path/to/your/repo/.git/config .

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

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

      Удалить глобальную идентификацию

      Чтобы заставить git искать вашу личность только в настройках репозитория, а не в глобальной конфигурации:

      Таким образом, если вы забудете указать свой user.name и user.email для данного репозитория и попытайтесь сделать фиксацию, вы увидите:

      Общий код

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

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

      На удаленном сервере:

      На локальной машине:

      (Обратите внимание, что ssh: это всего лишь один из возможных способов доступа к удаленному репозиторию.)

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

      Добавление —set-upstream (или -u ) создало —set-upstream (отслеживание), которая используется без аргументов Git-команд, например git pull .

      Git для начинающих

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

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

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

      Установка Git

      На официальном сайте Git есть подробная информация о его установке на различные системы — Linux, Mac, Windows. В нашем случае мы будем использовать Ubuntu 13.04, и Git мы будем устанавливать посредством apt-get .

      Начальная конфигуация

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

      Первым делом надо инициализировать Git-репозитарий в директории проекта. Сделать это можно командой init , которая создает директорию .git со всей информацией о вашем проекте.

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

      Стоит отметить, что если вы не укажете ваш адрес и имя, то вместо них будут использоваться значения по умолчанию. В нашем случае значениями по умолчанию будут donny и donny@ubuntu.

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

      Готовим файлы для коммита

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

      Проверяем состояние репозитария

      Теперь, когда в вашем проекте есть файлы, давайте посмотрим, как Git с ними обращается. Чтобы проверить текущий статус репозитария, используйте команду git status

      Добавляем файлы в Git

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

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

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

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

      Удаляем файлы

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

      Коммитим изменения

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

      Указывайте сообщение, которое будет содержать полезную информацию, так как они помогают понять, что же именно было изменено в рамках данного коммита. Избегайте каких-то общих сообщений, типа “Правил баги”. Если у вас есть баг-трекер, вы можете указать сообщение типа “Поправлен баг #123”. Хорошая практика — указывать в сообщении имя ветки или улучшения. Например, “Управление активами — добавлена возможность генерировать PDF на основе актива” — понятное и доходчивое сообщение.

      Git определяет коммит длинным шестнадцатеричным номером. Обычно, нет необходимости копировать всю строку, первых 5-6 символов достаточно для идентификации конкретного коммита. По скриншоту видно, что наш коммит идентифицируется числом 8dd76fc .

      Дальнейшие коммиты

      Давайте изменим несколько файлов после того, как мы их закоммитили. После того, как мы их изменили, git status сообщит о том, что у нас есть измененные файлы.

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

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

      Можно избежать использования этой команды, если добавить параметр -a к git commit . Эта команда проиндексирует все измененные файлы, и закоммитит их. Но такой подход может быть довольно опасным, так по ошибке можно закоммитить то, что не хотелось. Например, скажем, что вы открыли файл, и случайно его изменили. При индексировании измененных файлов вы будете оповещены об изменениях в каждом файле. Но если вы отправите на коммит все измененные файлы не глядя с помощь. git commit -a , то будут закоммичены все файлы, включая те, которые вы коммитить не хотели.

      Как только вы проиндексировали файлы, можно приступать к коммиту. Как упоминалось ранее, к коммиту можно указать сообщение с помощью ключа -m . Но также можно указывать и многострочные комментарии с помощью команды git commit , которая открывает консольный редактор для ввода комментария.

      Управление проеком

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

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

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

      Данный урок подготовлен для вас командой сайта ruseller.com
      Источник урока: https://www.sitepoint.com/git-for-beginners/
      Перевел: Станислав Протасевич
      Урок создан: 23 Мая 2014
      Просмотров: 55633
      Правила перепечатки

      5 последних уроков рубрики «Разное»

      Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

      Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

      Разработка веб-сайтов с помощью онлайн платформы Wrike

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

      20 ресурсов для прототипирования

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

      Топ 10 бесплатных хостингов

      Небольшая подборка провайдеров бесплатного хостинга с подробным описанием.

      Быстрая заметка: массовый UPDATE в MySQL

      Ни для кого не секрет как в MySQL реализовать массовый INSERT, а вот с UPDATE-ом могут возникнуть сложности. Чтобы не прибегать к манипуляциям события ON_DUPLICATE можно воспользоваться специальной конструкцией CASE … WHEN … THEN.

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