Git config как посмотреть текущие настройки

Git config как посмотреть текущие настройки

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

$ git config —list

Чтобы изменить глобальные настройки (которые едины для всех репозитариев), можно воспользоваться такими командами:

git config —global user.email «xintrea@gmail.com»
git config —global user.name «xintrea»

Кроме того, можно менять настройки не командами, а путем правки файла:

• Бесплатные сервиса размещения репозитариев Git
• Git workflow — Теория
• Git workflow — Краткое введение по основным инструкциям
• Git Wizardry
• Про Git на пальцах (для переходящих с SVN)
• Git на двоих
• Ежедневный Git
• Удачная модель ветвления для Git
• Синхронизация через GIT
• Git stash — работа с «карманом» в Git
• Как посмотреть настройки репозитария Git и как их изменить
• GIT: Инструкция-шпаргалка для начинающих
• Как перенести локальный GIT-репозитарий на сервер вместе со всей историей
• git reset — возврат к определенному коммиту, откат изменений, «жесткий» или «мягкий»
• git revert — отмена изменений, произведенных в прошлом отдельным коммитом
• Git — работа с ветками
• Git: Путь Github. Цикл разработки — Простое объяснение
• Машина времени в GIT
• Git Rebase: руководство по использованию
• Git: просмотр лога (истории) в консоли в виде дерева
• Git: понимание команды git merge
• Git: Опции слияния для команд merge и pull — определение стратегии слияния
• Git: как переключиться на нужный коммит
• Git: как смержить изменения из experimental в master
• Git: как посмотреть изменения, внесенные определенным коммитом
• Git: как посмотреть историю изменения одного файла
• Git: как вернуть один файл в состояние, которое было в определенном коммите
• git log — особенности данной команды при навигации по истории через git checkout
• Git: Как исправить HEAD detached from
• Git: что делать в состоянии detached head
• Работа в команде с использованием Git на примере проекта в среде Blender 3D
• Git: Как внести изменения в последний коммит
• Как в Git создать новую ветку в условиях, когда что-то уже было изменено после последнего коммита
• Как в Git залить новую локальную ветку в удаленный репозитарий
• Git: Как подключить новую ветку с удаленного сервера
• Git: Как узнать текущую ветку
• Git: В чем разница между Fetch и Pull?
• GIT: Как исправить ошибочный комментарий к коммиту или файлы в коммите
• Как настроить git на использование proxy-сервера
• Использование Git через HTTP-proxy
• Настройка работы Git через Proxy-сервер
• Git через proxy
• Использование git за прокси с аутентификацией
• Как в Git смержить изменения до конкретного коммита?
• Самый удобный визуальный клиент Git под основные платформы — SmartGit
• Основы системы управления версиями Git для новичков на примере SmartGit
• Как сделать подключение к репозитарию Git через Socks Proxy в условиях отсутствия DNS
• Как сделать подключение к репозитарию Git через проксирующее SSH соединение
• Как работать с незавершенными изменениями в коде? Как их коммитить в Git?
• Как в Git посмотреть незакоммиченные изменения в текстах исходников?
• Как поместить на GitHub уже существующий репозитарий
• Что происходит при откате изменений через git reset —soft
• Не бойся хардресета! Он твой друг и помощник. (Как пользоваться git reset)
• Как пометить определенный коммит тегом версии
• Как в Git удалить файлы из индекса, не удаляя их в рабочей директории
• Как настроить GIT, чтобы при конфликте слияния он прописывал в файл не только различия, но и «базу» этих различий
• Git: Разрешение конфликтов объединений
• Git: Извлечение старой версии файла
• Git stash: временный отказ от проделанной работы
• Git: проверка состояния репозитария, поддержание репозитария в рабочем состоянии
• Как в Git отменить локальные изменения и получить новое состояние из удаленного репозитария
• Как искать изменения в нужных файлах с помощью интерфейса gitk?
• Как выбрать одну из версий бинарного файла при возникновнии конфликта слияния?
• Как в Git посмотреть старый коммит, а потом вернуться обатно к самому последнему коммиту
• Получение хеша последнего коммита и его даты в Git (для версионирования)
• Памятка по неочевидным деталям использования Git
• Как синхронизировать форк на Github с основным репозитарием через веб-интерфейс
• Как пользоваться GitHUb: форки, ветки, запросы на добавление кода
• Как отменить (сбросить) еще не закоммиченные изменения в Git
• Первоначальная настройка имени пользователя и Email в Git-проекте
• Можно ли принимать изменения через git pull если не закоммичены изменения рабочей директории
• Как посмотреть какие команды генерирует git gui
• Как удалить файл в Git-репозитарии с изменением истории

Настройка имени пользователя в Git

Git использует имя пользователя для связывания фиксаций с удостоверением. Имя пользователя Git не совпадает с именем пользователя GitHub.

Platform navigation

Сведения об именах пользователей Git

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

Изменение имени, связанного с фиксациями Git, с помощью git config будет влиять только на будущие фиксации и не повлияет на имя, использованное для предыдущих фиксаций.

Настройка имени пользователя Git для каждого репозитория на компьютере

1. Откройте Терминал Терминал GIT Bash .
2. Задайте имя пользователя Git:

git config --global user.name "Mona Lisa" 

$ git config --global user.name > Mona Lisa 

Настройка имени пользователя Git для одного репозитория

1. Откройте Терминал Терминал GIT Bash .
2. Измените текущий рабочий каталог на локальный репозиторий, в котором необходимо настроить имя, связанное с фиксациями Git.
3. Задайте имя пользователя Git:

git config user.name "Mona Lisa" 

$ git config user.name > Mona Lisa 

Дополнительные материалы

• «Указание адреса электронной почты для фиксаций»
• Раздел «Конфигурация Git» из книги Pro Git

git. Настройка git

Сперва нужно настроить git, установив user.name и user.email. Приятно знать, от кого коммит. Таким образом команда git blame и ваша IDE будут подсказывать имя того, кто закоммитил ту или иную строчку.

git config --global --add user.name 'Name Surname' git config --global --add user.email 'your@mail.here'

Эти команды автоматически внесут правки в конфигурационный файл git: ~/.gitconfig. Также файл ~/.gitconfig можно редактировать и вручную vim ~/.gitconfig

git current branch

Для удобной работы с бренчами нужно поставить пакет bash-completion (под маком установить git с вариантом +bash_completion) и добавить такую инструкцию в ~/.bash_profile (или ~/.bashrc). Отображать имя git бренча в консоли:

PS1='\h:\W$(__git_ps1 " (%s)") \u\$ '

Теперь имя текущего бренча будет отображаться слева от строки ввода в консоли и будет всегда на виду (изменения вступят в силу после ребута). Чтобы не перезагружаться, можно сделать source ~/.bashrc , чтобы изменения добавленные в файл, немедленно вступили в силу.

git pull

От git pull нужно отказаться ввиду потенциальных проблем которые он несет. Вместо него лучше использовать явную связку git fetch + git merge.

Поэтому ежедневная работа должна строиться так:

git fetch # fetch remote changes to origin/* git branch # show the current branch, e.g. "master" git merge origin/master # merge remote changes of branch 'master' into local copy of branch 'master' git push origin master # push local changes of branch 'master' into remote branch 'master'

На одну команду больше — казалось бы, зачем. Тем не менее, такая схема будет способствовать тому что вы понимаете, что и куда мержите и что и куда вливаете. То есть, вызов git fetch не обязывает вас думать, правильно ли вы получаете изменения с центрального сервера, т.к. они всё равно попадут не в ваш текущий бренч, а в соответствующие бренчи origin/*, после чего вы, к примеру, сможете посмотреть, что это за изменения, стоит ли их в свой локальный бренч вливать, и т.д.

git merge

git merge branch2

Командой выше мы мерджим branch2 в текущий бранч, в тот, в котором мы сейчас находимся.

Влить ветку, но коммита при этом не произойдёт! После этого можно делать git diff или применять сторонние утилиты для diff. Очень удобно смотреть, какие изменения принесёт ветка:

git merge --squash --no-commit feature-branch

Узнать, в каком бранче мы сейчас находимся:

git branch

Текущий бренч помечен звёздочкой.

Список бренчей на сервере:

git branch -a

Удаление git бренчей

Удалить локальный branch:

git branch -d branch_name

Удалить локальный branch с игнорированием изменений в нём (если с -d не получается):

git branch -D branch_name

Удалить локальные бренчи, которые удалены с сервера:

git remote prune origin --dry-run

Удалить бренч с origin сервера git:

git push origin :master_my_branch

Как отменить последний коммит в git?

Если случайно закоммитили лишние файлы или изменения, но еще не запушили, отменить последний коммит:

git reset --soft HEAD^

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

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

git reset --hard HEAD^

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

git revert sha1

После этого надо сделать git push.

Удобным life-хаком для работы с git ещё будет настроить более короткие алиасы.

Введение в Git: настройка и основные команды

Как установить и настроить Git в различных ОС, создать новые и клонировать существующие репозитории, а также базовые концепции ведения веток.

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Введение

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

В целом СКВ можно разделить таким образом:

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

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

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

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

Принципы работы с Git

У проектных файлов в Git есть 3 базовых состояния

• Измененные (modified) — файлы в процессе рабочего редактирования.
• Индексированные (staged) — та часть измененных файлов, которая уже подготовлена к фиксации после редактирования.
• Зафиксированные (committed) — файлы, уже сохраненные в локальном репозитории.

У Git есть рабочий каталог, где хранятся метаданные и локальная база рабочего проекта. Именно эта часть копируется, когда вы клонируете проект (репозиторий) с сервера.

Чаще всего работа с Git устроена примерно так:

1. Вы вносите правки в файлы рабочей копии проекта.
2. Индексируете их, подготавливая к коммиту (здесь Git создает снимки новых правок).
3. Делаете коммит, и индексированные правки наконец сохраняются в вашем каталоге Git.

Установка Git

Создать свой проект и начать пользоваться Git в нем достаточно просто. Мы будем рассматривать работу в командной строке терминала, потому что там реализован полный набор команд. Вероятно, в будущем вам будет проще воспользоваться встроенными инструментами в крупном приложении (например, в Visual Studio, если вы программист).

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

Сначала потребуется установить Git на свой компьютер.

Установка в Linux

Для дистрибутивов, похожих на Fedora, RHEL или CentOS, выполните команду dnf:

> sudo dnf install git-all 

На Ubuntu и других Debian-подобных систем введите apt:

> sudo apt install git 

Более подробные сведения можно получить по ссылке: https://git-scm.com/download/linux.

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

Один из способов установки — воспользоваться Xcode Command Line Tools. В терминале нужно ввести:

> git --version 

И следовать дальнейшим инструкциям.

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

$ brew install git 

Установка в Windows

Новейшая сборка доступна на официальном сайте Git по ссылке: https://git-scm.com/download/win (загрузка запустится автоматически).

Настройка Git

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

Самый удобный способ изменения конфигурации — встроенная утилита git config. Настройки Git имеют три уровня:

1. Параметры из файла [path]/etc/gitconfig (системные) могут работать для всех пользователей системы и репозиториев. Они редактируются командой git config —system.
2. Параметры из файла ~/.gitconfig или ~/.config/git/config (глобальные) применяются к одному пользователю, если запустить команду git config —global.
3. Локальные параметры из файла config в рабочем каталоге .git/config сохраняют только для выбранного репозитория. Ему соответствует команда git config —local.

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

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

> git config --list --show-origin 

Представимся Git, чтобы в рабочих коммитах сохранялось ваше авторство:

> git config --global user.name "Danil Z" > git config --global user.email danilz@danilz.com 

Также можно выбрать и текстовый редактор, введя команду git config —global core.editor. Например, чтобы выбрать Emacs, выполните:

> git config --global core.editor emacs 

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

> git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" 

Стоит отметить, что на практике текстовый редактор в Git может и не пригодиться, особенно если вы активно используете стороннее ПО — например, в Visual Studio все текстовые заметки для Git можно писать в отдельном окне. Текстовые редакторы в командной строке отличаются своеобразным управлением, которое потребует от вас отдельного изучения.

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

> git config user.email 

> git config --global init.defaultBranch main 

> cd /home/user/SomeConsoleApp 

> cd /Users/user/SomeConsoleApp 

> cd C:/Users/user/SomeConsoleApp 

> git init 

> git add readme.md > git commit -m 'Initial project version' 

> git clone https://github.com/DanZDev2/SomeConsoleApp SomeConsoleApp 

On branch master Your branch is up to date with ‘origin/master’. nothing to commit, working tree clean 

>git status On branch master Your branch is up to date with ‘origin/master’. Untracked files: (use “git add . ” to include in what will be committed) Program.cs SomeConsoleApp.csproj SomeConsoleApp.sln nothing added to commit but untracked files present (use “git add” to track) 

> git commit -m "Task 2: basic project template added" 

/bin /obj *.pdb *.exe 

>git remote add myDemo https://github.com/DanZDev2/DemoApp >git remote myDemo origin 

> git push origin master 

>git branch Dev >git branch Test 

>git checkout Dev Switched to branch ‘Dev’ Your branch is up to date with ‘origin/Dev’. 

>git add . >git commit -m “dev readme changed” [Dev #####] dev readme changed 1 file changed, 2 insertions(+) 

>git merge Dev Updating #####..##### Fast-forward README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)