이 섹션에서 가장 중요한 것

Critical!	Important	Nice To Have
What Does Github Do?
Cloning
Registering for github & Setting Up SSH Keys
Creating Github Repos
Working With Remotes
Git Push

Github는 어떤 역할을 할까?

깃 저장소를 위한 호스팅 플랫폼이다.
깃허브를 사용하면 클라우드에 깃 저장소를 넣을 수 있다.

깃허브는 깃 저장소에 대한 협업 및 토론과 관련하여 구축된 기능의 묶음이다.
어디서나 엑세스 할 수 있고, 사람들과 공유할 수 있으며, 협업할 수 있다.

아래와 같이 로컬에서 작업하는 것은, 깃에서 작업하는 것이다.

아래와 같이 깃허브에 푸쉬를 하면 깃허브 작업.

계속 작업을 하다가 변경 사항이 있을 시 깃허브에 다시 푸시가 가능하다.

집에 불이나서 노트북이 소실되거나 하는 상황에서 깃허브를 최신 상태로 유지했다고 가정하면, 새로운 노트북을 사서 깃허브에 가서 해당 코드를 노트북에 다운로드가 가능하다.

'협업' 이 가능하다는 점도 큰 장점이다.

하지만, 깃허브에만 이러한 기능이 있는 것은 아니다. (깃랩, 빗버킷...)

하지만 깃허브는 세계에서 가장 큰 소스 코드 호스트가 되어서 개발자에게는 꼭 필요한 도구가 되었다.

그리고 무료라는 것이 중요하다.
(유료 옵션은 기업용이라 개인이 신경을 쓸 필요는 없다.)

Github를 사용해야 하는 이유!

-협업하기 위해-

-오픈 소스 프로젝트-

• 단순히 코드를 보는 게 아니라 기여를 할 수도 있다.

-취업에 도움-

• 깃허브 프로필이 우리의 코드에 대한 이력서로도 사용될 수 있다.

-깃 허브를 통해 최신 정보를 얻음-

Git Clone으로 Github Repo 복제하기

Cloning

• Git이라는 버전 관리 시스템을 이용해 다른 사람의 저장소(Repository)를 내 컴퓨터로 복사하는 것을 말합니다. 이를 통해 로컬 컴퓨터에서 해당 저장소의 파일들을 수정하거나 새로운 파일을 추가할 수 있습니다.
  
  
• Git을 사용하면 여러명이 함께 작업할 수 있는 협업 환경에서 개발을 진행할 수 있으며, 클로닝은 이를 가능하게 해주는 중요한 기능 중 하나입니다.
  
  
• 입력한 URL에 있는 저장소의 내용을 다운로드하는 것이다.
  
  
• URL은 깃허브와 같은 서비스에서 제공된다.
  
  
• 유의사항은, 이미 존재하는 저장소가 있는지 반드시 확인하고 Cloning을 해야 한다.

• 깃은 입력받은 URL로 가서 저장소에서 관련 정보를 가져오고, 파일을 컴퓨터에 복사하고 컴퓨터의 새 저장소를 초기화한다.

• 위 과정을 거치면, 우리는 클론한 프로젝트의 깃 전체 기록에 접근할 수 있다.

예를 들면 깃허브에 repo가 있다면

클론을 하면

깃은 그 모든 것을 Fetch해서 컴퓨터에 다운로드를 한다.
그러면 모든 기록, 모든 커밋, 모든 파일을 갖게 된다.

URL엔 아래와 같이 찾을 수 있다.

먼저, Cloning을 하기 전에 가장 먼저 해야 할 것은, 저장소에 있지 않은 지 확인해야 한다.

저장소가 없는 것을 확인 했으면, Cloning을 진행한다.

tip

• ctrl + insert : 복사하기
• shift + insert : 붙여넣기

Cloning이 완료 되면, 새로운 폴더가 생긴 것을 볼 수 있다.

깃 허브에서 온 이 파일들은, 정보들을 볼 수 있다.
(모든 커밋들, 누가 만들었는지, 언제 만들었는지... 기타등등)

Github가 아닌 저장소 복제하기

Cloning엔 허가가 필요한가?

• 허가가 없어도, 저장소를 우리 컴퓨터에 클론하는것은 괜찮다.
  즉, 깃헙에 보이는 것이면 그냥 쓸 수 있다.
  다만, 판매를 하는 것은... 안된다.
  어차피 비공개된 Git은 보이지 않는다.
  
  
• 하지만 클론한 것의 변경 사항을 다른 사람이 소유한 저장소로 푸쉬하는 것은 안된다. 변경 사항을 제안하고 기여자가 되는 방법은 따로 존재한다.

현재까지는 모든 Cloning은 깃허브 저장소에서 진행했다

하지만, git clone은 모든 호스팅 저장소에서 사용 가능하다.

위와 같은 GitLab에서도 클론이 가능하다.

Github 설정: SSH구성

이번 단계는 매우 중요하다. 바로 깃허브에 등록하는 것인데, 등록을 위해 먼저 github에 접속해야 한다.

GitHub

참고로, 깃허브 메일은 깃에 등록된 메일과 같은 메일을 사용하는 것이 좋다.

SSH

• Secure Shell의 약자이다.
• 이 프로토콜을 사용하면, 커맨드 라인에서 깃허브와 상호 작용 하고 싶을 때, 매번 이메일이나 사용자 이름과 비밀번호를 쓰지 않고도 인증이 가능하다.
• SSH 키 중 하나를 생성한 다음, 깃 허브에 알려주면 된다.
  Github_SSH

첫 번째 단계는, 이미 SSH키가 생성되었는지 확인 하는 것이다.

위 명령은 .ssh 디렉토리 안에 있는 기존 파일 전체를 보여준다.
첫 줄 달러표시($)는 입력하지 않아도 된다.

위 3 파일중 아무것도 존재 하지 않는 경우나 새로운 키를 만들고 싶은 경우엔 새 키를 생성해야 한다.

새 키를 생성하기 위해 아래와 같은 명령어를 입력하자

그럼, 해당 키를 저장할 파일을 요청하는데 기존 위치에 저장하고 싶으면 그냥 Enter를 누르면 된다.

다음엔 passphrase(비밀번호)를 입력하라 하는데 입력하고 비밀번호 확인을 위해 한 번 더 입력하면 마무리가 된다.

이제 내 신분 증명(identification)이 이 파일에 저장되었고, 내 공개 키(public key)도 파일에 저장되었다 알려준다.

그 다음 단계는, SSH키를 SSH에이전트에 추가하는 것이다.

eval "$(ssh-agent -s)" 를 입력하여 SSH를 백그라운드에 실행시켜준다.

그런다음

ssh-add ~/.ssh/id_ed25519

위 명령어를 입력하여 SSH 에이전트에 키를 등록한다.

마지막 단계는, 깃허브로 이동하여 해당 SSH키를 깃허브 계정에 추가하는 것이다.
생성된 키, 즉 공개 키의 내용을 복사한다.

아무 것도 출력되지 않지만, 이 명령(pbcopy)는 출력 결과를 클립보드에 복사한다.
즉, 지금 클립보드에는 이 출력 결과가 존재한다.
이제 키가 존재하니, 깃허브로 가서 내 프로필로 들어가서 setting - SSH and GPG keys를 눌르면 된다.

Key에 클립보드에 있는 내용을 붙여넣기 하고 저장하면 된다.

키를 설정했으니 잘 작동하는지 확인해야 하는데, 이 것은 푸쉬를 할 때 알 수 있다.

첫 Github Repo 만들기!

깃허브에 코드를 올리는 방법, 내 컴퓨터에 있는 로컬 깃 저장소를 가져오는 방법, 그걸 호스팅된 깃허브 저장소에 연결하는 방법을 알아보자.

두 가지 다른 저근 방법을 소개할거다.

방법1

컴퓨터에 기존 저장소가 있는 경우이다.
이미 작업하고 있는 것, 이미 깃 기록이 있는 것, 이미 코드가 있는 것 등을 기허브에 올리려면 다음과 같이 해야 한다.

• 깃허브에 새 저장소를 만든 다음, 원격(remote)이라는 것을 추가하여 로컬 저장소에 연결해야 한다.
• 원격을 로컬 컴퓨터에 추가한 다음, 변경 사항을 깃허브에 푸시한다.

방법2

아직 작업을 하지 않는 경우이다.
즉, 어디에도 저장소가 없는 경우이다.
이럴 떄는 프로젝트를 시작할 때 바로 깃과 함께 깃허브도 사용하고 싶은 경우이다.

• 이럴때는 깃 허브에서 먼저 repo를 만든다
• 내 컴퓨터에 clone을 한다.
• 컴퓨터에서 일은 한다.
• 변경이 생기면, 깃허브에 푸쉬를 한다.
• 이럴 경우, 로컬 저장소를 깃허브 저장소에 수동으로 연결할 필요가 없다. 깃허브에서 이 저장소를 클론하면, 해당 깃허브 URL에 자동으로 연결되기 때문이다.

위 처럼 클론을 해서 가져왔기 때문에, 깃허브URL이 자동적으로 인식된다.

우선 방법1을 먼저 실습해본다.

가장 간단한하게, FirstGit으로 실습해 본다.

이 모든 기록들과 파일들을 올린다.
어떤 저장소를 올리려면 가장 먼저 할 일은 깃허브로 가는 것이다.
로그인을 하고, 빈 저장소를 새로 만든다.

New버튼을 눌르면 된다.

안에 내용은 별로 볼 것 없이 설명만 조금 있다.

이렇게 되면, 로컬에 있는 repo는 github와 연결이 되지 않았다.
하지만, 다음 섹션에서는 둘이 연결해본다.

Git Remote 집중 학습

이번에 해야 할 일은 클라우드에 있는 위에서 제작한 빈 깃허브 저장소를 가져오는 것이다.

위에서 만든 깃허브 저장소는 로컬 저장소에 전혀 연결이 되어있지 않다. 따라서 로컬 저장소가 이 깃허브 저장소에 대해 알도록 구성해야 한다.

그러려면 깃허브를 사용하든 저장소 호스팅하는 다른 서비스를 사용하든 git remote를 설정해야 한다.

remote

목적지 URL을 부르는 말.
깃에게 알려줄 URL에 이름을 붙인 거다.
코드를 푸시하거나, Fetch하거나 새 코드를 풀 다운할 수 있는 URL이다.
우선, Remote를 설정한 후 그런 명령들에 대해 알아보겠다.

git remote 나 git remove -v이다.
이 명령은 현재 저장소에 있는 원격들을 나열해서 보여준다.

현재 우리 저장소에는, 지금은 원격을 하나도 구성하지 않았다.

입력을 해도, 아무 일도 일어나지 않는다.
그러나 클론한 저장소 중 하나에 가보면

git remote -v는 url까지 출력한다.

이 URL이자, Remote이자 Origin을 설정함으로써 나중에 깃에게 '추가된 코드'나 '새 업데이트'가 있는지, 만약 우리가 공동 작업자라면 '깃, 내 커밋 10개를 푸시하고 싶어' 라고 할 수 있다.

다시 FirstGit으로 돌아와서 보면

현재 우리는 아무런 remote가 없지만

git remote add [name] {url}

• 깃에게, URL을 이 이름으로 기억하게 한다.
• 기본적인 이름은 origin이다. (위에서 본 것과 같이)

위 명령을 사용하면 원격을 만들 수 있다.

위와 같이 git remote add origin repoURL을 쓰면, 여기 있는 URL을 오리진이라는 이름으로 기억해서, 유저가 origin이라고 말하면 이 URL을 말하는 거라 라고 기억하게 한다.

오리진이라는 용어는 일반적인 깃 원격 이름이다. 특별한 것은 아니다.
이 이름은 바꿀 수 있고, 아무거나 지정해도 상관 없다.

위와 같이, 동일한 url에 새로운 이름을 추가할 수 있다.

우리의 깃허브 빈 저장소로 가보면, 위와 같은 URL을 볼 수 있는데 이것이 바로 저장소 URL이다.

우리가 만약 repo가 없다면 첫 번째 CL을 따르면 되지만, 우리는 이미 있으므로 기존 저장소를 푸시하기인 두 번째 칸을 본다.

git remote add를 입력 했을 경우, 아무 변화도 없는 것 처럼 보이지만, git remote -v를 입력했을 때 잘 되었다는 것을 확인 할 수 있다.

이제 다음섹션에 push하는 법을 배운다.

위와 같이 remote의 이름을 변경 할 수 있고, 필요하면 remote를 삭제 할 수 있다.

나중에 보겠지만, 보통 remote는 여러개이다. 특히 오픈소스 프로젝트에서...
어떻게 만들고 작동하는 지는 그것을 다루는 섹션에서 배운다.

Git Push 소개

깃허브에 코드를 올리려면 push를 해야 한다.

지금은 위와 같은 방법1을 따라하는 중이다.
(깃허브에 새 저장소를 만들고, 깃허브 저장소에 remote를 추가하는 것이다.)
이번 섹션에선 옵션1의 마지막 단계인 변경사항을 푸시하는것을 다룬다.

현재 위에 단계까지는 완성이 되었다.

이제 위 그림처럼 Push만 해주면 끝이 난다.

git push remote branch

• 이 명령을 사용하여 위 작업을 수행한다.
• 마찬가지로, 깃허브에 국한된 명령어는 아니다. (깃허브가 나오기 전부터 존재했던 명령이다.)
• 모든 remote에서 작동한다
• 깃에게 어디로 푸시할지, 대상 저장소 및 푸시할 브랜치를 알려줘야 한다.

만약 엄청 큰 저장소에 많은 브랜치가 존재할 경우, 전부 깃허브에 올리고 싶지 않거나, 한 번에 모두 푸시하고 싶지 않을 수도 있다.

따라서, Push할 때는, 깃허브에 보내려는 특정 브랜치를 호출한다.
보통 그 브랜치는 Main이나 Master브랜치겠지만, 어떤 브랜치든지 깃허브로 푸시 할 수 있다.

위 처럼 말이다.

이렇게 Push를 완료하면

이 페이지가

이렇게 변경이 된다.

이제 다른 브랜치를 Push하기 위해

MoodBoard와 chapter1.txt를 삭제한 브랜치를 제작한다.

이제 커밋을 해주고, 이 코드를 푸시해본다.

깃허브의 repo를 확인해보면 달라진 점이 없는것 같지만...

새로운 브랜치가 생긴 것을 볼 수 있다.

empty브랜치를 클릭해 보면

message와 함께 변경되는 것을 알 수 있다.

이제, 로컬에서 마스터 브랜치에 변경점을 줘 보자.

깃허브는 내 로컬과 자동으로 동기화가 되지 않으므로, push를 해야 한다.
그리고, 특정 커밋을 푸쉬하는 것이 아니라 브랜치 전체를 푸쉬하는 것이므로 특정 커밋만 골라서 push하는 것은 안된다.

push를 수행하면, 깃허브repo에 chapter4가 추가된 것을 볼 수있다.

정리하하자면 밑과 같다.

▲ github repo에 아무것도 없는 상태

▲ github repo에 master 브랜치를 push한 상태

▲ github repo에 새로운 브랜치를 추가한 상태

▲ github repo 로컬에서 master브랜치에 변경을 줌

▲ github repo 로컬의 master브랜치 변경점을 push함

Github Repo 둘러보기

▲ 표시 된 것은 커밋이다. 이 파일 각각에 영향을 미친 가장 최근의 커밋들을 볼 수 있다.

▲ 표시된 부분을 클릭하면 아래와 같이 모든 커밋을 볼 수있다.

▲ 표시된 부분을 클릭하면, 아래와 같이 커밋했을 때 변경점을 볼 수 있다.

▲ 커밋의 메세지가 길어서 다 표시가 안됬을 때는, 커밋을 클릭하면 메시지가 전부 나타난다.



또한, 맨 밑으로 내려가면 커밋에 대한 댓글을 달 수 있다.
다른 사람과 협업을 할 때는 중요하다.

Git Push로 연습하기

이번 섹션은 기본 푸시 워크플로 및 깃허브 커밋 푸시에 대한 추가 연습 또는 복습을 한다.
잘 할 수 있을 것 같으면, 저장소를 클론하는 다음 강의로 넘어가자.

MoodBoard라는 폴더를 지우고 커밋을 실행하면, 이건 내 로컬저장소인 노트북의 마스터 브랜치에만 존재한다.

▲ 이제, 깃 브랜치를 empty로 바꾸고 summary라는 파일을 만들고 커밋을 한다.
이 커밋은 로컬저장소인 노트북의 empty브랜치에만 존재하고 깃허브에는 존재하지 않는다.

▲ 각각에 대한 푸쉬를 진행해 주면

▲ 둘 다 푸쉬가 된 것을 볼 수 있다.

Git Push 자세히 알아보기

이번 섹션에선 푸시가 작동하는 방식에 대해 자세히 다룬다.
그리고, 로컬에 있는 브랜치와 깃허브의 브랜치 간의 관계를 알아본다.

먼저 실습을 위해 새 저장소와 새 깃허브 저장소를 만든다.

이제 remote를 추가한다.

이제 마스터 브랜치를 푸시한다.

▲ 위 명령은, 깃허브에 master브랜치를 push한다는 것도 있지만, 처음으로 깃허브에 master브랜치를 생성한다는 뜻 도 있다.

▲ 화살표를 보면, master가 master를 가르키는 것을 볼 수 있다.
(이것은 다음 섹션에서 Fetch와 Pull에 대해 배울 때 나올 내용이다.)
로컬에 있는 브랜치와 깃허브의 브랜치 사이에 차이가 있다.


일반적으로는, 로컬의 마스터 브랜치를 깃허브의 마스터 브랜치에 연결하고 푸시하고 싶어하지만, 꼭 그럴 필요는 없다.

▲ 위는 새로운 파일(flowers.txt) 를 만들고 푸쉬를 한 것이다.
여기서, 깃허브에서는 마스터라는 새로운 브랜치를 만들지 않는다. (이미 존재하므로)
깃이 master브랜치를 푸쉬 할 때,

이렇게 된다.

그런데 사실 위와 같이 푸쉬하지 않고, 다른 브랜치로 푸쉬도 가능하다.

▲ 위와 같이 푸쉬를 하면 로컬 pancake브랜치를 깃허브의 waffle브랜치에 푸쉬 한다는 것이다.

• 즉, 로컬master브랜치를 항상 깃허브의master브랜치에 푸쉬할 필요는 없다.

▲ cats파일을 만든 cats브랜치를 만든 후, 깃허브의 cats브랜치로 푸쉬를 했다. 하지만 다음과 같이 활용이 가능하다.

▲ 위와 같이, cats브랜치를 master브랜치로 push가 가능하다.

'git push -u'는 무슨 뜻일까?

git push와 관려하여 하나 더 다룰 것은, -u 옵션이다.

새 브랜치를 만들 때가 아니라, 새 저장소를 만들 때 보게 될 명령어이다.

• u는 upsteam(상류)를 의미한다. (별 의미가 없는 것 같다.)
• 로컬 브랜치의 상류는, remote브랜치를 가리키는 일종의 연결이라고 생각 할 수 있다.

로컬 컴퓨터에 마스터 브랜치가 있는 경우, 일반적으로 업스트림 브랜치는 오리진 마스터 또는 깃허브에 있는 어떤 마스터 브랜치이면 좋을 것이다.
그러면, 오리진 마스터를 지정하지 않고 git push를 해도 된다.

즉, 마스터 브랜치에 대해 업스트림을 구성했다면, 이 바로 가기를 사용할 수 있다.
(풀링할 때도 이런 경우가 있는데, 다음에 다룬다.)
하지만, push를 위해서 반드시 필요한 것은 아니지만, 좀 더 편해지니 하는게 좋다.

git push -u origin master

이것을 실행하면, 깃에게 로컬 컴퓨터 저장소의 마스터 브랜치를 오리진 마스터로 푸쉬하라는 뜻이다.

• 기억해야 할 점은, 내 컴퓨터에 있는 마스터 브랜치가 오리진의 마스터 브랜치에 연결되야 한다는 것이다.

▲ 위에서 업 스트림을 설정해 주었다.

▲ moredogs파일을 만든 뒤에 git push만 해도 잘 된 것을 볼 수 있다.

git push -u origin dogs:cats

로컬의 dogs브랜치랑 깃허브의 remote cats브랜치로 푸쉬되고, 업스트림연결이 된다.
근데 보통 이렇게는 하지 않는다. 병합 이슈같은게 생길 수 있음

기타 Github 워크플로우: 복제 우선

이 섹션에서는 깃허브에 코드를 올리는 방법2를 다룬다.
로컬 저장소와 호스팅된 저장소를 연결하는 방법을 처음부터 보여준다.

먼저, 이 경우엔 깃허브부터 시작한다.

이제, 위에 과정을 실습해본다.

▲ 깃허브repo를 생성한다.

▲ 빈 저장소에 clone을 하여 chicken-demo폴더가 생겼다.
폴더 안에 아무것도 없는 것을 볼 수 있다.

▲ git status를 입력하면 git repo라는 것을 알 수 있고, 푸시할 작업은 없지만 remote연결이 되 있는 것을 볼 수 있다.

▲ 위는chickens.txt파일을 add하고 commit한 것이다.

▲ 깃허브에 푸쉬를 했다.

▲ 푸쉬가 된 것을 볼 수 있다.

메인 및 마스터: Github 기본 브랜치

2020년에 Github가 master에서 main으로 브랜치 이름을 바꿨다.

▲ 깃허브에서 repo를 만들 때, 파일을 추가하게 되면, 즉 이 저장소를 초기화하면 브랜치가 필요해지므로, 자동으로 브랜치가 생성되는데 기본 브랜치 이름이 main으로 정해진다.

만약, 마스터 브랜치에서 메인이나 메인에서 마스터로 이름을 바꿀 때는 다른 브랜치의 이름을 바꿀 때 처럼 하면된다.
저장소를 만들었을 때 나왔는데 아래와 같다.

▲ master를 깃허브에 푸쉬한다.

▲ main브랜치랑 master브랜치가 동시에 존재하는 것을 볼 수 있다.
또 잘 보면, main이 default로 설정되어 있는 것을 볼 수 있는데, main브랜치가 먼저 생성되었기 때문이다.
만약 default브랜치를 바꾸고 싶으면 setting에 들어가서 밑에 표시된 것을 클릭한다.

Github 기초 연습하기