[기초 Pre과정] Github 사용법

✔️ Git을 사용하면서 발생하는 각종 문제들을 계속해서 추가로 업데이트 해나갈 예정

Git이란

• Git은 분산형 버전 관리 시스템 (Distributed Version Control System)
  • 저장소가 '분산'됨 : 자신의 컴퓨터에 생성되는 로컬 저장소에 코드를 저장한 후, 이를 중앙 서버에 push할 수 있고, 다른 사람의 로컬 저장소에 저장된 코드를 가져와서 사용할 수도 있게 해줌
  • '버전 관리'를 통해 코드 관리를 용이하게 해줌 : 개발을 하다보면 로직이 꼬이거나 기획이 변경되어 코드를 예전 상태로 돌리고 싶은 경우 용이! Git은 commit된 코드의 변경이력을 모두 저장하고 있기 때문에, 언제든지 이전 버전으로 돌아갈 수 있음

⇒ 협업을 위해서, 버전 관리를 위해서는 Github 활용이 필수!

Git의 역할

• 소스 병합 (merge, rebase)
• 소스 리비전 관리 (reset, commit, branch)
• 소스 릴리즈 (push)
• 소스 태깅 (tag)
• 소스 변경사항 검토 (diff, log)

✒️ GitHub 사용법

1. GitHub 계정 만들기
상단에 'Sign up' 버튼을 클릭하여 회원가입을 진행합니다.

2. Git 설치하기

https://git-scm.com/downloads 에 접속하여 Downloads라 적힌 곳에서 사용 중인 운영체제를 선택합니다. 예) Windows

Download of '선택한 운영체제 ex. Windows' 창으로 넘어가면, 'Click here to download'을 클릭하여 다운로드를 진행합니다. 특별히 설정하고 싶은 부분이 없으면 Next 버튼을 계속 눌러 설치하시면 됩니다.

3. Git 환경 설정하기

Git을 설치하면 Git Bash가 함께 설치됩니다.
Git Bash 또는 명령 프롬프트를 열어주신 후 아래 명령어를 입력하여 이메일 주소와 이름을 등록합니다.

git config --global user.email "your_email@example.com"
git config --global user.name "Your Name"

(예시)

🔻 윈도우 11에서는 위 사진과 같이 윈도우 터미널을 열어서 작업하실 수도 있습니다.
🔻 이메일을 적는 부분에는 GitHub에 가입된 이메일을 적어주세요.
🔻 이름은 커밋 내역에 보이는 부분으로 아무 이름이나 적어도 됩니다.

4. GitHub 리포지터리 만들기
왼쪽 상단에 위치한 초록색 버튼인 'New' 버튼을 클릭하여 새로운 리포지터리를 생성해줍니다.

리포지터리의 이름, 공개여부 등을 설정하시면 됩니다.

5. 로컬 컴퓨터에 리포지토리 복제하기

GitHub 리포지토리에 있는 것을 로컬 컴퓨터로 가져오는 작업을 통해 복제, 즉 클론을 해야합니다.

먼저, 리포지토리를 생성하고자 하는 폴더를 열어줍니다. (아무 폴더나 다 가능합니다. 저는 한곳에 정리를 하기 위해 생성된 git 폴더에 관리하겠습니다.)

폴더에서 마우스 우클릭을 하면 '터미널에서 열기' 옵션이 나옵니다. 클릭하면 해당 폴더를 경로로 윈도우 터미널이 실행됩니다.

'더 많은 옵션 표시'를 클릭한 후 'Git Bash Here'를 클릭하면 Git Bash가 해당 폴더를 경로로 실행됩니다. 윈도우 터미널 또는 Git Bash 중 편한 것을 사용하시면 됩니다.

(일단 생략 - 추후 업데이트 하기)

6. 리포지토리 수정하기

7. 변경 내용 스테이징하기

8. 변경 내용 커밋하기

git commit -m "커밋 메세지"

위와 같은 형식으로 적어주면 됩니다. 커밋 메세지는 변경한 내용을 요약하는 말로 적어, 변경 내용을 모두가 쉽게 이해할 수 있도록 합니다.

'commit message convention'이라고 검색하면 많이 사용하는 커밋 메세지 작성법을 확인할 수 있습니다.
(참고 :https://velog.io/@archivvonjang/Git-Commit-Message-Convention)

9. 소스 기록하기

소스를 기록하기 위해서는 git add 명령어를 이용합니다.

git add .

ignore 파일이나, 삭제한 파일 이력까지 커밋을 할 경우, -f 옵션을 이용합니다.

git add . -f

git remote show origin을 프롬프트에 입력하여 origin에 remote 주소가 잘 등록되었는지 확인해봅니다!

git remote show origin

10. 로컬 컴퓨터에서 변경한 내용을 GitHub에 푸시(push)하기
push는 변경내용을 로컬 컴퓨터에서 GitHub으로 업로드를 하는 것으로, Git Bash나 명령 프롬프트에서 아래와 같은 명령어를 적어주시면 됩니다.

git push

11. 소스 업데이트하기
상대방이 커밋한 파일은 명령어를 통해서 직접 업데이트를 해야 동기화가 됩니다. 사용할 수 있는 명령어는 다음과 같습니다.

• git pull
  fetch+merge 작업

• git fetch
  merge를 하지 않음

#main 브랜치를 pull하여 업데이트
git pull origin main

#main 브랜치를 fetch하여 업데이트
git fetch origin main

12. 소스 복원하기
실수로 잘못 작업하였거나, 예전 버전으로 롤백하여 적용할 경우 아래의 소스 복원 작업을 통해 예전 버전으로 리셋할 수 있습니다. (정말 중요한 작업... my life saver)

git reset HEAD^ --soft/hard/mixed

reset의 옵션으로 soft, hard, mixed가 있으며 셋 중 하나를 선택해 작성하시면 됩니다.

• --soft : 되돌릴 때 기존의 인덱스와 워킹트리를 보존
• --hard : 되돌릴 때 기존의 인덱스와 워킹트리를 버림 (주의해서 사용해야 함!)
• --mixed : 되돌릴 때 기존의 인덱스는 버리고 워킹트리를 보존

🔻 git reset 다음 인수로는 되돌리는 버전의 위치를 가리킵니다.
🔻 현재위치(HEAD)를 기준하여 상대적인 위치를 설정하거나, 특정 버전 리비전 고유의 해시값을 지정하시면 됩니다.
🔻git reflog 명령어를 이용하여 HEAD 위치를 확인하세요!
🔻 되돌리는 위치의 경우 아래와 같이 사용할 수 있습니다.

# 바로 이전 단계로 인덱스와 워킹트리를 버리고 리셋.
$ git reset HEAD^ --hard

# 바로 두번째 전 단계로 인덱스와 워킹트리를 버리고 리셋.
$ git reset HEAD~2 --hard

# 특정 리비전의 기록으로 인덱스는 버리고 워킹트리를 보존하여 리셋.
$ git reset 991ee8c --mixed

13. 브랜치 branch
git에서는 마치 가지를 펼치듯 하나의 근본에서 여러 갈래를 쪼개어 관리할 수 있습니다.

📌 branch의 특징

• 기본은 main 브랜치라고 불리며, 필수로 제공되는 브랜치입니다.
• 서로 다른 브랜치들은 같은 조상을 가지고 있습니다.
• 브랜치를 새로 만든다면, git branch [브랜치명] 으로 생성합니다.

#new라는 브랜치를 생성
git branch new

• main을 기준으로 new를 브랜치(가지치기)하면 main와 똑같은 소스코드가 new에도 적용됩니다.
  • 예전 git 프로그램을 사용할 경우, master가 기본 브랜치로 보이게 됩니다.
• 하지만 이 이후로 new에서 코드를 수정하면, main과 new는 서로 다른 코드가 되기 때문에 갈라집니다.
• 생성된 new 브랜치로 접속하기 위해서는 git checkout [브랜치명] 을 사용합니다.

git checkout new

• 생성과정과 브랜치 이동과정을 동시에 하고자하면 git checkout에 -b 옵션을 사용합니다.

# 브랜치 new를 생성과 동시에 체크아웃.
git checkout -b new

• 생성한 브랜치는 현재 로컬에 저장되어 있습니다
  → 협업 작업에서는 생성한 브랜치를 원격 저장소에 등록해줘야 합니다! 그래야 코드 공유가 가능합니다.
  → git push [브랜치명] 명령어를 이용합니다.

git push origin new

• 브랜치 삭제 : git branch -d [브랜치명]
  • 삭제된 브랜치 역시 원격 저장소에 반영을 해야합니다.
  • 이때 브랜치 명 앞에 콜론 (:)을 붙여줘야 합니다!

git push origin :브랜치명

14. 소스 병합하기 : merge, rebase
서로 다른 브랜치에서 서로 다른 코드가 개발되었고, 실제 배포에서 이를 합쳐야 할 때 사용합니다. 각자 다른 기능을 맡을 경우가 많은데, 이를 합쳐서 확인하는 것이 중요하겠죠!

병합 방식에는 크게 두가지가 있습니다.

• git merge
  
  master에서 merge를 실행하면, master 브랜치의 HEAD에 새롭게 커밋이력이 생성됩니다. merge는 실행한 브랜치로 병합을 실행하고 새로운 커밋이력을 생성합니다.
  이 과정에서 conflict가 발생할 수 있지만, 충돌이 난 부분을 고친 후 다시 add → commit을 실행시켜주면 됩니다.
  
  

• git rebase
  
  rebase는 어떤 특정 브랜치를 base로 커밋 이력을 재정렬하겠다는 명령어입니다. 따라서 기준을 어디로 하느냐에 따라 rebase 모양이 달라질 수 있는데요!

예를 들어 설명을 드려보겠습니다. (출처 : https://dongminyoon.tistory.com/9)
- 초록색 노드 : master 브랜치
- 노란색 노드 : sub 브랜치

1. 초록색 master 브랜치에서 노란색 sub 브랜치를 기준으로 rebase를 시킨 경우, sub 브랜치를 베이스로 커밋 이력이 정렬됩니다.
   

2. 노란색 sub 브랜치에서 초록색 master 브랜치를 rebase 시키면, master 브랜치를 베이스로 커밋 이력이 정렬됩니다.
   

이때, 재정렬된 커밋이력에 (')가 추가되면서 해쉬 ID가 바뀌게 됩니다. 재정렬되는 commit 이력이기 때문에 이전과는 다른 새로운 해쉬 ID가 부여되는 것입니다!

따라서 master 브랜치에서 다른 브랜치를 기준으로 rebase를 실행하면, master의 커밋이력이 변하게 됩니다. 그렇기 때문에, master 브랜치에서 다른 브랜치를 기준으로 rebase을 하는 경우는 피하는게 좋을 것 같습니다..

15. 충돌과 해결...
충돌은 같은 조상을 기준으로 서로 다른 두개의 브랜치가 같은 소스코드를 변경했을 때 발생합니다. 협업 과정에서는 같은 소스파일을 merge 후 건드렸을 때 발생하게 됩니다(흑흑...)

이번에도 예시와 함께 설명드려보겠습니다.

#main 브랜치의 some_file.txt 내용
* main -> some_file.txt의 내용
Apple

#해당 브랜치를 복제한 sub 브랜치로, 복제 후 한 번 내용을 수정함
* sub -> some_file.txt의 내용
* 2번째 단계 HEAD
Banana

#이후 main에서도 내용을 변경하여 버전을 업데이트 함
* main -> some_file.txt의 내용
* 2번째 단계 HEAD(sub랑 단계가 겹침)
Strawberry

둘 모두 버전이 같으나 같은 라인에서 변경사항이 발생했습니다. 이 경우 충돌이 발생하게 됩니다!
총돌이 발생한 some_file.txt를 열어보면 아래와 같은 내용을 확인할 수 있습니다.

* 머지 이후 main -> some_file.txt (충돌)
<<<<<<< HEAD
Strawberry
=======
Banana
>>>>>>> sub

여기서 HEAD는 현재 브랜치(main)을 의미합니다.

충돌 해결 방법

• Head와 sub의 각각 내용을 보여주고 있는데 꺽쇠(<,>), 이퀄(=) 기호가 없도록 문장 하나를 선택해서 반영해줘야 합니다.

여기서는 main 브랜치의 Strawberry를 선택하여 충돌을 해결해보겠습니다.

* 머지 이후 main -> some_file.txt (수정)
Strawberry

수정이 되었다면 머지 해결을 위해 git add와 git commit으로 충돌을 해결해보세요!

$ git add *
$ git commit -m "Solved the conflict issue."

📌 번외 : Android Studio에서 Git 연동 및 리포지터리 클론하기

• Flutter 사용

출처

https://github.com/KennethanCeyer/tutorial-git
https://mindorizip.tistory.com/97
https://dongminyoon.tistory.com/9