Tortoisegit для начинающих: Инструкция-шпаргалка для начинающих / Хабр

Содержание

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

19 марта 2020 Разное Git

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

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

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

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

Содержание

1 Установка Git
2 Графический интерфейс Git
3 Конфигурация Git
4 Создание репозитория
5 Ветвление
6 Gitk
7 Файл . gitignore
8 Легкий тег

Установка Git

Самый простой способ установить Git на ПК или Mac — использовать установочный пакет. Загрузите установочный пакет с http://git-scm.com/downloads. Дважды щелкните по нему и следуйте указаниям мастера, чтобы установить Git на свой компьютер.

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

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

Source Tree — бесплатно для Mac и Windows
Tower — $67.80 (приблизительно), только для Mac
SmartGit — $79 Mac, ПК и Linux
GitX — бесплатно для Mac
TortoiseGit — бесплатно для Windows

Конфигурация Git

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

$ git config --global user. name "Joe Bloggs"

$ git config --global user.email "[email protected]"

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

Теперь после настройки Git мы можем создать наш первый Git-репозиторий. Перейдите в каталог ваших проектов:

$ cd path/to/project

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

$ git init

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

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

$ git status

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

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

$ git add index.html style.css

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

$ git add .

Эта команда добавит все ваши файлы в область подготовки Git.

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

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

$ git commit -m "Initial Commit"

Ветвление

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

$ git branch

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

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

 $ git checkout -b new-features

Мы только что создали новую ветку под названием «new-features» и переключились на эту ветку. Если мы запустим ветку Git, вы увидите следующее:

В нашей новой ветке мы добавим несколько новых файлов JavaScript. Если мы выполним git status, он определит, что новые файлы JavaScript не отслеживаются. Итак, мы сделаем это и зафиксируем библиотеку JavaScript:

 $ git add .
$ git commit -m "JavaScript Library"

В данный момент это файлы проекта в нашем каталоге:

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

$ git checkout master

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

Gitk

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

$ gitk

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

Вы можете заметить, что в этом ничего нет о ветке new-features. Это потому, что gitk выполняется только в основной ветке. Мы можем использовать флаг —all для отображения всех коммитов веток. Закройте окно gitk и в командной строке запустите:

$ gitk —all

Теперь мы видим коммиты, сделанные во всех ветках, включая new-features.

Допустим, мы закончили работу над нашими новыми функциями и довольны конечным результатом. Давайте объединим нашу ветвь с new-features в основную ветку. Закройте gitk и в командной строке запустите:

$ git merge new-features

Мы только что слили ветку new-features в основную ветку. Если вы посмотрите на наши файлы проекта, вы увидите, что JavaScript был объединен.

Существуют ситуации, когда вам не нужно фиксировать все в своем Git-репозитории — лично я использую SublimeText в качестве своего текстового редактора, но это программное обеспечение генерирует файлы .sublime-project и .sublime-workspace, которые мне не нужно фиксировать. Также ваши операционные системы могут генерировать пустые файлы, такие как .DS_Store или мусорные файлы.

Другое программное обеспечение можно купить у комсофт https://commsoft. ru/

В командной строке, если вы запустите git status, вы заметите, что Git выделит эти файлы и укажет, что они не отслеживаются.

Файл .gitignore

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

# Sublime Text generated files #
###########################
*.sublime-project
*.sublime-workspace
# OS generated files #
##################
.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
ehthumbs.db
Thumbs.db

В этом файле все, что c префиксом #, будет закомментировано. Теперь сохраните файл. Запустите git status снова, и вы заметите, что оба сгенерированных файла Sublime Text больше не отображаются в списке. Единственный файл без отслеживания — это .gitignore. Давайте добавим и это:

$ git add .
$ git commit -m "git ignore file"

Легкий тег

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

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

$ git tag release-1. 0.0.0

Это имя нашего тега с параметром release-1.0.0.0.

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

$ git tag -a release-1.0.0.0 -m "First full public release"

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

$ git tag

Если вы хотите просмотреть больше информации о конкретном теге, используйте git show с параметром tag:

$ git show release-1. 0.0.0

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

Слияния или мерджи веток. Урок 9

Видеоурок

Конспект урока

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

Ветка master — еще раз

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

Что такое мердж или слияние веток

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

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

Разница логическая

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

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

Следует четко различать мердж своей ветки в мастер и мердж мастера в свою ветку.

Мердж ветки в мастер

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


    $ git checkout master
    $ git merge news

При этом возможны разные ситуации

Поговорим о них подробнее

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

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


    $ git merge news
    Updating f32b91e..33ea897
    Fast-forward
     index.html | 3 ++-
     1 file changed, 2 insertions(+), 1 deletion(-)
     
    $ git push origin master
    $ git branch -d news

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

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

Теперь другая ситуация.

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

Сначала переключаемся на мастер


    $ git checkout master 
    Switched to branch 'master'
    Your branch is up-to-date with 'origin/master'.

Почему «is up-to-date»? Потому что мы еще не сделали git pull. Делаем


    $ git pull --rebase origin master

Мерджим свою ветку в мастер


    $ git merge news-styles

И не забываем запушить изменения


    $ git push origin master

Что если сначала не подтягивать мастер, а смерджить свою ветку

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

Как вмерджить мастер в свою ветку

Сначала идем в мастер, подтягиваем изменения с сервера, то есть делаем git pull. Затем переключаемся в свою ветку и делаем git merge master


    $ git checkout master
    $ git pull --rebase origin master
    $ git checkout news-redesign
    $ git merge master

Затем проверяем, что ничего не поломалось и продолжаем работать.

Мердж коммиты

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

Посмотрим список коммитов и найдем мердж-коммит с хэшем 051f754


    $ git log --oneline 
    051f754 Merge branch 'news'
    ...

Посмотрим его содержимое


    $ git show 051f754
    
    commit 051f75475cb1dca3cd08c1c7367a3308671ccf7b
    Merge: 0a3a6a3 2346be5
    Author: Alexandr Shestakov 
    Date:   Sat Feb 8 14:10:39 2020 +0300
    
        Merge branch 'news'

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

Мерджи всегда проходят так гладко?

К сожалению, нет

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

Подробнее о конфликтах и их разрешении мы поговорим в следующем уроке.

Что могу посоветовать

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

Спасибо за внимание и до встречи!

Стратегии слияния в Git: параметры и примеры

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

Стратегии слияния в Git

Под слиянием подразумевается объединение двух веток. Git пытается найти общий базовый коммит для двух или более указателей. Есть несколько методов поиска. Они называются «стратегиями слияния». Когда Git находит общий базовый коммит, создается коммит слияния, который объединяет изменения определенных коммитов. С технической точки зрения, коммит слияния — это обычный коммит с двумя родителями.

Команда git merge автоматически выбирает стратегию слияния, если она не указана явным образом. Команды git merge и git pull могут использоваться с параметром -s (стратегия). К параметру -s можно добавить имя стратегии слияния, которую вы хотите использовать. Если стратегия явно не указана, Git выберет подходящую на основе предоставленных веток. Далее мы рассмотрим конкретные стратегии слияния.

Рекурсивная стратегия

git merge -s recursive branch2 branch3

Эта стратегия работает с двумя указателями HEAD. Она применяется по умолчанию при выполнении команды pull или merge для одной ветки. Рекурсивная стратегия позволяет обнаруживать и обрабатывать слияния с переименованием, но на сегодняшний день не может использовать обнаруженные копии. Эта стратегия применяется по умолчанию при выполнении команд pull или merge для одной ветки.

Решение

git merge -s resolve branch2 branch3

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

Стратегия «Осьминог»

git merge -s octopus branch2 branch3 branch4 branchN

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

Стратегия «Наша»

git merge -s ours branch2 branch3 branchN

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

Стратегия «Поддерево»

git merge -s subtree branchA branchB

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

Типы стратегий слияния в Git

Явное слияние

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

Скрытое слияние с использованием методов rebase или fast-forward

Склеивание (обычно без явного слияния)

Параметры рекурсивной стратегии слияния в Git

Рассмотренная выше рекурсивная стратегия имеет свой поднабор параметров.

Не следует путать этот параметр со стратегией слияния «Наша» (Ours). Он позволяет автоматически разрешать конфликты путем предпочтения «нашей» (ours) версии. Изменения с «их» (theirs) стороны внедряются автоматически, если в них отсутствуют конфликты.

theirs

Параметр theirs, напротив, отдает предпочтение чужому дереву слияния при разрешении конфликтов.

patience

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

diff-algorithim

ignore-*

    ignore-space-change
    ignore-all-space
    ignore-space-at-eol
    ignore-cr-at-eol

Набор параметров, которые ориентированы на символы пробела. Любая линия, которая соответствует поднабору передаваемого параметра, будет проигнорирована.

renormalize

Этот параметр запускает команды check-out и check-in во всех трех деревьях Git при разрешении конфликтов трехстороннего слияния. Он используется при слиянии веток с разными статусами checkin/checkout.

no-normalize

Отключает параметр renormalize. Это переопределяет переменную конфигурации merge.renormalize.

no-renames

Этот параметр игнорирует переименованные файлы во время слияния.

find-renames=n

Это поведение по умолчанию. При рекурсивном слиянии поддерживается переименование файлов. Параметр n можно использовать для передачи порогового значения сходства при переименовании. По умолчанию значение n равно 100%.

subtree

Этот параметр является вариантом стратегии «Поддерево» (Subtree). В то время как стратегия работает с двумя деревьями и задает способ их совмещения в общем родителе, этот параметр работает с метаданными пути дерева для обеспечения совмещения.

Наша политика слияния в Git

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

Глава 2. Руководство по ежедневному использованию Tortoisegit — Tortoisegit — Документация — Tortoisegit — интерфейс оболочки Windows для GIT

Содержание

Начало начало

ICON Oldways
Context Menus
и Drop

Optay Ярлыки
Аутентификация
Развернуть Windows

Создать репозиторий

Клонировать репозиторий

Извлечение рабочего дерева (переключение для фиксации)

, совершив свои изменения в репозитории

Диалог Commit

Списки изменений

За исключением элементов из списка комплектов

. Сделайте только части файлов

Наложение значков
Свойства проводника
Статус
Просмотр различий

Извлечение и получение изменений

Push

Branch
Destination
Options

Sync

Branch
Destination
Options

Daemon

Browse All Refs

Submodules

Change Lists

Log Диалоговое окно

Вызов диалогового окна журнала изменений
Действия в журнале изменений
Граф изменений
Сообщения фиксации и индикаторы ветвей/тегов
Getting Additional Information
Filtering Log Messages
Navigation
Statistical Information
Refreshing the View

Revision Graphs

Revision Graph Nodes
Using the Graph
Refreshing the View

Reference Журнал

Браузер репозитория

Просмотр различий

Различия файлов
Параметры конца строки и пробела
Сравнение версии
Diffing Sumdules с использованием диалога Diff Diff Diff
Diffing Images с использованием Tortoisegitidiff
Внешние инструменты Diff/Merge

Добавление новых файлов

Копирование/перемещение файлов и файлов ренамирования и папки

заголовки. Поиск по образцу в списках игнорирования

Удаление, перемещение и переименование

Удаление файлов и папок
Перемещающие файлы и папки
Изменение случая в имене файла
, работая с конфликтами имен файла
Удаление безоперационных файлов

undo изменение

. Создание ветки или тега

Слияние

Выбор вишни

Перебазирование

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

Специальные случаи конфликта

Создание и применение исправлений и запросов на привлечение

Создание патча сериала
Отправка исправлений по почте
Применение одного патча
.

Кто какую строку изменил?

Авторство файлов

Экспорт рабочего дерева Git

Интеграция с системами отслеживания ошибок / системами отслеживания проблем

Добавление номеров выпусков к сообщениям журнала

Git
Скрипты перехвата на стороне клиента
Настройки TortoiseGitBlame
Настройки TortoiseGitUDiff
Дополнительные настройки
Экспорт настройки tortoisegit

GIT SVN DCOMMIT

GIT LFS блокировка

Настройка репозитория
. документ описывает повседневное использование клиента TortoiseGit. Это , а не — введение в системы контроля версий, и , а не — введение в Git. Это больше похоже на место, куда вы можете обратиться, когда примерно знаете, что хотите сделать, но не совсем помните, как это сделать.
Чтобы узнать, где найти дополнительную информацию об управлении версиями с помощью Git, см. раздел «Руководство по чтению».
Этот документ также находится в стадии разработки, как и TortoiseGit и Git. Если вы обнаружите какие-либо ошибки, пожалуйста, сообщите о них в список рассылки, чтобы мы могли обновить документацию. Некоторые снимки экрана в Руководстве по ежедневному использованию (DUG) могут не отражать текущее состояние программного обеспечения. Пожалуйста, простите нас. Мы работаем над TortoiseGit в свободное время.
Чтобы получить максимальную отдачу от Руководства по ежедневному использованию:
Вы уже должны были установить TortoiseGit.
Вы должны быть знакомы с системами контроля версий.
Вы должны знать основы Git.
У вас должен быть настроен сервер и/или доступ к репозиторию Git.
Наложения значков
Рисунок 2.1. Проводник с наложением значков

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

Все команды TortoiseGit вызываются из контекстного меню проводника Windows. Большинство из них видны сразу, когда вы щелкаете правой кнопкой мыши файл или папку. Доступные команды зависят от того, находится ли файл, папка или ее родительская папка под контролем версий или нет. Вы также можете увидеть меню TortoiseGit как часть файлового меню проводника.
Совет
Некоторые редко используемые команды доступны только в расширенном контекстном меню. Чтобы вызвать расширенное контекстное меню, удерживайте нажатой клавишу Shift при щелчке правой кнопкой мыши.
В некоторых случаях вы можете увидеть несколько записей TortoiseGit. Это не ошибка!
Рисунок 2.3. Меню файла проводника для ярлыка в версионной папке

Этот пример относится к неверсионному ярлыку в версионной папке, а в меню файлов проводника есть две записи для TortoiseGit. Один для самого ярлыка, а второй для объекта, на который указывает ярлык. Чтобы помочь вам различать их, значки имеют индикатор в правом нижнем углу, показывающий, предназначен ли пункт меню для файла, папки, ярлыка или для нескольких выбранных элементов.
Перетаскивание
Рисунок 2.4. Меню перетаскивания правой кнопкой мыши для каталога с контролем версий

Другие команды доступны в качестве обработчиков перетаскивания, когда вы перетаскиваете файлы или папки правой кнопкой мыши в новое место внутри рабочих деревьев или когда вы перетаскиваете правой кнопкой мыши файл или папку без версии в каталог который находится под контролем версий.
Общие ярлыки
Некоторые общие операции имеют хорошо известные ярлыки Windows, но не отображаются на кнопках или в меню. Если вы не можете понять, как сделать что-то очевидное, например обновить представление, проверьте здесь.
F1
Помощь, конечно.
F5
Обновить текущий вид. Это, пожалуй, самая полезная одноклавишная команда. Например… В Проводнике это обновит наложения значков на вашем рабочем дереве. В диалоговом окне фиксации он повторно просканирует рабочее дерево, чтобы увидеть, что может потребоваться зафиксировать. В диалоговом окне журнала изменений он снова свяжется с репозиторием, чтобы проверить наличие более свежих изменений.
Ctrl-A
Выбрать все. Это можно использовать, если вы получили сообщение об ошибке и хотите скопировать и вставить его в электронное письмо. Используйте Ctrl-A, чтобы выбрать сообщение об ошибке, а затем …
Ctrl-C
. .. Скопируйте выделенный текст.
CTRL-F
Поиск
Аутентификация
SSH (URLS выглядит как [email protected])
Tortoisegitplink рекомендуется, потому что это лучше, потому что это лучше. По умолчанию TortoiseGitPlink не хранит пароли, вы можете использовать агент аутентификации PuTTY для кэширования пароля (выполняется автоматически, если ключ PuTTY настроен для удаленного доступа). Дополнительные советы и рекомендации см. в Приложении F, 9.0425 Советы и рекомендации по SSH/PuTTY . Обратите внимание, однако, что TortoiseGitPlink не учитывает ~/.ssh/config , который специфичен для OpenSSH (см. советы и рекомендации по PuTTY или настройте OpenSSH в качестве клиента SSH, см. следующий абзац). Если вы также хотите использовать TortoiseGitPlink в Git Bash, создайте переменную среды с именем GIT_SSH с путем к PuTTY plink.exe или, что предпочтительнее, к TortoiseGitPlink.exe. Это можно сделать, повторно запустив установщик Git для Windows (там вы можете выбрать, какой SSH-клиент использовать), в командной строке, выполнив установить GIT_SSH=PATH_TO_PLINK. EXE" ( C:\Program Files\TortoiseGit\bin\TortoiseGitPlink.exe при установке по умолчанию) или настроить переменные среды на постоянной основе .
Также можно использовать OpenSSH (поставляется с Git для Windows, Cygwin и MSYS2). Просто откройте настройки TortoiseGit, откройте страницу «Сеть» и введите ssh.exe в качестве клиента SSH, см. раздел «Настройки сети» и этот ответ на StackOverflow . Когда используется OpenSSH , вы также можете использовать ~/.ssh/config (см. этот ответ на StackOverflow ).
HTTP/HTTPS (URL-адреса начинаются с https:// или http://)
По умолчанию Git не сохраняет и не кэширует учетные данные. Однако вы можете настроить помощник по учетным данным (рекомендуется, см. также раздел «gitcredentials(7)») или вручную использовать %HOME%/_netrc .
Если вы настроили хранилище учетных данных и хотите очистить некоторые сохраненные учетные данные, см. этот ответ на StackOverflow .
Развертывание Windows
Многие диалоговые окна TortoiseGit содержат много информации для отображения, но часто бывает полезно максимизировать только высоту или только ширину, а не максимизировать до заполнения экрана. Для удобства на кнопке «Развернуть» есть ярлыки. Используйте среднюю кнопку мыши для увеличения по вертикали и правую кнопку мыши для увеличения по горизонтали.
© TortoiseGit и участники. Выходные данные/Политика конфиденциальности
TortoiseGit — TortoiseGit — Документация — TortoiseGit — Интерфейс оболочки Windows для Git
Содержание
Предисловие
Аудитория
Руководство по чтению бесплатно!
Сообщество
Благодарности
Терминология, используемая в этом документе

1. Введение

Что такое TortoiseGit?

История TortoiseGit

TortoiseGit’s Features

Installing TortoiseGit

System requirements
Installation
Language Packs
Spell checker

2. TortoiseGit Daily Use Guide

Getting Started

Icon Overlays
Контекстные меню
Перетаскивание
Общие ярлыки
Аутентификация
Развертывание Windows

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

Репозиторий клона

Проверить рабочее дерево (переключение на фиксацию)

, совершив ваши изменения в репозиторий

Диалог Commit
Списки
За исключением элементов из списка фиксации 9000

. только части файлов
Сообщения журнала фиксации
Выполнение фиксации

Получение информации о состоянии

Наложение значков
Explorer Properties
Status
Viewing Diffs

Pull and Fetch change

Push

Branch
Destination
Options

Sync

Branch
Destination
Options

Демон

Просмотреть все ссылки

Подмодули

Списки изменений

Диалог журнала

Вызов диалога журнала изменений
Действия журнала пересмотра
График ревизии
Сообщения о коммит и индикаторы филиала/теги

Узлы графа изменений
Использование графа
Обновление представления

Журнал ссылок

Браузер репозитория

Viewing Differences

File Differences
Line-end and Whitespace Options
Comparing Version
Diffing submodules using Submodule Diff Dialog
Diffing Images Using TortoiseGitIDiff
External Diff/Merge Tools

Adding New Files

Копирование/перемещение/переименование файлов и папок

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

Соответствие шаблону в списках игнорирования

Удаление, перемещение и переименование

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

Перемещающие файлы и папки

Изменение дела в файле

. Очистка

Сброс

Изменения тайника

Разделение пополам

Ветвление/маркировка

Создание ветки или тега

Слияние

Сбор вишни

Rebase

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

Специальные случаи конфликта

Создание и применение патчей и запросы на привлечение

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

. одиночный файл исправления

Применение исправления Серийный номер

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

Кто какую строку изменил?

вина в файлах

Экспорт рабочего дерева GIT

Интеграция с системами отслеживания ошибок / трекеров выпуска

Добавление номеров выпусков к сообщениям журнала

Общие настройки
Настройки наложения значков
Настройки сети
Настройки внешней программы
Настройки сохраненных данных
Git
Client Side Hook Scripts
TortoiseGitBlame Settings
TortoiseGitUDiff Settings
Advanced Settings
Exporting TortoiseGit Settings

git svn dcommit

Git LFS Locking

Setting up the repository
Locking a file
Разблокировка файла
Показать диалог блокировки

Последний шаг

3. Программа GitWCRev

Командная строка GITWCREV
Замена ключевого слова
Ключевое слово Пример
Интерфейс

A. Часто задаваемые вопросы (FAQ)

B.

Интерфейс IBugTraqProvider2

C. Полезные советы для администраторов

Развертывание TortoiseGit с помощью групповых политик
Redirect the upgrade check
Disable context menu entries

D. Automating TortoiseGit

TortoiseGit Commands
TortoiseGitIDiff Commands

E. Implementation Details

Icon Overlays

F. Советы и рекомендации по SSH/PuTTY

Введение

Как использовать сеансы

Часто задаваемые вопросы и примеры раздел

Как использовать ключ по умолчанию для всех соединений SSH
Как подключиться к серверу SSH через другой порт
Как использовать два разных ключа SSH для одного пользователя на одном хосте

GIT Официальная документация

Руководство пользователя GIT

Руководство по пользователю GIT

GIT TURAND

Gittutorial (7)
Gittutorial-2 (7)
Gitcore-tut-tut-tut -те-0008
GITCVS-миграция (7)
Giteveryday (7)

Справочник по команде GIT

GIT (1)
GIT-ADD (1)
GIT-AM (1)
GIT-ANOTATATTATETATE (1)
git-apply(1)
git-archimport(1)
git-archive(1)
git-bisect(1)
git-blame(1)
git-ветка(1) )
git-bugreport(1)
git-bundle(1)
git-cat-file(1)
git-check-attr(1)
git-check-ignore(1)
git-check-mailmap(1)
git-check-ref-format(1)
git-checkout-index(1)
git-checkout(1)
git-cherry-pick(1)
git-cherry(1)
git-citool(1)
git-clean(1)
git-clone(1)
git-column(1)
git-commit-graph(1)
git-commit-tree(1)
git-commit(1)
git-config(1)
git-count-objects(1)
git- учетные данные(1)
git-credential-cache—daemon(1)
git-credential-cache(1)
git-credential-store(1)
git-cvsexportcommit(1)
git-cvsimport(1)
git-cvsserver(1)
git-daemon(1)
git-describe(1)
git-diff-files(1)
git-diff-index(1)
git-diff-tree (1)
git-diff(1)
git-difftool(1)
git-fast-export(1)
git-fast-import(1)
git-fetch-pack(1)
git-fetch(1)
git-filter-branch(1)
git-fmt-merge-msg(1)
git-for-each-ref(1)
git-for-each- репо(1)
git-format-patch(1)
git-fsck-objects(1)
git-fsck(1)
git-gc(1)
git-get-tar-commit- id(1)
git-grep(1)
git-gui(1)
git-hash-object(1)
git-help(1)
git-http-backend(1)
git-http-fetch(1)
git-http-push(1)
git-imap-send(1)
git-index-pack(1)
git-init-db(1)
git-init(1)
git-instaweb(1)
git- интерпретировать-трейлеры (1)
git-log (1)
git-ls-files (1)
git-ls-remote (1)
git-ls-tree (1)
git-mailinfo ( 1)
git-mailsplit(1)
git-maintenance(1)
git-merge-base(1)
git-merge-file(1)
git-merge-index(1)
git-слияние с одним файлом (1)
git-merge-tree(1)
git-merge(1)
git-mergetool—lib(1)
git-mergetool(1)
git-mktag(1)
git-mktree (1)
git-mv(1)
git-multi-pack-index(1)
git-name-rev(1)
git-notes(1)
git-p4(1)
git-pack-objects(1)
git-pack-redundant(1)
git-pack-refs(1)
git-patch-id(1)
git-prune-packed(1)
git-prune(1)
git-pull(1)
git-push(1)
git-quiltimport(1)
git-range-diff(1)
git-read-tree(1)
git-rebase(1) )
git-receive-pack(1)
git-reflog(1)
git-remote-ext(1)
git-remote-fd(1)
git-remote(1)
git -repack(1)
git-replace(1)
git-request-pull(1)
git-rerere(1)
git-reset(1)
git-restore(1)
git -рев-лист(1)
git-rev-parse(1)
git-revert(1)
git-rm(1)
git-send-email(1)
git-send-pack(1)
git- sh-i18n —envsubst(1)
git-sh-i18n(1)
git-sh-setup(1)
git-shell(1)
git-shortlog(1)
git-show -branch(1)
git-show-index(1)
git-show-ref(1)
git-show(1)
git-sparse-checkout(1)
git-stage(1) )
git-stash(1)
git-status(1)
git-stripspace(1)
git-switch(1)
git-submodule(1)
git-svn(1)
git-symbolic-ref(1)
git-tag(1)
git-unpack-file(1)
git-unpack-objects(1)
git-update-index(1)
git-update-ref(1)
git -update-server-info(1)
git-upload-archive(1)
git-upload-pack(1)
git-var(1)
git-verify-commit(1)
git -проверить-пакет(1)
git-verify-tag(1)
git-web-browse(1)
git-whatchanged(1)
git-worktree(1)
git-write-tree(1)

MISC

Gitcli (7)
Gitattributes (5)
Gitcredentials (7)
Gitdiffcore (7)
Gitignore (5)
Gitfaq (7)
Gitignore (5)
Gitfaq (7)

Gitignore (5)
Gitfaq (7)

. 1)
gitmailmap(5)
gitmodules(5)
gitnamespaces(7)
gitremote-helpers(7)
gitrepository-layout(5)
gitrevisions(7)
gitsubmodules(7)
gitweb(1)
gitweb.conf(5)
gitworkflows(7)
gitglossary(7)

Глоссарий

Алфавитный указатель

Список иллюстраций

2.1. Проводник с наложением значков
2.2. Контекстное меню для каталога под контролем версий
2.3. Файловое меню проводника для ярлыка в версионной папке
2.4. Меню перетаскивания вправо для каталога под контролем версий
2.5. Диалог создания репозитория
2.6. Сообщение об успешном создании репозитория
2.7. Диалоговое окно клонирования
2.8. Диалог переключения/проверки
2.9. Диалоговое окно фиксации
2.10. Проверка орфографии в диалоговом окне фиксации
2. 11. Диалоговое окно «Ход выполнения», показывающее, что фиксация выполняется
2.12. Проводник с наложением значков
2.13. Страница свойств Explorer, вкладка Git
2.14. Проверка на модификации
2.15. Вытягивающий диалог
2.16. Диалог выборки
2.17. Нажмите диалог
2.18. Диалог синхронизации
2.19. Диалог запущенного демона
2.20. Диалоговое окно «Обзор ссылок»
2.21. Диалоговое окно удаления удаленных тегов
2.22. Диалог добавления подмодуля
2.23. Пункты контекстного меню подмодуля
2.24. Диалог обновления субмодуля
2.25. Кнопка обновления подмодулей в диалоге прогресса
2.26. Диалог фиксации со списками изменений
2.27. Диалог журнала изменений
2.28. Верхняя панель диалогового окна журнала изменений с контекстным меню
2.29. Свернутые ревизии
2.30. Диалоговое окно сообщений журнала поиска
2. 31. Контекстное меню верхней панели для 2 выбранных ревизий
2.32. Нижняя панель диалогового окна журнала с контекстным меню
2.33. Гистограмма коммитов по автору
2.34. Круговая диаграмма коммитов по авторам
2.35. График 9 коммитов по дате0008
2.36. График изменений
2.37. Диалог RefLog
2.38. Браузер хранилища
2.39. Диалоговое окно сравнения версий
2.40. Диалог отличия субмодулей
2.41. Средство просмотра разницы изображений
2.42. Контекстное меню проводника для неверсированных файлов
2.43. Добавить готовые
2.44. Меню перетаскивания вправо для каталога под контролем версий
2.45. Контекстное меню проводника для неверсированных файлов
2.46. Игнорировать диалог
2.47. Контекстное меню проводника для версионных файлов
2.48. Диалог возврата
2.49. Чистый диалог
2.50. Диалог сброса
2.51. Диалоговое окно «Прервать слияние»
2. 52. Диалог изменений тайника
2.53. (не)тайники
2.54. Начало биссектрисы
2.55. Варианты биссектрисы
2.56. Ветка Диалог
2.57. Диалог тегов
2.58. Диалог слияния
2.59. Диалоговое окно Cherry Pick
2.60. Диалоговое окно «Перебазировать»
2.61. Диалоговое окно разрешения конфликтов
2.62. Разрешение конфликта удаления-изменения Диалог
2.63. Разрешение конфликта субмодулей Диалог
2.64. Диалоговое окно «Создать патч»
2.65. Диалоговое окно отправки исправлений
2.66. Диалоговое окно выбора репозитория
2.67. Диалоговое окно «Применить исправление»
2.68. Диалог запроса на получение
2.69. TortoiseGitBlame
2.70. Диалог экспорта
2.71. Пример диалогового окна запроса средства отслеживания проблем
2.72. Диалог настроек, страница «Общие»
2.73. Диалог настроек, страница контекстного меню
2. 74. Диалог настроек, контекстное меню 2
2.75. Диалог настроек, страница диалогов
2.76. Пример символизации имен ссылок
2.77. Диалог настроек, диалоги Страница 2
2.78. Диалог настроек, диалоги 3 Страница
2.79. Диалог настроек, цвета Страница
2.80. Диалог настроек, страницы цветов
2.81. Диалог настроек, цвета Страница
2.82. Диалоговое окно настроек, страница наложения значков
2.83. Диалоговое окно настроек, страница набора значков
2.84. Диалог настроек, страница обработчиков значков
2.85. Диалоговое окно «Настройки», страница «Сеть»
2.86. Диалог настроек, настройки электронной почты
2.87. Диалоговое окно настроек, страница просмотра различий
2.88. Диалоговое окно настроек, страница инструмента слияния
2.89. Диалоговое окно «Настройки», расширенное диалоговое окно «Различие/объединение»
2.90. Диалог настроек, Альтернативный редактор Страница
2. 91. Диалоговое окно настроек, страница сохраненных данных
2.92. Диалог настроек, Git
2.93. Диалог настроек, Git, Remote
2.94. Диалог настроек, Git, Credential
2.95. Диалог настроек, страница скриптов хуков
2.96. Диалоговое окно настроек, настройка скриптов подключения
2.97. Диалоговое окно настроек, страница интеграции системы отслеживания проблем
2.98. Диалоговое окно настроек, конфигурация системы отслеживания проблем
2.99. Диалоговое окно настроек, TortoiseGitBlame Страница
2.100. Диалоговое окно настроек, страница TortoiseGitUDiff
2.101. Панель задач с группировкой по умолчанию
2.102. Панель задач с группировкой репозиториев
2.103. Группировка панели задач с наложением цветов репозитория
2.104. Диалог блокировки
C.1. Диалоговое окно обновления

Список таблиц

3.1. Список доступных ключей командной строки
3. 2. Список кодов ошибок GitWCRev
3.3. Список доступных ключевых слов
3.4. Поддерживаемые COM/методы автоматизации
C.1. Пункты меню и их значения
D.1. Список доступных команд и опций
D.2. Список доступных опций

Список примеров

G.1. Слить вверх
G.2. Тематические ветки
G.3. Слияние с нисходящим потоком только в четко определенных точках
G.4. Одноразовые интеграционные ветки
G.5. Убедитесь, что master является надмножеством обслуживание
G.6. Маркировка выпуска
G.7. Копировать
G.8. Обновите maint до новой версии
G.9. Перемотать и восстановить следующий
G.10. Push/pull: Публикация веток/тем
G.11. Push/pull: постоянное обновление
G.12. Push/pull: объединение удаленных тем
G.13. format-patch/am: Публикация веток/тем
G.14. format-patch/am: Обновление тем
G. 15. format-patch/am: Импорт патчей

Git Reference

Основные операции

Создать репозиторий
Зарегистрировать файлы/каталоги в индексе
Зафиксировать проиндексированные файлы
Посмотреть список измененных файлов
Просмотр различий в измененных файлах
Просмотр журнала фиксации
Просмотр сведений о фиксации
Переместить/изменить имя файла/каталога

Удалить файл
Удалить неотслеживаемые файлы из рабочего дерева
Восстановить измененный файл в рабочем дереве
Удалить файл из индекса
Зарегистрировать изменения только из файлов, добавленных в индекс

Я хочу создать репозиторий.

 $ git инициализация

Запустите команду «init» в каталоге, в котором вы хотите создать репозиторий.

Работа с Git: создать репозиторий

Зарегистрировать файлы/каталоги в индексе 903:30

 $ git добавить

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

Если вы добавите параметр -p, вам будет предложено принять/отклонить определенные разделы измененного файла. Если вы добавите опцию -i, вы сможете зарегистрировать измененные файлы в интерактивном режиме.

Работа с Git: коммит файла

Зафиксировать проиндексированные файлы

 $ git совершить

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

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

Работа с Git: коммит файла

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

 $ гит статус

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

Добавление параметра -s, за которым следует параметр -b, приведет к включению в вывод имени ветки.

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

 $ git разница

Команда «diff» по умолчанию покажет различия между рабочим деревом и индексом.

Если вы добавите параметр –cached, будут показаны различия между индексом и HEAD.

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

Просмотр журнала фиксации

 $ журнал git

«log» по умолчанию покажет список коммитов ветки.

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

Просмотр сведений о фиксации

 $ git show <коммит>

Укажите идентификатор фиксации, который можно найти с помощью команды log или HEAD в параметре команды show.

Переместить/изменить имя файла/каталога

 $ git mv <старое имя файла> <новое имя файла>

Удалить файл

 $ git rm <файл>

Удалить неотслеживаемые файлы из рабочего дерева

 $ гит очистить

Добавление параметра -n покажет только те файлы, которые будут удалены. Добавление опции -f фактически удалит файлы.

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

Восстановить измененный файл в рабочем дереве

 $ git checkout -- <файл>

Удалить файл из индекса

 $ git reset HEAD -- <файл>

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

 $ git добавить -u

Удаленные операции

Клонировать копию существующего удаленного репозитория
Добавить удаленный репозиторий
Просмотр списка удаленных репозиториев
Создать ветку в моем локальном репозитории на основе ветки в удаленном репозитории
Создать ветку в удаленном репозитории/отправить изменения в ветку в удаленном репозитории
Проверка измененного содержимого веток в удаленном репозитории

Как получить последние изменения ветки из удаленного репозитория и объединить их с моей текущей работой?
Удалить ветку в удаленном репозитории
Создать тег в удаленном репозитории
Удалить тег в удаленном репозитории
Изменить адрес существующего предварительно настроенного удаленного репозитория в моем локальном репозитории
Изменить имя существующего предварительно настроенного удаленного репозитория в моем локальном репозитории

Клонировать копию существующего удаленного репозитория

 $ git clone

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

Эта конфигурация позволяет выполнять Git push или Git fetch/pull без указания имени удаленного репозитория.

Работа с Git: клонировать удаленный репозиторий

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

 $ git удаленный добавить <имя>

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

 $ git удаленный

Если вы добавите параметр -v, вы сможете увидеть подробную информацию об удаленном репозитории.

Создать ветку в моем локальном репозитории на основе ветки в удаленном репозитории

 $ git checkout <ветка>

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

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

 $ git branch <название ветки> origin/<ветка>

Создать ветку в удаленном репозитории/отправить изменения в ветку в удаленном репозитории

 $ git push <репозиторий>

Передача параметра -u команде push позволит Git добавить отслеживающую ссылку на удаленный репозиторий, когда локальная ветвь будет успешно отправлена. Вам не нужно будет указывать параметр репозитория в следующий раз, когда вы будете выполнять push/fetch/pull.

Вы можете использовать либо псевдоним, заданный командой «git remote add», либо URL-адрес для .

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

Изучение основ Git: синхронизация репозиториев
Работа с Git: отправка на удаленный сервер

Проверка измененного содержимого веток в удаленном репозитории

 $ git fetch <репозиторий>

Команда fetch позволяет получить последние данные из удаленного хранилища. Однако эта команда не объединяет и не модифицирует изменения автоматически ни в одну из ваших существующих работ.

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

Возьмите последнее изменение ветки из удаленного репозитория и объедините его с текущей работой

 $ git pull <репозиторий>

Команда pull извлечет последнее измененное содержимое из удаленного репозитория и объединит его непосредственно с вашим локальным репозиторием. Вы можете воспринимать это как «вытягивание = выборка + слияние».

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

Изучение основ Git: синхронизация репозиториев
Работа с Git: извлечение из репозитория

Удалить ветку в удаленном репозитории

 $ git push --delete <репозиторий> <название ветки>

Назначьте опцию –delete в команде push с помощью .

Если вы используете Git версии 1.7 и старше, параметр –delete использовать нельзя. Вместо этого вы должны назначить его, как показано ниже:

 $ git push <репозиторий> :<название ветки>

Создать тег в удаленном репозитории

 $ git push <репозиторий> <тэг>

Если вы добавите параметр –tags, все теги, существующие в локальном репозитории, будут перемещены и созданы в удаленном репозитории.

Удалить тег в удаленном репозитории

 $ git push --delete <репозиторий> <тэг>

Назначьте параметр –delete в вашей команде «push» с помощью

 $ git push <репозиторий> :<тэг>

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

 $ git удаленный набор URL <имя> <новый URL>

Укажите новый адрес удаленного репозитория в формате .

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

 $ git удаленное переименование <старое> <новое>

Измените имя удаленного репозитория с на .

Филиальные операции

См. список филиалов
Создать новую ветку
Переименовать ветку

Удалить ветку
Переключатель ответвлений
Объединить ветки

См.

список филиалов 903:30

 $ ветка git

При добавлении параметра -r также будут перечислены ветки удаленного отслеживания. Добавление параметра -a покажет как удаленные, так и локальные ветки.

Создать новую ветку

 $ git ветка <название ветки>

Работа с Git: создать ветку

Переименовать ветку

 $ git branch -m <старая ветка> <новая ветка>

Удалить ветку

 $ git branch -d <название ветки>

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

Работа с Git: удалить ветку

Переключатель ответвлений

 $ git checkout <ветка>

Это позволит вам проверить и переключиться на нужную ветку.

Добавление параметра -b приведет к созданию новой ветки, а затем ее извлечению.

Изучение совместной работы с Git: переключение веток
Работа с Git: переключение веток

Объединение ветвей

 $ git слияние <ветка>

Добавление параметра –no-ff приведет к тому, что слияние Git всегда будет создавать фиксацию слияния вместо быстрой перемотки вперед. Это полезно, поскольку позволяет сохранить историческую информацию о ветке до ее слияния.

Изучение совместной работы с Git: интеграция веток
Работа с Git: объединение веток

Параметры подключения SSH

Настройка SSH-соединения (Windows)
Настройка подключения SSH (Mac)

Настройка подключения SSH (консоль)
Зарегистрируйте мой открытый ключ SSH в Backlog

Настройка SSH-соединения (Windows)

Перейдите в меню «Пуск» > «Все программы» > «Открыть TortoiseGit» и запустите генератор ключей Putty.

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

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

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

Чтобы настроить SSH-соединение при отправке с помощью TortoiseGit, щелкните правой кнопкой мыши TortoiseGit и выберите «Управление».

Выбрав «происхождение» в удаленном столбце, назначьте путь SSH в поле URL и назначьте путь к файлу ppk, который мы только что сохранили, в поле «Ключ шпатлевки». Нажмите «Добавить новый/Сохранить». Теперь удаленный источник, связанный с путем URL-адреса SSH, будет добавлен в список удаленных устройств в этом репозитории. Нажмите «ОК» для завершения.

Настройка подключения SSH (Mac)

Откройте терминал в приложении/утилите и выполните следующую команду.

 $ ssh-кейген

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

Продолжите, нажав Enter, если вы не хотите устанавливать кодовую фразу.

 Создание пары открытый/закрытый ключ rsa.
  Введите файл для сохранения ключа (/Users/eguchi/.ssh/id_rsa): <Нажмите клавишу Enter>
  Создан каталог '/Users/eguchi/.ssh'.
  Введите парольную фразу (пусто, если нет парольной фразы): <Введите парольную фразу>
  Введите ту же фразу-пароль еще раз: <Пожалуйста, введите ту же фразу-пароль еще раз>
  Ваша идентификация сохранена в /Users/eguchi/.ssh/id_rsa.
  Ваш открытый ключ сохранен в /Users/eguchi/.ssh/id_rsa.pub.
  Ключевой отпечаток пальца:
  57:15:3c:ca:f2:dc:27:6d:c2:9a:88:d0:70:cf:8d:31 [email protected]
  Случайное изображение ключа:
  +--[RSA 2048]----+
  | .о. |
  | .о |
  | ... . |
  | . . Э.о |
  | +Так.О о . |
  | . ..+ + = +|
  | . . . о = |
  | . . о |
  | |
  +-----------------+

Вы можете просмотреть открытый ключ SSH с помощью следующей команды.

 $ кошка ~/.ssh/id_rsa.pub

Пример вывода

 ssh-rsa AAAAB3NzaC1yc2EAAAAADAQABAAABAQDkkJvxyDVh9а+zh2f7ZQq/JEI79dVjDSG
  4RzttQwfK+sgWEr0aAgfnxdxQeDKxIxqI1SwyTY8oCcWzvpORuPqwbc7UWWPcCvbQ3jlEdN
  5jvwKM82hincEWwI3wzcnVg2Mn8dH86b5m6REDzwRgozQ3lqrgwGVlTvkHDFs6H0b/1PSrM
  XGppOP/QXGEVhZ6Hy4m3b1wMjjrbYwmWIeYklgoGHyrldhAaDYc33y7aUcRyFyq5DubtsLn
  2oj4K+1q36iviCHxCOri0FDmn2dzylRCI4S+A2/P7Y7rVfdT+8OWYKCBUs8lfjujghEtejq
  Qmj9ikyGTEAW1zQCN7hVwYdjL hoge@hoge. local

Скопируйте и вставьте этот ключ в настройки удаленного репозитория.

Настройка подключения SSH (консоль)

Выполните следующую команду.

 $ ssh-кейген

Продолжите, нажав Enter, если вы не хотите устанавливать кодовую фразу.

 Создание пары открытый/закрытый ключ rsa.
  Введите файл для сохранения ключа (/Users/eguchi/.ssh/id_rsa): <Нажмите клавишу Enter>
  Создан каталог '/Users/eguchi/.ssh'.
  Введите парольную фразу (пусто, если нет парольной фразы): <Введите парольную фразу>
  Введите ту же фразу-пароль еще раз: <Пожалуйста, введите ту же фразу-пароль еще раз>
  Ваша идентификация сохранена в /Users/eguchi/.ssh/id_rsa.
  Ваш открытый ключ сохранен в /Users/eguchi/.ssh/id_rsa.pub.
  Ключевой отпечаток пальца:
  57:15:3c:ca:f2:dc:27:6d:c2:9a:88:d0:70:cf:8d:31 [email protected]
  Случайное изображение ключа:
  +--[RSA 2048]----+
  | . о. |
  | .о |
  | ... . |
  | . . Э.о |
  | +Так.О о . |
  | . ..+ + = +|
  | . . . о = |
  | . . о |
  | |
  +-----------------+

Вы можете просмотреть открытый ключ SSH с помощью следующей команды.

 $ кошка ~/.ssh/id_rsa.pub

Пример вывода

 ssh-rsa AAAAB3NzaC1yc2EAAAAADAQABAAABAQDkkJvxyDVh9а+zh2f7ZQq/JEI79dVjDSG
  4RzttQwfK+sgWEr0aAgfnxdxQeDKxIxqI1SwyTY8oCcWzvpORuPqwbc7UWWPcCvbQ3jlEdN
  5jvwKM82hincEWwI3wzcnVg2Mn8dH86b5m6REDzwRgozQ3lqrgwGVlTvkHDFs6H0b/1PSrM
  XGppOP/QXGEVhZ6Hy4m3b1wMjjrbYwmWIeYklgoGHyrldhAaDYc33y7aUcRyFyq5DubtsLn
  2oj4K+1q36iviCHxCOri0FDmn2dzylRCI4S+A2/P7Y7rVfdT+8OWYKCBUs8lfjujghEtejq
  Qmj9ikyGTEAW1zQCN7hVwYdjL [email protected]

Скопируйте и вставьте этот ключ в настройки удаленного репозитория.

Зарегистрируйте мой открытый ключ SSH в Backlog

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

Нажмите «Зарегистрировать открытый ключ SSH».

Вставьте открытый ключ SSH в текстовую область и нажмите «Зарегистрироваться».

Фиксация операций журнала

Изменить предыдущую фиксацию
Изменить только комментарии предыдущей фиксации
Изменить предыдущую фиксацию
Изменить только комментарии прошлой фиксации
Выход из переустановки
Просмотр изменений HEAD в истории

Просмотр изменений в ответвлении
Удалить предыдущую фиксацию
Сбросить ребаз
Отменить предыдущий сброс
Скопируйте фиксацию из другой ветки
Поиск фиксации, содержащей определенный комментарий

Изменить предыдущую фиксацию

 $ git commit --изменить

Назначьте опцию –amend, чтобы перезаписать последнюю фиксацию ветки, над которой вы работаете.

Изучение основ Git: переписывание истории
Работа с Git: коммит – изменение

 $ git commit --изменить

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

Изучение основ Git: переписывание истории
Работа с Git: коммит – изменение

Изменить предыдущую фиксацию

 $ git rebase -i <коммит>

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

Затем назначьте параметр –amend для фиксации. Появится экран для добавления комментариев. Исправьте комментарий.

 $ git commit --изменить

Наконец, назначьте параметр –continue для выполнения перебазирования.

 $ git rebase --продолжить

Изучение основ Git: переписывание истории
Работа с Git: изменение коммита с помощью rebase

 $ git rebase -i <коммит>

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

 $ git commit --изменить

Наконец, назначьте параметр –continue для выполнения перебазирования.

 $ git rebase --продолжить

Изучение основ Git: переписывание истории
Работа с Git: изменение коммита с помощью rebase

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

 $ git rebase --abort

Добавив параметр –abort, вы можете выйти из операции перебазирования.

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

 $ git ссылка

Команда reflog позволяет просмотреть список коммитов, которые HEAD использовал для указания в прошлом.

 08084a5 HEAD@{0}: commit: добавить описание команды pull
  99daed2 HEAD@{1}: commit: добавить описание команды фиксации
  48eec1d HEAD@{2}: checkout: переход от master к issue1
  326fc9f HEAD@{3}: commit: добавить описание команды добавления
  48eec1d HEAD@{4}: фиксация (начальная): первая фиксация

Будут отображаться как удаленные, так и успешные коммиты, собранные с помощью rebase.

Просмотр изменений в подсказке ответвления

 $ git reflog <ссылка>

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

 445e0ae issue1@{0}: фиксация (объединение): объединить ветку «мастер» в issue1
  1c904bd issue1@{1}: commit (исправление): изменить описание команды pull
  08084a5 issue1@{2}: commit: добавить описание команды pull
  99daed2 issue1@{3}: commit: добавить описание команды фиксации
  48eec1d issue1@{4}: ветвь: Создано из 48eec1ddf73a7fb508ef664efd6b3d873631742f

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

Удалить предыдущую фиксацию

 $ git reset --hard HEAD~

Изучение основ Git: отмена изменений
Работа с Git: git reset

Сбросить ребаз

 $ git reset --hard

Используйте команду reflog для поиска коммитов до того, как они были перебазированы. Определите хэш фиксации или значение [HEAD@{number}] фиксации, которая произошла до перебазирования. В этом примере 71bdfbd и HEAD@{4} являются ссылками на фиксацию.

 a51f8d2 HEAD@{0}: rebase -i (завершение): возврат к refs/heads/dev
  a51f8d2 HEAD@{1}: rebase -i (сквош): обновление 1
  3a273e1 HEAD@{2}: rebase -i (сквош): обновление HEAD
  f55ef69 HEAD@{3}: проверка: переход от dev к f55ef69
  71bdfbd HEAD@{4}: коммит: обновление 2
  f55ef69 HEAD@{5}: фиксация (изменение): обновление 1

Назначьте хеш-значение (71bdfbd и HEAD@{4}) для при выполнении команды сброса.

Головная позиция ветки теперь будет перемещаться на фиксацию до выполнения перебазирования. Состояние ветки теперь будет идентично тому, что было до выполнения перебазирования.

Отменить предыдущий сброс

 $ git reset --hard ORIG_HEAD

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

Изучение основ Git: отмена изменений
Работа с Git: git reset

Скопируйте фиксацию из другой ветки

 $ git cherry-pick ""

Коммит с идентификатором будет скопирован в текущую ветку.

Изучение основ Git: переписывание истории
Работа с Git: лучший выбор

 $ git log --grep "<шаблон>"

Отображает фиксации с текстом, указанным в .

Тайник Git

Временно спрятать мои текущие изменения
Просмотреть мой список тайников
Восстановить сдачу из тайника

Удалить тайник
Удалить все тайники

Временно спрятать мои текущие изменения

 $ гит сохранить

Вы можете не указывать «сохранить». Если вы укажете «сохранить», вы можете ввести сообщение, чтобы пометить содержимое тайника (например, git stash save «внесение больших изменений»).

Просмотреть мой список тайников

 $ список тайников git

Восстановить сдачу из тайника

 $ git stash pop

Просто вызовите «git stash pop», и на вашей текущей работе будет восстановлен последний тайник.

Назначение параметра идентификатора тайника (например, тайник@{1}) восстановит этот конкретный тайник для вашей текущей работы.

Удалить тайник

 $ git stash drop

Просто вызвав «git stash drop», последний тайник будет удален.

Назначение параметра идентификатора тайника (например, тайник@{1}) удалит этот конкретный тайник.

Удалить все тайники

 $ git очистить тайник

Операции с тегами

См. список тегов
Создать новый тег

Создать тег с комментарием
Удалить тег

См. список тегов

 $ git-тег

При добавлении параметра -n будут отображаться аннотации к каждому тегу.

Создать новый тег 903:30

 $ git тег <имя тега>

 $ git тег -a <имя тега>

Удалить тег

 $ git тег -d <имя тега>

Git-конфигурация

Настройка имени пользователя/адреса электронной почты
Цвет отображаемого вывода
Установить псевдоним для команды Git
Удалить файлы из системы отслеживания версий

Отслеживание пустых каталогов под контролем версий
Настройки дисплея
Настройка HTTP-соединения с прокси-сервером
Установить HTTP-подключение к прокси-серверу с проверкой подлинности пользователя

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

 $ git config --global user. name <имя пользователя>
  $ git config --global user.email <почтовый адрес>

Без параметра –global этот параметр будет применяться только к определенному репозиторию.

Цвет отображаемого вывода

 $ git config --global color.ui авто

Установить псевдоним для команды Git

 $ git config --global alias.

Удалить файлы из системы отслеживания версий

 $ эхо <имя файла> >> .gitignore

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

Отслеживание пустых каталогов под контролем версий

 $ cd <имя каталога>
  $ коснуться .gitkeep

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

Настройки дисплея

 $ git config --global --list

Настройка HTTP-соединения с прокси-сервером

Добавьте следующий параметр в элементы http файлов .gitconfig.

 [http]
  proxy = <адрес прокси-сервера>:<порт прокси-сервера>

Вы также можете настроить его с помощью следующей команды конфигурации:

 $ git config --global http.proxy <адрес прокси-сервера>:<порт прокси-сервера>

Установить HTTP-подключение к прокси-серверу с проверкой подлинности пользователя

Добавьте следующий параметр в элементы http файлов .gitconfig.

 [http]
  proxy = http://<имя пользователя>:<пароль>@<адрес прокси-сервера>:<порт прокси-сервера>

Вы также можете настроить его с помощью следующей команды конфигурации

 $ git config --global http.proxy http://<имя пользователя>:<пароль>@<адрес
  прокси-сервер>:<порт прокси-сервера>

Устранение неполадок

SSH

Ошибка «Отказано в доступе (открытый ключ)» при подключении к удаленному репозиторию с использованием SSH

HTTPS

Невозможно клонировать удаленный репозиторий через его URL-адрес HTTPS

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

SSH/HTTPS

Изменения, отправленные в удаленный репозиторий, не отражаются там

Ошибка «Отказано в доступе (общедоступный ключ)» при подключении к удаленному репозиторию с использованием SSH

В первую очередь необходимо убедиться в следующем:

URL правильный?
Правильно ли настроен секретный ключ на локальном компьютере?
Правильно ли настроен открытый ключ на удаленном компьютере?

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

 $ ssh <пробел>@<пробел>. git.backlogtool.com

Замените пространством Backlog, которым вы владеете (например, для пространства «demo.backlogtool.com» это будет «[email protected]»)

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

 Привет, твое имя! Вы успешно прошли аутентификацию, но Backlog не предоставляет
  доступ к оболочке.
  Соединение с git.backlogtool.com закрыто.

Невозможно клонировать удаленный репозиторий через его URL-адрес HTTPS

В более старых версиях Git вы можете иногда сталкиваться с проблемами при выполнении push или pull. Рекомендуется использовать Git версии 1.7.10 или новее. Если вы используете клиент Git, например Source Tree или TortoiseGit, используйте версию Git, поставляемую вместе с соответствующим клиентом.

Меня запрашивают пароль каждый раз, когда я отправляю данные в удаленный репозиторий или извлекаю их из него

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

Окна

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

Mac

Вы можете использовать SourceTree (которое мы рассмотрели в предыдущей главе) для связи с Mac Keychain. Это позволит Git выяснить, какие учетные данные использовать каждый раз, когда вы извлекаете или нажимаете.

Консоль

На Mac вы можете использовать API учетных данных Git, чтобы связать имя пользователя/пароль с операциями Git. Если вы используете Homebrew, API учетных данных Git устанавливается автоматически. В противном случае вам придется установить его вручную.

Вы можете проверить, установлен ли Credential API, с помощью приведенной ниже команды.

 $ git credential-osxkeychain
  Использование: git credential-osxkeychain

Если Credential API не установлен, вы увидите результат ниже.

 $ git credential-osxkeychain
  git: «credential-osxkeychain» не является командой git. См. «git --help».

В этом случае вы можете скачать его и переместить файлы в /usr/local/bin

 $ curl -s -O http://github-media-downloads.s3.amazonaws.com/osx/git-credential-osxkeychain
  $ chmod u+x git-credential-osxkeychain
  $ mv git-credential-osxkeychain /usr/local/bin

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

 git config --global credential.helper osxkeychain

Изменения, отправленные в удаленный репозиторий, не отражаются там

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

 $ гит пуш
  Нет общих и не указанных ссылок; ничего не делать.
  Возможно, вам следует указать ветку, такую как «мастер».
  Все самое современное

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

 $ git push -u источник происхождения

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

Git против команд SVN

Сравнительная таблица команд Git-Subversion

Команда	Операция	Подрывная деятельность
git-клон	Скопируйте репозиторий	СВН касса
git совершить	Запись изменений в историю файлов	СВН фиксирует
git-шоу	Просмотр сведений о фиксации	свн кошка
статус git	Подтвердить статус	статус свн
git разница	Проверить различия	свн дифф
журнал Git	Журнал проверки	журнал свн
git добавить	Дополнение	свн добавить
гит мв	Перемещение	свн мв
гит рм	Удалить	свн рм
проверка git	Отменить изменение	возврат СВН ¹
git сброс	Отменить изменение	возврат СВН ¹
ветка git	Сделать ветку	копия СВН ²
проверка git	Ветвь переключателя	переключатель СВН
git слияние	Объединить	свн слияние
гит-тег	Создать тег	копия СВН ²
git pull	Обновление	обновление SVN
git fetch	Обновление	обновление SVN
git push	Отражается на пульте	SVN фиксирует ³
гитигнор	Игнорировать список файлов	. No related posts. Вперед Как склеить 2 фотографии в фотошопе: Соединить две фотографии в одну в Фотошопе Назад Веб дизайнерство: Веб-дизайнер: кто это, чем занимается и как им стать Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт Рубрики Css Html Http Javascript Photoshop Верстка Вопросы и ответы Макет Развитие сайтов Сайт Шаблон Шрифт Разное Рубрики Css Html Http Javascript Linux Photoshop Адаптив Верстка Вопросы и ответы Макет Развитие сайтов Разное Сайт Советы Шаблон Шаблоны Шрифт Шрифты Блог сумасшедшего сисадмина © 2024. Все права защищены. Карта сайта