6.깃허브
6-1.원격 저장소
지금까지 실습한 것은 로컬 깃에 모두 저장되어 있다. 소스를 엉망으로 만들어 놔도 언제든지 저장소에서 원하는 버전을 꺼내 복구할 수 있으니 안심이 된다. 그러나 로컬 백업은 컴퓨터가 무사할 때에 한해서만 안전하다. 저장 장치의 수명이 다하거나 컴퓨터가 고장날 수도 있고 극단적인 예로 집에 불이 나면 모든게 사라져 버린다.
컴퓨터 안에 있는 깃 백업 폴더를 지역 저장소라고 한다. 원본과 백업이 같은 장소에 있으면 같이 사라질 위험이 있어 안전을 보장하려면 백업은 분리되어 있어야 한다. 이런 역할을 하는 것이 바로 네트워크로 연결된 원격 저장소(Remote Repository)이다. 컴퓨터에 무슨 일이 발생해도 원격 저장소의 백업은 지구가 멸망할 때까지 안전하다.
원격 저장소는 소스를 백업하는 것 뿐만 아니라 아무 곳에서나 접속할 수 있다는 이점이 있다. 예를 들어 회사에서 일하다가 원격 저장소에 올려 두고 퇴근 후 집에서도 접속하여 일을 계속할 수 있다. 노트북 들고 카페에 앉아서도 소스 내용뿐만 아니라 작업하던 이력까지 관리할 수 있다.
나 뿐만 아니라 동료나 모르는 사람도 같은 저장소에 접속하여 똑같은 프로젝트를 동시에 사용할 수 있다. 내가 한국에서 올린 소스를 미국의 동료가 계속 개발할 수 있으며 반대도 마찬가지이다. 네트워크를 통해 협업을 할 수 있으며 소스 공유 뿐만 아니라 이슈나 버그 보고, 토론 등이 가능해진다.
원격 저장소를 경유하면 프로젝트를 만천하에 공개할 수 있으며 그래서 오픈소스 배포용으로 많이 사용한다. 개발에 필요한 라이브러나 예제 샘플 뿐만 아니라 완벽하게 동작하는 프로그램, 심지어 운영체제까지 수십년간 인류가 만들어낸 코드가 이 안에 다 있다고 보면 틀림없다. 그래서 개발자가 필수적으로 활용해야 하는 서비스이다.
6-2.깃허브
원격 저장소를 리눅스에 직접 설치할 수 있지만 설정하고 관리하는 일이 만만치 않다. 이미 잘 만들어진 서비스가 많이 있으므로 그 중 하나를 골라 사용하면 된다. 대표적인 서비스가 깃허브이다.
https://github.com/
모든 서비스가 다 그렇듯이 회원 가입부터 해야 한다. 회원 관리 정책은 매번 달라지므로 알아서 가입하자. 이메일 계정, ID, 비밀번호 등의 개인 정보를 입력하고 메일을 통해 계정 확인을 받으면 무료로 사용할 수 있다. 단, 무료인 경우는 프로젝트를 공개해야 하며 비공개 프로젝트는 제한이 있다.
본질적으로 공유를 위한 서비스이다 보니 기본 정책이 공개 프로젝트로 되어 있으며 개인 무료 사용자에게는 제약을 둘 수밖에 없다. 팀 인원이 많거나 프로젝트가 거대하다면 유료 결제하고 비공개 프로젝트를 보관할 수 있다. 실습을 진행해 보자. 상단 메뉴의 + 버튼을 누르면 저장소를 생성하는 메뉴가 있다.
New repository 명령을 선택하면 새 저장소를 만든다. 로컬에서 폴더를 만들고 git init 명령으로 초기화하던 동작을 원격에서 수행하는 것과 개념적으로 같다. 다만 원격지에 만들다 보니 옵션이 좀 많으며 정보를 입력하는 폼이 나타난다.
이중 이름은 필수이고 나머지는 선택적이거나 디폴트를 받아들이면 된다. 최소한 저장소끼리 구분 가능한 이름은 있어야 한다. 로컬에서 실습했던 폴더와 구분하기 위해 rem_game으로 저장소 이름을 지정하고 간단한 설명을 붙인다. 그외 프로젝트 공개, README 파일 생성, .gitignore 파일 생성, 라이선스 등의 옵션을 선택할 수 있는데 모두 디폴트를 받아 들인다.
옵션을 다 입력한 후 아래쪽의 초록색 Create ropository 버튼을 클릭하면 저장소를 생성하여 페이지로 이동한다. 저장소 주소는 https://github.com/아이디/이름 형식이며 주소에 누가 만든 어떤 저장소인지 정보가 이미 포함되어 있다. 방금 만든 저장소의 주소는 다음과 같다.
https://github.com/soenmaster/rem_game
soenmaster는 내 ID이고 rem_game은 방금 만든 저장소 이름이다. 누구든 이 주소로 접속하면 내가 만든 프로젝트를 볼 수 있다. 저장소 생성 후 저장소 옵션 폼이 나타난다.
원래는 프로젝트의 파일 목록이 나오지만 새로 만든 저장소라 아직 파일이 없다. 파일 목록의 Creating a new file 링크를 클릭하여 파일을 만든다. 파일을 편집할 수 있는 편집기가 열리는데 이름은 game.cpp로 지정하고 코드를 한줄 작성한다.
현재 브랜치는 로컬에서와 마찬가지로 main으로 되어 있는데 추가 브랜치를 얼마든지 만들 수 있다. 웹 환경에서도 코딩을 수행할 수는 있지만 로컬에서와 같은 컴파일이나 테스트까지 해 보기는 어렵다. 저장소는 어디까지나 저장이 임무이므로 보통은 파일만 만들고 실제 개발은 로컬에서 한다. 한줄 입력하고 상단의 Commit changes 버튼을 클릭하면 메시지 입력창을 보여 준다. 아래쪽에 상세 메시지를 더 길게 입력할 수도 있다.
첫 커밋을 하면 파일 목록이 나타난다. 프로젝트를 시작한 셈이니 상단에 프로젝트를 관리하는 메뉴도 생기고 전체적인 모양이 대폭 바뀐다.
여기까지 원격 저장소를 생성하고 소스 파일도 하나 만들어 올려 봤다. 웹 브라우저에서 작업을 수행했을 뿐 로컬에서 다음 작업을 순서대로 수행한 것과 비슷하다.
① 폴더 만들고 git init로 저장소 초기화
② 파일 생성 및 편집기로 소스 입력 후 저장
③ commit -m 명령으로 커밋
로컬이나 원격이나 저장소라는 것은 같으니 작업 절차도 비슷할 수밖에 없다. 그러나 로컬과는 다른 차이점이 있는데 원격은 소스를 저장하는 역할만 할 뿐이며 여기서 개발을 수행하지는 않는다. 따라서 원격에는 스테이지와 워킹트리의 개념이 없다. 스테이지에 먼저 추가할 필요 없고 커밋하면 바로 저장소로 올라가 버전이 된다.
원격 저장소는 로컬 저장소의 네트워크 버전일 뿐이며 구조는 같다. 브라우저로 접속하다 보니 파일 목록을 보여 주고 관리하는 방식이 다를 뿐이다. 목록에 추가된 파일은 언제든지 클릭하여 편집, 삭제할 수 있다. 실습삼아 한번 더 수정해 보자. 목록에서 파일을 클릭하면 파일 보기 페이지로 이동하여 파일 내용을 보여 준다.
일단은 보여만 주는데 오른쪽의 연필 버튼을 클릭하면 편집 상태로 들어간다. 게임을 계속 실행하는 루프를 작성해 보자. 물론 의사코드이다.
커밋하고 메시지를 "루프 작성"이라고 입력한다. rem_game 저장소 이름을 클릭하면 목록으로 돌아오며 최신 커밋 상태가 표시된다.
이런 식으로 파일을 추가, 편집하여 프로젝트를 수행한다. 여기서 컴파일까지 할 수는 없으니 개발은 로컬에서 작업해야 한다. 이 실습은 다음 항에서 계속해 보자.
잘못 만들었거나 더 이상 필요없는 저장소는 삭제한다. 저장소를 지우는 경우는 흔하지 않지만 지금은 실습중이고 실수로 잘못 만들 수도 있으니 지우는 방법도 알아 두어야 한다. 상단 메뉴의 제일 오른쪽에 있는 Settings 버튼을 클릭한다.
이 페이지 제일 아래에 Delete this repository 버튼을 클릭한다. 삭제 명령이 메인에 드러나 있지 않아 처음에는 찾기 어렵다. 저장소를 지우는 것은 굉장히 위험할 수 있어 여러번 확인하며 비밀번호도 입력해야 한다. 나 혼자 작업한게 아니라 여러 명의 참여자가 있을 수도 있어 모두의 동의를 받은 후 신중하게 삭제해야 한다.
웹 서비스의 특성상 UI가 고정되어 있지 않고 매번 바뀐다. 여러분이 이 강좌를 읽을 때 쯤에는 디자인이나 구조가 완전히 달라질 수도 있다. 또 페이지 단위로 상태를 저장하다 보니 불편하거나 직관적이지 못한 부분도 있다. 처음에는 헷갈리고 어렵지만 자주 써 보고 익숙해지면 네이버나 구글 서비스를 쓰는 것과 별반 다르지 않다.
6-3.로컬과 연결
원격 저장소는 소스만 저장할 뿐 개발 환경은 아니다. 개발을 진행하려면 로컬 저장소와 연결하여 소스를 내 컴퓨터로 가져와야 한다. StudyGit 폴더에 rem_game 폴더를 만들고 저장소를 초기화한다. 그냥 game으로 해도 되지만 로컬에서 실습했던 저장소와 이름이 같아 원격지의 게임 프로젝트라는 뜻으로 다른 이름을 붙였다.
$ git init rem_game;cd rem_game
rem_game 폴더안에 .git 폴더가 생기고 버전 관리 대상으로 초기화한다. 그러나 아직 파일은 하나도 없다. 로컬 저장소를 원격 저장소와 연결한다. 그 전에 연결할 원격 저장소의 주소를 미리 알아 두어야 한다. 깃허브 사이트에서 rem_game을 클릭한 후 주소 표시줄을 복사하면 된다.
id/repository 형식이라 외워서 쓸 수도 있다. 원격 저장소와 로컬 저장소를 연결하는 명령은 git remote add이다. 인수로 원격 저장소의 이름과 주소를 전달한다. 주소가 너무 길어 매번 사용하기는 불편하니 별명을 붙인 후 연결한다고 생각하면 된다.
$ git remote add origin https://github.com/soenmaster/rem_game
이 명령은 rem_game 저장소를 연결하고 origin이라는 이름을 부여한다. 여기서 origin은 어디까지나 원격지를 상징하는 별명일 뿐이어서 mygame이나 gitgame 따위로 붙여도 무방하지만 관행적으로 origin 이름을 쓴다.
origin은 이 저장소의 원본이 있는 곳이라는 뜻인데 깃 폴더내에서는 항상 연결된 원격지 주소를 의미한다. 이런걸 관습적 명칭이라고 하는데 누구나 원격지의 별명은 origin으로 붙인다. 관행을 어겨봐야 헷갈리기만 할 뿐이므로 웬만하면 이 이름을 쓰는 것이 좋다.
원격지가 존재하지 않으면 에러 메시지를 출력하며 무사히 잘 연결했으면 아무 메시지도 나타나지 않는다. 성공 메시지를 따로 보여주지 않아 썰렁한데 잘 연결되었는지는 직접 확인해야 한다. git remote 명령은 연결명을 보여 주며 -v 옵션을 지정하면 주소도 보여준다. 가장 상세한 정보는 show 명령으로 확인하되 연결명을 인수로 지정한다.
$ git remote show origin
* remote origin
Fetch URL: https://github.com/soenmaster/rem_game
Push URL: https://github.com/soenmaster/rem_game
HEAD branch: main
Remote branch:
main new (next fetch will store in remotes/origin)
연결된 주소와 현재 브랜치명이 나타나면 잘 연결되어 있는 것이다. 연결명을 변경할 때는 rename 명령을 사용한다. origin이라는 이름이 정 마음에 안들면 다른 이름으로 바꿀 수 있다.
$ git remote rename origin gitgame
이후부터 원격지를 칭할 때 바꾼 이름을 사용한다. 연결을 끊을 때는 remove 명령을 사용한다.
$ git remote remove origin
원격지 소스를 받아 개발하다가 다시 업로드할 일이 없거나 독자적으로 개발하고 싶을 때는 연결을 끊어 버리면 된다. 원격지의 주소가 바뀐 경우는 set-url 명령으로 변경된 주소를 새로 지정한다.
git remote set-url origin 새주소
원격지의 주소가 바뀌는 경우는 무척 드물지만 인증 방식을 바꾸면 주소가 바뀌는 경우는 가끔 있다.
6-4.pull
연결했으면 원격지의 파일을 로컬로 가져올 수 있다. 이때는 pull 명령을 사용하는데 원격지에서 소스를 당겨오라는 명령이다. 일반적인 용어로는 다운로드라고 생각하면 된다. 인수로 원격지 저장소와 브랜치를 지정한다. 저장소는 앞에서 지정한 origin을 지정하고 브랜치는 main이다.
$ git pull origin main
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (6/6), 1.82 KiB | 109.00 KiB/s, done.
From https://github.com/soenmaster/rem_game
* branch main -> FETCH_HEAD
* [new branch] main -> origin/main
이 명령에 의해 원격 저장소에 만들어 놓은 main 브랜치와 그 브랜치에 속한 game.cpp가 지역 저장소로 들어온다. 내용을 확인해 보면 원격 저장소에서 편집했던 그대로이다.
이런 식으로 소스를 공유한다. 파일만 가져오는게 아니라 브랜치의 모든 커밋 이력도 다 가지고 온다. 과연 그런지 로그를 찍어 보자.
$ git log
commit 7ea42f28af5e36b6d9a5357c1e0534250f9958fc (HEAD -> main, origin/main)
Author: SangHyung <46168678+soenmaster@users.noreply.github.com>
Date: Mon Oct 28 02:13:11 2024 +0900
루프 작성
commit f8c1db34031429ed41da925e5b4323e27bf23f7c
Author: SangHyung <46168678+soenmaster@users.noreply.github.com>
Date: Mon Oct 28 02:10:20 2024 +0900
프로젝트 시작
보다시피 깃허브에서 작업했던 이력이 그대로 표시된다. 다만 작업자 이름이 원격지의 로그인명으로 표시되는데 이름만 다른 같은 사람, 즉 본인이다. 현재는 한 사람이 실습을 하고 있지만 아예 다른 사람이 작업한 것을 가져올 수도 있고 다른 사람도 rem_game을 퍼 갈 수 있다.
깃허브의 원격지 저장소를 로컬로 가져왔는데 별다른 제약이나 신분 확인 과정이 없다. 가져가는 사람이 누구인지 물어 보지도 않고 요청만 하면 내준다. 왜냐하면 애초에 rem_game 저장소를 공개용으로 만들었고 세상 모든 사람에게 공유되어 있기 때문이다. 대신 누가 이 소스를 가져 갔는지는 알 수 있다.
한명이 이 저장소에 연결했음을 표시하며 클릭하면 누구인지 보여준다. 지금은 물론 같은 사람이다. 게시판에서 조회수와 같은 개념인데 이 숫자를 보면 내 프로젝트가 얼마나 인기가 있는지 알 수 있다.
pull 명령은 원격지의 변경 사항을 가져오는 fetch와 로컬 브랜치에 병합하는 merge 명령을 동시에 수행하여 동기화한다. 양쪽에서 각자 수정한 것을 병합하는 것이므로 충돌이 발생할 수 있다. 필요하다면 옵션을 지정하여 두 동작 중 일부만 수행한 후 수동 병합해야 한다.
|
옵션 |
설명 |
|
--no-commit |
변경 사항을 병합하지만 커밋하지는 않는다. 변경 내역을 검토한 후 수동으로 커밋할 때 사용한다. |
|
--ff-only |
빠른 전진 병합만 수행하며 불가능한 경우 오류를 리턴한다. 병합 가능한 것만 병합한다. |
|
--rebase |
변경 사항을 병합하기보다는 다시 적용한다. 커밋 목록이 더 깔끔하게 유지된다. |
지금은 로컬 저장소를 새로 만들어서 가져온 것이라 충돌이 발생할 이유가 없다. 그러나 프로젝트 중간에 로컬에서도 수정하고 원격에서도 누군가 수정을 했다면 충돌이 발생할 수 있다. 충돌 발생시의 대처는 앞에서 했던 병합 실습과 유사하다. 원격지에서 여러 사람이 협업하다보면 피할 수 없는 현상이다.
6-5.push
이번에는 로컬에서 소스를 편집하여 커밋한 후 원격지에 올려 보자. 소스를 받았으니 원하는대로 수정하여 개발을 진행할 수 있다. 소스에 몇 줄 추가하여 루프 내부의 논리를 채워 넣는다.
소개 화면 표시하고 키 누를 때까지 대기
while (죽을 때까지) {
주인공 이동
적군 이동
총알 발사 및 충돌 점검
}
수정한 파일을 저장하는 것은 워킹트리의 파일만 바꾸는 것이다. commit 명령으로 스테이지에 올린 후 저장소에 커밋한다.
$ git commit -am "적군, 아군 이동"
[main c81b484] 적군, 아군 이동
1 file changed, 3 insertions(+)
이 커밋은 로컬 저장소에 저장하는 것이지 아직 원격으로 올라간 것은 아니다. 원격지로 보낼 때는 push 명령을 사용한다. 당긴다는 의미의 pull이 다운로드이고 밀어 넣는다는 의미의 push가 업로드이다. 올릴 곳과 올릴 브랜치를 인수로 지정한다.
$ git push origin main
origin은 최초 연결할 때 준 이름이며 soenmaster/rem_game이다. 이 저장소로 로컬의 main 브랜치를 올리라는 명령이다. 최초 이 명령을 내리면 로그인창이 뜬다. 소스를 받을 때와는 달리 올릴 때는 누가 올리는지 알아야 한다. 이런 확인 과정이 없으면 엉뚱한 사람이 원격지의 소스를 망쳐 놓을 수도 있다.
공개 프로젝트는 누구든 참여할 수 있지만 최소한 누가 올리는지는 확인해야 한다. 웹브라우저를 열어 로그인하면 원격지로 소스를 푸시한다. 한번 로그인해 두면 이후에는 푸시해도 더 확인하지 않는다.
$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 28 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 397 bytes | 397.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To https://github.com/soenmaster/rem_game
7ea42f2..c81b484 main -> main
웹브라우저에서 잘 들어왔는지 확인해 보자. 로컬에서 커밋한 내용이 원격지에도 반영되어 있으며 방금 커밋한 메시지가 보인다. game.cpp를 열어 보면 소스 내용도 바뀌어 있다. 이런 식으로 소스를 공유한다.
대부분 한 사람이 한 컴퓨터에서 실습하고 있겠지만 떨어져 있어도 상관없고 다른 사람이어도 무방하다. 내가 회사에서 작업한 결과를 깃허브에 올려 놓고 집에 와서 소스를 받아볼 수도 있으며 저장소 주소만 알려주면 친구가 자기 집에서 이 소스를 볼 수도 있다.
이 실습에서는 메일 주소가 같은 동일인임을 확인할 수 있고 별다른 보안 설정을 하지 않아 푸시한 내용이 원격지에 바로 반영되지만 상황에 따라 바로 반영되지 않고 반영 요청(pull reguest) 상태가 되기도 한다. 대형 프로젝트는 아무나 소스를 바꿀 수 없도록 되어 있고 요청해 두면 관리자가 검토하여 반영 여부를 결정한다.
즉시 반영 여부는 설정에 따라 달라진다. 아무리 오픈소스라고 해도 아무나 찝쩍대도록 방만하게 관리하지는 않는다는 얘기다. 푸시도 일종의 병합이므로 충돌이 발생할 수 있다. 충돌이 발생하지 않도록 작업 분담을 잘 해야 하지만 불가피하게 충돌이 발생하면 옵션으로 강제 병합해야 한다.
|
옵션 |
설명 |
|
-u |
원격지와 로컬의 브랜치를 연결해 둔다. 한번만 연결해 두면 이후부터는 git push 명령만 내리면 된다. |
|
--all |
로컬의 모든 브랜치를 푸시한다. |
|
--tags |
로컬의 모든 태그를 푸시한다. |
|
|
충돌 발생시 로컬의 커밋 기록을 강제로 덮어 쓴다. 이 옵션을 주지 않으면 푸시를 거부한다. |
|
--force-with-lease |
원격지의 소스가 변경되지 않았을 때만 강제 푸시한다. |
강제 푸시는 상당히 위험해 조심스럽게 사용해야 한다. git은 기본적으로 빠른 전진 병합을 사용하는데 각 작업자가 자신의 소스만 수정하면 큰 문제가 없다. 그러나 불가피하게 한 소스를 동시에 수정하면 상황이 복잡해진다.
상황별 병합 옵션의 정확한 동작과 효과를 잘 알아 두어야 한다. 정확히 알지도 못하면서 강제 병합해 버리면 프로젝트가 엉망이 될 수도 있다. 이런 기술을 완전히 체득하려면 상황을 만들어가며 모든 테스트를 다 해 봐야 하는데 굉장히 오랜 시간이 걸릴 것임을 예측할 수 있다. 이걸 잘 하는게 깃을 잘 쓰는 것이다.
6-6.SSH
소스를 공유하고 협업하려면 사용자 확인은 필수이다. 아무리 공개되어 있는 프로젝트라도 누가 소스를 바꾸는지, 권한은 있는지는 꼭 확인해야 한다. 읽는 것은 자유지만 바꾸는 것은 관리가 필요하다. 깃허브는 두 가지 방식으로 사용자를 확인한다.
▶ HTTPS : 깃허브의 로그인 ID와 비밀번호로 인증하는 전통적이고 상식적인 방법이다. 한번 인증하면 계속 쓸 수 있지만 브라우저의 인증 정보가 사라지면 주기적으로 재인증해야 하는 불편함이 있다.
▶ SSH(Secure Shell) : 개인키, 공개키 암호와 기법을 사용하여 컴퓨터를 인증한다. 인증 정보를 로컬 컴퓨터에 저장해 두므로 한번만 인증하면 별도의 인증없이 계속 사용할 수 있어 편리하다.
앞 실습에서 rem_game은 HTTPS로 연결했었다. 당장은 못 느끼겠지만 프로젝트를 진행하다 보면 인증이 풀리는 경우가 빈번해 불편하다. SSH로 연결을 바꿔 보자. 다음 명령으로 한쌍의 키를 만든다.
ssh-keygen -t 알고리즘 -C "이메일"
알고리즘은 과거에는 RSA를 주로 사용했으나 지금은 보안성이 더 높은 ed25519를 더 권장한다. 더 짧은 길이로도 보안성을 강화한 알고리즘이다.
여러 프로젝트에서 사용할 수 있고 접속 기기 자체를 인증하는 것이므로 홈 디렉토리에 만드는 것이 좋다. 홈 디렉토리로 이동하는 것이 원칙이지만 그렇지 않아도 어차피 홈 디렉토리에 생성된다. 암호 생성에 필요한 몇 가지 질문을 한다.
$ cd ~
soen@SoenDesk MINGW64 ~
$ ssh-keygen -t ed25519 -C "soenmaster@naver.com"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/c/Users/soen/.ssh/id_ed25519):
Created directory '/c/Users/soen/.ssh'.
Enter passphrase for "/c/Users/soen/.ssh/id_ed25519" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /c/Users/soen/.ssh/id_ed25519
Your public key has been saved in /c/Users/soen/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:bWlAE1Ix2h5pEViO+1wIIUVi5KmcoeAE7YKEu5Vl0sk soenmaster@naver.com
The key's randomart image is:
+--[ED25519 256]--+
|o. +=+=+@+ |
|o.ooE+.O = |
|++.=o + B |
|Bo++ = = . |
|.=+ . S * |
|. o + |
| o |
| |
| |
+----[SHA256]-----+
키 파일명을 입력하라고 하는데 디폴트는 id_ed25519이며 변경하지 않으려면 그냥 Enter만 치면 된다. 다음은 패스프레이즈를 입력하라고 하는데 이는 암호에 대한 암호이다. 키 파일이 유출될 때를 위해 이중으로 암호를 걸어 두는 것인데 필요 없으면 Enter만 두 번 누르면 된다. 키는 홈 디렉토리의 .ssh 디렉토리에 생성된다.
확장자 pub가 붙은 파일이 공개키이고 확장자가 없는 파일이 개인키이다. 파일 내용을 보면 알 수 없는 알파벳으로 가득 차 있다. 공개키의 내용을 모두 선택하여 클립보드에 복사하여 깃허브에 등록한다. 계정 아이콘을 클릭한 후 Settings를 선택한다. 저장소의 Setting이 아님을 유의하자.
아직 아무 키도 등록되어 있지 않다. New SSH Key 버튼을 클릭한다. 사용자당 컴퓨터를 여러 대 쓸 수도 있고 집, 회사 등 다른 장소에서 접속할 수도 있어 공개키는 여러 개 등록할 수 있다. 관리를 위해 이름을 붙이고 공개키를 붙여 넣는다.
보안과 관련된 설정이므로 로그인 비번으로 확인한다. 추가 완료하면 공개키가 목록에 나타난다. 필요없으면 삭제할 수 있고 더 추가할 수도 있다.
이제 SSH 주소만 알면 원격지에 바로 연결할 수 있다. 저장소의 초록색 Code 버튼을 누르면 연결 방법별 주소가 나타나는데 SSH를 눌러 주소를 복사해 둔다.
rem_game 폴더로 이동한 후 원격지의 주소를 변경한다. 이미 HTTPS로 연결했던 주소여서 URL을 바꿔야 한다.
$ git remote set-url origin
git@github.com:soenmaster/rem_game.git
새 저장소를 만들었다면 연결할 때부터 SSH 주소를 지정하면 된다. 접속 주소만 다를 뿐 연결하는 방법은 같다.
$ git remote add origin
git@github.com:soenmaster/rem_game.git
최초 접속할 때는 다음 메시지를 보여 준다. 이 시스템의 개인키가 아직 등록되지 않았는데 등록하겠냐는 뜻이다. y를 누르고 yes라고 한번 더 대답하면 연결된다.
The authenticity of host 'github.com (20.200.245.247)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
이제 별다른 조치가 없어도 이 컴퓨터에서는 rem_game 저장소에 자유롭게 접속할 수 있다. 소스 수정 후 push만 하면 자동으로 인증되고 별다른 질문없이 잘 업로드된다. 연결을 끊으려면 .ssh 폴더를 지우거나 github에 등록된 공개키를 지워 버리면 된다.