Git — Работа с 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

28 декабря 2011

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

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

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

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

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

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

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

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

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

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

Введение в 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.

Цукерберг рекомендует:  Графики и диаграмы на HTML5 с помощью Flotr2

Для того, чтобы внести свои изменения, Артему нужно опять скопировать репозиторий (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. Спасибо за внимание.

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

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

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

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

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

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

Настройка Git

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знакомство с работой Git – и не только с командами

Git, заметки для самого себя

Git — это популярный децентрализованный репозиторий исходного кода. Его разработал Линус Торвальдс, создатель операционной системы Linux, для управления исходным кодом ядра Linux. На нем основаны целые службы, такие как GitHub. Он используется даже в IBM DevOps Services – наряду с IBM Rational Team Concert™. Так что тем, кто хочет программировать в мире Linux или использовать IBM DevOps Services с Git, будет полезно хорошее понимание Git.

Когда я начал работать с Git, я имел некоторый опыт работы с Concurrent Versions System (CVS) и Apache Subversion (SVN), поэтому я пытался освоить его с точки зрения этих классических систем хранения исходного кода. Такой подход дал мне лишь ограниченное понимание возможностей Git. С тех пор я освоил Git гораздо лучше, так что эта статья – своего рода «Заметки для самого себя», чтобы напомнить себе, как работает Git, и объяснить это всем начинающим. Я предполагаю, что вы знакомы с другими, более классическими хранилищами исходного кода, такими как CVS или SVN.

Основы

Так что давайте начнем с простого примера классического репозитория исходного кода, показанного на рисунке 1. В классическом репозитории исходного кода папка с файлами и подпапки обрабатываются как информация (content) (CVS и Git на самом деле работают не с папками, а просто с файлами по указанному пути). Все версии информации содержатся в репозитории, а рабочий каталог – это место, где работают с кодом. Из репозитория код выгружают (checkout) в рабочий каталог, а изменения, внесенные в этом рабочем каталоге, фиксируют (commit) в новой версии информации в репозитории.

Рисунок 1. Управление рабочим пространством в классическом репозитории исходного кода

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

Такая последовательность версий называется потоком или ветвью. В SVN основной поток называется стволом; в CVS он обычно носит имя HEAD; в Git его обычно называют master. Ветви используются при реализации проекта для выделения разработки конкретной функции или для поддержки старой версии.

Рисунок 2. Создание новой версии в классическом репозитории

Пока Git мало чем отличается от классических хранилищ исходного кода, не правда ли? К сожалению, на этом сходство заканчивается. Одна из основных особенностей CVS и SVN заключается в том, что у них есть центральный репозиторий. Git – децентрализованный репозиторий. При разработке программного обеспечения несколько репозиториев могут работать одновременно, и они так и работают, потому что репозиторий каждого разработчика действует и сообщается с другими точно так же, как любой другой Git-репозиторий на сервере.

Так как же работает Git?

Основной принцип работы Git на удивление прост – его только нужно усвоить.

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

Это поистине основополагающий принцип. Все остальное – его следствия. Так что давайте немного углубимся в Git.

Работа с Git

Чтобы начать работу с Git, достаточно выполнить команду git init . Она превращает текущий каталог в рабочий каталог Git и создает в нем подкаталог .git (скрытый) с репозиторием. Теперь можно приступать к работе с Git. Команды checkout и commit такие же, как и в других репозиториях исходного кода, но акцент делается на наборы изменений, поэтому в Git есть команда add (как в SVN). С помощью этой команды изменение, внесенное в рабочий каталог, переносится в промежуточную область для следующей фиксации. Эту промежуточную область обычно называют индексом. Рисунок 3 иллюстрирует процесс создания набора изменений из снимка версии A в снимок версии B.

Команда git status помогает отслеживать добавленные изменения, в какой бы ветви вы ни находились.

Рисунок 3. Создание набора изменений в Git

Команда git log показывает историю изменений (т.е. коммитов) в рабочем каталоге, а команда git log

– историю изменений по данному пути.

Команда git status перечисляет измененные файлы в рабочей области, а также файлы в индексе, а с помощью команды git diff можно увидеть различия между файлами. Используя только команду git diff (без параметров), можно увидеть изменения в рабочем каталоге, которые еще не добавлены в индекс. Чтобы увидеть, что на самом деле находится в индексе, – то есть изменения, ожидающие своей очереди, нужно использовать команду git diff —cached . Команда git diff или git diff —

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

Имена

Примечание.
Из-за длинных идентификаторов коммитов я буду использовать на своих рисунках только аббревиатуры, такие как «(A)», «(B)» и т.п.

Рассмотрим принципы именования объектов в Git. Основные элементы Git – это снимки текущего состояния. Их называют по идентификаторам коммитов, которые представляют собой идентификаторы хешей, например, «c69e0cc32f3c1c8f2730cade36a8f75dc8e3d480». Их получают из содержимого снимка, который включает в себя фактическую информацию и некоторые метаданные, такие как время подачи, сведения об авторе, родительская версия и т.д. Снимок не имеет номера версии через точку, как в CVS, и номера операции (и пути относительно каталога верхнего уровня /branches), как в SVN. Поэтому между именами снимков текущего состояния Git невозможно установить какой-либо порядок, как в других репозиториях. Для удобства Git позволяет сокращать эти длинные хэши до кратких имен с минимальным количеством символов от начала ID, так чтобы краткое имя все равно оставалось уникальным в пределах репозитория. В приведенном выше примере кратким именем будет «c69e0cc».

Отметим, что термин commit используется и как глагол, означающий действие по созданию снимка текущего состояния, и как имя существительное, означающее результирующий снимок.

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

Как Git «узнает», куда поместить изменения из рабочей области? На это указывает HEAD. HEAD разработки — это место, откуда взято последнее рабочее пространство и, что еще важнее, куда фиксируются изменения. Обычно HEAD указывает на ветвь последней выгрузки. Это отличается от интерпретации термина HEAD в CVS как вершины разработки ветви по умолчанию.

Команда tag указывает коммит и позволяет адресовать отдельный коммит с читабельным именем. Как правило, тег (tag) — это псевдоним, заменяющий идентификатор коммита, но коммиты могут обозначаться и ярлыками. HEAD – это вершина разработки в рабочем каталоге. HEAD^1 — первый родитель коммита HEAD, HEAD^2 – второй и т.д.

Подробнее см. на странице руководства gitrevisions. Так как имена, такие как теги или имена ветвей, указывают на коммиты, они называются указателями (refnames). Команда reflog показывает, что изменилось за время жизни имени, с момента его создания (обычно вместе с ветвью) до текущего состояния.

Ветвление

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

Рисунок 4. Пример структуры ветвления в Git

Рисунок 4 иллюстрирует эту структуру ветвей в Git. Ветвь master, где в настоящее время происходит некоторая разработка, указывает на снимок F. Другая ветвь, old, соответствует более старому снимку, возможно, точке исправления разработки. Ветвь feature содержит другие изменения – для конкретной функции. Наборы изменений помечены как переходы из одной версии в другую, например, «[B->D]». В этом примере у снимка текущего состояния B есть два потомка, два направления развития, – ветвь feature и другая ветвь. Коммит А также помечен как исправление ошибки номер 123.

Ветви создаются посредством применения команды git branch
к текущему HEAD или команды git branch
к любой допустимой версии снимка текущего состояния. Это приводит к созданию нового указателя ветви в репозитории. Будьте внимательны, при ветвлении таким способом рабочая область остается в старой ветви. Сначала нужно выгрузить новую ветвь. Команда git checkout -b
создает новую ветвь и переносит в эту ветвь рабочую область.

Есть еще две чрезвычайно полезных команды:

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

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

Слияние

При реализации новой функции ее загружают в репозиторий, например, в ветвь feature. Когда функция готова, необходимо вернуть ее в основную ветвь (master). Для этого нужно выгрузить основную ветвь и воспользоваться командой git merge
. Тогда git объединит изменения из данной ветви с выгруженной ветвью. Для этого Git применяет все наборы изменений из ветви feature к вершине основной ветви.

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

  • Быстрое прямое слияние: в принимающей ветви не произошло никаких изменений с тех пор, как две ветви разошлись. Она по-прежнему указывает на последний коммит, предшествующий отделению другой ветви. В этом случае Git перемещает указатель принимающей ветви вперед, как показано на рисунке 5. Так как кроме продвижения указателя ветви ничего делать не нужно, в Git это называется «быстрым прямым слиянием».
Рисунок 5. Быстрое прямое слияние
  • Бесконфликтное слияние: имеются изменения в обеих ветвях, но они не конфликтуют. Это происходит, например, если изменения в обеих ветвях влияют на разные файлы. Git автоматически применяет к принимающей ветви все изменения из другой ветви и создает новый коммит с этими изменениями. Затем принимающая ветвь перемещается вперед к этому коммиту, как показано на рисунке 6.

Обратите внимание, что результирующий коммит – merge commit – имеет двух родителей. Однако я не отметил здесь наборы изменений. В принципе, набор между изменений (E) и (H) будет комбинацией всех наборов изменений из ветви feature с момента расхождения двух ветвей, но это, вероятно, заводит аналогию слишком далеко.

Рисунок 6. Бесконфликтное слияние
  • Конфликтное слияние: имеются изменения в обеих ветвях, и они конфликтуют между собой. В этом случае конфликтующий результат останется в рабочем каталоге, чтобы пользователь мог исправить и зафиксировать его или же отменить слияние командой git merge –abort .

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

Понятие отката и повторения набора изменений ведет еще дальше, к таким расширенным возможностям, как сдвиг (rebasing) и выборочное применение изменений (cherry picking).

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

Сдвиг

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

Рисунок 7. Смещение ветви

Если повтор приводит к конфликту, смещение останавливается при первом же конфликте и оставляет конфликтующее состояние в рабочем каталоге для исправления пользователем. Затем смещение можно продолжить или прервать.

Смещение с параметром —onto позволяет переместить точку расхождения смещения к любому новому снимку текущего состояния в другой ветви.

Выборочное применение изменений

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

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

Рисунок 8. Выборочное применение изменений

Возврат

Команда revert выполняет откат одного или нескольких наборов изменений в рабочий каталог, а затем создает новый коммит с результатом. revert – это почти cherry pick наоборот. См. пример на рисунке 9.

Рисунок 9. Возврат коммита

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

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

Сотрудничество

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

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

Рисунок 10. Два репозитория

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

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

После этого можно объединить содержимое удаленной ветви и своей собственной. На рисунке 11 показан процесс выгрузки удаленной ветви в локальную ветвь master, но это не обязательно, ее можно слить с любой другой ветвью с общей историей, например, с помощью обычной команды merge.

Рисунок 11. Извлечение и выгрузка удаленной ветви

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

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

Рисунок 12. Получение удаленных изменений

На рисунке 12 показано действие команды git fetch ; она обновляет ветвь дистанционного отслеживания. Затем просто выполняется обычная операция слияния между ветвью дистанционного отслеживания и локальной ветвью, в данном примере – git checkout master; git merge repo1/master . После копирования имя FETCH_HEAD можно использовать в команде слияния в качестве ярлыка скопированной удаленной ветви, например, git merge FETCH_HEAD . Кроме того, как говорилось выше, это слияние может привести к быстрому прямому слиянию, бесконфликтному слиянию или к конфликту, который нужно разрешить вручную.

Команда git pull удобна тем, что выполняет оба действия fetch и merge .

Когда изменения зафиксированы в локальной ветви, их нужно передать в удаленную ветвь. Это делается с помощью команды push , которая переносит локальные изменения в удаленную ветвь. Это действие, противоположное действию fetch , а не pull . Однако это больше, чем просто копирование, так как обновляется как локальная копия удаленной ветви, так и удаленная ветвь в другом хранилище, как показано на рисунке 13. Команда push также позволяет создавать новые ветви в удаленном репозитории.

Рисунок 13. Публикация изменения

Существует одно условие. Это срабатывает только в том случае, если операция push приведет к быстрому прямому слиянию с удаленной ветвью в удаленном репозитории. В противном случае в удаленной ветви уже есть другие изменения (коммиты) из других репозиториев или от других коммиттеров. Тогда Git прерывает операцию push и оставляет все как есть. Затем нужно извлечь изменения, объединить их со своей локальной ветвью и повторить попытку публикации.

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

Помимо команд fetch и push, есть еще один способ распространения изменений; старая добрая почта. Существует команда git format-patch , которая создаёт файл изменений для каждого коммита, ведущий от данного коммита к текущему состоянию ветви. Команда git am применяет эти файлы изменений к текущей ветви.

Предостережения

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

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

Расширенный Git

Рисунок 14. Пример структуры с несколькими репозиториями

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

Выше я описал сдвиг как воспроизведение наборов изменений поверх другой точки ветвления (или расхождения) исходной ветви. Как правило, Git воспроизводит порядок, в котором создавались коммиты. Расширенная функция git rebase -i позволяет выбирать, в каком порядке должны следовать коммиты, и даже можно ли удалять коммиты или объединять два коммита друг с другом (squash). Этого нельзя делать с коммитами, которые уже опубликованы – иначе те, кто работает с ними, получат много конфликтов.

Я также описал, как выгрузить конкретную ветвь, но выгрузить можно любой коммит (снимок текущего состояния). Тогда указатель HEAD будет указывать на коммит, а не на ветвь. Этот режим называется detached HEAD. При фиксации изменения в этой ситуации начинается новый поток разработки. Как правило, вы совершаете ветвление, но без необходимости присваивать имя этой новой ветви. Вершина разработки доступна только через идентификатор коммита; у нее нет никакого имени refname. Можно создать ветвь от этой вершины с помощью обычной команды git branch
.

Что происходит с теми коммитами, которые недоступны ни по какой ссылке? Если не делать ничего специально, то они останутся в репозитории. Однако можно – и службы хостинга так и делают – запустить git gc , сборщик мусора Git для удаления ненужных файлов. Коммиты, не доступные ни по какому имени, не нужны и будут удалены. Поэтому рекомендуется всегда работать с реальной ветвью, особенно с учетом того, как быстро и легко создаются новые ветви в Git.

Заключение

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

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

Еще один отличный инструмент, помогающий понять Git, – это графический инструмент gitk, который показывает структуру локального репозитория. Используйте команду gitk —all , чтобы увидеть все ветви, теги и т.п. Он также предоставляет простой интерфейс для выполнения действий в Git.

Цукерберг рекомендует:  Вакансии ООО Глория

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

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

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

Начинаем работать с git — пошаговая инструкция

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

Наверное, пора узнать…

Секреты командной разработки

Разработка – это почти всегда командная игра. Пора учиться работать в команде.
Даже если пока что в твоей команде только монитор, системник (или старенький ноутбук) и острое желание стать программистом, всё равно пора учиться.

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

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

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

Шаг 1. Выбираем git-хостинг

Git-хостинг на разных условиях предлагают десятки компаний.
Самые известные из них: Github, Sourceforge, Google Code, GitLab, Codebase. Выбери удобный интерфейс и регистрируйся на понравившемся хостинге.
В этой статье мы рассмотрим работу с git-хостингом на примере Github’а.

Шаг 2. Регистрация

Процедура регистрации на Гитхабе простая и интуитивно понятная даже для тех, чей уровень английского далёк от Upper Intermediate.

Логин, пароль, почта –> подтверждение, и связь с мировым сообществом программистов налажена.

Шаг 3. Создание репозитория

Ты можешь создать любое количество репозиториев, у каждого из которых будет issue tracking, wiki, условия для проведения code review и многое другое.
Политика разработчиков Github предполагает бесплатное использование хостинга для всех open-source проектов.


Чтобы создать новый репозиторий нажмём кнопку + в верхней части экрана и выберем New repository

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




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

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


Жмём волшебную кнопку Create внизу экрана, и репозиторий готов.

Шаг 4. Работа с репозиторием

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

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

Шаг 5. Выбираем Гит-клиент

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

Но вернёмся к git-клиентам.

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

SmartGit


Удобное приложение гармонично сочетает все необходимые функции и доступную интуитивно понятную систему управления. SmartGit – один из самых удобных графических интерфейсов для профессиональной разработки. Некоммерческая разработка и разработка open-sourse проектов не требуют платной лицензии.

GitHub Desktop

«Родной» графический интерфейс Гитхаба. GitHub Desktop работает под Windows и Mac и практически полностью копирует функционал основного сайта. Работает под той же учётной записью.
Правда, не всегда оперативно справляется с большими программами.

Зато отлично подходит для начала работы с git.

GitKraken


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

SourceTree

SourceTree позволяет работать с Bitbucket и GitHub. В приложении довольно простой интерфейс, подходящий, как для опытных программистов, так и для новичков.

Шаг 6. Работа со SmartGit


В этой статье мы рассмотрим работу с SmartGit.

Скачать SmartGit можно, например, отсюда:
Устанавливаем и запускаем.

Основные операции для работы с git


Clone


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


Затем копируем ссылку репозитория, созданного на Гитхабе (шаг 2)

Ссылка на репозиторий


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

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

Commit

Репозиторий готов – пора приступать к работе.
Написанный код мы помещаем в локальный репозиторий — папку .git (путь к которой мы указали в операции clone).

Добавление файла в локальный репозиторий


Если всё прошло успешно, в окошке SmartGit’а появится скопированный файл.

Новый файл в SmartGit



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

В открывшемся окне пишем пояснительный комментарий к сохраняемому файлу и снова нажимаем кнопку Commit

Пояснения к Commit’у



Файл сохранён, а изменения внесены в журнал.

Файл отправлен в локальный репозиторий

Теперь заглянем на Github.com в наш удалённый репозиторий. Там до сих пор нет ни одного файла. Нужно срочно менять ситуацию.
Чтобы перенести изменения, внесённые в локальный репозиторий, в удалённый репозиторий, необходимо нажать кнопку Push.



К слову, отправить изменения в удалённый репозиторий, нам предлагают ещё в точке Commit’а


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



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

Перенос информации из сторонних репозиториев на Гитхаб

Когда нужно собрать разрозненные кусочки кода в один проект, используйте кнопку Import repository и работайте с файлами в удобном репозитории Гитхаба.

Кнопка New gist на этой панели предназначена для мгновенного обмена информацией.

А кнопка New organization открывает массу возможностей для командной разработки.

Заключение

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

Благодаря своей политике (поддержка open-sourse проектов) Github предоставляет удивительную возможность детально рассматривать программы, написанные как новичками, так и признанными гениями – программистами.

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

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

Сайт tproger.ru опубликовал перевод статьи «The Ultimate Beginner Git Cheatsheet».

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

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

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

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

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

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

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

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

Подготовка Git

Установка Git

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коммиты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ветвление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Слияние

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

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

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

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

Перемещение

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

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

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

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

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

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

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

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

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

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

Резюмируем

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

GitHub

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Основы Git. Как работает Git?

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

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

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

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

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

Обычно, команды Git имеют следующий вид:

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

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

Установка Git

Если вы пользуетесь Windows, качайте Git отсюда. Что касается macOS, то здесь Git поставляется как часть инструмента командной строки XCode. Наличие Git можно проверить, открыв терминал и набрав git —version . Для Linux используйте команду sudo apt install git-all либо sudo dnf install git-all .

Настраиваем конфигурационный файл

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

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

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

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

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

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

Чтобы инициализировать новый репозиторий .git используют команду git init . Если хотите скопировать уже существующий репозиторий — git clone .

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

Git хранит имеющиеся данные в виде набора «снимков», называемых коммитами. Коммиты хранят состояние файловой системы в конкретный момент времени, а также имеют указатель на предыдущие коммиты. Каждый коммит содержит уникальный контрольный идентификатор, который используется Git, чтобы ссылаться на этот коммит. Для отслеживания истории Git хранит указатель HEAD, указывающий на 1-й коммит.

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

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

Система файлов в Git

Git может отслеживать файлы в 3-х основных разделах: — рабочая директория (речь идёт о файловой системе вашего ПК); — область подготовленных файлов (это staging area, где хранится содержание следующего коммита); — HEAD (последний в репозитории коммит).

Как просматривать изменения в файловых системах?

Для этого используют команду git status . Она отображает все файлы, которые различаются между 3-мя отделами. Файлы имеют четыре состояния: 1) untracked (неотслеживаемый). Находится в рабочей директории, но его нет ни в HEAD, ни в области подготовленных файлов. Можно сказать, что Git о нём не знает; 2) modified (изменён). В рабочей директории находится его более новая версия по сравнению с той, которая хранится в HEAD либо в области подготовленных файлов (при этом изменения не находятся в следующем коммите); 3) staged (подготовлен). В области подготовленных файлов и в рабочей директории есть более новая версия, если сравнивать с хранящейся в HEAD, но файл уже готов к коммиту; 4) без изменений. Во всех разделах содержится одна версия файла, то есть в последнем коммите находится актуальная версия.

Чтобы посмотреть не изменённые файлы, а непосредственно изменения, можно использовать: — git diff — для сравнения рабочей директории с областью подготовленных файлов; — git diff —staged — для сравнения области подготовленных файлов с HEAD.

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

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

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

Для игнорирования предусмотрен файл .gitignore, где отмечаются файлы для игнорирования.

Коммиты

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

Ряд советов по коммитам: — коммитьте часто; — одно изменение — один коммит, но не коммитьте слишком незначительные изменения (в большом репозитории они могут засорить историю); — комментируя сообщение о коммите, логически дополняйте фразу this commit will ___ и не используйте более 50 символов.

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

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

Для вывода списка удалённых репозиториев нужна команда git remote –v . С её помощью мы не только загружаем копию репозитория, но и отслеживаем удалённый сервер, находящийся по указанному адресу (ему присваивается имя origin).

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

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

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

Ветвление в Git

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

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

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

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

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

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

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

Слияние

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

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

Маркеры разрешения конфликта:

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

Перемещение

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

Чтобы выполнить перемещение, используют команду git rebase . Она воспроизводит изменения тематической ветви на основной. При этом HEAD тематической ветви указывает на последний воспроизведённый коммит.

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

Если хотите откатить коммит: — git revert — создаёт новый коммит, который отменяет изменения, но сохраняет историю; — git reset — перемещает указатель HEAD, и создаёт более чистую историю, как будто коммита никогда не было. Но это также значит, что вы не сможете вернуться обратно к изменениям, если решите, что отмена была лишней. В общем, чище — не значит лучше!

Пошаговая инструкция по работе с системой контроля версий GIT и сервисом GitHub для новичков

Наверняка многие слышали о системе контроля версий git. Сегодня мы рассмотрим весь путь от установки git до внесения своих изменений в удаленный репозиторий на примере библиотеки OsEngine.Для начала скачаем клиент git по ссылке и установим его. Вопросов возникнуть не
должно, просто везде жмем Next. Далее взаимодействие с git будет рассмотрено на примере работы с консольным клиентом.Следующим шагом необходимо зарегистрироваться на сайте https://github.com/. Теперь мы можем присоединиться к работе над OsEngine. Для этого перейдем к репозиторию проекта и в правом верхнем углу нажмем кнопку Fork.

Этим действием мы создали fork (другими словами ответвлние), который хранится в репозитории нашей учетной записи и теперь можно вносить в него изменения, не опасаясь чего-то сломать в главной ветке проекта. Далее этот самый наш репозиторий на github мы будем называть удаленным репозиторием.
Теперь приступим к работе с самим git и первым делом нам надо создать на своем компьютере локальную копию удаленного репозитория. Для этого переходим в желаемую папку, в контекстном меню выбираем пункт Git Bash Here и у нас откроется консоль.

Дальше идем на github в наш репозиторий и нажимаем на зеленую кнопку Clone or download (1) и затем на кнопку под номером 2 на снимке.

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

$ git clone «здесь вставляем ссылку без кавычек»

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

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

Настройка git

Перед началом работы с git, его необходимо настроить. Откройте git bash, задайте логин и пароль командами:

$ git config —global user.name “ваше имя”
$ git config —global user.email “ваша почта”

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

$ git config —global —list

Работа с ветками

Ветки в git это тоже самое что и ветки на github. Чтобы создать новую ветку, выполните в консоли команду:

$ git branch желаемое имя

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

$ git checkout имя ветки

для возврата в основную ветку наберите:

$ git checkout master

$ git branch –m новое имя

команда $ git branch позволяет определить в какой ветке сейчас находимся. Удаляет ветку команда

$git branch –D имя ветки

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

$ git merge имя ветки

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

Коммиты

Вся суть использования git в commits (коммиты). Коммит – это так называемый снимок состояния проекта на определенном этапе
разработки. Например: у нас есть библиотека OsEngine, мы добавили в
нее новый индикатор и закоммитили, потом решили подправить какой-либо файл в
движке и после этого приложение крашится или не хочет правильно работать. Чтобы
не делать лишнюю работу и не править все обратно, мы можем просто напросто
откатиться к прошлому коммиту, когда приложение работало как надо. Соответственно
вся работа с git крутится вокруг создания, удаления, редактирования, слияния
коммитов и веток.

Добавление файлов в индекс

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

$ git add README

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

$ git add .

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

Удаление файлов из индекса

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

$ git reset README

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

$ git checkout — имя файла

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

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

Теперь можно коммитить изменения, делается это при помощи команды:

$ git commit –m “Здесь должен быть комментарий в кавычках”

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

$ git log

$ git show покажет только последние изменения. Для выхода из режима просмотра нажмите q.

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

$ git commit –a –m “комментарий в кавычках”

-a означает: добавить все изменения в индекс до передачи.
-m: комментарий.

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

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

$ git revert HEAD

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

$ git revert HEAD

Команда $ git reset —soft HEAD

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

$ git reset — hard HEAD

полностью удалит три последних коммита.

Состояние файлов

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

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

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

$ git push origin master

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

$ git pull

Использование SSH ключей

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

$ ssh-keygen

Далее 3 раза нажать enter и в дирректории по умолчанию C:\Users\имя пользователя\.ssh появиться папка с ключами. Нужно открыть файл
id_rsa типа PUB в любом текстовом редакторе и скопировать его содержимое. Затем идем на github в настройки своей учетной записи

После чего в колонке слева выбираем пункт: SSH and GPG keys и жмем зеленую кнопку справа New SSH key

задаем Title, в поле Key вставляем данные, скопированные из ключа и жмем

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

После того как вы внесли все необходимые изменения в свой удаленный репозиторий, можно отправить запрос на слияние с главным репозиторием проекта OsEngine. Просто нажмите кнопку New pull request

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

Prgm / Scripts

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

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

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

Команды GIT

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

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

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

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