Git gui windows как пользоваться

A1.1 Приложение A: Git в других окружениях — Графические интерфейсы

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

Графические интерфейсы

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

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

gitk и git-gui

Установив Git, вы также получаете два графических инструмента: gitk и git-gui .

gitk — это графический просмотрщик истории. Что-то типа улучшенных git log и git grep . Это тот инструмент, который вы будете использовать для поиска событий или визуализации истории.

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

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

Интерфейс на картинке похож на вывод git log —graph ; каждая точка соответствует коммиту, линии отражают родство коммитов, а ссылки изображены цветными прямоугольниками. Жёлтая точка обозначает HEAD, а красная — изменения, которые попадут в следующий коммит. В нижней части расположены элементы интерфейса для просмотра выделенного коммита: слева показаны изменения и комментарий, а справа — общая информация по изменённым файлам. В центре расположены элементы для поиска по истории.

git-gui , в отличие от gitk — это инструмент редактирования отдельных коммитов. Его тоже очень просто вызвать из консоли:

И его интерфейс выглядит так:

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

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

Справа снизу находится область для ввода сообщения коммита и несколько кнопок. Введите сообщение и нажмите кнопку «Commit» чтобы выполнить коммит. Также можно изменить предыдущий коммит, выбрав радиокнопку «Amend», что приведёт к обновлению индекса содержимым предыдущего коммита. После этого вы можете как обычно добавлять или удалять файлы из индекса, изменить сообщение коммита и, нажав кнопку «Commit» создать новый коммит, заменив им предыдущий.

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

GitHub для Mac и Windows

Компания GitHub выпустила два инструмента, ориентированных на рабочий процесс, а не на конкретные задачи: один для Windows, второй — для Mac. Эти клиенты — хороший пример процесс-ориентированного ПО: вместо предоставления доступа ко всей функциональности Git, они концентрируются на небольшом наборе фич, работающих вместе для достижения цели. Выглядят они примерно так:

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

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

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

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

И стоит обратить внимание на кнопку «Sync» справа вверху, которая используется для синхронизации по сети.

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

Установка

GitHub для Windows можно скачать на https://windows.github.com, а для Mac — на https://mac.github.com. При первом запуске обе программы проведут первоначальную настройку Git, например, сконфигурируют ваше имя и email, а также установят разумные значения по умолчанию для распространённых опций типа CRLF-поведение и хранилище паролей.

Оба инструмента поддерживают автообновление в фоне — это означает, что у вас всегда будет последняя версия. Это также относится к поставляемому в комплекте с ними Git — вам никогда не придётся обновлять его вручную. На Windows вы также получаете ярлык для запуска PowerShell с Posh-Git, который мы рассмотрим далее в этой главе.

Следующий шаг — скормить программе парочку репозиториев для работы. Клиент для GitHub показывает список репозиториев, доступных вам на GitHub, и вы можете клонировать любой в один клик. Если же у вас уже есть клонированный репозиторий, просто перетяните его из окна Finder (или Windows Explorer) в окно клиента GitHub, и он будет включён в список репозиториев слева.

Рекомендуемый рабочий процесс

После установки GitHub клиент можно использовать для решения кучи стандартных задач. Рекомендуемый ниже подход к работе иногда называют «GitHub Flow». Мы рассмотрели этот рабочий процесс в разделе Рабочий процесс с использованием GitHub главы 6, но вкратце, важны два момента: (а) вы коммитите в отдельные ветки и (б) вы регулярно забираете изменения с удалённого репозитория.

Управление ветками слегка различается на Mac и Windows. В Mac версии для создания ветки есть кнопка вверху окна:

На Windows создание ветки происходит путём ввода её имени в переключатель веток:

После создания ветки добавление коммитов в неё довольно тривиально. Измените что-нибудь в рабочем каталоге и, переключившись в окно клиента GitHub, вы увидите свои изменения. Введите сообщение коммита, выберете файлы для включения в коммит и нажмите кнопку «Commit» (ctrl-enter или ⌘-enter).

Взаимодействие с удалёнными репозиториями происходит в первую очередь посредством кнопки «Sync». В Git есть отдельные команды для отправки изменений на сервер, слияния изменений воедино и перемещения веток друг относительно друга, но клиент GitHub совмещает все эти команды в одну. Вот что происходит когда вы жмёте «Sync»:

git pull —rebase . Если эта команда выполнится с ошибкой, будет выполнено git pull —no-rebase .

Это довольно привычный, но рутинный процесс при работе по «GitHub Flow», совмещение команд воедино действительно экономит время.

Заключение

Перечисленные инструменты отлично решают поставленные перед ними задачи. С их помощью разработчики (и не только) могут начать совместную работу над проектами в считанные минуты, причём с настроенным рабочим процессом. Но если вы придерживаетесь иных подходов к использованию 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 <name> .

Тем самым вы создаёте новую ветвь, на данном этапе одинаковую с 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 :

Как видите, id-номера действительно длинные, но для работы с ними необязательно копировать строку полностью – нескольких первых символов обычно достаточно. Увидеть, что было изменено в каждой версии, позволяет команда 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: подробный гайд для новичков

Привет тебе, будущий Senior Software Engineer. Сегодня поговорим о системе контроля версий, а именно о Git (читается как ГИТ, а не ДЖИТ, как могло бы показаться из грамматики английского языка). Да-да, я знаю что есть еще и Mercurial, SVN… Но будем откровенны: их время уже ушло, и тратить ваше драгоценное время на них не собираюсь. Чтобы вы понимали важность знания гита в наше время, скажу так: без знания/понимания этого вам делать в программировании нечего. Но прелесть в том, что для постоянной работы не нужно держать в голове все команды и возможности. Нужно знать набор команд, которые помогут понимать всё, что происходит.

Основы Git

Установка Git

Установка для Windows

Как обычно, нужно скачать exe файл и запустить его. Здесь все просто: жмем на первую ссылку гугла, устанавливаем и всё. Для работы будем использовать bash консоль, которую они предоставляют. Чтобы работать в виндоусе, нужно запустить Git Bash. Вот как он выглядит в меню пуск: И это уже консоль, в которой можно работать. Чтобы не переходить каждый раз в папку с проектом, чтобы там открыть гит, можно в папке правой кнопкой мыши открыть консоль с нужным нам путем:

Установка для Linux

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

Настройка гита

Немного теории…

• гит репозиторий (git repository);
• коммит (commit);
• ветка (branch);
• смерджить (merge);
• конфликты (conflicts);
• спулить (pull);
• запушить (push);
• как игнорировать какие-то файлы (.gitignore).

Состояния в Гит

• неотслеживаемое (untracked);
• измененное (modified);
• подготовленное (staged);
• закомиченное (committed).

Как это понимать?

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

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

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

Что такое ветка

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

Начало работы с Гитом

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

• git add -A — добавить все файлы из состояния в staged;
• git add . — добавить все файлы из этой папки и все внутренних. По сути тоже самое, что и предыдущее;
• git add <имя файла> — добавляет только конкретный файл. Здесь можно пользоваться регулярными выражениями, чтобы добавлять по какому-то шаблону. Например, git add *.java: это значит, что нужно добавить только файлы с расширением java.

Работа с .gitignore

• первая строка — это игнорирование всех файлов с расширением .class;
• вторая строка — это игнорирование папки target и всего, что она содержит;
• третья строка — это игнорирование всех файлов с расширением .iml;
• четвертая строка — это игнорирование папки .idea.

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

• создать новую ветку на основе той, на которой находимся (99% случаев);
• создать ветку на основе конкретного коммита (1%).

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

Опираться будем на уникальный идентификатор коммита. Чтобы найти его, напишем: Я выделил коммит с комментарием “added hello world…”. У него уникальный идентификатор — “6c44e53d06228f888f2f454d3cb8c1c976dd73f8”. Я хочу создать ветку development начиная с этого коммита. Для этого напишу: Создается ветка, в которой будут только первые два коммита из ветки master. Чтобы проверить это, мы сперва убедимся, что перешли в другую ветку и посмотрим на количество коммитов ней: И правда: получилось, что у нас два коммита. Кстати, интересный момент: в этой ветке еще нет файла .gitignore, поэтому наш скомпилированный файл (GitTest.class) теперь подсвечивается в untracked состоянии. Теперь можем провести еще раз ревизию наших веток, написав: Видно, что есть две ветки — master и development — и сейчас стоим на development.

Создаем ветку на основе текущей

• git checkout master — переходим на ветку master;
• git status — проверяем, точно ли на мастере.

Резолвим конфликты

1. между “<<<<<<< HEAD” и “=======” находятся изменения мастер, которые были в этой строке в мастер ветке.
2. между “=======” и “>>>>>>> feature/add-header” находятся изменения, которые были в feature/add-header ветке.

Работа с удаленными репозиториями

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

GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD пайплайн и другими функциями.
После новости о том, что Microsoft купила GitHub, некоторые разработчики продублировали свои наработки в GitLab.

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

Работа с системой контроля версий GIT и сервисом GITHub

Здесь начинается работа с системой контроля версий GIT.

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

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

Исходный проект —> Копия проекта

Допустим, что работа с копией прошла успешна и на каком-то этапе нам нужно сохранить именно эту копию. Получается, что у нас будет уже три папки с проектом.

Исходный проект —> Копия проекта —> Копия копии проекта

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

Что такое GIT

Хотелось бы иметь такую программу, которая все эти изменения в проекте фиксировала и сохраняла какие-то контрольные точки.

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

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

Что дает GIT

В чем достоинства системы управления версиями GIT?

Во-первых, не нужно вручную делать копии папок проектов. Все сохраняется в так называемом репозитории: все изменения, все контрольные точки. Обратившись к/в репозиторий можно найти все изменения и информацию о том, кем и когда они были сделаны . Можно откатиться на старые версии проекта и/или снова вернуться к более новым. Это очень удобно.

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

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

Как это происходит? Об этом немного ниже.

А пока ответим на такой вопрос: нужно ли использовать систему управления версиями GIT, если над проектом работает один человек ? Ответ: ДА. Нужно .

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

GIT и GitHub

Рассмотрим еще один момент прежде чем начнем устанавливать GIT на персональный компьютер.

Есть GIT, а есть GitHub и это разные вещи. Что такое GIT — этому было дано определение выше. А GitHub — это удаленное хранилище репозиториев — github.com.

Итак, GIT — это программа для создания репозиториев, а GitHub — это удаленное хранилище репозиториев.

Начало работы — GIT How To

Теперь начнем работать с системой управления версиями GIT. Для этого переходим на сайт по ссылке git-scm.com. Скачиваем версию GIT для своей операционной системы (я использую ОС Windows 10) и устанавливаем GIT как обычную программу.

Далее на этой странице мы познакомимся с основными/базовыми возможностями и функциями системы управления версиями GIT. Для тех, кто хочет получить больше знаний, существует интерактивный тур GIT How To — githowto.com/ru, который познакомит вас с основами GIT.

Git GUI или Терминал?

Для работы с системой управления версиями GIT можно использовать его графический интерфейс Graphical User Interface.

Что бы запустить Git GUI нужно открыть любую папку и при клике правой кнопки мыши из контекстного меню нужно выбрать пункт Git GUI Here . Либо открыть Git GUI через меню Пуск .

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

Работа с терминалом

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

— открыть любую папку, а лучше перейти в папку с проектом;

— зажимаем клавишу Shift и при клике правой кнопки мыши из контекстного меню следует выбрать пункт Открыть окно команд или на английском языке Open PowerShell window here .

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

Есть более простой способ — работать с терминалом непосредственно в редакторе VScode .

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

Создание репозитория — Команда git init

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

Все команды GIT (большая их часть) начинается с git .

Команда git init — создает репозиторий. При этом создается скрытая директория .git (в корневой папке проекта), которая содержит файлы все необходимые для работы GIT. Другими словами, команда git init позволяет GIT следить за текущим проектом.

Настройка GIT — Локальная и глобальная конфигурация

После создания репозитория нужно настроить систему управления версиями GIT. Что это значит?

Дело в том, что как правило над проектом работает не один человек . И чтобы понимать, кто какие изменения внес, необходимо так сказать представиться: указать свое имя и e-mail . Поэтому для начала необходимо прописать две конфигурационные команды.

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

git config —local user.name "Anton"

git config —local user.email my_mail@mail.ru

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

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

Для этого необходимо снова запустить выше указанные команды. Только в них local нужно заменить на global.

git config —global user.name "Anton"

git config —global user.email my_mail@mail.ru

Как работает система GIT

Теперь можно перейти непосредственно к тому, как работает система управления версиями GIT?

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

1-е состояние — это когда файлы только созданы . Здесь все просто: допустим мы создали файл index.html, он просто лежит в проекте и с ним ничего не происходит.

2-е состояние — это когда GIT следит за файлами , при этом файлы попадают в так называемый индекс.

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

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

Статус репозитория — Команда git status

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

1. Что у нас еще нет ни одного коммита — ни одной контрольной точки — No commits yet .

2. Далее идет список не отслеживаемых файлов (untracked files — об этом мы говорили — это первое состояние , когда файлы существуют, но с ними ничего не происходит, они не отслеживаются).

3. И еще ниже предлагается использовать команду git add для отслеживания.

Файлы в индексе — Команда git add

Добавим файлы в индекс, используя команду git add.

git add -A — эта команда означает, что GIT будет следить за всеми файлами проекта (git add All). Что мы в результате и видим: сообщение Changes to be committed говорит о том, что произошли изменения, подлежащие фиксации . Таким образом в GIT-репозитории файлы находятся во 2-м состоянии — в состоянии слежения . И далее приведен список файлов, за которыми будет следить система управления версиями GIT.

Но коммитов по-прежнему нет — No commits yet .

Здесь же мы видим предупреждение : warning: LF will be replaced by CRLF in .jshintrc.
The file will have its original line endings in your working directory . Что это значит?

Дело в том, что в разных операционных системах принят разный формат символов, обозначающий перевод строк:
— Windows — \r\n или CRLF (код 0D0A);
— Unix — \n или LF (код 0A);
— Mac — \r или CR (код 0D).

Из этого сообщения мы видим, что файл .jshintrc был создан в unix-подобной операционной системе и в нем будет заменен формат перевода срок на CRLF , т.е. на тот, что принят в ОС Windows .

Мы еще вернемся к вопросу о различиях переноса строк в проектах, разрабатываемых в разных ОС. А пока переходим к 3-му состоянию файлов в GIT.

Создание коммита — Команда git commit

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

Для создания коммита используется команда git commit, которая имеет следующий синтаксис git commit -a -m"first point" , где:

— git commit — сама команда;

— -a — означает All, то есть коммит (контрольная точка) будет затрагивать все файлы проекта;

— -m"first point" — это обязательная часть команды git commit, где -m означает message — сообщение /описание коммита. "first point" — это само сообщение (может быть любым/произвольным и обычно оно более информативно).

Все прошло успешно — была создана контрольная точка . При этом, если снова ввести команду git status , то мы увидим, что ничего не надо делать, рабочее дерево чистое (nothing to commit, working tree clean).

Внесение и отмена изменений — Команда git restore

Пробуем внести изменения в один из файлов проекта, например, index.html и снова проверяем статус репозитория.

Мы видим сообщение о модификации/изменении файла index.html . При этом система управления версиями GIT предлагает варианты возможных дальнейших действий: использовать команду git add, с которой мы уже знакомились или команду git restore, чтобы отменить изменения в рабочем каталоге (to discard changes in working directory) до состояния предыдущего коммита.

Теперь, как и подсказывает GIT в последнем примере: no changes added to commit (use "git add" and/or "git commit -a") , мы снова:

— добавим в индекс файл index.html , в котором произошли изменения (команда git add);

— и создадим новый коммит (новую контрольную точку).

Просмотр комитов — Команда git log

Теперь, когда есть несколько коммитов (несколько контрольных точек), при помощи команды git log мы можем посмотреть логи (log/журнал) того, какие коммиты были/есть.

Здесь мы видим созданные коммиты, а также кто и когда их сделал.

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

Копия репозитория — git push -u origin main

Как сделать Backup — копию репозитория? Как выложить репозиторий на GitHub?

Для начала нужно зарегистрировать на сервисе GitHub, о котором шла речь в начале статьи.

После регистрации появится возможность создать новый репозиторий New Repository .

Здесь нужно выбрать флаг Private — You choose who can see and commit to this repository — Вы выбираете, кто может видеть и фиксировать (оставлять коммиты) этот репозиторий.

После этого мы увидим следующее:

Выбираем вариант push an existing repository from the command line — добавить существующий репозиторий из командной строки. Для этого нужно:

Скопировать команду, выделенную на иллюстрации синим цветом и вставить в терминал программы VScode.

git remote add origin https://github.com/veavl/udemy_RU_02.21.git

Что делает эта команда? Что при этом происходит ?

В папке, содержащей локальный репозиторий, мы запускаем команду git remote add origin — при этом устанавливается подключение к удаленному серверу и git репозиторию на нем:
— git — это должно быть обязательно;
— remote add — сама команда;
— origin — имя удаленного репозитория , которое дается по умолчанию и далее url-адрес к нему https://github.com/veavl/udemy_RU_02.21.git .

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

Вторая команда git push -u origin main позволяет отправить локальный репозиторий на сервер .

push в программировании означает заталкивание элемента в массив/стек, или git-ветки на удаленный репозиторий.

— origin — имя удаленного репозитория и main — это ветка удаленного репозитория.

-u — это ключ, который устанавливает связь с веткой main. Этот ключ указывается единожды . В дальнейшем при использовании команды git push отправка локальных данных на сервер будет связана именно с веткой main

То есть при следующей отправке локального репозиторий на сервер команда git push -u origin main сокращается до git push.

Ошибка — error: failed to push some refs

При попытке выполнить команду git push -u origin main возможно появление ошибки: error: failed to push some refs to ‘https://github.com/veavl/udemy_RU_02.21.git’

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

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

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

Второй вариант указан на сайте GitHub (это также отражено на иллюстрации выше): перед выполнением команды git push -u origin main следует выполнить команду git branch -M main, после которой в локальном репозитории главная ветка также будет носить имя main.

Команда git branch -M main переименовывает ветку master на локальном репозитории в main. Таким образом, изменения , произошедшие на удаленном репозитории больше не конфликтуют с локальным хранилищем , в котором главная ветка стала также называться main.

Теперь осталось проверить результат проделанной работы: удалось ли нам заpush-ить "затолкнуть" наш локальный репозиторий на удаленный сервер.

Все прошло успешно. Все файлы локального проекта теперь есть и на удаленном репозитории: это файл index.html и папка js , содержащая файл script.js .

И если кликнуть на второй контрольной точке second point (на втором коммите), то будут отображаться изменения, сделанные в файле index.html . Это видно на нижней иллюстрации: были изменения в теге title.

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