git

Jeongyun Heo·2021년 1월 1일

git

목록 보기

4/4

가장 쉬운 Git 강좌 - (하) Github편
https://youtu.be/GaKjTjwcKQo

Git - GitHub편

github-practice 라는 새로운 폴더를 만든다.

VS code에서 폴더를 연다.

터미널에 git init 입력하여 Git의 관리 하에 둔다.

아래 명령어들은 컴퓨터에서 한 번 입력했으면 다시 입력할 필요가 없다.

git config --global user.name "이름입력"
git config --global user.email "이메일입력"

cat 이라는 파일과 mouse 라는 파일을 생성한다.

터미널에 명령어를 입력해서 커밋한다.

git add -A
git commit -m "FIRST COMMIT"

1. GitHub 저장소 만들기

https://github.com/ 에 접속한다.

왼쪽의 Repositories에서 새 레파지토리를 만든다.

Git으로 관리되는 프로젝트 폴더 하나가 원격으로 저장되는 공간이다.

프로젝트명, 그리고 선택사항으로 간단한 설명을 입력한다.

Public을 선택하면 Github에 접속한 모든 사람들이 내 코드를 방문하거나 검색해서 볼 수 있다.

Private은 나, 그리고 내가 이제 레파지토리에 초대한 특정 사용자들만 볼 수 있다.

오픈소스로 만들어서 사람들에게 공유하고 도움이나 참여를 받으려면 혹은 기업들에게 공개할 내 포트폴리오로 사용하려면 Public으로 선택한다.

외부에 공개되어서는 안 되는 프로젝트를 올리려면 Private을 선택한다.

만든 이후에도 수정 가능하다.

이미 Git으로 관리하던 프로젝트를 올리는 거니까 여기에는 체크하지 않는다.

Create repository 클릭

이런 화면이 나올 텐데 아직 올라간 코드가 없을 때 뜨는 화면이다.

username과 레파지토리명이 Guthub 레파지토리 url에 들어가 있는 걸 볼 수 있다.

2. GitHub에 소스 올리기

이제 이 프로젝트를 이 레파지토리에 올려보자

터미널에 git status 입력하여

현재까지의 사항들이 모두 commit 되었는지 확인한다.

빠진 게 있다면 전부 add 해서 commit 한다.

이 상태에서 git remote를 입력한다.

git remote 👈 현 폴더의 원격 레파지토리를 확인하는 명령어

아직 설정한 게 없기 때문에 아무것도 안 뜬다.

이제 Github에서 만든 이 레파지토리를 원격 저장소로 추가해보자

여기 있는 명령어들을 사용한다.

현존하는 레파지토리를 올린다고 되어있다.

이 명령어는 이 Github 레파지토리를 이 폴더의 'origin' 이라는 이름의 원격 저장소로 설정하겠다는 의미이다.

'origin'은 원하는 다른 이름으로 바꿔도 되는데
Git 초기화시 기본 브랜치명이 master인 것처럼 흔히 기본값으로 사용되는 이름이다.

이 push 명령어는 폴더의 현 브랜치에 커밋된 내용들을 'origin' 이라는 이름의 원격, 즉 이 레파지토리의 master 라는 이름의 브랜치에 올리겠다는 의미이다.

오른쪽에 있는 버튼으로 이 둘을 한꺼번에 복사해서 터미널에 붙여넣기 한다.

이 컴퓨터(lacal)의 main 브랜치가 origin 이라는 원격의 main을 추적한다는 메시지가 뜬다.

github 페이지를 새로고침 해보면 로컬로부터 푸시한 파일들이 올라와 있고
각 파일들이 어떤 커밋에서 마지막으로 생성되었거나 변경되었는지 나와 있다.

파일명을 클릭하면 파일 내용을 볼 수 있다.

커밋 메시지를 클릭하면 해당 커밋에서 어떤 변화들이 있었는지 확인할 수 있다.

터미널에 다시 git remote를 입력해보면 추가한 원격 레파지토리 이름이 나오는 것을 볼 수 있다.

SourceTree에서 하는 법

저장소 메뉴 클릭 - 원격저장소 추가 클릭

원격 이름 입력하고
Github 페이지에서 복사한 Guthub 레파지토리 주소를 붙여넣는다.

Github 주소 붙여넣기 하면 자동으로 호스트 종류 GitHub으로 바뀜

마지막으로 Github 유저명을 입력해주고 확인 버튼 클릭

확인 버튼 클릭

원격 탭을 펼치면 원격 레파지토리 이름을 볼 수 있다.

원격이 추가되었으니 그 쪽으로 푸시를 해보자

푸시 버튼 클릭

로컬의 main 브랜치를 원격 origin의 main 브랜치로 올리는 걸로 설정한 뒤 확인 버튼 클릭

다음 변화를 주고 푸시를 해보자

dog 파일을 추가한 뒤 커밋을 하고

git push origin main을 입력해준다.

역시 푸시가 이루어지고 Github에 추가된 걸 볼 수 있다.

이런 식으로 내 컴퓨터에 있는 코드들을 클라우드에 올리듯 Github에 저장하고 관리할 수 있다.

3. 다루지 않을 파일 설정

.gitignore

프로그래밍 프로젝트를 진행하다보면 Git으로 관리하고 Github에 올릴 필요가 없거나 오히려 그래서는 안 되는 파일들이 있을 수 있다.
코드를 실행하면 패키지가 다운받아지거나 코드대로 빌드되어서 자동으로 생성되는 파일들은 어차피 코드만 있으면 그때그때 실행해서 만들 수 있는데 굳이 Git에 무리를 주거나 Github 용량을 차지할 필요가 없다.
또는 보안적으로 정말 중요한 내용, 데이터베이스 계정 등이 담긴 파일은 오픈소스 프로젝트라도 대중에게 공개되면 곤란하다.
이럴 때 사용되는 게 .gitignore 파일이다.

프로젝트 폴더 바로 안쪽, 최상위 공간에 .gitignore 파일을 생성한다.

숨김파일로 지정이 된다.

여기에 이런 형식으로 Git의 관리에서 제외시킬 파일이나 폴더, 기타 요소들을 적는다.

Git ignore patterns
https://www.atlassian.com/git/tutorials/saving-changes/gitignore

secret-animal이란 파일을 만들고 이렇게 작성한다.

터미널에 git status 입력

.gitignore와 함께 secret-animal이 add할 목록으로 나타난다.

.gitignore에 secret-animal이란 이름을 추가, 저장

다시 git status 실행해보면 secter-animal은 없어졌고 .gitignore만 있다.

add, commit 해서 push 해준다.

Github 페이지를 보면 secret-animal은 보이지 않는다.

안드로이드나 스프링 등 처음부터 골격이 세팅된 프로그래밍 프로젝트들을 생성해보면 .gitignore 파일을 볼 수 있다.
.gitignore 파일의 내용을 살펴보면 '아 이건 Git에 안 올려도 되는 것들이구나' '이것들은 빌드하면 만들어지는 거고 이것들은 이 컴퓨터에서의 IDE 세팅이구나' 등등을 파악할 수 있다.

4. GitHub의 소스 내려받기

이제 Github에 올린 소스들을 내 컴퓨터에 다운받아본다.

레파지토리가 Public이라면 누구나,
Private이라면 나, 그리고 이 레파지토리에 초대된 사람만 가능하다.

다른 사용자를 초대하려면 이 레파지토리에서 Setting으로 들어간 뒤

Manage access 클릭

여기서 유저네임이나 이메일로 초대를 해서 Private 레파지토리를 보거나 내가 만든 레파지토리에 소스를 푸시할 수 있도록 지정해줄 수 있다.

집에 있는 맥으로 작업해서 Github에 올린 소스를 회사의 윈도우 컴퓨터에서 다운받아서 이어 작업한다고 가정해보자.

나는 폴더 두 개 만들어서 해 볼 거

윈도우 컴퓨터
프로젝트의 폴더가 들어갈 위치를 VS Code로 연 다음 터미널을 연다.
그리고 Github 레파지토리의 페이지에서

Code 버튼 클릭

주소 복사 버튼 클릭

터미널에 git clone 다음에 '복사한 주소' 붙여넣기

레파지토리명의 폴더가 생긴 것을 볼 수 있다.

지금 VS Code에서는 이 바깥 폴더를 연 거라서 이 폴더에서 작업을 하려면
cd 다음에 폴더명을 입력해서 그 폴더 안으로 들어가야 한다.

cd 폴더명

폴더에 들어간 뒤 git log를 입력해보면 프로젝트의 내역들이 그대로 이 컴퓨터에 똑같이 복사된 걸 볼 수 있다.

SourceTree에서 하는 법

'URL에서 복제' 클릭

복사했던 URL과 프로젝트 폴더가 위치할 곳을 지정해주면
역시 다운받아지고 SourceTree에서 해당 폴더가 열린다.

5. 작업 주고 받기

윈도우 컴퓨터에서 작업을 추가해서 Github에 올리고 원래의 맥에서 받아보자

dog 파일을 수정한다.

그리고 add 해서 commit을 해준다.

commit 메시지는 팀원들과 협업할 때, 이번 커밋에서 어떤 변화들이 주어졌는지 간략히 알려주는 역할도 수행한다.

구글에 'git 커밋 메시지 작성법' 검색해보면 커밋 메시지를 작성하는 좋은 예시들을 찾아볼 수 있다.

이제 origin의 main에 push 해보자

Github에 올라온 걸 확인할 수 있다.

그런데 저쪽에서 새로 올린 내역이 있는지 일일이 Github에 들어가서 확인하기는 번거롭다.

맥 쪽의 터미널에서 git fetch를 입력해본다.

그리고 git status를 입력해보면
이 브랜치가 원격 origin의 main에 커밋 하나가 뒤쳐져 있다고 나온다.

Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded.

Github에서 다운받아야 할 사항이 있다는 얘기다.

다운 받아 보자

git pull 원격명 브랜치명을 입력한다.

dog의 변경사항이 다운받아졌고

SourceTree에서 보면 커밋 내역까지 동기화 되어 있는 걸 볼 수 있다.

SourceTree에서 하는 법

이번에는 맥에서 다시 작업을 하고 SourceTree로 주고 받아 보자

dog 파일을 수정한다.

SourceTree로 가서 체크해서 스테이지에 올려주고

커밋 메시지를 작성한다.

커밋 버튼을 누르고 위에 있는 푸시 버튼을 눌러도 되지만

여기에 체크를 해주면 바로 푸시까지 진행된다.

Github 페이지에 가면 새 작업내역이 올라간 것을 확인할 수 있다.

윈도우에서 작업내역 가져오기

SourceTree 창 보면 숫자 알림 떠있음

SourceTree에서 페치 버튼 클릭

'모든 원격에서 가져오기'로 설정하면

이렇게 마스터 브랜치에서 뭔가 받아올 게 있다고 뜬다.

풀 버튼을 눌러서 Github으로부터 당겨오면

마찬가지로 이렇게 동기화 된 것을 볼 수 있다.

저쪽에서 올린지 시간이 지나거나 SourceTree를 다시 열거나 했을 때도 숫자 알림 표시가 나타나지만 Git을 사용해 원격으로 협업할 때는 뭔가 작업하거나 푸시하기 전에 숫자 알림이 있든 없는 Pull을 먼저 눌러주는 것이 좋다.

팀원이 작업한 내역을 꾸준히 업데이트 받아야 괜한 작업을 하거나 conflict가 나는 일을 방지할 수 있다. 그리고 Github에 올라간 내역을 Pull로 다 업데이트 받기 전까지는 내쪽에서 Push를 할 수가 없다.

6. 브랜치 주고 받기

이제 branch도 원격에서 다뤄보자

상편에서 git branch 브랜치명으로 브랜치를 만들고

git checkout 브랜치명으로 넘어가는 걸 배웠다.

git branch 브랜치명 👈 브랜치 생성

git checkout 브랜치명 👈 해당 브랜치로 넘어간다

그걸 한 번에 하려면

➡️ git checkout -b 브랜치명 👈 위에 명령어 두 개 합친 기능

윈도우 터미널에 git checkout -b my-idea 입력

바로 my-idea 브랜치가 만들어져서 체크아웃까지 됐다.

상편에서 했던 것처럼 mouse는 없애고 dinosaur를 추가해서 add, commit을 해준다.

그리고 로컬에서처럼 my-idea란 브랜치를 Github에 만들어서 거기에 올린다.

git push 원격이름 브랜치이름

완료가 되면 Github 페이지를 새로고침 하고 나서

Branch를 눌러 보면 my-idea가 새로 생겨났고

my-idea를 선택해보면 로컬의 my-idea의 상태가 그대로 반영된 것을 볼 수 있다.

맥에서 이 브랜치를 받아보자.

먼저 원격에 어떤 브랜치가 있는지 확인한다.

git branch는 로컬에서의 브랜치만 볼 수 있지만

여기에 -a를 붙여주면 로컬과 원격 모두를 볼 수 있다.

git branch 👈 로컬에 있는 브랜치만 확인

git branch -a 👈 로컬과 원격 모두 볼 수 있음

근데 원격에 main 밖에 없다.

아직 Github의 현 상태를 파악하지 않았기 때문이다.

git fetch 👈 깃헙에서 업데이트 내역 새로 받아오기

git fetch를 실행해서 Github에서의 소식을 알아보면

* [new branch]      my-idea    -> origin/my-idea

새 브랜치가 나왔다는 메시지가 뜬다.

다시 git branch -a를 입력해보면 리모트의 my-idea가 확인가능하다.

이걸 로컬로 가져와서 거기로 넘어가보자

git checkout -b my-idea origin/my-idea

git checkout -b my-idea
👉 로컬에 my-idea 라는 브랜치를 새로 만들어서
origin/my-idea
👉 origin이라는 원격의 my-idea 브랜치의 내용을 받아오고
그 평행우주로 건너간다.

파일 상태가 로컬에도 반영됐고

브랜치들을 확인해보면 로컬에도 my-idea 라는 브랜치가 생겨서 현재 체크아웃 되어 있다.

SourceTree에서 하는 법

이번에는 SourceTree로 맥에서 윈도우로 넘겨본다.

SourceTree에서 브랜치 버튼 클릭

my-another-idea 브랜치로 분기하고

cat 파일을 수정한다.

SourceTree로 가서 체크해주고

커밋 메시지를 작성해주고

원격 origin에 my-another-idea를 만들어서 푸시까지 하겠냐고 물어본다.

체크하고 커밋 한다.

Github 페이지를 새로고침 하면 my-another-idea 브랜치를 확인할 수 있다.

윈도우에서 맥 작업내역 가져오기

SourceTree에서 페치 버튼 클릭

원격 origin을 펼쳐보면 새로 나타난 것을 볼 수 있다.

my-another-idea 우클릭 하고 체크아웃 클릭

로컬에 같은 이름으로 브랜치가 설정되고 체크아웃 버튼을 눌러주면 된다.

main으로 이동한다.

my-another-idea 우클릭 하고 Merge 클릭

my-idea에서 한 것, my-another-idea에서 한 것
그리고 그걸 main으로 가져와서 병합한 것
새 커밋내역들이 숫자로 푸시 버튼 옆에 나타난다.

푸시 버튼을 눌러서 main이 my-another-idea의 변경사항들까지 병합되었음을 Github에 올린다.

my-another-idea에 체크해주기

맥의 SourceTree에서 페치로 원격 상황을 받아오면

main에 풀 받을 커밋들이 있다고 뜬다.

main으로 이동해서 풀 버튼 클릭

7. 충돌 해결하기

Git을 사용하면서 익혀 나갈 때 많은 사람들이 어려워하고 부딪치기 싫어하는 경우가 상편에서도 다뤘던 충돌이 발생하는 경우이다.

막상 맞닥뜨려서 어쩔 수 없이 해결해보면 생각보다 간단해서 자신감이 붙게 되는데 아직 Git에 익숙하지 않아서 뭐 잘못 만지면 프로젝트가 다 망가지지 않을까 걱정이 된다.

Conflict에 대한 두려움이 없어지도록 연습을 해두는 것이 좋다.

Conflict는 상편에서처럼 브랜치 간에도 발생하지만 같은 브랜치에서 같은 파일의 같은 부분을 원격의 두 컴퓨터가 같이 건드린 상황에서도 발생한다.
정확히 말하자면 한쪽에서 이 파일을 수정해서 Github에 push 했는데 다른 쪽에서 이를 pull 받지 않은 상태에서 같은 파일을 수정해서 커밋한 상태, 이쪽이 새로 push를 했어서 이걸 pull 받기 전까진 push가 안 되는 상황이다. 이 때 pull을 하면 conflict가 발생한다.

직접 충돌을 내보자.

윈도우 컴퓨터에서 dog 파일에 bark: wang wang 입력

커밋하고 푸시한다.

마침 맥에서도 dog 파일을 이렇게 작업하는 중이었다.

커밋하고 푸시하려고 하는데 이렇게 에러가 뜬다.

pull 할 게 있기 때문에 push가 안 되는 것이다.

원격에 누가 새 작업을 올렸구나 하고 pull을 받는데

저 쪽에서도 dog 파일의 같은 부분을 수정했다는 걸 알게 된다.

git status로 상황을 보면 더 알기 쉽게 나타난다.

dog 파일을 보면 양쪽의 작업이 겹치는 부분이 이런 식으로 처리가 돼서 저장이 되어 있다. git에서 dog 파일을 이렇게 수정한 것이다. 텍스트 내용 자체는 이렇게 바뀐 거지만 VS Code에서 친절하게 색칠까지 해줘서 분량이 많은 코드에서도 어디에서 충돌이 난 건지 쉽게 알아볼 수 있다.

HEAD 라고 된 위쪽이 내가 작성한 부분이고, 그 아래에 있는 부분이 상대방이 작성한 부분이다. 둘 중 하나만 남기거나 합의를 봐서 적당히 파일을 수정하고 저장하면 된다.