Git gui here что значит

Русские Блоги

Базовая работа Git GUI

1. Основные операции графического интерфейса пользователя Git

1. Инициализация репозитория

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

Щелкните правой кнопкой мыши пустое пространство папки, которую вы хотите инициализировать, и выберите Git GUI Here.Папка будет автоматически расположена в текущей папке, когда вы создадите новый репозиторий.

2. Описание графического интерфейса.

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

Повторное сканирование: сканирование измененных файлов и отображение их в рабочей области. Графический интерфейс не обновляет изменения на складе в реальном времени, вам нужно нажатьRescanКнопка для повторного сканирования.
Этап изменен: поместите все файлы из рабочей области во временное хранилище.
Выйти: прикрепите информацию о текущей учетной записи git к отправленным инструкциям. Когда несколько человек работают вместе, удобно видеть представленных редакторов.
Зафиксировать: зафиксировать файлы из области временного хранения в репозитории.
Отправить: отправить в удаленный репозиторий.

3. Новый файл

Начнем с добавления нового файла в gitpractise Новое в hello.txt File, затем нажмите Rescan, вы увидите hello.txt Появляться вРабочая зона

Изменения в отправленных файлах можно отменить, выбрав «Зафиксировать» -> «Вернуть изменения».

4. Временное хранилище

Commit -> Stage To Commit

Операция здесь заключается в том, чтобы поместить выбранный отдельный файл во временную область хранения (сочетание клавиш Ctrl + t). Можно удерживать несколько файловshift/ctrlСделайте выбор. Нажмите «Этап изменен напрямую», чтобы сохранить все

4.1, отменить временное хранение

Я хочу отредактировать перед отправкой. Фиксация -> Отключить от фиксации

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

5. Отправить

6. Узел версии и откат

6.1. Просмотр узла версии

Чтобы продемонстрировать откат версии, я hello.txt Внес изменения и отправил. На данный момент у нас есть две версии. Репозиторий -> Визуализировать историю мастера

6.2. Откатиться и вернуться к первой версии

Существует три режима сброса: ** мягкий | смешанный | жесткий **. Различные режимы по-разному влияют на рабочую область, область временного хранения и библиотеку версий, как показано на рисунке ниже:

soft: история отправки версии отката, область временного хранения и рабочая область остаются без изменений.

Два, ветвление и слияние

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

1. Создайте ветку

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

Коммутация ответвлений, Brach — Checkout

Перед переключением необходимо сохранить рабочую область и область подготовки текущей ветки.Чистый(чистый), то есть незафиксированных изменений нет. Если вы изменили его половину, и вам нужно переключиться на другую ветку по разным причинам, вы можете использовать команду git stash, которая будет записывать статус файлов в текущей рабочей области и области временного хранения, а также «сохранять» рабочий сайт, поэтому Рабочая зона чистая. Вернитесь в эту ветку снова и используйте команду git stash pop, чтобы восстановить сцену. Git GUI не предоставляет связанных операций, вам нужно перейти в Git bash, чтобы выполнить эти две команды.

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

Для демонстрации я также создал новую ветку, используя master в качестве прототипа.branch2
(1), изменить в branch1 hello.txt Первый актhi

world.И добавляем файл world.txt
(2), изменить в branch2 hello.txt Первый актwork hard pls.

Давайте посмотрим на текущую ситуацию с веткой:

2.1, объединить ветку 1 с мастером

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

world.И добавляем файл world.txt , Следующий шаг — проверка. Сначала переключитесь на мастер ветки, затем нажмите Слияние -> Локальное слияние в строке меню.

Результат ожидаемый. Посмотрите на ситуацию в ветке в это время:

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

2.2, объединить ветку 2 с мастером

Затем мы объединяем ветку 2 с мастером.

Слияние не удалось! Давайте подробнее рассмотрим сообщение об ошибке:

В поле подсказки есть предложение:Automatic merge failed, То есть автоматическое объединение не удалось. Сравним с советами по слиянию branch1

Мы виделиFast-forwardПодсказки. Поскольку мастер является прямым восходящим потоком ветви branch1, подлежащей слиянию, мастер может достичь ветви branch1, спустившись вниз. Эта однострочная историческая ветвь не имеет никаких различий, которые необходимо разрешить. Процесс слияния называется Fast forward.

Мастер после слияния ветки 1 больше не является прямым восходящим потоком ветки 2. В это время слияние ветки 2 потребует разрешения различий (если таковые имеются). ПоэтомуAutomatic merge failed: fix conflicts and then commit the resultПодсказки. (Не удалось выполнить автоматическое объединение, пожалуйста, разрешите конфликт перед отправкой). Git записывает все конфликтующие места в файле в файл и отображает его вОбласть различия, Мы можем следовать изображению, чтобы удалить ненужную часть в указанном файле, а затем временно сохранить его и отправить снова. (Временное хранилище здесь не может быть достигнуто нажатием на Stage Changed)

Branch1 и branch2 завершили свою миссию и могут быть удалены через Branch -> Delete.Одно замечание: вы не можете удалить ветку в работе.

Вид области разницы
Предыдущий «-1,2» разделен на три части: знак минус означает файл до изменения, «1» означает первую строку, а «2» означает две последовательные строки. Вместе это означает, что это две последовательные строки, начинающиеся со строки 1 файла до модификации. Точно так же «+1,6» означает, что после изменения это становится 6 последовательными строками, начиная с первой строки измененного файла.

3. Удаленное сотрудничество

Теперь мы используем проект ASP.NET MVC, размещенный на GitHub, для демонстраций удаленного сотрудничества.

1. Клонируйте удаленный склад на локальный

2. Игнорировать файлы

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

2.1, создайте деталь .gitignore файл

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

На Github есть официальные рекомендации для множества популярных операционных систем / сред / языков разработки. .gitignore файлпроект. Также может пройтиgitignore.ioСоздайте соответствующую операционную систему / язык разработки / IDE .gitignore файл.

2.2, создайте глобальный .gitignore файл

Мы также можем передать глобальный .gitignore Файл будетИгнорировать правилоПрименить ко всем репозиториям Git на этом компьютере.
（1）、git config —global core.excludesfile

/.gitignore_global。
(2), создать в корневом каталоге пользователя .gitignore файл.

2.3. Исключить склад прямо

Если вы не хотите использовать .gitignore Файл, вы также можете перейти в корневую директорию склада .git/info/exclude Добавление файлаИгнорировать правилоДостигните цели игнорирования указанных файлов / папок этого хранилища.

1. Если файл был добавлен в репозиторий, добавьте соответствующее правило игнорирования в gitignore/exclude Файл не вступит в силу. В этом случае вам нужно сначала отключить файл с помощью следующей команды:
git rm —cached FILENAME
2, глобальный и локальный .gitignore Файлы будут работать вместе.

3. Тяни и толкай

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

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

Получите сообщение об ошибке:

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

1. Получите запись версии удаленного хранилища Remote -> Fetch

2. Локальное слияние -> Локальное слияние

После разрешения конфликта нажмите еще раз:

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

Источник

Git GUI моей мечты

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

Гит имеет максимально функциональный command-line интерфейс и десятки если не сотни приложений для работы с ним локально при помощи графического интерфейса, которые умеют выполнять только часть функционала гита. Беда в том, что я пишу код уже 10 лет, но никак не нашел идеальный (подходящий для меня) git GUI клиент. Пример: недавно вышел Github Desktop. Я его использовал до тех пор, пока мне не понадобилось сделать checkout на конкретный коммит. И я испытал уже привычную боль от того, что данное приложение так делать не умеет. И вновь вернулся в терминал (с автодополнением для гита). И такие вещи есть в каждом GUI приложении для гита. Однако, я сюда пришел не критиковать их. Уверен, что вы и без меня имеете много претензий к этим приложениям. Я долго думал о том каким должно быть идеальное git GUI приложение. Это были мимолетные обрывки желаний, из которых трудно собрать что-то цельное. И совсем недавно эти обрывки мыслей у меня собрались в единую картину. Ниже я опишу это в формате ТЗ (технического задания) в максимально понятной форме.

Идеальный Git GUI клиент

Важно чтобы интерфейс не был суперусложнен. Если юзер откроет прилажку и увидит больше 20 кнопок, то идея отстой. Бóльшая часть пользователей переключаясь на консоль для работы с гитом пишут команду git status чтобы узнать список файлов с измененным статусом. Потому наше приложение должно почти на весь экран показывать список файлов в виде иерархии, которые имеют измененный статус (примерно как проводник/finder). Туда будет входить все, что мы можем увидеть командой git status : измененные файлы, untracked файлы, добавленные и удаленные (возможно, какой-то статус я забыл). Каждый файл должен как и в консоли отображаться либо красным цветом, либо зеленым, что показывает его добавленность в коммит. На любой файл можно кликнуть правой кнопкой мыши или нажать на три точки в правой части строки чтобы вызвать контекстное меню. В контекстном меню можно добавить файл если он не добавлен ( git add команда в терминале), сделать reset если он добавлен, удалить если он не находится в индексе (clean). Еще можно кликнуть на папку правой кнопкой и добавить всю папку ( git add folder ). Аналогично работает reset. Еще можно добавить в индекс все маленькой кнопкой в верхнем левом углу дерева файлов. Можно кликнуть по строчке с файлом чтобы открыть дифф по нему на весь экран.

Сверху окна есть отдельный заголовочный блок примерно как в Xcode с названием ветки и статусом того, что сейчас происходит (pulling, pushing, idle). Это все. То есть, окно по-умолчанию только показывает статус: нынешнюю ветку и статус файлов.

Когда пользователь намерен сделать какое-либо действие ( git log — посмотреть историю, git branch — операция с ветками, git commit — осуществление коммита, git push — загрузка в remote, git pull — загрузка из remote, git remote — управление списком remote и т.д.) он должен зажать tab чтобы вызвать селектор действий (прям как селектор оружия в GTA 5).

Далее пользователь наводит указатель мыши на нужную команду и кликает на нее. После этого происходит вызов команды если это команда без аргументов (например, pull, push, fetch). Если нужно указать аргументы, то пользователь кликает правой кнопкой на название команды (например, push) и появляется соответствующее модальное диалоговое окно с вводом аргументов (цель remote и имя ветки, а также галочка force), которые указываются мышью или горячими клавишами. К этом моменту изначально зажатый tab можно уже отпустить. Если кликнуть за пределами модального окна или нажать esc, то модальное окно закроется и вызов команды будет отменен. Если же в этом модальном окне указать аргументы и нажать кнопку push, то начнется выполнение команды. Процесс выполнения команды будет отображен на верхней панели под названием ветки.

Еще одно важное преимущество терминала над остальными git GUI приложениями это возможность склеивать команды последовательно при помощи операторов && и ||. Например, я лично в работе часто использую такую последовательность для подлития в свою ветку той ветки, от которой моя ветка была срезана:

git checkout dev && git pull && git checkout — && git merge —

Данная последовательность выполняет 4 операции:

переключается на ветку dev

скачивает последние изменения ветки dev

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

вливает ветку dev в нынешнюю ветку

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

Для того, чтобы указать команду и добавить после нее другую команду нужно сделать то же самое, что и для указания обычной команды, но помимо кнопки tab нужно еще зажать alt (или shift, тут нужно еще подумать). То есть, в привычном уже круговом селекторе мы выбираем команду checkout, указываем ветку dev, жмем ok в окошке, где мы указывали ветку. Однако из-за того, что в момент появления окошка помимо клавиши tab была зажата еще и клавиша alt, команда checkout не начинает выполняться сразу после нажатия ok, а добавится в список, который появляется в верхнем левом углу, а селектор продолжит отображаться в ожидании новой команды (tab держать уже не нужно — селектор остается открытым после указания первой команды с зажатым alt). Также указываем другие команды левой или правой кнопкой мыши как обычно — они пополняют список команд. Когда мы завершили этот список жмем еще раз tab (или esc если передумали), селектор закрывается, команды начинают выполняться, их статус виден на верхней панели статуса. Признаться честно, на эту идею меня подтолкнул смелая фича в игре Red Alert 2. Там можно зажать клавишу z и указать последовательность точек куда следует идти юниту. Я считаю, что это гениальная фича, которой очень не хватает в других популярных стратегиях.

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

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

Эмоджи намного лучше запоминаются человеком, чем безымянные шестнадцатеричные хэши. Если везде, где мы ни показывали хэши коммитов (история или статус pull’а), показывать их эмоджи хэши, то пользователь лучше будет помнить на каком он коммите работает прям сейчас, и меньше будет ошибок когда он забыл влить другую ветку, запушить или запулить изменения. Вообще было бы здорово если бы эмоджи-хэш использовался везде: на github, bitbucket, teamcity. Это позволило бы проще сверять коммиты билдов с коммитами в истории.

Источник