🎧Be Dilettante⌨️

원문:  https://dev.to/reenatoteixeira/everything-that-you-need-to-know-about-git-2440

 

 
 
나는 당신이 변경 사항을 되돌리고 손실된 데이터를 복구할 수 있도록 코드 버전의 중요성을 생각할 것이라고 확신한다. 창의적인 이름으로 파일 복사본을 만들어 가며 버전 관리를 하는 누군가(저는 아님)를 알 거라고 생각한다..
 

 
이것은 아마도 1972년 이전에 처음으로 중앙 집중식 버전 제어 소프트웨어 중 하나인 SCCS(Source Code Control System)가 출시되면서 누구나 자신의 코드로 버전 제어를 할 수 있는 방법이었을 것이다. 
 
그러나 우리는 여기서 SCSS를 얘기하려는 것이 아니라, 우리가 가장 관심있어 하는 것은 내년(07/04/2005)에 20주년을 맞는 분산형 오픈소스 버전 제어 소프트웨어인 GIT이다. 
 

목차

• 1. What's GIT?
• 2. How does GIT work?
• 3. Installing GIT
• 4. Configuring GIT
• 5. Starting a local repository
• 6. Working with GIT
• 7. Knowing branches
• 8. Syncing with the remote repository
• 9. Conclusion
• 10. References

 

1. GIT이란 무엇인가?

 

GIT은 리눅스 커널 제작자인 Linus Torvald이 개발한 2005년에 출시된 분산형 오픈소스 버전 관리 시스템이다. 
 
GIT을 통해 우리는 프로젝트의 버전을 전역적으로 관리할 수 있고(작업하는 폴더에서) 모든 변경사항을 리모트 레포지토리와 싱크를 맞출 수 있다(예를 들어 GitHub에서). 

 

---

 

2. GIT은 어떻게  작동할까?

 

모든 프로젝트 파일이 있는 폴더가 있는 물리적인 파일 캐비닛을 상상해보라. 누군가 파일을 조작하려고 할 때마다, 그들은 그것을 골라야 하고 폴더에서 그것을 지우고 끝난 후에는 다시 폴더에 되돌려 놓아야 한다. 따라서 두 사람이 동일한 파일을 작업하는 것은 불가능하여 발생 가능한 충돌을 완전히 피할 수 있다.
 

그러나 이것이 GIT이 작동하는 방식은 아니다! (thanks God)

 

이것은 중앙 집중된 버전 컨트롤 시스템이 작동되는 방식으로, 사용자는 파일을 'check-out(체크아웃)'하고 'check-in(체크인)'해야 한다. 특정 파일에 대한 작업이 필요할 때마다 해당 파일을 체크아웃하여 저장소에서 제거한 다음 작업이 완료되면 파일을 체크인하여 저장소로 반환해야 한다.

 
GIT같은 분산형 시스템에서는 같은 레포지토리의 파일에 여러 사람들이 동시에 파일에 접근하는 것이 가능하다. 누군가 파일을 조작할 때마다 파일을 로컬로 복제(또는 전체 레포지토리를 복제)한 다음 수정사항을 원격 레포지토리로 다시 보낼 수 있다. 이를 통해 여러 사람이 동일한 파일을 조작하면서 동일한 프로젝트에서 작업할 수 있다.

이것은 세계 여러 지역의 사람들이 같은 프로젝트에서 작업하고 수정 및 발생 가능한 충돌을 관리하는 대규모 오픈 소스 프로젝트의 배포를 허용한다(여기서 병합 충돌(merge conflicts)이 발생할 수 있다).

---

3. GIT 설치하기

GIT은 매우 간단한 설치 프로세스를 통해 주요 운영 체제(Windows, Linux, MacOs...)에서 사용할 수 있으며, 이는 명령줄이나 git-scm.com 의 공식 설치 프로그램을 통해 설치가 가능하다.

3.1 윈도우에서 설치하기

윈도우에 GIT를 설치하려면 공식 웹사이트에 들어가서 설치 프로그램을 다운로드하기만 하면 된다. 그리고 나서 지시사항을 따라가면 모든 것이 잘 될 것이다. 그리고 우리는 터미널에서 GIT 명령을 사용할 수 있을 것이다.

3.2 리눅스에서 설치하기

리눅스의 경우는 아래 명령을 사용해 GIT를 설치할 수 있다:

sudo apt install git-all

이 명령어를 통해 GIT이 우리의 터미널에서 실행될 준비를 해야 한다.

3.3 Mac에서 설치하기

Mac의 경우 GIT를 설치하는 가장 쉬운 방법은 Homebrew를 설치한 다음 터미널에서 아래 명령을 실행하는 것이다:
 

brew install git

 
이 명령어를 통해 GIT이 우리의 터미널에서 실행될 준비를 해야 한다.

---

4. GIT 구성하기

 
설치한 후에는 아래 실행을 통해 GIT을 구성하는 것이 중요하다:

git config --global user.name "[username]"
# e.g. John Doe

git config --global user. email "[email@email.com]"
# e.g. johndoe@email.com

 

또한 --global 태그를 제거하여 특정 로컬 리포지토리에 대한 특정 사용자를 구성할 수도 있다.

 

---

 5. 로컬 레포지토리 시작하기

 
GIT이 구성되면 로컬 저장소를 시작할 수 있다. 이를 위해 새 저장소를 처음부터 시작하거나 기존 원격 저장소를 복제할 수 있다.

5.1 처음부터 시작하기(git init)

새 레포지토리를 시작하려면 원하는 레포지토리 루트 폴더로 이동하고 아래 명령을 실행하기만 하면 된다.

git init

 

 

이를 통해 프로젝트 폴더에  .git 디렉토리가 생성되며, 이 디렉토리는 로컬 저장소의 작업 폴더의 버전 컨트롤을 담당한다. 

 

5.2 기존 레포지토리 복제하기(git clone)

기존 원격 저장소를 복제하는 것은 새 저장소를 처음부터 시작하는 것만큼 쉽다. 이를 위해 우리는 레포지토리를 다운로드 하고 싶은 곳에 리모트 저장소의 URL과 함께 git clone 명령어를 사용한다.

 

git clone [repository-url]

 

 

그리고 나면 전체 레포지토리가 우리의 로컬 저장소에 복제될 것이고 자동으로 연관된 원경 저장소와 연결될 것이다.

 

레포지토리 복제는 우리가 더이상 git remote 명령어를 미래에 사용할 필요가 없다는 것을 뜻한다.

 

---

 

6. GIT으로 작업하기

우리의 로컬 저장소에서 우리는 우리 프로젝트에 필요한 파일을 만들 수 있지만 그 파일들이 자동으로 GIT에 의해 동기화되지는 않을 것이다. 우리는 버전 변경 사항이 생길 경우 GIT에 보고해야 한다.

 

그러므로 우리는 우리가 원하는 대로 파일을 조작하고 변경 사항을 수정한 후에는 깃에 수정된 파일을 보낸다.

 

이를 위해 버전 컨트롤에 3단계의 무한 플로우가 있다는 것을 이해하는 것이 중요하다.

 

 MODIFY -> STAGE -> COMMIT

 

 

• MODIFY(수정 단계): 버전 컨트롤의 첫 번째 작업은 MODIFY이다. 여기서는 사용 가능한 마지막 버전과 비교하여 변경된 파일을 찾는다.
• STAGE(스테이지 단계): 두 번째 stage 단계에서는 우리가 다음 커밋에 추가하고 싶은 파일을 수정된 파일에 위치 시킨다.
• COMMIT(커밋 단계): 마지막 단계인 commit 단계에서는 우리가 변경 사항을 확인할 때 스테이지의 수정된 파일을 로컬 저장소에 보낸다.

 

수정된 파일들을 커밋한 후에는 로컬 저장소에서 새로운 버전을 가지게 되며, 다시 업데이트 사항들을 받고 한 번 더 '수정'하고 '스테이지'에 위치시키고 다시 '커밋'할 수 있으며 새로운 버전을 확인하는 등의 작업을 수행할 수 있다. (그래서 '무한' 플로우라고 한 것 ㅎㅎ)

 

커밋은 수정된 파일의 이전 버전을 덮어쓰지 않으며, 마지막 버전에 대한 포인터가 있는 새 버전을 포함하므로 GIT에 의해 트래킹되는 각 파일의 버전을 추적하는 것이 중요하다.

 

6.1 추가하고 커밋하기(git add와 git commit)

복잡하게 들릴지 모르지만, 버전 제어 흐름을 수행하는 것은 매우 간단하다다. 원하는 수정이 완료되었으므로, 우리는 아래 명령으로 커밋하고자 하는 단계에 수정된 파일을 추가한다:

git add [filename]

 

git add -A : 모든 수정된 파일을 스테이지에 한 번에 추가
git add *. [extensão-do-arquivo] : 특정 익스텐션 파일의 수정된 파일을 스테이지에 한 번에 추가 (git add *.html 과 같이)

 

 

우리는 git status 명령을 사용하여 언제든지 현재 로컬 저장소 상태를 확인할 수 있다:

 

 

새 파일을 만든 후 저장소 내에서 git status를 실행하면 새 파일이 "Untracked(추적되지 않음)"으로 표시된다. 즉, 이 파일은 새로운 것이며 GIT에 의해 추적되기 위해서는 어떤 커밋에라도 추가되어야 한다는 것을 의미한다.

 

GIT가 저장소 내의 특정 파일이나 폴더를 무시하도록 할 수 있다. 이를 위해서는 루트 폴더에 .gitignore라는 파일을 추가하고, 그 안에서 무시해야 할 파일이나 폴더의 이름을 적으면 된다.

주의: 무시된 파일과 폴더는 더 이상 GIT 트랙에 나타나지 않으며, 심지어 "Untracked"로도 표시되지 않는다. 추적을 재설정하려면 .gitignore 파일에서 원하는 이름을 삭제하기만 하면 된다.

 

 

파일을 포함하기 위해 git add 명령을 추가할 파일의 이름("index.html")으로 실행할 수 있다:

 

 

 

이러한 방식으로 git status 다시 실행하면 새 파일이 "stage"에 추가되었으며 최종적으로 다음 커밋에서 보낼 준비가 되었음을 알 수 있고, 이는 아래 명령을 통해 수행할 수 있다:

 

git commit -m "[descriptive-message]"

 

커밋은 고유 ID(해시 코드)를 가지며, 변경할 수 없다. 즉, 커밋은 확인되면 수정할 수 없다.

git commit -a: 직접 커밋을 수행하며 모든 수정된 파일을 스테이지에 추가하고 커밋한다.

 

파일을 성공적으로 커밋한 후 git status를 실행할 때 마지막 커밋을 통해 모든 수정 사항이 로컬 저장소에 효과적으로 저장되었기 때문에 더 이상 업로드할 수정된 파일이 없음을 알 수 있다.

 

 

또한 해시 코드, 브랜치, 작성자, 날짜 등 모든 커밋의 일부 메타데이터를 보여주는 git log 명령을 사용해 저장소의 커밋 로그를 검토해 변경한 내용을 확인할 수 있다.

 

 

 

이 모든 과정을 반복하여 프로젝트에 필요한 새 파일을 추가하고 수정한 후 새로운 커밋을 만들어 로컬 저장소로 보낼 수 있다.

 

 

git log -N : 마지막 N개의 커밋이 포함된 log를 보여준다.
git log [branch-A] [branch-B]: "branch-B"에는 있지만 "A"에는 없는 커밋 로그를 표시한다.
git log --follow [filename]: 파일의 이름을 변경한 경우에도 지정한 파일을 변경한 커밋 로그를 표시한다.
git diff: 저장소에서 사용 가능한 최신 버전과 비교하여 변경한 내용을 나열한다.
git diff [nome-do-arquivo]: 저장소에서 마지막으로 사용 가능한 버전과 관련하여 지정된 파일에 대해 수행한 변경 사항을 나열한다.

 

6.2 커밋 전과 후에서 변경 사항 취소하기

커밋이 이루어지기 전에 로컬 저장소에서 이루어진 모든 변경은 취소하거나 변경할 수 있지만, 커밋이 한 번 이루어지면 변경할 수 없다. 커밋은 불변의 객체이기 때문에 커밋에서 데이터를 편집하거나 변경하는 것은 불가능하다.

 

그러나 변경을 취소하는 새로운 커밋을 만들거나 이전 커밋에서 잘못된 정보를 수정할 수 있다. 어느 쪽이든 우리는 다음 명령 중 하나를 사용할 수 있다:

 

git checkout -- [filename]
# 커밋 전에 로컬 파일에 대한 변경 사항을 폐기(돌이킬 수 없는 작업)

 

git reset --hard HEAD
# 스테이지 단계(커밋 전)에 있는 파일의 변경 내용을 폐기

 

git reset --hard HEAD~1
# 로컬 리포지토리에서 수행한 마지막 커밋을 폐기(마지막 커밋만 해당)

 

git commit --amend
# 로컬 저장소에서 수행한 마지막 커밋을 대체하여 새 커밋을 작성

 

git revert [commit-hash]
# 지정한 커밋의 변경사항을 되돌리는 새 커밋을 작성

 

---

 

7. 브랜치에 대해 알아보기

브랜치는 저장소의 가지치기(ramification)에 지나지 않으며, 지금까지 모든 작업은 브랜치 'master/main'에서 수행되었다. 

 

기본적으로 레포지토리에 생성된 첫 번째 브랜치는 레포지토리의 메인 브랜치인 master/main 이다.

 

7.1 왜 브랜치를 사용하는가?

처음에는 별것 아닌 것처럼 보일 수 있지만 브랜치는 프로젝트 개발에 막대한 파워를 가지고 있다.

 

우리가 웹 플랫폼을 개발하고 있고, 새로운 기능을 테스트하고 싶지만, 우리의 저장소는 이미 호스트되었거나 다른 사람들과 공유하고 있고, 어떤 문제가 있는 변경들이 그것들에게 나쁜 경험을 야기할 수 있다고 생각해보라. 이 상황에서 우리는 무엇을 할 수 있을까?

 

프로젝트 폴더를 복사하여 붙여넣고 새로운 "테스트 버전"을 만드는 것에 대해 생각해본 적이 있다면, 맞는 말이다! 음, 거의...

 

GIT를 사용하면, 우리는 브랜치들로 비슷한 일을 할 수 있다. 브랜치이기 때문에, 우리는 단순히 "테스트"라고 불리는 새로운 브랜치를 만들 수 있다. 따라서 우리 프로젝트의 버전을 완전히 고립된 브랜치에서, main 브랜치에 영향을 주지 않고 바꿀 준비를 한다.

 

 

 

7.2 브랜치 만들기 (git branch)

브랜치를 만드는 것은 master/main 브랜치에 영향을 주지 않고 독립적으로 작업할 수 있는 저장소의 병렬 복사본을 만드는 것을 의미한다. 이를 위해서 우리는 단순히 아래의 명령어를 실행하면 된다:

 

git branch [branch-name]

 

 

특정 브랜치의 이름 없이 git branch 명령을 실행하려면 저장소에 사용 가능한 브랜치 목록을 표시하며, "*"의 표시는 현재 사용 중인 브랜치를 나타낸다.

 

git branch test 명령을 실행하기 전에 git branch 명령은 master 브랜치만 반환한다.

 

git checkout [branch-name]

 

git checkout test 명령을 실행한 후 활성 브랜치가 전환되는 것을 확인할 수 있다. 그 순간부터 모든 커밋된 정보는 브랜치 master/main 에 영향을 주지 않고 저장소의 test 브랜치로 전송된다.

 

 

필요한 만큼의 브랜치를 생성할 수 있으며, 아래 명령을 사용하여 기존 브랜치와 상호 작용할 수 있다:

git checkout -b [branch-name]
 -> 지정된 이름으로 새 브랜치를 만들고 직접 그 브랜치로 전환한다.
git branch -d [branch-name] -> 지정한 branch를 삭제한다.
git branch -m [new-name] -> 현재 branch의 이름을 지정된 이름으로 변경한다.

 

 

7.3 브랜치 병합하기(git merge)

다른 브랜치 작업을 완료하고 변경한 내용이 프로젝트에 문제를 일으키지 않았다고 확신한다면, 현재 브랜치의 모든 변경 사항을 적용하여 master/main 브랜치로 병합할 수 있다. 

 

브랜치를 병합하려면 변경 사항을 받을 브랜치로 전환하고 다음 명령을 실행해야 한다.

 

git merge [branch-name]
# 지정된 브랜치를 현재 활성된 브랜치로 병합

 

여기서 우리는 branch 'test'에 있기 때문에 git checkout 명령어를 통해 master 브랜치로 전환해야 하며 git merge 명령어를 병합하고 싶은 브랜치 이름과 함께 실행해야 한다. (여기서는 'test')

 

 

이렇게 하면 test 브랜치에서 수행된 모든 작업(이 경우 style.css 파일 작성)이 master 브랜치에 병합된다.

 

 

 

7.4 병합 충돌

서로 다른 브랜치를 깃 머지(git merge)로 병합할 때 동일한 행에서 하나 이상의 파일이 변경되어 병합을 자동으로 수행할 수 없는 경우에서 일부 충돌이 발생할 수 있다.

 

 

 

이렇게 되면 git status 명령을 실행하여 어떤 파일이 충돌하는지 확인할 수 있다.

 

 

 

우리는 병합을 진행하기 전에 어떤 변경 사항이 발생해야 하는지 정의하거나 변경 사항을 검토하여 상호 호환되도록 충돌을 해결해야 한다. 이를 위해 GIT는 충돌하는 파일에 마커를 삽입하여 해결을 돕는다.

 

 

 

충돌을 해결한 후 수정된 파일을 다시 스테이지에 올려놓고 새로운 충돌 없는 버전을 커밋하고 git merge 명령을 다시 실행하면 문제 없이 성공적으로 병합할 수 있다.

 

---

 

8. 원격 저장소와 동기화

우리는 이미 로컬 저장소를 원격 저장소에 연결하고 모든 작업을 원격으로 동기화하여 최신 상태로 유지하는 것이 가능하다는 것을 알고 있다.

 

이를 위해 git push 명령어를 실행해 로컬 저장소로부터 모든 커밋을 원경 저장소로 보내야 한다. 그러나 먼저 원격 저장소를 구성해야 한다.

 

8.1 원격 저장소 구성하기

 

원격 저장소를 구성하는 것은 매우 간단하다. 우리는 이를 위해 Github를 사용할 것이다.

 

먼저 GitHub 계정에서 빈 저장소를 새로 시작해야 한다(이름을 선택하고 "Creating repository"를 클릭하기만 하면 된다) :

 

 

 

다음으로 원격 저장소와 로컬 저장소와의 관계를 다음 명령어를 우리의 로컬 저장소에서 실행해 구성해야 한다.

 

git remote add origin [remote-repository-url]

 

 

 

 

git remote -v : 로컬 저장소에 연결되어 있는 원격 저장소의 URL을 보여준다.

 

 

원격 저장소가 적절하게 연결되었다면, 우리는 우리의 로컬 브랜치 master/main의 이름을 git branch -m main 명령어를 통해  main으로 바꿔야 한다(당신의 로컬 브랜치가 이미 main으로 불리고 있다면 이 단계를 무시하라).

 

 

 

우리가 push 하는 로컬 저장소의 메인 브랜치를 원격 저장소의 메인 브랜치와 동일한 이름으로 유지하는 것이 중요하다.

 

 

마지막으로 위의 단계를 완료한 후 다음 명령을 사용하여 로컬 저장소를 처음으로 원격 저장소와 동기화할 수 있다:

 

git push -u origin main

 

 

 

 

git push-u origin main 명령을 실행할 때 GitHub credentials(사용자 및 액세스 토큰)을 입력해야 할 수도 있다.

 

만약 Github 액세스 토큰이 무엇인지 모른다거나 하나의 액세스 토큰을 설정하지 않았다면 여기를 클릭하라.

GitHub CLI를 사용해 인증을 구성함으로써 이 문제를 해결할 수도 있다. 여기를 클릭하여 방법을 알아보세요.

 

 

인증(Authenticating)을 한 후에는 git push 실행이 성공적으로 되어야 하고 로컬 저장소의 모든 커밋이 원격 저장소와 동기화된다.

 

 

 

 

 

 

8.2  처음 이후 Git push (git push)

 

위의 모든 단계를 거친 후에는 아래와 같이 별도의 파라미터 없이 git push 명령만으로 새로운 동기화를 할 수 있다.

 

 

 

 

 

이 경우 github CLI를 이용하여 git push 명령 실행에 필요한 인증을 건너뛰었다. 여기를 클릭하면 방법을 알 수 있다.

 

 

8.3  로컬 저장소 업데이트하기 (git pull)

 

분산된 원격 저장소를 사용하면 원격으로 변경할 수 있으므로 (원격 저장소에서 직접) 로컬 저장소가 오래된 상태일 수 있다.

 

이를 고려할 때, 로컬 저장소를 업데이트하고 원격 저장소에서 변경한 내용을 동기화하는 것이 매우 중요하며 로컬 프로젝트를 항상 원격 저장소에서 사용할 수 있는 최신 버전으로 유지해야 한다. 이 작업을 수행하기 위해 다음 명령을 실행한다:

 

 

git pull

 

 

새로운 README.md 파일이 우리의 원격 저장소에 직접 생성되어 우리의 로컬 저장소가 업데이트되지 않았다고 생각해보라.

 

 

 

위에서 언급한 것처럼 git pull을 사용하여 원격 저장소로부터의 변경 사항을 로컬 저장소 내에서 동기화할 수 있다. 

 

 

 

 

처음 7개의 행이 git pull 명령을 실행할 때 git fetch 명령의 return 값이다. 즉, git fetch 명령을 먼저 실행하지 않고 git pull 명령을 실행하면 GIT는 둘 다 함께 실행해 원격 저장소에서 업데이트를 찾아 로컬 저장소에 동기화한다.

git fetch -> 원격 저장소에서 업데이트를 가져오지만 로컬 저장소를 동기화하지는 않습니다(git pull이 필요함).

 

 

---

 

9. 결론

여태까지의 모든 것은 GIT이 프로그래머의 일상생활에서 필요한 버전 제어 시스템이라는 확신을 갖게 하며, GIT의 주요 명령과 사용법을 아는 것이 우리의 기술적 연공서열의 전환점이 될 수 있다는 점이다. 마지막으로, 로컬 및 원격 저장소를 동기화하고 업데이트하며 지금까지 배운 모든 것을 바탕으로 이 놀라운 버전 제어 시스템의 실용성을 계속 발전시킬 준비가 되어 있다.

 

---

10. 참조

• GIT's official documentation.
• [PT-BR] GIT: Mini course to get you started (learn in 45 minutes) - Codigo Fonte TV