깃허브의 가장 중요한 기능은, 깃허브를 요약하는 한 단어는 깃 저장소(레포지토리)를 위한 호스팅(to provide the space and other thins necessary for a special event) 플랫폼(애플리케이션을 인터넷을 통해 접근 가능하게 만든느 서비스)이다. 깃허브를 사용하면 클라우드에 깃 저장소를 넣을 수 있다. 어디서나 액세스할 수 있고 사람들과 공유할 수 있으며 사람들과 협업할 수 있다.
예를 들어, 비디오 게임(모바일 게임)을 내 컴퓨터에서 개발 중이라고 가정해보자. 버전을 추적하기 위해 깃을 이용해 컴퓨터에 몇 백개의 커밋을 만들었다고 가정하자. 그 다음 깃허브 계정과 깃허브 저장소를 만들고 내 로컬 코드를 내 컴퓨터의 저장소에서 깃허브로 푸시할 수 있다. 이렇게 하는 이유는 다음과 같다. 첫째는 백업을 하기 위해서이다. 만약에 집에 불이 나서 랩탑이 없어지더라도 레포지토리가 깃허브에 올려져있기 때문에, 코드의 history는 유효하다. 두번째는 협업을 위해서이다.
왜 깃허브를 사용해야할까?
코드 백업이나 협업이라는 기본적인 이유 외에도 다른 이유가 있다. 그 이유 중 하나는 오픈 소스 프로젝트라는 것이다. 언젠가 구직할 계획이라면 오픈 소스에 참여해보는 것도 좋다. 깃허브를 통해 개발자로서의 역량을 강화할 수 있다. 또한 깃허브를 통해 새로운 정보를 얻을 수 있기 때문이다. 예를 들어 리액트 개발자라면, 리액트 프로젝트로 가면 변경 사항에 대한 최신 정보를 얻을 수 있다.
git clone은 입력한 URL에 있는 저장소의 내용을 다운로드하는 것이다. git clone 은 깃허브의 명령어가 아니라 git의 명령어이기 때문에, github 말고 다른 호스팅 플랫폼에도 적용이 가능하다. 그리고 Github에서 제공된 레포지토리는 오픈되어있기 때문에 누구든지 Github에서 레포지토리를 클론 가능하다. 비공개라면 어차피 URL을 모르기 때문에, 클론할 수 없다. 그러나 우리가 변경한 것을 push하는 것은 허용되지 않는다. push란 우리가 변경한 변경 사항을 다른 사람이 소유한 저장소로 보내 기여자가 되는 것인데, 이렇게 기여자가 되는 방법은 따로 있다.
git clone <url> 을 할 때 가장 중요한 것은 깃 저장소에서 이 명령을 실행하지 않는 것이다.
SSH 는 자세히 설명하지는 않겠지만 Secure Shell의 약자로 이 프로토콜을 이용하면, 커맨드 라인에서 깃허브와 상호 작용하고 싶을 때, 매번 이메일이나 사용자 이름과 비밀번호를 쓰지 않고 인증이 가능하다. 우리가 해야되는 일은 SSH 키 중 하나를 생성한 후, 깃허브에 알려주면 된다.
우선 SSH key가 이미 존재하는지 알아보기 위해서 ls -al ~/.ssh 명령어를 실행한다. id_rsa.pub, id_ecdsa.pub, id_ed25519.pub 가 없는 경우에 키가 없는 것이다.
그 다음 단계는 SSH 키를 SSH 에이전트(사용자가 SSH 키를 안전하게 관리하고 키의 패스워드를 다시 입력하지 않고 여러 서버에 접근할 수 있도록 도와주는 프로그램이다)에 추가하는 것이다. 이러한 과정은 에이전트에게 해당 키의 사용 권한을 부여하는 과정이다.
start the ssh-agent in the background
*SSH Key란?
SSH는 암호화된 원격 접속 프로토콜이며, 서버에 접속 할때 비밀번호 대신 키를 제출하는 방식으로 비밀번호보다 높은 수준의 보안을 적용할 수 있고, 로그인 없이 자동으로 서버에 접속할 수 있게 한다. SSH Key는 개인키(Private Key)와 공유키(Public Key)로 구성된다. 공유키는 다른사람과 공유가 되는 자물쇠 같은 역할을 하고 개인키는 자물쇠를 푸는 열쇠의 역할을 한다.
Github Repo를 만들 때는 두가지 옵션이 있다. 첫 번째는 컴퓨터에 기존 저장소가 있는 경우이다. 깃허브에서 새 저장소를 만든 다음 원격이라는 것을 추가하여 로컬 저장소에 연결해야한다. 그 다음 변경 사항을 깃허브에 추가한다. 정리하면 다음과 같다.
1. Create empty Github repo
2. Tell your local repo about the Github repo(연결짓기)
3. Push from local repo to the new Github repo
두 번째는 아직 작업을 하지 않는 경우이다. 즉 어디에도 저장소가 없는 경우이다. 이런 경우는 깃허브에서 새 저장소를 만든 후, 그것을 내 컴퓨터에 클론한다. git init 을 실행하는 대신 git clone을 한다. 그 다음 작업을 시작해서 깃허브에 푸쉬한다. 이 방법은 로컬 저장소와 깃허브 저장소에 수동으로 연결할 필요가 없다. 왜냐하면 깃허브에서 이 저장소를 클론하면 해당 깃허브 URL에 자동으로 연결되기 때문이다. 정리하면 다음과 같다.
1. Create a new empty repo on Github
2. Clone the Github repo to your local machine
3. Push that new work up to Github
empty 브랜치로 갔을 때, This branch is 1 commit ahead, 1 commit behind master 여기서 ahead는 master 보다 하나 많아서 앞에 나가있다는 뜻이고behind는 master 보다 하나 적어서 뒤에 있다는 뜻이다.

여기서 검정 선이 나타내는 것은 커밋인데, 각각의 파일에 영향을 미친 가장 최근 커밋들을 나타낸다.

모든 커밋을 보려면 검정 선이 나타내는 곳을 클릭한다.
git remote -v를 사용하는데, 이 때 remote는 URL에 이름을 붙인 것 뿐이다. git remote -v 명령은 현재 저장소에 있는 원격들을 나열해서 보여준다.

git remote -v 명령을 사용하면 원격의 이름과 관련된 URL이 표시된다. 만약에 이어져있는 원격이 없다면, git remote add <name> <url> 명령을 사용하여 원격을 만들 수 있다. 이는 "안녕 깃, 이 URL을 이 이름으로 기억하렴 내가 이름을 말하면 이 URL을 이야기하는 것이라고 생각해" 로 명령하는 것과 같다. 예를 들어 다음과 같이 사용가능하다.
git remote add origin https://github.com/blah/repo.git

local에 repo가 있는 경우에는 위 사진의 밑줄 친 부분의 명령어를 커맨드 라인에 입력한다. 필요하다면 git remote rename <old> <new> 명령어로 원격의 이름을 바꾸거나 git remove <name> 명령어로 원격을 삭제할 수 있다.
git push <remote> <branch> 명령을 사용하여 이 작업을 수행한다. 지금 우리가 다루는 예시의 경우 remote는 1개이지만 여러개가 있을 수도 있다. 그리고 <branch> 의 경우 푸쉬할 브랜치를 의미한다. 만약에 큰 저장소에 많은 브랜치가 있을 수 있는데, 이러한 브랜치를 모두 깃허브에 올리고 싶지 않을 수 있기 때문이다. 보통 마스터 브랜치겠지만, 어떤 브랜치든지 깃허브로 푸쉬할 수 있다. 따라서 다음과 같이 사용할 수 있다.
git push origin master
Push가 작동하는 방법과 로컬에 있는 브랜치와 깃허브의 브랜치 간의 관계를 알아보겠다.
처음 git push origin master 를 하면, github에서 master 브랜치가 만들어진다. 그 다음 다시 git push origin master를 하면 깃허브에 마스터라는 새로운 브랜치를 만들지는 않는다.
일반적으로는 로컬의 마스터 브랜치를 깃허브의 마스터 브랜치에 연결하고 푸시하지만 흔하지는 않지만 꼭 그렇게 해야될 필요는 없다. 즉 다른 브랜치로 푸쉬할 수 있다. 명령어는 다음과 같다.
git push <remote> <local-branch>:<remote-branch>
만약 git push origin cats master를 한다면 로컬의 cats 브랜치를 master 브랜치로 푸쉬한 것이다. 이를 통해 로컬 환경의 브랜치와 깃허브의 브랜치가 구분되어있고 엄연히 다르다는 것을 알 수 있다.
-u는 upstream을 의미한다. 로컬 브랜치의 upstream은 원격 브랜치를 가리키는 일종의 연결라고 볼 수 있다. 로컬 컴퓨터에 마스터 브랜치가 있는 경우 일반적으로 업스트림 브랜치는 오리진의 마스터 브랜치로 하기를 원한다. 만약 git push -u origin master를 한 경우 다음에 푸쉬할 때에는 git push를 하면 된다. 즉 깃에게 로컬 컴퓨터 내 저장소의 마스터 브랜치를 오리진 마스터로 푸시하라는 뜻이다.
-> 깃에게 master가 master와 연결되고 이를 기억하고 있으라는 것이다. 따라서 다음번에 push를 할때는 이미 연결되어있는 것을 알기 때문에 단순히 git push로 푸쉬 가능하다. 보통은 이런 방식으로 사용되지만 업스트림을 같은 이름의 원격 브랜치가 아닌 다른 걸로 설정할 때에도 사용 가능하다. 예를 들어 git push -u origin dogs:cats 을 하면 로컬의 dogs 브랜치를 깃허브의 cats 로 푸쉬하고 로컬 dogs의 업스트림을 cats로 설정을 한다. 그러나 이렇게는 보통 이렇게 하지 않는다. 보통은 앞서 말한 것처럼 처음 푸쉬할 때 사용한다.
main 과 master 브랜치가 같다.
git branch -M main-> 브랜치 이름을 main으로 바꾸는 것
처음에 로컬의 master 브랜치가 있는데, 이를 먼저 푸쉬한 상태에서 로컬에서 main으로 바꾸고 다시 푸쉬하면, github에는 main과 master 두 가지가 존재한다.

아래의 그림에서 처럼 default branch를 바꿀 수 있다.