Github Repository 생성

[Repository name *] 부분에 아무 이름을 넣고 새로운 리포지토리(원격 저장소)를 만들어준다.

Git Push

GitHub로 올릴 로컬 디렉토리에서 아래 코드를 순차적으로 따라가면 된다.

코드를 푸시 할 원격 브랜치를 설정한다.
git branch를 입력해보면 기본적으로 master로 설정되어 있을 것이다. 최근에는 master보다 main을 많이 쓴다. 메인 브랜치를 main으로 변경한다.
```
git branch -M main
```
Git에서 브랜치는 매우 중요한 개념이다. Git으로 협업을 하다 보면 여러 사람이 각자 수정한 코드를 리포지토리에 반영해야 하는데 바로 main 브랜치에 반영하는 건 미친짓이다. 버그나 충돌이 일어났을 때 원인을 찾거나 되돌리기가 어려워지기 때문이다. 그렇기 때문에 나중에 나오겠지만 GitHub에 코드를 업데이트할 때 기본적으로 main이 아닌 다른 브랜치(예를 들어 develop)로 우선 푸시한 다음, main 브랜치와 develop 브랜치를 병합(merge)하기 위한 풀-리퀘스트(Pull-Request)를 생성하여 main 브랜치와 합친다. 새로운 브랜치를 생성하기 위해서는 git checkout을 사용한다. `git checkout은 브랜치를 변경할 때도 사용한다.
```
git checkout -b <브랜치 이름>
git checkout <브랜치 이름>
```
git branch를 입력하면 현재 브랜치를 볼 수 있다.
```
git branch
```

Git 리모트를 생성한다. 주로 origin이라는 이름으로 생성한다. 이 때 내가 만든 리포지토리 주소를 뒤에 붙여 적는다. 웬만해서 리모트는 생성 후 건들 일이 잘 없다.
```
git remote add origin https://github.com/<유저 이름>/<리포지토리 이름>.git
```
git remote를 통해 현재 리모트를 볼 수 있다.
```
git remote
```

Git 푸시를 진행할 준비를 모두 마쳤으면 코드를 원격 브랜치로 푸시한다.
```
git push origin main
```
쉽게 생각해서 origin을 로컬, main을 원격이라고 생각하면 쉽다. 푸시를 통해 코드 변경 사항을 origin의 내용을 main으로 푸시한다고 생각하자.
사실 엄연히 말하면 브랜치는 로컬 브랜치와 원격 브랜치로 나누어지기 때문에 이를 잘 구분해야 한다. 커밋을 하면 원격 브랜치가 아니라 로컬 브랜치에 반영이 된다. 그래서 처음 커밋을 할 때 어떤 브랜치에서 커밋을 하는지 잘 확인해야 된다. 만약 잘못 커밋 했다면, 예를 들어 patch-1에서 커밋을 해야 하는데 patch-2에서 커밋을 진행했다면 cherry-pick으로 커밋을 끌어올 수는 있다.
```
git checkout patch-1
git cherry-pick <커밋 해시>
```
-u 옵션을 사용하면 푸시 시 리모트와 브랜치를 저장해 놓을 수 있다. 즉 푸시할 때마다 원래는 git push origin main처럼 입력해 주어야 하지만, -u를 이용해 초기에 푸시해 놓으면 이후부터는 git push만 입력해도 자동으로 리모트는 orgin으로, 브랜치는 main으로 설정된다.
```
git push -u origin main
```