Как сменить директорию в git bash

Сменить директорию в git bash

Я хочу в git bash написать команду cd. Я на рабочем столе создал папку 4. В ней есть папка work. Внутри папки work файл 1.html. Я пишу в git bash $ cd 4 / work. Он выдает bash: cd: too many arguments. Подскажите, пожалуйста, как правильно вводить эту команду в git bash.

Отслеживать
25.9k 7 7 золотых знаков 31 31 серебряный знак 48 48 бронзовых знаков
задан 15 окт 2021 в 12:30
user465242 user465242
19 1 1 серебряный знак 2 2 бронзовых знака
Наверное, как обычно в большинстве командных оболочек: cd 4/work
15 окт 2021 в 12:37
cd ~/desctop/4/work попробуйте так
– user341547
15 окт 2021 в 12:41

с английского переводиться как слишком много аргументов. чтобы путь задать как один аргумент можно заключить в кавычки, но вы должны понять, что система пробелы воспримет как имя директории с пробелом и имя файла так-же с пробелом. решением будет просто убрать эти пробелы и для надёжности закрепить в кавычках. cd «4/work»

22 мая 2022 в 7:44

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Операционная система то какая?

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

Давайте попробуем разобраться.

Я буду исходить из того, что у Вас установлен линукс.

Когда у Вас открывается баш, то слева, до курсора, написан путь в файловой системе. Это — то место, где Вы находитесь сейчас. Что то вроде /home/kirill/ Если Вы сомневаетесь, то есть команда pwd , которая выводит этот путь.

Когда Вы создаёте папку на рабочем столе — то это не то же самое, что создать папку в текущей директории баша.

Попробуйте её найти, навскидку — это будет что то вроде /home/kirill/Desktop/

когда найдёте и перейдёте в ту директорию, где есть папка 4 — тогда самое время писать cd 4/work/ , и не забудьте, что между 4 , слешем и work не должно быть пробелов.

Скорее всего, именно они и вызвали сообщение «too many arguments»

Как сменить расположение .gitconfig?

Доброго дня.
Я установил git, однако при запуске у меня сверху отображается адрес, который я не указывал нигде, и он кажется мне странным, так как git решил использовать для хранения папку. Cadence/SPB_Data, в папке Cadence у меня находится OrCAD Allegro (я им иногда пользуюсь).
Возможно ли перенести .gitconfig из этой папки, не повредив при этом Cadence?

Как это выглядит

Вопрос задан более трёх лет назад
184 просмотра

Комментировать

Решения вопроса 1

Casufi

Адрес сверху покахывает не гит а bash, а точнее git bash
Сама фраза «git решил использовать для хранения папку» звучит диковато. Гит сам ничего не решает.
Кроме того у вас будет несколько файлов .gitconfig. Один — глобальный, в корневой папке пользователя, второй — в корневой папке репозитория. Поэтому переосить кудато глобальный конфиг нет надобности.
Вообще вот это сочетание похоже на то, что домашняя папка вашего пользователя — Cadence/SPB_Data, попробуйте в обычном терминале выполнить команду cd ~

Чтобы сделать новый репозиторий или начать контролировать папку проеткта зайдите в папку, в которую хотите добавить контроль версий, например cd /c/Projects/MyProject и сделайте git init

Ответ написан более трёх лет назад

Нравится 1 1 комментарий

8.1 Настройка Git — Конфигурация Git

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

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

В главе Введение кратко упоминалось, что вы можете настроить Git, используя команду git config . Первое, что вы делали, это установили своё имя и e-mail адрес:

$ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com

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

Кратко: Git использует набор конфигурационных файлов для изменения стандартного поведения, если это необходимо. Вначале, Git ищет настройки в файле /etc/gitconfig , который содержит настройки для всех пользователей в системе и всех репозиториев. Если передать опцию —system команде git config , то операции чтения и записи будут производиться именно с этим файлом.

Следующее место, куда смотрит Git — это файл ~/.gitconfig (или ~/.config/git/config ), который хранит настройки конкретного пользователя. Вы можете указать Git читать и писать в него, используя опцию —global .

Наконец, Git ищет параметры конфигурации в файле настроек в каталоге Git ( .git/config ) текущего репозитория. Эти значения относятся только к текущему репозиторию и доступны при передаче параметра —local команде git config . (Если уровень настроек не указан явно, то подразумевается локальный.)

Каждый из этих уровней (системный, глобальный, локальный) переопределяет значения предыдущего уровня, например, значения из .git/config важнее значений из /etc/gitconfig .

Примечание

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

Базовая конфигурация клиента

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

$ man git-config

Эта команда выведет список доступных настроек с довольно подробным описанием. Так же, соответствующую документацию можно найти здесь https://git-scm.com/docs/git-config.html.

core.editor

По умолчанию, Git использует ваш редактор по умолчанию ( $VISUAL или $EDITOR ), если значение не задано — переходит к использованию редактора vi при создании и редактировании сообщений коммитов или тегов. Чтобы изменить редактор по умолчанию, воспользуйтесь настройкой core.editor :

$ git config --global core.editor emacs

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

commit.template

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

Например, предположим что вы создали файл ~/.gitmessage.txt , который выглядит так:

Subject line (try to keep under 50 characters) Multi-line description of commit, feel free to be detailed. [Ticket: X]

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

Чтобы заставить Git отображать содержимое этого файла в редакторе каждый раз при выполнении команды git commit , следует установить значение параметра commit.template :

$ git config --global commit.template ~/.gitmessage.txt $ git commit

Теперь, при создании коммита, в вашем редакторе будет отображаться сообщение изменённого вида:

Subject line (try to keep under 50 characters) Multi-line description of commit, feel free to be detailed. [Ticket: X] # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD . " to unstage) # # modified: lib/test.rb # ~ ~ ".git/COMMIT_EDITMSG" 14L, 297C

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

core.pager

Данная настройка определяет какая программа будет использована для разбиения текста на страницы при выводе такой информации как log и diff . Вы можете указать more или любую другую (по умолчанию используется less ), а так же выключить совсем, установив пустое значение:

$ git config --global core.pager ''

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

user.signingkey

Если вы создаёте подписанные аннотированные теги (как описано в разделе Подпись главы 7), то установка GPG ключа в настройках облегчит вам задачу. Установить ключ можно следующим образом:

$ git config --global user.signingkey

Теперь, вам не нужно указывать ключ для подписи каждый раз при вызове команды git tag :

$ git tag -s

core.excludesfile

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

Однако, иногда вам нужно игнорировать определённые файлы во всех ваших репозиториях. Если на вашем компьютере работает Mac OS X, вероятно вы знакомы с файлами .DS_Store . Если вы используете Emacs или Vim, то вы знаете про файлы, имена которых заканчиваются на ~ или .swp .

Данная настройка позволяет вам определить что-то вроде глобального файла .gitignore . Если вы создадите файл ~/.gitignore_global с содержанием:

*~ .*.swp .DS_Store

… и выполните команду git config —global core.excludesfile ~/.gitignore_global , то Git больше не потревожит вас на счёт этих файлов.

help.autocorrect

Если вы ошибётесь в написании команды, Git покажет вам что-то вроде этого:

$ git chekcout master git: 'chekcout' is not a git command. See 'git --help'. The most similar command is checkout

Git старается угадать, что вы имели ввиду, но при этом команду не выполняет. Если вы установите help.autocorrect в значение 1, то Git будет выполнять эту команду:

$ git chekcout master WARNING: You called a Git command named 'chekcout', which does not exist. Continuing under the assumption that you meant 'checkout' in 0.1 seconds automatically.

Обратите внимание, что команда выполнилась через «0.1» секунды. help.autocorrect — это число, указываемое в десятых долях секунды. Поэтому, если вы установите значение 50, то Git даст вам 5 секунд изменить своё решение перед тем, как выполнить скорректированную команду.

Цвета в Git

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

color.ui

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

$ git config --global color.ui false

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

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

color.*

Если вы хотите явно указать вывод каких команд должен быть подсвечен и как, Git предоставляет соответствующие настройки. Каждая из них может быть установлена в значения true , false или always :

color.branch color.diff color.interactive color.status

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

$ git config --global color.diff.meta "blue black bold"

Для установки цвета доступны следующие значения: normal , black , red , green , yellow , blue , magenta , cyan , или white . Для указания атрибутов текста, как bold в предыдущем примере, доступны значения: bold , dim , ul (подчёркнутый), blink и reverse (поменять местами цвет фона и цвет текста).

Внешние программы слияния и сравнения

Хоть в Git и есть встроенная программа сравнения, которая описывается в этой книге, вы можете установить вместо неё другую. Вы также можете настроить графический инструмент разрешения конфликтов слияния вместо того, чтобы разрешать конфликты вручную. Мы покажем как настроить Perforce Visual Merge Tool (P4Merge) для разрешения конфликтов слияния, так как это прекрасный и бесплатный инструмент.

Если у вас есть желание попробовать P4Merge, то она работает на всех основных платформах, так что у вас должно получиться. В примерах мы будем использовать пути к файлам, которые работают в системах Linux и Mac; для Windows вам следует изменить /usr/local/bin на путь к исполняемому файлу у вас в системе.

Для начала скачайте P4Merge. Затем, создайте скрипты обёртки для вызова внешних программ. Мы будем использовать путь к исполняемому файлу в системе Mac; в других системах — это путь к файлу p4merge . Создайте скрипт с названием extMerge для вызова программы слияния и передачи ей заданных параметров:

$ cat /usr/local/bin/extMerge #!/bin/sh /Applications/p4merge.app/Contents/MacOS/p4merge $*

Скрипт вызова программы сравнения проверяет наличие 7 аргументов и передаёт 2 из них в скрипт вызова программы слияния. По умолчанию, Git передаёт следующие аргументы программе сравнения:

path old-file old-hex old-mode new-file new-hex new-mode

Так как вам нужны только old-file и new-file , следует использовать скрипт, который передаст только необходимые параметры.

$ cat /usr/local/bin/extDiff #!/bin/sh [ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

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

$ sudo chmod +x /usr/local/bin/extMerge $ sudo chmod +x /usr/local/bin/extDiff

Теперь можно изменить файл конфигурации для использования ваших инструментов слияния и сравнения. Для этого необходимо изменить ряд настроек: merge.tool — чтобы сказать Git какую стратегию использовать, mergetool..cmd — чтобы сказать Git как запускать команду, mergetool..trustExitCode — чтобы сказать Git как интерпретировать код выхода из программы, diff.external — чтобы сказать Git какую команду использовать для сравнения. Таким образом, команду конфигурации нужно запустить четыре раза:

$ git config --global merge.tool extMerge $ git config --global mergetool.extMerge.cmd \ 'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"' $ git config --global mergetool.extMerge.trustExitCode false $ git config --global diff.external extDiff

или вручную отредактировать файл ~/.gitconfig добавив соответствующие строки:

[merge] tool = extMerge [mergetool "extMerge"] cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED" trustExitCode = false [diff] external = extDiff

После этого, вы можете запускать команды diff следующим образом:

$ git diff 32d1776b1^ 32d1776b1

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

P4Merge

Рисунок 142. P4Merge

Если при слиянии двух веток у вас возникнут конфликты, выполните команду git mergetool ; она запустит P4Merge чтобы вы могли разрешить конфликты используя графический интерфейс.

Используя скрипт обёртку для вызова внешних программ, вы можете легко изменить вызываемую программу. Например, чтобы начать использовать KDiff3 вместо P4Merge, достаточно изменить файл extMerge :

$ cat /usr/local/bin/extMerge #!/bin/sh /Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

Теперь, Git будет использовать программу KDiff3 для сравнения файлов и разрешения конфликтов слияния.

Git изначально настроен на использование ряда других инструментов для разрешения конфликтов слияния, поэтому вам не нужно дополнительно что-то настраивать. Для просмотра списка поддерживаемых инструментов, выполните команду:

$ git mergetool --tool-help 'git mergetool --tool=' may be set to one of the following: emerge gvimdiff gvimdiff2 opendiff p4merge vimdiff vimdiff2 The following tools are valid, but not currently available: araxis bc3 codecompare deltawalker diffmerge diffuse ecmerge kdiff3 meld tkdiff tortoisemerge xxdiff Some of the tools listed above only work in a windowed environment. If run in a terminal-only session, they will fail.

Если вы хотите использовать KDiff3 только для разрешения конфликтов слияния, но не для сравнения, выполните команду:

$ git config --global merge.tool kdiff3

Если выполнить эту команду вместо настройки использования файлов extMerge и extDiff , то Git будет использовать KDiff3 для разрешения конфликтов слияния, а для сравнения — стандартную программу diff.

Форматирование и пробелы

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

core.autocrlf

Если вы программируете в Windows и работаете с людьми, которые не используют её (или наоборот), рано или поздно, вы столкнётесь с проблемами переноса строк. Это происходит потому, что Windows при создании файлов использует для обозначения переноса строки два символа «возврат каретки» и «перевод строки», в то время как Mac и Linux используют только один — «перевод строки». Это незначительный, но невероятно раздражающий факт кроссплатформенной работы; большинство редакторов в Windows молча заменяют переносы строк вида LF на CRLF или вставляют оба символа, когда пользователь нажимает клавишу ввод.

Git может автоматически конвертировать переносы строк CRLF в LF при добавлении файла в индекс и наоборот — при извлечении кода. Такое поведение можно включить используя настройку core.autocrlf . Если у вас Windows, то установите значение true — при извлечении кода LF окончания строк будут преобразовываться в CRLF:

$ git config --global core.autocrlf true

Если у вас система Linux или Mac, то вам не нужно автоматически конвертировать переносы строк при извлечении файлов; однако, если файл с CRLF окончаниями строк случайно попал в репозиторий, то Git может его исправить. Можно указать Git конвертировать CRLF в LF во время коммита, но не наоборот, установив настройке core.autocrlf значение input :

$ git config --global core.autocrlf input

Такая конфигурация позволит вам использовать CRLF переносы строк в Windows, при этом в репозитории и системах Mac и Linux будет использован LF.

Если вы используете Windows и программируете только для Windows, то вы можете отключить описанный функционал задав значение false , сохраняя при этом CR символы в репозитории:

$ git config --global core.autocrlf false

core.whitespace

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

Те, что включены по умолчанию — это blank-at-eol , что ищет пробелы в конце строки; blank-at-eof , что ищет пробелы в конце файла; и space-before-tab , что ищет пробелы перед символом табуляции в начале строки.

Те, что выключены по умолчанию — это indent-with-non-tab , что ищет строки с пробелами вначале вместо символа табуляции (и контролируется настройкой tabwidth ); tab-in-indent , что ищет символы табуляции в отступах в начале строки; и cr-at-eol , которая указывает Git на валидность наличия CR в конце строки.

Указав через запятую значения для настройки core.whitespace , можно сказать Git какие из этих опций должны быть включены. Чтобы отключить ненужные проверки, достаточно удалить их из строки значений или поставить знак — перед каждой из них. Например, чтобы включить все проверки, кроме space-before-tab , выполните команду (при этом trailing-space является сокращением и охватывает как blank-at-eol , так и blank-at-eof ):

$ git config --global core.whitespace \ trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

Или можно указать только часть проверок:

$ git config --global core.whitespace \ -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

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

$ git apply --whitespace=warn

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

$ git apply --whitespace=fix

Эти настройки так же применяются при выполнении команды git rebase . Если проблемные пробелы попали в коммит, но ещё не отправлены в удалённую ветку, можно выполнить git rebase —whitespace=fix для автоматического исправления этих проблем.

Конфигурация сервера

Для серверной части Git не так много настроек, но есть несколько интересных, на которые стоит обратить внимание.

receive.fsckObjects

Git способен убедиться, что каждый объект, отправленный командой push , валиден и соответствует своему SHA-1-хешу. По умолчанию эта функция отключена; это очень дорогая операция и может привести к существенному замедлению, особенно для больших объёмов отправляемых данных или для больших репозиториев. Вы можете включить проверку целостности объектов для каждой операции отправки, установив значение receive.fsckObjects в true :

$ git config --system receive.fsckObjects true

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

receive.denyNonFastForwards

Если вы перебазируете коммиты, которые уже отправлены, и попытаетесь отправить их снова или попытаетесь отправить коммит в удалённую ветку, в которой не содержится коммит, на который она указывает, то данные приняты не будут. В принципе, это правильная политика; но в случае перебазирования — вы знаете, что делаете и можете принудительно обновить удалённую ветку используя флаг -f для команды push .

Для запрета перезаписи истории установите receive.denyNonFastForwards :

$ git config --system receive.denyNonFastForwards true

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

receive.denyDeletes

Политику denyNonFastForwards можно обойти, удалив ветку и создав новую с таким же именем. Для предотвращения этого, установите receive.denyDeletes в значение true :

$ git config --system receive.denyDeletes true

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

Работа с Git через консоль

Задача: форкнуть репозиторий в GitHub, создать ветку и работать с кодом.

Сразу появляется много вопросов — что такое GitHub, какие для этого нужны команды, зачем, а главное, как всем этим пользоваться? Давайте разберёмся.

Когда мы пишем код, мы постоянно туда что-то добавляем, удаляем, и иногда всё может ломаться. Поэтому перед любыми изменениями стоит сделать копию проекта. Если собирать проекты в папки с именами проект1 , проект1_финал и проект2_доделка , вы быстро запутаетесь и точно что-нибудь потеряете. Поэтому для работы с кодом используют системы контроля версий.

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

Git — самая популярная система контроля версий. С Git можно работать через командную строку (или терминал). В каждой системе своя встроенная программа для работы с командной строкой. В Windows это PowerShell или cmd, а в Linux или macOS — Terminal. Вместо встроенных программ можно использовать любую другую — например, Git Bash в Windows или iTerm2 для macOS.

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

Но давайте по порядку — установим Git на компьютер.

Устанавливаем и настраиваем Git

Windows. Скачайте Git для Windows, запустите exe-файл, следуйте инструкциям.

macOS. Скачайте Git для macOS и запустите dmg-файл. Если он не запускается, зайдите в Системные настройки — Безопасность и нажмите кнопку Open anyway (Всё равно открыть).

Linux. Установите Git через встроенный менеджер пакетов. Если у вас Ubuntu, используйте команду sudo apt-get install git . Команды для других дистрибутивов можно посмотреть здесь.

Как проверить, что Git установился

Откройте терминал и введите команду

git --version

Если Git установлен, то вы увидите номер версии, например, 2.35.1 .

Настраиваем Git

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

Добавить имя (введите его внутри кавычек):

git config --global user.name "ваше имя"

Добавить электронную почту (замените email@example.com на вашу почту):

git config --global user.email email@example.com

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

Регистрируемся на GitHub

GitHub (или Гитхаб) — веб-сервис на основе Git, который помогает совместно разрабатывать IT-проекты. На Гитхабе разработчики публикуют свой и редактируют чужой код, комментируют проекты и следят за новостями других пользователей.

Профиль на Гитхабе и все проекты в нём — ваше публичное портфолио разработчика, поэтому нужно завести профиль, если у вас его ещё нет.

Зайдите на сайт https://github.com и нажмите кнопку Sign up.
Введите имя пользователя (понадобится в дальнейшей работе), адрес электронной почты (такой же, как при настройке Git) и пароль.
На почту придёт код активации — введите на сайте.
Появится окно с выбором тарифного плана. Если вы пользуетесь Гитхабом для учёбы, то укажите, что профиль нужен только для вас и вы студент.
Опросы и выбор интересов можно пропустить.

На этом всё — вы зарегистрировались и у вас есть собственный профиль.

Устанавливаем SSH-ключи

Чтобы получить доступ к проектам на GitHub со своего компьютера и выполнять команды без постоянного ввода пароля, нужно, чтобы сервер вас узнавал. Для этого используются SSH-ключи.

SSH — протокол для безопасного соединения между компьютерами.

SSH-ключ состоит из двух частей — открытого и закрытого ключа. Открытый ключ мы отправляем на сервер. Его можно не прятать от всех и не переживать, что кто-то его украдёт, потому что без закрытого ключа он бесполезен. А вот закрытый ключ — секретная часть, доступ к нему должен быть только у вас. Это важно.

Мы будем подключаться к GitHub по SSH. Это работает так:

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

А чтобы подключиться к GitHub с помощью SSH-ключа, сначала нужно его создать.

Проверяем SSH-ключи

Перед созданием нового SSH-ключа проверим, есть ли на компьютере другие ключи. Обычно они лежат в папке с названием .ssh — поэтому посмотрим, есть ли в ней что-то, с помощью команды в терминале:

ls -al ~/.ssh

Если у вас уже есть SSH-ключ, то в списке будут файлы с именами вроде id_rsa.pub , id_ecdsa.pub или id_ed25519.pub . А если терминал ругается, что директории ~/.ssh не существует, значит, у вас нет SSH-ключей. Давайте это исправим.

Создаём новый SSH-ключ

Откройте терминал и скопируйте туда эту команду. Не забудьте подставить в кавычки почту, на которую вы регистрировались на Гитхабе.

ssh-keygen -t ed25519 -C "your_email@example.com"

ed25519 — это алгоритм для генерации ключей. Если ваша система не поддерживает алгоритм ed25519 (и вы увидели ошибку), используйте немного другую команду с алгоритмом rsa :

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Терминал спросит, куда сохранить ключ. Если не хотите менять имя файла, которое предлагает терминал, просто нажмите Enter.

> Generating public/private имя-ключа key pair. > Enter a file in which to save the key (/c/Users/ваш-профиль/.ssh/id_имя-ключа):*[Press enter]*

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

В результате создаётся новый SSH-ключ, привязанный к вашей электронной почте.

Создание ключа по шагам:

Добавляем SSH-ключ в ssh-agent

ssh-agent — программа для хранения и управления SSH-ключами. Давайте запустим её и добавим туда наш SSH-ключ. Запускаем командой eval «$(ssh-agent -s)» :

eval "$(ssh-agent -s)"

Если в ответ терминал покажет надпись «Agent pid» и число — значит, всё ок, агент запущен.

Теперь добавим наш ключ командой.

ssh-add ~/.ssh/id_ed25519

Если у вашего ключа другое имя, замените название id_ed25519 именем файла с ключом (это правило применяется и дальше в инструкции). Если вы устанавливали пароль на ключ, введите его два раза после ввода команды ssh-add (терминал подскажет, когда это сделать).

Теперь, если всё хорошо, появится надпись Identity added — значит, можно переходить к добавлению ключа на GitHub.

Копируем SSH-ключ

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

clip < ~/.ssh/id_ed25519.pub

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

Сложный способ. Найдите скрытую папку .ssh , откройте файл id_ed25519.pub в текстовом редакторе и скопируйте его содержимое.

Простой способ. Введите команду ниже и ключ появится прямо в терминале — его нужно вручную скопировать в буфер обмена. Ключ начинается с ssh-ed22519 или ssh-rsa (или похожей строки) — поэтому копируйте строку прямо с самого начала.

~ cat ~/.ssh/id_ed25519.pub ssh-ed25519 AAAAC3NzaCZvnr4ax+Fr shklyar@htmlacademy.ru

Не копируйте этот ключ из статьи — он уже не работает.

Добавляем SSH-ключ на GitHub

Это нужно сделать, чтобы GitHub вас узнавал.

Перейдите на страницу для работы с ключами в вашем профиле на GitHub и нажмите кнопку New SSH key.

В поле Title нужно добавить название нового ключа. Например, если вы используете Mac, вы можете назвать ключ MacBook Air, или, если ключ для курсов Академии, то Academy. А ключ, который вы скопировали на прошлом шаге, вставьте в поле Key.

Не копируйте ключ со скриншота — он уже не работает.

Теперь нажмите кнопку Add SSH key и, если потребуется, введите свой пароль от GitHub, чтобы подтвердить сохранение. Если всё сделано верно, новый ключ появится в списке на странице https://github.com/settings/keys.

Теперь мы можем поработать с проектом в репозитории.

Что такое репозиторий

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

Если над проектом работает несколько программистов, сначала создаётся мастер-репозиторий — это общий репозиторий с рабочей версией проекта. А каждый программист работает с форком — то есть полной копией мастер-репозитория. В форке вы можете безнаказанно менять код и не бояться что-то сломать в основной версии проекта.

Делаем форк мастер-репозитория

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

Появится окно Create a new fork — проверьте, что он называется так, как вам нужно, и жмите кнопку Create fork. Через пару секунд всё готово.

Клонируем форк на компьютер — git clone

Клонировать форк — значит скачать его, чтобы работать с кодом на своём компьютере. Тут нам и пригодится SSH.

Открываем терминал и переходим в папку с будущим проектом — для этого используем команду cd your-project . Если вы хотите, чтобы проект лежал в папке device , введите

cd device

Если такой папки на компьютере нет, то сначала введите md your-project , чтобы создать эту папку, а затем cd your-project . Когда перейдёте в папку, введите команду git clone для клонирования репозитория:

git clone git@github.com:your-nickname/your-project.git

Замените your-nickname на ваше имя пользователя на GitHub, а your-project на название проекта. Проще всего их найти прямо наверху страницы репозитория.

Если вы правильно настроили SSH-ключи, Git скопирует репозиторий на ваш компьютер.

➜ device git clone git@github.com:academy-student/1173761-device-34.git Клонирование в «1173761-device-34»… remote: Enumerating objects: 15, done. remote: Counting objects: 100% (15/15), done. remote: Compressing objects: 100% (14/14), done. remote: Total 15 (delta 0), reused 15 (delta 0), pack-reused 0 Получение объектов: 100% (15/15), 145.07 КиБ | 900.00 КиБ/с, готово.

Если вы видите ошибку Error: Permission denied (publickey) , скорее всего, вы ошиблись в настройке SSH-ключа. Вернитесь в этот раздел инструкции и повторите процесс настройки.

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

git clone git@github.com:_your-nickname_/_your-project_.git folder_name

Теперь на вашем компьютере в папке your_project или в той, название которой вы указали, находится полная копия репозитория c GitHub.

В каждом репозитории есть как минимум одна основная ветка, которую создаёт сам Git — она называется master . Обычно в ней хранят проверенную версию программы без ошибок.

А если вы хотите исправить ошибку в коде или добавить что-то в проект, но не хотите сломать код в основной ветке, нужно создать новую ветку из master и работать из неё. Каждая ветка — что-то вроде второстепенной дороги, которая затем снова соединится с основной.

Создаём новую ветку — git branch

Откройте терминал и введите команду

git branch

Она показывает список веток, с которыми мы работаем в проекте, и выделяет текущую. Если мы находимся в master , то создаём новую ветку командой

git checkout -b имя-новой-ветки.

➜ 1173761-device-34 git:(master) git checkout -b task1 Переключено на новую ветку «task1» ➜ 1173761-device-34 git:(task1)

Если текущая ветка не master , переключитесь на неё с помощью команды checkout . После git checkout надо указать название нужной ветки.

git checkout master

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

git branch -m старое-имя-ветки новое-имя-ветки.

Сохраняем изменения — git add

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

Если вы хотите сохранить изменения не во всех файлах, для начала введите команду git status . Она покажет текущее состояние в вашей ветке, а именно список с названиями изменённых файлов, если они есть, и укажет на те, которые ожидают записи и сохранения (обычно они выделены красным цветом).

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

git add -A

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

git add index.html

Если название очень длинное, вы начните его писать, нажмите Tab и терминал сам предложит продолжение пути к файлу.

Делаем коммит — git commit

Сделать коммит — значит зафиксировать все сохранённые изменения и дать им название. Это делается с помощью команды commit

git commit -m "ваше сообщение"

Текст сообщения должен быть лаконичным и вместе с этим сообщать о том, что делает коммит (внесённые изменения). Например,

Добавляет имя наставника в Readme
Вводит функцию сортировки изображений
Правит ошибку в поиске городов на карте

Отправляем изменения на GitHub — git push

Сохранённые изменения пока не видны коллегам, потому что находятся в нашем локальном репозитории. Нужно отправить коммиты на GitHub. Для этого введите команду

git push origin название-текущей-ветки

Где origin означает репозиторий на компьютере, то есть ваш форк. Слово origin — часть команды, не меняйте это название на своё.

Создаём пулреквест

Пулреквест (или PR) — это предложение изменить код в репозитории. PR должен проверить администратор мастер-репозитория — это может быть коллега-разработчик, техлид или наставник на курсе.

Если к коду нет вопросов, пулреквест принимается. Если нужно что-то исправить — отклоняется, и придётся исправить код и снова пройти цепочку git add — git commit — git push . Если вы и дальше работаете в той же ветке, а пулреквест ещё не принят, все ваши изменения автоматически добавятся в пулреквест, созданный из этой ветки после команды git push origin название-текущей-ветки .

Чтобы создать пулреквест, зайдите на страницу вашего форка на GitHub. Вверху появилась плашка Compare & pull request, а ещё можно зайти на вкладку Pull Requests.

Нажмите на неё и окажетесь на странице открытия пулреквеста. Проверьте описание и нажмите Create pull request.

Готово, теперь ждём остаётся ждать одобрения пулреквеста или комментариев к нему.

Синхронизируем репозитории

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

Теперь код в мастер-репозитории обновился, а в вашем форке нет, вы ведь не обновляли свою версию репозитория с тех пор, как клонировали её себе на компьютер. Приведём форк в актуальное состояние.

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

git checkout master

Забираем изменения из ветки master мастер-репозитория

git pull git@github.com:academy-student/1173761-device-34.git master

Отправляем изменения уже из своей ветки master в ваш форк на GitHub с помощью команды

git push origin master

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

Словарик

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

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

Как работает терминал: мы вводим команду и получаем ответ компьютера — или всё получилось, или где-то ошибка, или нужно ввести что-то ещё.

GitHub (или Гитхаб) — веб-сервис, основанный на Git, который помогает совместно разрабатывать IT-проекты. На Гитхабе разработчики публикуют свой и редактируют чужой код, комментируют проекты и следят за новостями других пользователей.

SSH-ключ нужен, чтобы получить доступ к проектам на GitHub со своего компьютера и выполнять команды без постоянного ввода пароля, нужно, чтобы сервер нас узнавал.

ssh-agent — программа для хранения и управления SSH-ключами.

Репозиторий — папка с файлами вашего проекта на сервере GitHub или у вас на компьютере.

Мастер-репозиторий — это общий для всей команды репозиторий с рабочей версией проекта.

Форк — полная копия мастер-репозитория, в которой вы можете безопасно работать.

Клонировать форк — скачать его командой git clone , чтобы работать с кодом на своём компьютере.

Пулреквест (или PR) — предложение изменить код в репозитории. PR должен проверить администратор мастер-репозитория — это может быть коллега-разработчик, техлид или наставник на курсе.

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

Читать дальше

5 частых ошибок при работе с Git

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

27 августа 2023

GitHub Desktop: обзор и первая настройка

Самая короткая инструкция о том, как сохранить файлы в GitHub и ничего не сломать. И самое главное — никакой консоли, всё через окошки и с помощью мышки. Для этого используем GitHub Desktop.

Внимание! GitHub Desktop не работает на Windows 7×32, поэтому если у вас эта версия системы, обновитесь до Windows 10 или воспользуйтесь программой GitKraken.

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

7 августа 2023

Как склеить коммиты и зачем это нужно

Когда вы открываете пулреквест и ваш код смотрят и комментируют другие, бывает нужно что-то исправить. Обычно такие изменения мы комментируем сообщением вроде «Увеличил шрифт на 2px » или «Поменял оттенок фона в шапке». Такие маленькие изменения интересны, только пока они в пулреквесте. Ревьювер (человек, который смотрит ваш код), может легко узнать, что и когда вы изменили, а не читать весь diff заново, а вы можете легко откатить коммит, если он не нужен. Но когда приходит время вливать пулреквест, эти маленькие коммиты теряют свою ценность. Поэтому лучше их склеить в один.

14 июня 2023

Основные команды для работы с Git

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

☝ В некоторых командах мы будем писать URL-адрес удалённого репозитория и название проекта в квадратных скобках, вот так — [ссылка на удалённый репозиторий] . Мы делаем это только для наглядности. Вам квадратные скобки ставить не нужно.

22 февраля 2023

Как бесплатно залить сайт на GitHub Pages

Допустим, вы сделали какой-то проект, например, собрали себе портфолио по шаблону, и теперь хотите выложить его в интернет. Если вы использовали только HTML и CSS, то необязательно платить деньги, чтобы загрузить сайт куда-то. Вы можете бесплатно выложить сайт на сервис GitHub Pages. Всё, что нужно — аккаунт на Гитхабе.

29 ноября 2022

Регистрация на GitHub

Создание нового аккаунта на GitHub состоит всего из 10 шагов — и вся регистрация занимает меньше пяти минут.

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

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

Ввод почты. На следующем шаге начинается регистрация. Подтвердите свою почту с прошлого шага и нажмите Continue (Продолжить).

Пароль. Придумайте сложный пароль, чтобы его никто не взломал. Например, Гитхаб просит, чтобы в пароле было не меньше 15 символов или 8 символов, но тогда должны быть и латинские буквы, и цифры.

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

Если имя недоступно, Гитхаб вам об этом скажет. А если доступно — жмите Continue.

Рассылки. Дальше Гитхаб спросит, хотите ли вы подписаться на рассылку об обновлениях. Впечатайте латинскую У, если хотите, или n, если письма вам не нужны. Готовы спорить, мы знаем, что вы выберете.

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

Подтверждение почты. После капчи вам придёт письмо с кодом на почту. Введите его на следующей странице.

Вот здесь. Главное — не ошибайтесь.

Общая информация о вас и вашей команде. Если вы регистрируете аккаунт для себя, выбирайте Just me. Второй пункт — студент вы или учитель. Выбирайте «Студент», если вы не учитель.

Интересы. Дальше Гитхаб спросит вас об интересах — то есть о том, зачем вы регистрируете аккаунт. Из вариантов:

Совместная разработка и код ревью.
Автоматизация. CI/CD, API и другие админские вещи.
Безопасность. Двухфакторная аутентификация, ревью, сканирование кода и списки зависимостей.
Приложения. Выбирайте, если будете использовать GitHub Mobile, CLI, Desktop.
Управление проектами. Проекты, метки, ишьи, вики и другие управленческие дела.
Управление командами. Организации, приглашения, роли, домены.
Сообщество. Выбирайте, если Гитхаб интересен вам как соцсеть.

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

Выбор тарифа. На выбор бесплатный тариф или платный GitHub Pro. Практика показывает, что для большинства личных проектов хватит бесплатного тарифа. В сентябре 2022 в него входили:

Безлимитное количество репозиториев.
2000 минут CI/CD в месяц.
500 мегабайт места в хранилище пакетов.
Поддержка сообщества.

Выбор тоже можно пропустить, тогда у вас будет бесплатный тариф.

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

28 сентября 2022

Работа с Git в Visual Studio Code

Если вы вёрстаете сайты или пишете код в редакторе Visual Studio Code, то Git за пять минут настраивается прямо внутри редактора. Не нужно запоминать команды для консоли, не нужно тыкать в лишние приложения.

Следуйте инструкции и всё получится.

16 сентября 2022

Markdown за 5 минут

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

Главный пример использования маркдауна, с которым мы часто сталкиваемся — файлы readme.md , которые есть в каждом репозитории на Гитхабе. md в имени файла это как раз сокращение от markdown.

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

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

5 октября 2021

Шпаргалка по Git. Решение основных проблем

Поговорим о решении проблем с Git.

11 декабря 2020

Полезные команды для работы с Git

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

1 января 2020