Git extensions инструменты linux sh не найдены

Обновлено: 03.07.2024

терминология

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

Настройка рабочей станции / Visual Studio

В последнее время Microsoft, похоже, признает Git в качестве ценной альтернативы своей проприетарной TFS (Team Foundation Server) тому, что касается контроля версий, и поэтому начала выпускать свое собственное расширение Visual Studio, которое в настоящее время находится в фазе «предварительного просмотра». Вы можете найти его здесь: Visual Studio Tools for Git (Microsoft)

Скотт Хансельман также написал об этом. Я быстро попробовал плагин и, хотя он отлично интегрируется с Visual Studio (в основном, как TFS), он все еще слишком большой бета на мой вкус.

В настоящее время лучшая альтернатива, которую я нашел, — это установить Git Extensions для Windows и Git Source Control Provider Visual Studio Plugin. В следующих разделах рассматриваются соответствующие установки.

Установите Git Extensions для Windows

Первым шагом является загрузка Git Extensions из соответствующего Google Code Repository .

Его мастер установки установит все, что вам нужно для полной настройки Git, установки Git (из git-scm ) в различные инструменты Unix для Git Bash.

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

Вы найдете этот контрольный список при открытии приложения Git Extensions, а затем перейдя к Plugins > Settings .

Установка Git Source Control Provider

Git Source Control Provider — это расширение с открытым исходным кодом, которое использует установку Git вашей машины и интегрирует ее в Visual Studio.

Если вы успешно настроили Git (следуя процедуре, упомянутой выше), вы можете продолжить и установить расширение Git Source Control Provider для Visual Studio. Возможно, самый простой способ — через диалоговое окно «Расширения и обновления», в котором вам нужно просто выполнить поиск «git source control».

В качестве одного из следующих шагов вам нужно правильно установить провайдера исходного кода в Visual Studio, поскольку у вас их может быть больше (например, TFS). Это делается в настройках Visual Studio в разделе «Source Control»:

Вы должны увидеть запись «Git Source Control Provider». Выберите это и подтвердите ваши настройки. После этого вы также должны убедиться, что он правильно ссылается на ваши установки Git и Git Extensions:

Настройка вашего ключа SSH

Многие репозитории Git-сервера допускают разные модели аутентификации:

Лично я предпочитаю последнее, так как ненавижу постоянно вводить свои учетные данные.

Чтобы получить руководство по генерации открытого ключа SSH, просто обратитесь к документации по GitHub, которая довольно подробно и хорошо объяснена.

Ну, вот и все, что касается установки. Теперь вы должны быть готовы начать.

Давайте начнем: создайте новый Git-репозиторий

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

Это можно сделать, щелкнув правой кнопкой мыши по решению и выбрав «Создать Git Repository»:

После этой операции вы должны увидеть репозиторий для успешной настройки:

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

Просто щелкните их все, добавьте содержательный комментарий и подтвердите их, нажав кнопку «Подтвердить».

Git SCP (отныне ссылающийся на расширение Git Source Control Provider для VS) предоставляет очень удобный и удобный механизм для просмотра реальной ситуации в вашем Git-репозитории, а именно путем визуализации лежащего в его основе дерева Git. Просто нажмите кнопку «История» …

… В окне «Ожидающие изменения» откроется новое окно с красивым графиком:

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

.gitignore

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

Из коробки Git SCP уже создает тот, который подходит для Visual Studio. В противном случае вы можете обратиться к проекту Gitignore GitHub, который представляет собой набор файлов .gitignore для различных типов IDE и языков программирования.

Создать и зафиксировать новый файл

Просто добавьте новый файл в ваш проект Visual Studio. Я добавил Person.cs с некоторым контентом. Вы должны сразу увидеть изменения, перечисленные в окне Pending Changes.

Примечание. Вы можете открыть окно « Ожидающие изменения », щелкнув правой кнопкой мыши проект или файл решения Visual Studio и выбрав «Git (master)», а затем «Ожидающие изменения».

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

Наше дерево после коммита выглядит так:

Создать (особенность) ветку

Чтобы создать новую ветку, нажмите кнопку « Расширения Git» в окне ожидающих изменений, а затем « Создать ветку».

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

Примечание: мы также устанавливаем флажок «Оформить заказ после создания», и сразу же переключаемся на новую ветку. Это как-то похоже на git checkout -b <branch-name> команду на оболочке.

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

Более того, в окне Pending Changes мы теперь видим текущую ветвь, в которой мы находимся, которая является только что созданной «my-feature-branch».

Теперь мы можем изменить существующий файл — скажем, наш Person.cs — и зафиксировать его. Окно Pending Changes точно показывает разницу изменений до того, как мы их передадим

После внесения изменений дерево продвинулось и обратите внимание, что сейчас master и my-feature-branch указывают на разные места. HEAD находится в нашей ветви функций, поскольку она является текущей активной.

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

Вернемся к мастеру . Мы можем сделать это — снова — используя кнопку ветви Checkout из меню «Git Extensions».

Мы должны выбрать в master качестве нашего филиала и продолжить.

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

Дерево Git отражает это переключение на master ветку, так как оно HEAD теперь правильно указывает master снова.

Если представленной ниже информации окажется недостаточно, напишите к статье комментарий с вопросами. Итак, начнем..

Небольшая прелюдия

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

Установка GitExtensions

По завершению установки у вас на рабочем столе и в меню ПУСК появится ярлык Git Extensions. Запустим программу и начнем работу с Git.

Первый запуск программы

Нажимаем на красной полоске:

Это была первая статья из серии GitExtensions. А пока выходит вторая, у вас будет достаточно времени, чтобы подтянуть свои знания, изучив такие понятия, как коммит, ветвь (branch), репозиторий, слияние (merge), pull, push.

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

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

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

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

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

Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:
Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

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

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

Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

Командная строка должна вернуть что-то вроде:

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

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

В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:

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

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

Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:

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

1. Подключение к удаленному репозиторию

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

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

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

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

Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

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

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

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

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

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

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

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

Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками

Сейчас, если мы запустим branch, мы увидим две доступные опции:

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

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

Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

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

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

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

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

1. Отслеживание изменений, сделанных в коммитах

У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

[/spoiler]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
[spoiler title='Вывод git show']

[/spoiler]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

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

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

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

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

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

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

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

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

Тим предпочитает forEach:

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

[/spoiler]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

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

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

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

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

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

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

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.

Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

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

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

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

Im с использованием версии Git Extensions [2.50.02 - последняя (текущая)]. Когда я открываю "Объединить ветки", я вижу флажок "Не совершать". Когда я

Как настроить Araxis merge/diff с помощью Git Расширений? Я пытаюсь настроить Araxis merge с помощью "Git Extensions" , но не нашел никакой помощи, все ссылки или поисковые запросы направляются тол.

Когда я открываю Git Extensions и использую git из bash, я часто сталкиваюсь с ошибкой: fatal: Не удалось создать '/home/ldombek/code/navkit/.git/index.lock': Файл существует. В этом репозитории ра.

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

Я использую Visual Studio 2010 Express. Я знаю, что это издание не поддерживает интеграцию расширений git. Поэтому я попробовал автономный источник управления Gui, как git расширения, но сегодня я .

Есть ли способ изменить аргументы на утилиту diff по умолчанию, используемую расширениями git, в контексте самих Git Extensions, НЕ, изменив настройки Git Extensions для запуска внешней утилиты?

Я использую Git расширения как дополнение в Visual Studio 2010. Он отлично работает. Однако всякий раз, когда я собираюсь передать репозиторий, GUI заставляет меня вручную выбирать соответствующие .

Мои извинения, если это глупый вопрос, но я парень VSS/VSTS, пытающийся преобразовать в Git:) Я клонировал репозиторий и сбрасывал загрузку проектов Visual Studio. Работая над этими проектами, я за.

Я установил, что мой.gitignore игнорирует файлы.sdf и.vcxproj, но они все еще продолжают появляться в Git Extensions, чтобы я мог их совершить. В частности, *.sdf вызывает множество конфликтов, пос.

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

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

При попытке клонирования репозитория через новейшую версию Git Extensions появляется окно, в котором говорится: Ключ хоста сервера не кэшируется в реестре. Вы не имеют гарантии, что сервер - это ко.

Я изучаю git в Windows, я установил git Extensions (Version 2.47.3) и немного поиграл с ним. Я создал голый репозиторий в своем блоке C: (как центральный репозиторий) и личный репозиторий где-то ещ.

Как указано в названии. Мне было интересно, что будет, когда я Reset current branch to here . Я спрятал все изменения, которые я сделал, и хочу: 10 месяцев, 2 недели назад

У меня несколько коммитов на сервере, некоторые избыточные, и я бы хотел их сквош. Я нашел в stackoverflow, как это делается через командную строку, но не используя Git Extension.

Мне нужно создать клон-репозиторий. но я не знаю, где я могу получить файл ssh key Обновление: git clone tes

Я использую git bash под окнами, потому что сейчас у меня проблемы с Linux. Я должен сделать фиксацию, но я не знаю, как создать файл с расширением .md под платформой Windows. не могли бы вы расска.

Я хочу создать тег для текущей версии. Я не вижу никаких параметров для этого в контекстном меню Windows.

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

Есть ли простой способ получить diff в рабочем каталоге с помощью Git Расширения UI (помимо диалога Commit)? Похоже, что View Diff должен позволять мне различать мой рабочий каталог и версию фиксац.

Представьте решение в Visual Studio 2008, состоящее из трех проектов. Два из них - файловая система, расположенная в домашней директории решения, и третья, добавленная с помощью добавления существу.

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

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

У меня установлены расширения Visual Studio 2012 v3 и git. Я хочу изменить инструмент слияния по умолчанию для winmerge, но кажется, что это не тривиальная задача при выборе Microsoft git Provider.

Я пытаюсь запустить команду arc arc из git bash, которая открывается из расширения git, и это бросает мне исключение. Когда я открываю bash.exe непосредствен

У меня есть мой сайт, хранящийся на удаленном сервере Linux, и я использую FTP для загрузки, редактирования и повторной загрузки. В настоящее время я могу использовать git bash для подключения и за.

У меня установлен VS 2008, и я поставил Git и Git Extensions в свою систему. Я запускаю Windows 7. Когда я запускаю VS и работаю, кнопки будут серыми. Если я запустил указатель мыши над ними, они с.

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

Я пробовал: щелкните правой кнопкой мыши на панели инструментов и снимите флажок GitExtensions щелкните правой кнопкой мыши на панели инструментов > Настроить и удалить GitExtensions переместил .

Я пытался установить Git Extensions много раз и не могу заставить его отображаться в VS 2010. Просто нет меню панели инструментов Git. Любые идеи?

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

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

Как я могу выполнить git pull form много репозиториев? Это возможно с помощью GitExtension?

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

Я действительно подключаюсь к удаленному репозиторию и могу сделать это с помощью git bash но не используя gitextensions . git bash запрашивает у меня пароль, но git расширения нет. Есть ли у кого .

Я пытаюсь создать запрос на перенос для репозитория nuget git (из которого я только что сделал клон). Я сделал локальную фиксацию. Но когда я пытаюсь создать запрос на pull, я получаю следующую оши.

Рубрики

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

Однако, я бы хотел увидеть визуальный разницу между двумя ветвями. Пока что лучший вариант:

который не очень информативен и не очень визуальен.

Есть ли что-нибудь лучше?

ОТВЕТЫ

Ответ 1

Это будет сравнивать советы каждой ветки.

Если вы действительно хотите использовать какое-то программное обеспечение GUI, вы можете попробовать что-то вроде SourceTree, которое поддерживает Mac OS X и Windows.

Ответ 2

Чтобы увидеть визуальные различия всех различий между двумя ветвями, мне нравится объединять две ветки - БЕЗ фиксации слияния - и затем использовать git gui или git Extensions, чтобы получить обзор различий.

Командная строка Git для слияния без коммитов:

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

(h/t к @jcugat для комментария)

Ответ 3

Если вы используете Intellij Idea IDE, вы можете просто использовать опцию сравнения в ветке.

Ответ 4

Вы также можете сделать это с помощью gitk.

Сначала нажмите на кончик ветки1. Теперь щелкните правой кнопкой мыши на кончике ветки2 и выберите Diff this- > selected.

Ответ 5

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

Ответ 6

Если вы используете OSX или Windows 7+, Atlassian SourceTree работает очень хорошо для этого. Это бесплатно.

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

Предполагая, что вы проверили ветвь функции, и вы хотите увидеть diff против "master", щелкните правой кнопкой мыши на ветке "master" и выберите "Diff to current"

К сожалению, похоже, что он будет доступен в дистрибутивах * nix в ближайшее время.

Ответ 7

Я нашел статус имени для резюме, но difftool выполнит итерацию изменений (и параметр -d предоставит вам представление каталога), например

Или как @rsilva4, упомянутый в -d , и по умолчанию ваша текущая ветка просто - например. сравнить с мастером:

Ответ 8

Если вы используете github, вы можете использовать веб-сайт для этого:

Это покажет вам сравнение двух.

Ответ 9

В GitExtensions вы можете выбрать обе ветки в сетке ревизий с нажатой клавишей Ctrl . Затем вы можете видеть файлы, которые отличаются между этими ветвями. Когда вы выберете файл, вы увидите diff для него.

Ответ 10

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

Linux: я имел успех с:

Например, чтобы установить smartgit на Ubuntu:

Это делает работу:

git-diffall с инструментом различий GUI, таким как meld. Смотрите пункт 5 здесь:

Ответ 11

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

Ответ 12

Вы можете использовать бесплатный P4Merge из Perforce, чтобы сделать это:

Подробности об интеграции с Git можно найти здесь и здесь

но краткое изложение приведенных выше ссылок:

Изменения для .gitconfig

Ответ 13

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

Ответ 14

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

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

Ответ 15

Вот как можно увидеть визуальную разницу между целыми коммитами, в отличие от отдельных файлов, в Visual Studio (протестировано в VS 2017). К сожалению, он работает только для коммитов в пределах одной ветки: в "Team Explorer" выберите представление "Branches", щелкните правой кнопкой мыши по репо и выберите "View history", как показано на следующем рисунке.

Затем история текущей ветки появляется в основной области. (Там, где ветки, которые закончились как более ранние коммиты в текущей ветке, помечены метками.) Теперь выберите пару коммитов с помощью Ctrl-Left, затем щелкните правой кнопкой мыши и выберите "Compare Commits. " во всплывающем меню.

Дополнительную информацию о сравнении веток в мире Microsoft см. В этом вопросе о стековом потоке: Различия между ветками git, использующими Visual Studio.

Читайте также: