Git как войти в аккаунт в консоли

1.6 Введение — Первоначальная настройка Git

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

В состав Git входит утилита git config , которая позволяет просматривать и настраивать параметры, контролирующие все аспекты работы Git, а также его внешний вид. Эти параметры могут быть сохранены в трёх местах:

1. Файл [path]/etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев. Если при запуске git config указать параметр —system , то параметры будут читаться и сохраняться именно в этот файл. Так как этот файл является системным, то вам потребуются права суперпользователя для внесения изменений в него.
2. Файл ~/.gitconfig или ~/.config/git/config хранит настройки конкретного пользователя. Этот файл используется при указании параметра —global и применяется ко всем репозиториям, с которыми вы работаете в текущей системе.
3. Файл config в каталоге Git (т. е. .git/config ) репозитория, который вы используете в данный момент, хранит настройки конкретного репозитория. Вы можете заставить Git читать и писать в этот файл с помощью параметра —local , но на самом деле это значение по умолчанию. Неудивительно, что вам нужно находиться где-то в репозитории Git, чтобы эта опция работала правильно.

Настройки на каждом следующем уровне подменяют настройки из предыдущих уровней, то есть значения в .git/config перекрывают соответствующие значения в [path]/etc/gitconfig .

В системах семейства Windows Git ищет файл .gitconfig в каталоге $HOME ( C:\Users\$USER для большинства пользователей). Кроме того, Git ищет файл [path]/etc/gitconfig , но уже относительно корневого каталога MSys, который находится там, куда вы решили установить Git при запуске инсталлятора.

Если вы используете Git для Windows версии 2.х или новее, то так же обрабатывается файл конфигурации уровня системы, который имеет путь C:\Documents and Settings\All Users\Application Data\Git\config в Windows XP или C:\ProgramData\Git\config в Windows Vista и новее. Этот файл может быть изменён только командой git config -f , запущенной с правами администратора.

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

$ git config --list --show-origin

Имя пользователя

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

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

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

Многие GUI-инструменты предлагают сделать это при первом запуске.

Выбор редактора

Теперь, когда вы указали своё имя, самое время выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git. По умолчанию Git использует стандартный редактор вашей системы, которым обычно является Vim. Если вы хотите использовать другой текстовый редактор, например, Emacs, можно проделать следующее:

$ git config --global core.editor emacs

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

В случае с Notepad++, популярным редактором, скорее всего вы захотите установить 32-битную версию, так как 64-битная версия ещё не поддерживает все плагины. Если у вас 32-битная Windows или 64-битный редактор с 64-битной системой, то выполните следующее:

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

Примечание

Vim, Emacs и Notepad++ — популярные текстовые редакторы, которые часто используются разработчиками как в Unix-подобных системах, таких как Linux и Mac, так и в Windows. Если вы используете другой редактор или его 32-битную версию, то обратитесь к разделу Команды git config core.editor за дополнительными инструкциями как использовать его совместно с Git.

Предупреждение

В случае, если вы не установили свой редактор и не знакомы с Vim или Emacs, вы можете попасть в затруднительное положение, когда какой-либо из них будет запущен. Например, в Windows может произойти преждевременное прерывание команды Git при попытке вызова редактора.

Настройка ветки по умолчанию

Когда вы инициализируете репозиторий командой git init , Git создаёт ветку с именем master по умолчанию. Начиная с версии 2.28, вы можете задать другое имя для создания ветки по умолчанию.

Например, чтобы установить имя main для вашей ветки по умолчанию, выполните следующую команду:

$ git config --global init.defaultBranch main

Проверка настроек

Если вы хотите проверить используемую конфигурацию, можете использовать команду git config —list , чтобы показать все настройки, которые Git найдёт:

$ git config --list user.name=John Doe user.email=johndoe@example.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto . 

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

Также вы можете проверить значение конкретного ключа, выполнив git config :

$ git config user.name John Doe

Примечание

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

$ git config --show-origin rerere.autoUpdate file:/home/johndoe/.gitconfig false

Запуск GitHub Desktop из командной строки

1. В строке меню выберите меню GitHub Desktop и нажмите кнопку Установить программу командной строки.

github /PATH/TO/REPO 

Вы также можете изменить путь к репозиторию, а затем ввести github . , чтобы открыть этот репозиторий.

$ cd /PATH/TO/REPO [repo]$ github . 

1. Откройте командную строку.
2. Чтобы запустить GitHub Desktop для последнего открытого репозитория, введите github . Чтобы запустить GitHub Desktop для определенного репозитория, введите github и затем путь к репозиторию.

C:\Users\octocat> github PATH\TO\REPO 

Вы также можете изменить путь к репозиторию, а затем ввести github . , чтобы открыть этот репозиторий.

C:\Users\octocat> cd REPO\MY-REPO C:\Users\octocat\repo\myrepo> github . 

6.1 GitHub — Настройка и конфигурация учетной записи

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

Эта глава про эффективное использование GitHub. Мы разберём регистрацию, управление учётной записью, создание и использование Git репозиториев, как вносить вклад в чужие проекты и как принимать чужой вклад в собственный проект, а так же программный интерфейс GitHub и ещё множество мелочей, который облегчат вам жизнь.

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

Настройка и конфигурация учетной записи

Первым делом нужно создать бесплатную учётную запись. Просто зайдите на https://github.com, выберите имя которое ещё не занято, укажите адрес электронной почты и пароль, а затем нажмите большую зелёную кнопку «Sign up for GitHub».

Рисунок 81. Форма регистрации на GitHub

Далее вы попадёте на страницу с тарифными планами, её пока можно проигнорировать. GitHub вышлет письмо для проверки вашего электронного адреса. Сделайте этот шаг, он достаточно важный (как мы увидим далее).

Примечание

GitHub предоставляет почти все свои функции для бесплатных учётных записей, за исключением некоторых расширенных возможностей. Платные тарифы GitHub включают расширенные инструменты и функции, а также увеличенные лимиты на бесплатные услуги, но мы не будем рассматривать их в этой книге. Для того, чтобы получить более подробную информацию об имеющихся тарифах и их сравнение, посетите https://github.com/pricing.

Клик на расположенном в верхнем левом углу экрана логотипе, изображающем гибрид кота и осьминога (его называют осьмикот), откроет панель управления. Теперь всё готово для работы с GitHub.

Доступ по SSH

На данный момент вы можете подключаться к репозиториям Git используя протокол https:// авторизуясь при помощи только что созданного логина и пароля. Однако для того чтобы просто клонировать публично доступный проект, вам необязательно авторизовываться на сайте, но тем не менее, только что созданный аккаунт понадобится в то время, когда вы захотите загрузить (push) сделанные вами изменения.

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

Рисунок 82. Ссылка «Настройка учётной записи» («Account settings»)

Выберите секцию слева под названием «Ключи SSH» («SSH keys»).

Рисунок 83. Ссылка («SSH keys»)

Затем нажмите на кнопку «Добавить ключ SSH» («Add an SSH key»), задайте имя ключа, а так же скопируйте и вставьте сам публичный ключ из ~/.ssh/id_rsa.pub (ну или как бы у вас не назывался этот файл) в текстовое поле, затем нажмите «Добавить ключ» («Add key»).

Примечание

Задавайте такое имя SSH ключа, которое вы в состоянии запомнить. Называйте каждый из добавляемых ключей по-разному (к примеру «Мой Ноутбук» или «Рабочая учётная запись»), для того чтобы в дальнейшем, при аннулировании ключа быть уверенным в правильности своего выбора.

Ваш аватар

Следующий шаг, если хотите — замена аватара, который был сгенерирован для вас, на вами выбранный аватар. Пожалуйста зайдите во вкладку «Профиль» («Profile»), она расположена над вкладкой «Ключи SSH» и нажмите «Загрузить новую картинку» («Upload new picture»).

Рисунок 84. Ссылка «Профиль» («Profile»)

Выберем логотип Git с жёсткого диска и отредактируем картинку под желаемый размер.

Рисунок 85. Редактирование аватара

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

Если вы используете такой популярный сервис как Gravatar (часто используется для учётных записей WordPress), тот же самый аватар будет использован «по умолчанию».

Ваши почтовые адреса

GitHub использует ваш почтовый адрес для привязки ваших Git коммитов к вашей учётной записи. Если вы используете несколько почтовых адресов в своих коммитах и хотите, чтобы GitHub работал с ними корректно, то вам нужно будет добавить все используемые почтовые адреса в секцию под названием «Почтовые адреса» («Emails»), расположенную на вкладке «Администрирование» («Admin»).

Рисунок 86. Почтовые адреса

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

Двухфакторная аутентификация

В качестве дополнительной меры безопасности, вы можете настроить «Двухфакторную аутентификацию» («Two-factor Authentication» или «2FA»). Двухфакторная аутентификация — механизм, который становится всё более и более популярным методом по снижению риска скомпрометировать вашу учётную запись в ситуации, когда пароль от вашей учётной записи, по тем или иным причинам, стал известен злоумышленникам. Активация этого механизма заставит GitHub запрашивать у вас оба пароля при авторизации, поэтому даже в ситуациях, когда ваш основной пароль скомпрометирован, злоумышленник всё равно не получит доступ к вашей учётной записи.

Вы сможете найти настройку «Двухфакторной аутентификации» («Two-factor Authentication») в секции «Безопасность» («Security») вкладки «Настройка учётной записи» («Account settings»).

Рисунок 87. Двухфакторная аутентификация («Two-factor Authentication»)

При нажатии на кнопку «Настроить двухфакторную аутентификацию» («Set up two-factor authentication») вы будете перенаправлены на страницу, где вам нужно будет настроить использование мобильного приложения для генерации вторичного кода проверки (так называемый «одноразовый пароль основанный на времени»), так же можно настроить GitHub таким образом, чтобы он отправлял вам СМС с кодом в момент, когда вам нужно авторизоваться на сайте.

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

Git/Git-console

Небольшое руководство по консольному git. Часть про установку рассчитана на Windows, часть про работу с Github будет актуальна и для пользователей гуи-интерфейсов.

Есть много различных GUI-клиентов, например TortoiseGit (на вики tg-станции есть подробный обновляемый гайд), SourceTree. Мы же в данной статье остановимся по большей части на консольном клиенте git:

1. Сам Git — изначально консольный инструмент. И удобный!
2. Консоль дает больше возможностей, чем GUI-клиенты.
3. В GUI-клиентах есть возможность запустить консоль, если понадобится. Так что это универсальная инструкция.
4. С консолью, вы словно хакер!

В любом случае, какой-бы клиент вы не выбрали, в интернете всегда найдется документация и куча различных инструкций.

• 1 Git клиент, настройка
• 2 Краткий курс
  • 2.1 Делаем форк
  • 2.2 Создаем локальную рабочую копию
  • 2.3 Подключаем удаленный репозиторий
  • 2.4 Создаем ветку, переключаем ветки
  • 2.5 Обновляем ветку
  • 2.6 Фиксируем изменения
  • 2.7 Отправляем изменения
  • 2.8 Немного о merge (слиянии изменения)

  Git клиент, настройка

  

  Пример Posh-Git на Windows 8.

  Гитхаб — наиболее популярный в сообществе станции хостинг репозиториев. Более подробнее в Git/GitHub

  Регистрируемся по адресу https://github.com/join, подтверждаем email, всё стандартно.
  Важно: email, который вы укажете при регистрации, в дальнейшем будет указан под каждым вашим коммитом на гитхабе. Если не хотите светить — зарегистрируйте отдельный.

  Самый простой способ начать — скачать git с официального сайта: https://git-scm.com/downloads

  Краткий курс

  Здесь и дальше алгоритм приводится на примере текущего основного репозитория Тау Киты, TauCetiClassic.

  Делаем форк

  Достаточно на странице репозитория https://github.com/TauCetiStation/TauCetiClassic в правом верхнем углу нажать Fork. В течении пары минут гитхаб подготовит ваш собственный репозиторий по адресу вида https://github.com/%аккаунт%/TauCetiClassic Кстати, нет никакой необходимости поддерживать актуальность вашего форка, не нужно специально его обновлять или пересоздавать. Ниже будет описанно, как обновляться напрямую с репозитория Тау Киты, а форк нам пригодится только для создания ПуллРеквестов.

  Создаем локальную рабочую копию

  Со страницы вашего репозитория среди кнопок находим и копируем https адрес

  https://github.com/%аккаунт%/TauCetiClassic.git

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

  git clone https://github.com/%аккаунт%/TauCetiClassic.git tauceticlassic

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

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

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

  Традиционно центральный репозиторий именуется как upstream (или апстрим), но никто не мешает подобрать своё имя, к тому же никто не мешает иметь подключенными сразу несколько удаленных репозиториев. Кстати, после git clone . у вас уже есть 1 подключенный удаленный репозиторий под названием origin , ссылающийся на репозиторий, который вы клонировали (ваш форк на гитхабе).

  Подключим центральный репозиторий Тау Киты:

  git remote add upstream https://github.com/TauCetiStation/TauCetiClassic.git

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

  git fetch upstream

  Можете посмотреть список своих удаленных репозиториев по команде git remote -v

  Создаем ветку, переключаем ветки

  Ветка, или же branch — ссылка на определенное состояние репозитория. Изначально у вас есть основная ветка master , как правило это актуальная рабочая версия, которая и стоит на сервере. Но при активной работе над билдом, предпочтительно её не трогать, и создавать для каждого фикса\фичи свою отдельную ветку.

  git checkout -b some-awesome-feature

  Создаст ответвление от вашей текущей ветки с названием some-awesome-feature , и переключится на неё. Важно: по умолчанию создается ответвление от текущей ветки, что может быть неудобно в случае работы сразу над несколькими ветками. В качестве параметра можно указать необходимую ветку для ответвления git checkout -b some-awesome-feature master

  Список своих веток можно посмотреть по команде git branch -v . На каждую из них можно переключится по команде git checkout %branchname% , например

  git checkout master

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

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

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

  Обновляем ветку

  Пока мы работали с локальным репозиторием, в центральном репозитории могло уже что-то изменится. Обновим нашу ветку с апстрим мастером:

  git pull upstream master

  Если было что обновлять, то откроется тектовый редактор и предложит отредактировать название для merge-коммита. Можно оставить дефолтный, так что сохраняем/закрываем. Желательно это так же делать в дальнейшем перед самым ПР-ом, и аналогично придется делать в случае возникновения конфликтов в ПР-е (придется мержить).

  Фиксируем изменения

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

  git status

  Мы увидим список всех измененных/добавленных файлов. Можно посмотреть изменения построчно с git diff , или воспользоваться какой-нибудь утилитой вроде gitk (скорее всего у вас он уже есть, так что достаточно просто ввести в консоли).

  Перед коммитом нужно отметить необходимые для коммита файлы через git add (добавить в «индекс»). Добавлять файлы по одному (для удобства можно пользоваться автодополнением по TAB-у, он здорово помогает):

  git add path/to/file/file.dm

  Либо же отметить сразу все изменения:

  git add .

  В случае, если вы зафиксировали не нужный вам файл, то для извлечения из индекса вам необходимо ввести следующею команду:

  git reset head path/to/file/file.dm

  Через git status мы увидим список добавленных файлов, и если всё ок — делаем коммит:

  git commit -m "Ваше описание коммита"

  В названии желательно подробно и доступно описывать, что было измененно, и зачем. Если это был фикс бага из трекера — нужно прописать в названии «Fixes #номер» — гитхаб понимает такие коммиты, и в дальнейшем сам проставит ссылку с номера на баг в багтрекере, а после мержа сам закроет баг.

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

  git checkout -- path/to/file/file.dm

  Отправляем изменения

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

  git push -u origin some-awesome-feature

  Создаст ветку some-awesome-feature в вашем репозитории на гитхабе, закинет туда наши коммиты. Флаг -u нужен, что бы зафиксировать связь между нашей локальной и удаленной ветками. При следующих можно будет просто указать git push , либо для надежности при работе сразу с несколькими ветками/репозиториями — git push origin some-awesome-feature

  О создании ПРа стоит прочитать в этой статье

  Немного о merge (слиянии изменения)

  Скорее всего вам редко придётся пользоваться командой git merge, поэтому мы просто оставим ссылку на документацию.

  Полезные советы

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

  git checkout -b some-awesome-feature upstream/master

  Сразу создаст ветку на основе upstream/master , без необходимости дополнительно обновлять.

  2. При обновлении и мерже изменений с апстримом, можно использовать флаг rebase — избавит от лишних коммитов в истории вида «юзернейм слил мастер в свою ветку»

  git pull --rebase upstream master

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

  git push --force

  3. Изменить или дополнить последний коммит можно с помощью флага —amend. Как обычно добавляете файлы в индекс, потом прописываете

  git commit --amend

  Все изменения попадут в последний коммит. Можно так же сразу поменять название:

  git commit --amend -m "Новое название коммита"

  Чтобы не изменять название коммита можно воспользоваться опцией —no-edit:

  git commit --amend --no-edit

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

  git push --force

  Напоследок

  Это довольно поверхностное описание без углубления в детали и другие возможности git. Ознакомится подробнее можно в многочисленных гайдах на просторах интернета, как пример: https://git-scm.com/book/ru/v1

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

  Похожие публикации:

  1. Crashdumps что это за папка
  2. Web scraping что это
  3. Как сделать интернет в mit app inventor
  4. Как сохранить написанный документ с помощью горячих клавиш