AIFFEL_개발자를 위한 첫 번째 필수 교양

https://opentutorials.org/module/2676

✒️ Git

개발을 진행하며 작성하는 소스코드가 업데이트 되는 버전을 기록해두고 관리할 수 있는 소스코드 버전 관리 시스템

✒️ GitHub

Git으로 관리하는 프로젝트를 호스팅하고, 시간과 공간의 제약 없이 협업할 수 있는 온라인 서비스

Git이 버전 기록을 저장한다면, GitHub에서는 그 기록을 다른 사람과 함께 공유하며 협업할 수 있다.
로컬(Local)에서 작업한 내용을 Git이 저장해 두었다면, 그 기록을 온라인 작업공간인 GitHub에 올려 원격(Remote)으로도 작업할 수 있도록 한다.

아래 명령어를 실행하면 Git의 버젼 확인이 가능하다. (설치되어 있다면)

$ git --version

깃허브 계정을 만들 때 유의해야 할 것은 중복되지 않는 Username을 잘 선택해야 한다는 것, 그리고 인증 가능한 email을 사용해야 한다는 것

특히 Username은 내 GitHub 페이지의 도메인 주소가 되기 때문에 신중하게 짓는 것을 추천
깃허브 주소

https://m.post.naver.com/viewer/postView.nhn?volumeNo=24622891&memberNo=42458017

가. 로컬의 Git에 GitHub의 계정 정보 등록하기

첫 번째로 해야 할 일은 로컬의 Git과 원격에 있는 GitHub을 연결하는 것
이 때 로컬의 Git과 동기화를 해서 온라인으로 관리할 수 있는 원격저장소를 GitHub에서는 레파지토리(Repository)라고 부릅니다.
따라서 우리가 로컬에서 다양한 코드 작업을 한 후, GitHub의 내 계정에 있는 원격저장소, 레파지토리로 잘 전송하려면 로컬의 Git이 원격의 GitHub 계정 정보를 알고 있어야 한다.

$ git config --global user.email "[email protected]"
$ git config --global user.name "my-username"

위에서 [email protected] 과 my-username 부분은 자신의 email 주소와 username으로 변경해서 입력하면 된다.
이렇게 입력해주고 나면 Git 툴이 내가 GitHub 사이트로 코드 정보를 전송할 때 어떤 계정에 있는 레파지토리로 전송해야 하는지 기억한다.

Git에 등록한 config의 정보를 모두 확인하고 싶으면 다음과 같이 입력

$ git config -l

나. 내 컴퓨터에 로컬 저장소 만들기
그 다음으로는 먼저 내 컴퓨터에 Git으로 관리해 보고 싶은 로컬 저장소를 만들어보다.우리가 보통 파일을 관리할 때 쓰는 폴더, 즉 디렉토리를 만들기. Git은 디렉토리를 기준으로 그 하위에 있는 모든 폴더와 파일에 대한 버전을 기록할 수 있습니다.

사용자 홈 디렉토리로 이동한 후 workplace 라는 이름으로 새로운 폴더를 만들어 본다.

$ cd ~
$ mkdir workplace

다. Git으로 버전 관리 시작하기
우리가 작업을 진행할 새로운 디렉토리 workplace 를 생성
이제 그 디렉토리로 옮겨가보시죠.

$ cd workplace

우리는 이제 이 디렉토리를 Git으로 관리하기 시작할 것입니다. 다음 명령어로 Git을 현재의 디렉토리 내에 심어놓을 수 있죠!

$ git init

init 은 initialization의 약자입니다. 시작한다는 뜻을 갖고 있죠. 이제부터는 Git이 지금 있는 workplace 디렉토리에서 발생하는 모든 변화를 기록해둘 것입니다. ls만 해서는 보이지 않겠지만 다음과 같이 하면 빈 디렉토리였던 workspace 안에 새롭게 생긴 .git 디렉토리와, 그 안에 있는 내용들을 확인해 볼 수 있습니다.

$ ls -a
.  ..  .git
$ cd .git
$ ls 
HEAD  branches  config  description  hooks  info  objects  refs

git init은 workplace라는 디렉토리를 새로운 Git 로컬 저장소로 만들었다는 뜻입니다. 모든 Git 로컬 저장소는 .git이라는 디렉토리를 가지고 있습니다.

라. README.md 파일 생성하기
README 파일을 들어보셨나요? 리드미 파일이라고도 부르는 이 파일은, GitHub의 레파지토리에서 대문과 같은 역할을 하는 파일
README.md 파일은 레파지토리를 들어갔을 때 그 레파지토리가 담은 오픈소스 코드들에 대해 소개하는 역할을 합니다.

md 라는 확장자는 Markdown, 마크다운이라는 파일을 지칭하는데 마크다운이란 개발자들이 가장 많이 사용하는 문서작업 용 언어

내 레파지토리를 구경 올 사람들에게 내 작업물에 대해 간단히 소개하기 위한 파일이 바로 README.md 파일

$ cd ~/workplace  # 이전 스텝에서 .git 디렉토리로 들어갔던 경우에만 실행하여 workspace 디렉토리로 다시 돌아와주세요
$ echo "# first-repository" >> README.md

위와 같은 명령어를 입력하면 README.md 파일을 생성함과 동시에 그 파일 내에 # first-repository 라는 한 줄이 입력되게 됩니다.

echo는 출력을 하는 명령어인데, 출력 스트림을 지정하는 >>을 통해 출력 타겟을 README.md 파일로 지정했기 때문

위 명령어를 실행했다면 다음과 같이 README.md 파일이 생성된 것을 확인할 수 있을 것이다. cat 명령어를 통해 생성된 텍스트 파일을 열어 본다.

$ ls
README.md

$ cat README.md
# first-repository

ls 로 파일 목록을 확인하면 README.md 파일이 목록 내에 출력될 것이고, cat 명령어를 통해 해당 파일에 작성되어 있는 내용을 확인하면 우리가 입력한 # first-repository 가 출력될 것입니다.

마. git으로 변화 확인! 지금 버전에 도장 쾅! 찍기
자, 우리는 방금 git으로 버전을 관리하고 있는 workplace 디렉토리에 README.md 파일을 생성함으로써 변화를 주었습니다.

그 변화가 아무리 미미할지언정 변화는 변화이니, git은 그 변화를 감지했을 것

Git이 추적하고 있는 변화는 다음 명령어로 확인할 수 있습니다.

$ git status
On branch main

No commits yet

Untracked files:
    (use "git add <file>..." to include in what will be committed)
    README.md

nothing added to commit but untracked files present (use "git add" to track) 

💡 main, master. 깃허브의 정책 변화?
위 실행창에서 On branch main 부분은 On branch master로 뜰 수도 있습니다.
이를 잘 확인하여 다음 스텝에서 살펴볼 git push명령어에서 변경하여 사용 하시면 됩니다.
깃허브의 입장에 따르면, 기존에 사용하던 master 라는 표현은 인종차별을 연장할 수 있다며 main이라는 표현으로 바꾸기로 했답니다.
깃허브, 개발용어 '마스터'→메인으로 바꾼다

Untracked files: 라고 하며 아직 추적되지 않은 새로운 파일인 README.md 파일을 잡아내었죠.
그렇다면 우리는 git에 이 변경사항을 저장해 둘 필요가 있겠죠. add 와 commit 두 가지의 명령어로 진행할 수 있습니다.

$ git add README.md
$ git commit -m "new readme file"
[master (root-commit) 438a37c] new readme file 
    1 file changed, 1 insertion(+)
    create mode 100644 README.md

-m은 메세지 옵션입니다. git commit -m 뒤에는 해당 커밋에 대한 설명을 작성
add 와 commit 의 개념은 Git을 다룰 때 아주 중요한 개념 중 하나입니다. 두 명령어 모두 현재의 변화를 기록하기 위한 명령어인데, 중요한 차이가 있습니다.
Git 저장소 생성 및 커밋 ( init / add / commit )

git - 간편 안내서

• add는 변화를 기록하기 위한 준비 단계에 해당한다. 파일을 add 하는 것은 staging 한다, 또는 stage에 올려둔다는 등의 표현을 사용하며, 본격적인 스냅샷(snapshot)을 찍기 전에 임시로 올려두는 개념의 작업이다.

• commit은 실제로 특정 순간의 버전을 스냅샷으로 확정시켜 남겨두는 역할을 한다.

add 는 해당 순간을 스냅샷으로 남겨두기 위한 준비작업, commit 은 해당 순간을 정말 도장처럼 쾅! 찍어서 기록해두는 확정 작업인 셈

바. GitHub에 나의 첫 번째 레파지토리 만들기
깃허브(Github) 원격저장소(Repository) 생성

사. 내 로컬 저장소와 원격 저장소를 연결해 보자!

이제 로컬 저장소도, 원격 저장소도 모두 준비가 되었으니 둘을 연결하는 일만 남았습니다.

둘을 연결하는 연결고리는 바로 위의 이미지에서 봤던 내 레파지토리의 주소입니다.

위 이미지에서 HTTPS 라고 적힌 오른쪽에 https://... 라고 적혀있는 레파지토리의 주소가 보이시나요? 저 주소를 로컬 저장소에 있는 git에게 알려주면 git은 GitHub의 원격 저장소의 주소를 알고 두 저장소 간에 정보를 전송할 수 있습니다. 주소 칸의 맨 오른쪽에 보이는 아이콘을 누르면 주소가 클립보드에 복사됩니다.

주소를 클립보드에 저장한 후, 터미널에서 아래 명령어를 입력해서 로컬 저장소에 있는 Git이 원격 저장소의 주소를 알 수 있도록 저장하겠습니다. 아래 명령어는 꼭 로컬 저장소 디렉토리 안에서 실행해야 합니다.

$ cd ~/workplace
$ git remote add origin https://github.com/xxx/first-repository.git

origin 은 원격 저장소의 닉네임과 같은 역할을 합니다. 앞으로는 복잡한 https://... 의 주소를 매번 사용하는 것이 아니라, origin 이라는 이름으로 원격 저장소를 지칭할 수 있는 것이죠. 물론 위의 xxx 부분은 본인의 username이 들어가야합니다!

샤. GitHub에서 토큰 생성하기

이제 로컬 저장소에 저장된 내용을 원격 저장소로 전송해야 합니다.

그런데 연결만 한다고 아무나 원격 저장소로 전송할 수 있다면 어떻게 될까요? 이걸 막기 위해 비밀번호를 사용해야 겠죠?

하지만 GitHub에서는 이제 비밀번호를 사용하지 않습니다. 대신 토큰을 만들어서 사용합니다. 토큰은 시간 제한이 있는 비밀번호라고 생각하면 됩니다. 또 한 가지 다른 점은 내가 만들 수 없다는 거에요. GitHub이 만들어 줍니다.

GitHub Token

GitHub에 로그인 한 상태에서 위 링크를 참고해 토큰을 만들어 주세요! 토큰의 유효 기간을 지정하고 그 기간을 잘 기억해놔야 나중에 당황하지 않을거에요~! 어느날 갑자기 안돼서 당황할 수가 있어요!!

아. 로컬 저장소의 기록을 원격 저장소로 전송하기
이제 모든 준비가 끝났으니 로컬에서 레파지토리로 전송하는 것은 아주 간단합니다.

바로 다음 명령어 두 줄이면 되죠.

$ git config credential.helper store
$ git push origin main
Username for 'https://github.com': [계정에 사용된 이메일을 입력하세요]
Password for 'https://[위에 입력한 이메일]@github.com': [비밀번호(토큰)를 입력하세요]
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 230 bytes | 230.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/jeina7/first-repository.git
    * [new branch]      master -> master

계정에 사용된 이메일을 입력하고, 비밀번호를 입력해야 합니다. 비밀번호 대신 위에서 생성한 토큰을 입력하면 됩니다.

긴 토큰을 입력하기 위해 복사/붙여넣기를 해야하는데요. 터미널에서 붙여넣을 때는 Ctrl+Shift+V를 입력하면 됩니다.

위 커멘드에서 에러가 난다면 git push origin master로 시도 해보시기 바랍니다.

위 명령어는 현재 로컬에 있는 버전 기록과 모든 파일들을 origin, 즉 원격 저장소의 master 브랜치로 push해 밀어넣겠다는 뜻을 가집니다.

브랜치란, 간단히 말하자면 작업을 하는 '가지'를 말합니다. 하나의 작업을 여러 개의 가지로 분기하여 작업을 진행할 수 있습니다.

그리고 push를 할 때마다 매번 로그인을 하지 않으려면 git config credential.helper store 명령어를 단 한 번만 실행해주시면 됩니다.

브랜치의 개념

브랜치란?

자. 원격 저장소를 로컬로도 가져올 수 있을까?
만약 우리가 지금까지 했던 것처럼 로컬 저장소를 GitHub의 원격 저장소로 전송하는 것이 아니라, 그 반대로 이미 GitHub에 올라와 있는 저장소를 통째로 내 로컬에 가져오고 싶다면 어떻게 해야 할까요?

이 작업 또한 아주 간단합니다.

원격 저장소를 로컬에 가져오려면 역시 그 연결고리가 필요하겠죠. 다음과 같이 레파지토리의 주소를 복사하겠습니다.

우리는 이 저장소를 아까 생성했던 workplace가 아닌 다른 디렉토리인 project에 가져와보겠습니다.

$ cd ~
$ mkdir project
$ cd project

이동 후에, 다음과 같은 명령어를 사용하면 GitHub의 레파지토리를 통째로 가져올 수 있습니다. 명령어는 복제라는 뜻을 가진 clone 을 사용합니다.
❗ (주의) 아래 코드를 실행할 때 ...github.com/xxx/first-repository...에서의 xxx 부분을 본인의 깃허브 username 으로 대체해주세요

$ git clone https://github.com/xxx/first-repository.git
Cloning into 'first-repository'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.

그러면 제대로 잘 복사가 되었는지 확인해볼까요?

$ ls
first-repository

ls 로 확인하면 레파지토리 이름으로 폴더가 생성된 것을 확인할 수 있습니다. 이동해서 확인해 보죠.

$ cd first-repository
$ ls
README.md

폴더 내로 이동해서 다시 ls 로 확인하면 우리가 아까 만들어놓고 레파지토리로 전송했던 README.md 파일을 확인할 수 있습니다. cat 으로 내용을 확인해 보죠!

$ cat README.md
# first-repository

차. 로컬로 가져온 원격 저장소를 수정해서 다시 push 해 보자!
그렇다면 이제 로컬로 가져온 레파지토리 내용을 수정해서 다시 원격으로 전송해 보는 작업을 할 것입니다.

파일에 변화를 주기 위해서 현재 있는 README.md 파일을 한번 수정해 보겠습니다.

$ echo "add new contents" >> README.md

이번에도 echo 명령어를 활용하지만, 아까와는 다르게 이미 README.md 파일이 있기 때문에 새로 생성하는 것이 아니라 현재 있는 파일의 아래쪽에 문자열을 추가하게 됩니다.

다시 한 번 파일 내용을 확인해볼까요?

$ cat README.md
# first-repository
add new contents

내용에 원래 있던 첫 번째 줄과 아래 두 번째 줄이 추가되었군요.

그렇다면 다시 변화가 생긴 것이니, git이 이 변화를 추적하고 있을 것입니다. 확인해봅시다.

$ git status
On branch master
Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

이번에는 README.md 파일이 새로 생긴 것이 아니라, modified 되었다고 나옵니다. 맞게 잘 추적하고 있는 것 같군요.

이제 다시 아까 했던 작업과 동일하게 add, commit 을 진행하도록 하겠습니다.

$ git add README.md
$ git commit -m “new contents”
[master c82640d] new contents
    1 file changed, 1 insertion(+)

새로운 commit, 즉 새로운 스냅샷이 저장되었습니다.

마지막 단계는 이것을 다시! 원격 저장소로 전송하는 것이죠. 원격 저장소로 보내는 명령어가 뭐였죠!? push !

$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 276 bytes | 276.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/jeina7/first-repository.git
    438a37c..c82640d  master -> master

그렇다면 우리가 처음에 만들었던 workplace 디렉토리에도 이 변화가 반영되었을까요?

카. 로컬 저장소를 원격 저장소의 내용과 같게 업데이트하자!
이제 오늘의 마지막 작업입니다. 원격 저장소의 README.md 파일이 수정된 것을 처음에 만들었던 workplace 로컬저장소에도 업데이트해주는 것이죠.

처음에 만들었던 로컬 저장소의 README.md 파일이 자동으로 업데이트 되었을까요? 다시 이동해서 확인해봅시다.

$ cd ~/workplace
$ ls
README.md
$ cat README.md
# first-repository

음, 당연하지만 자동으로 업데이트가 되지는 않았군요. 하지만 다행히 이 로컬 저장소를 수정된 원격 저장소와 같게 업데이트 해주는 것 또한 매우 간단합니다.

$ git pull origin main
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/jeina7/first-repository
    * branch            master     -> FETCH_HEAD
    438a37c..c82640d  master     -> origin/master
Updating 438a37c..c82640d
Fast-forward
    README.md | 1 +
    1 file changed, 1 insertion(+)

push 의 반댓말, pull 로 origin 별칭의 원격 저장소를 로컬 저장소로 "당겨올" 수 있습니다.

잘 가져와졌다면, 다음과 같은 결과가 나와야겠죠!

$ cat README.md
# first-repository
add new contents

add new contents 라는 내용이 추가되었다면 성공

여기까지 모두 진행했다면, 우리의 GitHub 프로필 페이지에서 초록색 칸으로 색칠이 된 잔디를 확인하실 수 있을 것입니다. 확인이 되나요?

이렇게 잔디가 칠해지려면 commit, push 등의 GitHub 활동을 해야합니다. 즉, 맨 처음에 봤던 그 1년 내내 파릇파릇한 잔디는 이러한 코드 작업을 매일매일 한 것으로 볼 수 있죠.

우리가 지금까지 무엇을 한 걸까요?

그림으로 간단히 정리하자면 다음과 같습니다.

한 눈에 들어오시나요?

workplace 라는 로컬저장소, 다른 말로는 디렉토리를 만드는 것부터 시작해서, add, commit, push 세 가지의 명령어를 통해 원격 저장소로 전송하는 것까지 진행해 보았습니다.

그 후에는 원격 저장소를 다시 first-repository 라는 디렉토리로 복제해와서 파일을 수정한 후 다시 원격저장소로 전송했죠.

마지막에는 수정된 원격 저장소를 workplace 로 가져와서 처음 만들었던 저장소를 업데이트 하는 작업까지 진행해 보았습니다!

그렇다면 이렇게 복잡한 GitHub은 왜 써야하는 걸까요? 위 이미지를 단순화 된 이미지로 재구성하자면 다음과 같을 것입니다.

우리는 위의 작업을 모두 혼자서 진행했지만, 사실 다른 개발자들과 협업을 할 때는 다음 이미지와 같이 진행되는 것이죠.

위에서 봤던 workplace 를 만든 것이 개발자 A, 원격 저장소를 복제해왔던 first-repository 를 다루는 사람이 개발자 B라고 해 봅시다.

협업을 진행하는 두 개발자가 GitHub을 활용한다면, 둘은 서로 업데이트한 파일을 따로 전송할 필요 없이 GitHub에 Push 또는 Pull 하는 것만으로 효율적인 협업을 진행할 수 있는 것이죠. 지금은 크게 중요하지 않아 보일 수 있지만, 여러 개발자가 동시에 개발을 진행하며, 여러 개의 파일에 작업을 하고, 그 버전들이 다양해 질 경우, 각 파일의 버전이 관리되지 않는다면 파일을 관리하는 작업은 굉장히 복잡해질 수 있습니다.

이러한 어려움을 Git과 GitHub은 commit 이라는 버전 관리 작업을 통해 손쉽게 관리할 수 있도록 한 것이죠.

Git을 활용한 버전 관리는 앞서 언급했듯 오늘 배운 것보다 훨씬 다양한 명령어, 작업들을 포함하고 있습니다. 다른 사람이 관리하는 메인 레파지토리는 망치지 않으면서, 손님으로써 작업하기 위해 레파지토리를 fork 한다거나, fork 한 레파지토리에서 작업한 것을 다시 메인 레파지토리에 반영하도록 요청하기 위해 pull request 를 보내는 등 다른 기능들은 너무 방대해서 오늘 다 다루지 못했습니다.

앞으로 GitHub은 개발 공부를 진행하면서 쭉 함께할 친구일테니, 앞으로 더 다양하게 찾아보면서 공부하는 것을 권합니다. 많이 알수록, 더 편리해질 것이니까요!