Necesitatea de a gestiona mai multe conturi GitHub pe aceeași mașină apare la un moment dat pentru majoritatea dezvoltatorilor. De fiecare dată când îmi schimb Mac-ul sau trebuie să Git push cu un nou cont de lucru, ajung să navighez pentru a afla cum să fac ceva ce am făcut de peste o jumătate de duzină de ori.

Lenea mea de a nu documenta procesul și incapacitatea de a-mi aminti pașii mă fac să petrec o cantitate decentă de timp obținând bucăți de pe întregul web și apoi făcându-l cumva să funcționeze.

Sunt sigur că sunteți mulți dintre voi care ați fost acolo, ați făcut asta și mulți alții dintre voi care așteptați pentru următoarea dată când se întâmplă același lucru (inclusiv eu!). Acest efort este menit să ne ajute pe toți.

1. Generarea cheilor SSH

Înainte de a genera o cheie SSH, putem verifica dacă avem chei SSH existente: ls -al ~/.ssh Aceasta va enumera toate perechile de chei publice și private existente, dacă există.

Dacă ~/.ssh/id_rsa este disponibil, îl putem reutiliza sau altfel putem genera mai întâi o cheie a valorii implicite ~/.ssh/id_rsa prin alergare:

ssh-keygen -t rsa

Când vi se solicită locația pentru a salva tastele, acceptați locația implicită apăsând Enter. O cheie privată și o cheie publică ~/.ssh/id_rsa.pub va fi creat la locația ssh implicită ~/.ssh/.

ad-banner

Să folosim această pereche de chei implicită pentru contul nostru personal.

Pentru conturile de lucru, vom crea diferite chei SSH. Codul de mai jos va genera cheile SSH și va salva cheia publică cu eticheta „Email@work_mail.com” la ~/.ssh/id_rsa_work_user1.pub

$ ssh-keygen -t rsa -C "email@work_mail.com" -f "id_rsa_work_user1"

Avem două chei diferite create:

~/.ssh/id_rsa
~/.ssh/id_rsa_work_user1

2. Adăugarea noii chei SSH la contul GitHub corespunzător

Avem deja cheile publice SSH pregătite și le vom cere conturilor noastre GitHub să aibă încredere în cheile pe care le-am creat. Aceasta este pentru a scăpa de necesitatea introducerii numelui de utilizator și a parolei de fiecare dată când faceți o apăsare Git.

Copiați cheia publică pbcopy < ~/.ssh/id_rsa.pub și apoi conectați-vă la contul dvs. personal GitHub:

  1. Mergi la Settings
  2. Selectați SSH and GPG keys din meniul din stânga.
  3. Click pe New SSH key, furnizați un titlu adecvat și lipiți cheia în caseta de mai jos
  4. Clic Add key – și gata!

Pentru conturile de lucru, utilizați cheile publice corespunzătoare (pbcopy < ~/.ssh/id_rsa_work_user1.pub) și repetați pașii de mai sus în conturile dvs. de lucru GitHub.

3. Înregistrarea noilor chei SSH la ssh-agent

Pentru a utiliza tastele, trebuie să le înregistrăm la ssh-agent pe aparatul nostru. Asigurați-vă că ssh-agent rulează folosind comanda eval "$(ssh-agent -s)".
Adăugați cheile agentului ssh astfel:

ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/id_rsa_work_user1

Faceți agentul ssh să utilizeze cheile SSH respective pentru diferitele gazde SSH.

Aceasta este partea crucială și avem două abordări diferite:

Folosind fișierul de configurare SSH (Pasul 4) și având o singură cheie SSH activă în agentul ssh la un moment dat (Pasul 5).

4. Crearea fișierului de configurare SSH

Aici adăugăm de fapt regulile de configurare SSH pentru diferite gazde, precizând ce fișier de identitate să folosim pentru ce domeniu.

Fișierul de configurare SSH va fi disponibil la adresa ~ / .ssh / config. Editați-l dacă există sau altfel îl putem crea.

$ cd ~/.ssh/
$ touch config           // Creates the file if not exists
$ code config            // Opens the file in VS code, use any editor

Faceți intrări de configurare pentru conturile GitHub relevante similare cu cele de mai jos în ~/.ssh/config fişier:

# Personal account, - the default config
Host github.com
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_rsa
   
# Work account-1
Host github.com-work_user1    
   HostName github.com
   User git
   IdentityFile ~/.ssh/id_rsa_work_user1

„utilizator_utilizator1”Este ID-ul de utilizator GitHub pentru contul de lucru.

„github.com-utilizator_utilizator1”Este o notație utilizată pentru a diferenția mai multe conturi Git. De asemenea, puteți utiliza „utilizator_utilizator1.github.com ” notație, de asemenea. Asigurați-vă că sunteți în concordanță cu notația numelui de gazdă pe care o utilizați. Acest lucru este relevant atunci când clonați un depozit sau când setați originea la distanță pentru un depozit local

Configurația de mai sus cere ssh-agent să:

  • Utilizare id_rsa ca cheie pentru orice adresă URL Git care folosește @ github.com
  • Folosește id_rsa_work_user1 cheie pentru orice adresă URL Git care folosește @ github.com-work_user1

5. O cheie SSH activă în agentul ssh la un moment dat

Această abordare nu necesită regulile de configurare SSH. Mai degrabă ne asigurăm manual că agentul ssh are atașată doar cheia relevantă în momentul oricărei operațiuni Git.

ssh-add -l va lista toate cheile SSH atașate agentului ssh. Eliminați-le pe toate și adăugați singura cheie pe care urmează să o utilizați.

Dacă sunteți pe un cont personal Git pe care sunteți pe cale să îl împingeți:

$ ssh-add -D            //removes all ssh entries from the ssh-agent
$ ssh-add ~/.ssh/id_rsa                 // Adds the relevant ssh key

Agentul ssh are acum cheia mapată cu contul personal GitHub și putem face un push Git către depozitul personal.

Pentru a trece la contul dvs. GitHub de lucru-1, schimbați cheia SSH mapată cu agentul ssh eliminând cheia existentă și adăugând cheia SSH mapată cu contul de lucru GitHub.

$ ssh-add -D
$ ssh-add ~/.ssh/id_rsa_work_user1

În prezent, agentul ssh are cheia mapată cu contul Github de lucru și puteți efectua un push Git în depozitul de lucru. Totuși, acest lucru necesită un pic de efort manual.

Setarea URL-ului git remote pentru depozitele locale

Odată ce avem clonate / create depozite locale Git, asigurați-vă că numele de utilizator și adresa de e-mail Git este exact ceea ce doriți. GitHub îl identifică pe autorul oricărui commit din ID-ul de e-mail atașat cu descrierea commit.

Pentru a lista numele de configurare și adresa de e-mail în directorul local Git, faceți git config user.name și git config user.email. Dacă nu este găsit, actualizați în consecință.

git config user.name "User 1"   // Updates git config user name
git config user.email "user1@workMail.com"

6. În timp ce clonați depozite

Notă: pasul 7 va ajuta, dacă avem depozitul deja disponibil pe local.

Acum, când configurațiile sunt la locul lor, putem continua și clona depozitele corespunzătoare. La clonare, notați că folosim numele de gazdă pe care le-am folosit în configurația SSH.

Depozitele pot fi clonate folosind comanda de clonare oferită de Git:

git clone git@github.com:personal_account_name/repo_name.git

Depozitul de lucru va necesita o modificare cu această comandă:

git clone git@github.com-work_user1:work_user1/repo_name.git

Această modificare se face în funcție de numele de gazdă definit în configurația SSH. Șirul dintre @ și: ar trebui să se potrivească cu ceea ce am dat în fișierul de configurare SSH.

7. Pentru depozitele existente la nivel local

Dacă avem depozitul deja clonat:

Enumerați telecomanda Git a depozitului, git remote -v

Verificați dacă adresa URL se potrivește cu gazda noastră GitHub pentru a fi utilizată sau altfel actualizați adresa URL de origine la distanță.

git remote set-url origin git@github.com-worker_user1:worker_user1/repo_name.git

Asigurați șirul dintre @ și: se potrivește cu gazda pe care am dat-o în configurația SSH.

Dacă creați un nou depozit pe local:

Inițializați Git în folderul proiectului git init.

Creați noul depozit în contul GitHub și apoi adăugați-l ca telecomandă Git la depozitul local.

git remote add origin git@github.com-work_user1:work_user1/repo_name.git

Asigurați șirul dintre @ și: se potrivește cu gazda pe care am dat-o în configurația SSH.

Împingeți angajamentul inițial către depozitul GitHub:

git add .
git commit -m "Initial commit"
git push -u origin master

Am terminat!

Adăugarea sau actualizarea telecomenzii Git din directorul local Git cu gazda corespunzătoare se va ocupa de selectarea cheii SSH corecte pentru a ne verifica identitatea cu GitHub. Cu toate cele de mai sus la locul nostru git operations ar trebui să funcționeze perfect.