팀 개발을 위한 Git, GitHub 입문

버전 관리란?

수정 사항들을 커밋(하나의 버전) 으로 정리해서 관리하는 것이다. 커밋을 여러 개로 쪼개면 쪼갤수록 관리하기 편리할 것이다.

<<< 내 생각에는 코드를 한번에 완성하는 경우가 없다. 많은 수정 사항들이 생기고, 추가하는 사항들이 생기기 때문에 커밋으로 그 사항들을 정리해서 어떻게 진행되고 있는지도 알아볼 수 있고, 원본을 훼손하지 않고 계속 코드를 안정적으로 저장할 수 있다. 그래서 버전 관리가 중요한 것 같다.

그런데 버전 관리한 부분을 어디서 볼 수 있는지 아직 잘 모르겠다.

여기서 확인할 수 있을 것 같은데 자꾸 로딩만 뜬다...

++ 찾았다 !!! commits를 클릭하면 전의 코드들도 모두 볼 수 있다.

참고 링크 : commit history 확인하기

Git과 GitHub?

(1) Git : 버전 관리, 저장 공간이 필요하다.
사용하는 방법 : CLI (명령어 이용)와 GUI (버튼을 이용)
(2) GitHub : 저장 공간을 의미한다.

목차

• git과 버전 관리
• git, github + CLI
• git, github + GUI
• git, github + 실무 사례

환경 설정하기

(1) Git, Git Bash 설치하기.
(2) vscode 설치하기.
(3) gitHub 가입하기.

1. Git 초기화와 로컬 저장소 만들기

(1) 로컬 저장소 : 나만 볼 수 있는 저장소를 의미한다. 내 컴퓨터 안에 있는 저장소이다.
(2) 원격 저장소 : GitHub에 있는 저장소를 의미한다. 같이 협업하는 사람들이 모두 같이 볼 수 있다.

(주의) 1개의 폴더에 하나의 로컬 저장소 만 생성 가능하다. 꼭 주의하자 !!! 여러 개를 만들어 버리면 충돌이 일어날 수 있다.

이런 경우를 막기 위해서 한 프로젝트는 하나의 폴더에 저장해서 관리를 해줘야 할 것 같다.

(ex1) 1개의 프로젝트를 진행하는 경우, 1개의 폴더를 생성한다.
(ex2) 매주 올려야 되는 경우, 어차피 원격 저장소의 위치가 같기 때문에 그냥 1개의 폴더 안에서 처리하고, 올리고 싶은 파일만 add를 이용해서 올려준다.

Git을 초기화하고 로컬 저장소를 만들기.
내가 코드를 작성하고자 하는 폴더로 들어가서 git bash를 켜주기.

? 버전 관리란 무엇인가 ?

수정 사항 수정 + 원본 보존에 탁월하다.
현업 시에 유용하다.
만약에 코드가 돌아가지 않는 경우, 바로 전 단계의 버전으로 들어가면 최신 코드를 가져올 수 있다.

git init

git bash에 이 명령어를 실행하면, 초기화가 되면서 로컬 저장소가 만들어진다.

ls // 폴더에 있는 모든 파일을 확인할 수 있다.
ls -al // 폴더에 있는 보이지 않는 파일들도 모두 확인할 수 있다.

++ git bash에서 작업 공간을 cd를 이용하여 설정할 수 있다. 이런 경우에는 한 단계씩 천천히 내려가야 한다.

(ex) 만약 작업 공간의 주소가 C:\Users\ajouu\Documents\coding-test 인 경우

cd C:
cd Users
cd ajouu
cd Documents
cd coding-test

# 이런 방식으로 한 단계씩 내려가기.
# cd : 작업 공간의 위치를 설정하기.

2. 첫 번째 버전 만들기

(1) 전역 사용자 설정하기 : 닉네임과 이메일 입력하기.

git config --global user.name "NohJeongKim" // 닉네임
git config --global user.email ajouunihospitalrn@naver.com // 이메일 주소

사용자 정보를 설정해준 뒤에, vscode에서 열심히 코딩을 해준다.

README.md
index.html
style.css
app.js

(2) 원하는 파일 선택하기

git add 원하는 파일

(3) 메세지를 달아 커밋으로 만들기
커밋은 1개의 버전이라고 생각하면 편하고, 의미있는 변동사항을 커밋에 적어줘야 한다.

git commit -m "원하는 메세지 입력"

(4) 생성한 커밋 보기

git log

여기까지만 제대로 해도, 버전 관리는 제대로 하고 있는 것이다.

3. 만든 버전을 GitHub에 올리기

git remote add origin 원격 저장소 주소
git push origin main
# 구글링을 해보니 master 보다는 main 브랜치에 올리는 것이 좋다고 한다. 

4. 다른 사람이 만든 저장소 받아오기

(주의) 반드시 .을 찍어줘야 한다. 아니면 새로운 폴더에 저장되기 때문이다! 이 과정은 맨 처음 과정에서만 사용하면 된다.

git clone 원격 저장소 위치 . 
// 이런 경우는 맨 처음 과정에서만 사용하기.
git pull origin main
// 상대방이 올린 코드를 가져올 때 이용하기.

git clone의 경우는 처음에 모든 코드를 복제할 때에 이용하는 것이 좋다. 그리고 git pull origin main 같은 경우에는 몇 개의 고친 커밋을 가져오는 데에 유용하다.

5. 위의 과정을 정리하기

(1) A,B가 협업의 짝꿍으로 정해진다.
(2) A가 로컬 저장소를 생성하고, 코드를 작성한 뒤 add, commit 그리고 push를 이용해서 원격 저장소에 올린다.
(3) B가 새로운 코드를 작성하기 위해 clone을 이용해서 A가 올린 코드를 모두 복제한다.
그리고 collaborator에 B를 추가한다.
(4) B도 마찬가지로 add, commit, 그리고 push를 이용해서 코드를 원격 저장소에 올린다.
(5) A는 변경된 사항을 고려하면서 코드를 작성하기 위해서 pull을 이용해서 원격 저장소에서 변경된 코드를 모두 가져온다. 그리고 다시 코드를 작성한다.
... 과정 반복 ...

여기까지가 cli를 이용한 버전 관리가 끝이 났다...
각자 개발한 버전을 언제든지 중간에 있는 원격 저장소에 올리고 받아올 수 있다~!

감상평

생각보다 별거 아니였고, 배우고 나니까 엄청나게 좋은 코드 저장소라는 것을 깨닫게 되었다 ;; 항상 수정하면 그 전의 코드를 보관할 생각을 전혀 하지 않았는데 (일단 코드가 돌아가는 것에 대해 엄청나게 기뻐서 ㅜㅜ) 그 코드가 사실 효율적이지 않을 수 있기 때문에 꼭 가지고 있어야 한다. 또한, 협업에 있어서 엄청 유용하다. 항상 손으로 긁어서 가져왔는데 정말 그럴 필요가 없어졌다..

참고 링크

하위 폴더에 push
error: failed to push some refs to : 원격 저장소에 내 로컬 저장소에 없는 파일이 있는 경우에 생기는 오류 >>> "pull" 이용해서 한번 땡겨와주면 된다.
git bash END 해결 방법 : quit의 약자인 "q" 눌러주면 끝난다.
리눅스 명령어 모음

+ 브랜치 생성한 후 push 시켜주기

이미 원격 저장소가 있는 경우에는 다 지워준 다음에 다시 1개만 있도록 만들어줘야한다.

git remote rm origin

반드시 한 폴더에 1개의 로컬 저장소, 그리고 또 1개의 원격 저장소만 존재해야 충돌이 일어나지 않는다.

(1) 로컬 저장소 만들어주고, user의 정보를 입력해준다.
(2) 즐겁게 코딩한다.
(3) 생성할 브랜치를 만들어주고, 해당 브랜치로 이동한다.

git checkout -b 브랜치 이름 // 이 코드를 실행하면 만들기와 이동이 동시에 이뤄진다.

(4) 원하는 파일을 git에 올려주기.

git add "원하는 파일 이름"
// 모두 올리고 싶으면 git add .을 작성한다
git commit -m "원하는 커밋 메세지"
git push origin "아까 만들어서 이동한 브랜치 이름"

만약에 브랜치를 삭제하고 싶은 경우에는

git branch -d "삭제하고 싶은 브랜치 이름"

결국 차근차근 수행해주는 것이 중요하다~!
하나의 로컬 저장소와 하나의 외부 저장소와 연결시켜서 코드를 push하거나 pull 해오면 된다. 이로 인하여, 버전 관리, 협업, 그리고 백업을 쉽게 해낼 수 있다.

기본 브랜치가 master인 경우

cd를 이용하여 원하는 파일 경로로 옮기고 git init를 했는데, master인 경우에는 main으로 브랜치를 변경해야 한다.

git init
# master인 경우
git add . # 모든 파일을 가져오기.
git commit -m "원하는 메세지 입력하기"
git remote add origin "파일 올리고 싶은 깃허브 주소 입력하기."
git branch -M main # main으로 브랜치 변경하기.
git push -u origin main # git push origin main?

• git push origin main VS git push -u origin main 비교하기!!
  git push -u origin main을 이용하게 되면 -u 뒤로 origin, main을 컴퓨터가 기억하고 있기 때문에, 그 다음부터는 그냥 git push만 이용해도 원하는 위치로 push할 수 있다. (반복하는 부분을 줄여줄 수 있다는 장점이 있다.)

6. git + github + GUI

sourcetree download 받기.
로컬 저장소 추가하고, history까지 볼 수 있다.

원격 저장소에 있는 커밋과 로컬 저장소에 있는 커밋이 무엇인지 잘 체크하기 !!! 원격 코드와 로컬 코드 위치를 잘 맞춰주기 !!!

1. 내 컴퓨터에만 있는 경우 : 원격 저장소에는 없다는 의미이기 때문에, git push origin main을 이용하자.
2. 원격 저장소에만 있는 경우 : 내 컴퓨터에 없다는 의미이기 때문에, git pull origin main을 이용해서 커밋을 가져오자.

origin이 붙어있는 경우, 원격 코드라는 의미이고 origin이 없는 경우, 로컬 코드라는 의미이다.

7. git 원리 이해하기

git 이전에 사용하던 svn : 변동 사항만 저장, 안 좋은 점은 변동 사항을 모두 뒤져야 해서 시간이 많이 소요가 된다. 그러므로 속도가 굉장히 느려진다.

git은 변경 사항의 모음은 아니고, 최종 코드의 모음을 의미한다. 그래서 최신 버전을 보고 싶으면 바로 직전으로 돌아가면 된다.

untracked : git에 올리기 전
tracked : git에 올린 후, git에 올리면 기차처럼 버전 관리가 된다. 최종 코드가 기차에 실려있다고 생각하면 좋다.

? stage란 ?
add를 통해서 커밋을 stage에 올릴 수 있다. stage에 올린 이후에 commit을 해주면 원격 저장소에 올라갈 수 있게 만들어준다. 무대라고 생각하자.

8. branch

한 줄로 쌓으면 둘이 겹치는 문제가 발생 (예를 들면, 같은 코드를 서로 다르게 고칠 수 있기 때문이다.) 이를 해결하기 위해서 여러 줄로 쌓아서 코드를 커밋하면 된다. 평행 세계를 나누는 것이다. 한 줄로 커밋하면 충돌할 수 있다. 나중에 merge를 이용해서 합칠 수 있다.

git branch <브랜치명> # 브랜치 생성하기.
git checkout <브랜치명> # 이 브랜치로 옮기기.

(ex) A 브랜치 1개 만듦. -> main 브랜치로 돌아가기. -> B 브랜피 1개 만듦.

9. merge

나눈 branch를 main branch에 합치기 위해서 사용하는 명령어이다.

(ex) main branch에서 협업한 뒤에, 서로 동시에 코드를 쌓아야 되는 경우 (A는 메인 페이지 작업, B는 댓글 기능 작업) 각자 브랜치를 파서 코드를 커밋한다. 그 뒤에 모두 작업이 끝난 뒤에 main branch에 merge해서 합쳐준다.

10. conflict

merge 하는 경우에 conflict가 발생하는 경우가 있다. 왜냐하면 merge의 기본 개념이 합집합 이기 때문에, 새 것이 나오는 경우가 있기 때문에 충돌이 생기는 경우가 생긴다.