TIL 210729 - 가장 대중적이고 강력한 git basic

9일 

어제는 리눅스 오늘은 깃!

버전 관리

커밋, 머지, 풀, 푸쉬 나오려나.

자 볼께요.

 

Github, GiLab, Bitbucket

 

버전관리 시스템 시작!========

버전관리 시스템

Achievement Goals

• Git의 환경설정을 할 수 있다.
• 버전 관리 시스템의 필요성을 이해할 수 있다.
• Github과 Git의 관계에 대해 이해할 수 있다.
• Repository에 대해 이해할 수 있다.
  • Local Repository와 Remote Repository의 차이를 이해할 수 있다.

 

버전 관리를 사용하는 이유

Git이란 개발자의 코드를 효율적으로 관리하기 위해서 개발된 '분산형 버전 관리 시스템'

Git으로 관리되는 파일은 Github, GitLab, Bitbucket 등의 여러 가지 원격 저장소를 이용해서 백업과 협업이 가능

 

특정 시점에 생성된 백업 복사본을 스냅샷이라고 하는데요.

이렇게 하나 하나 스냅샷을 만들어 주는 작업을 commit이라고 합니다.

Git에서는 이렇게 소스 코드가 변경된 이력을 쉽게 확인할 수 있고, 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 되돌아갈 수도 있습니다. (좋네, 자 이제 작동법과 사용법을 배우면 되겠네!)

 

Github은 Git Repository를 관리할 수 있는 클라우드 기반 서비스, 개발자들의 SNS

Github은 내 컴퓨터에서 Git으로 관리하는 프로젝트를 올려둘 수 있는 사이트

 

 

Git Repository

 

내가 작업하는 소스 코드 폴더가 버전 관리를 받게 하기 위해서는 내 폴더를 Git의 관리 아래에 두어야 하는데요. Git으로 관리되는 폴더를 Git repository 라고 합니다. Git repository 는 Remote Repository와 Local Repository 두 종류의 저장소를 제공합니다. 작업할 때는 Local Repository에서 할 수 있고 내가 작업한 코드를 공유하려면 Remote Repository에 업로드해 여러 사람이 함께 공유할 수 있습니다. 다른 사람이 Remote Repository에 올려 놓은 소스 코드를 내 Local Repository 로 가지고 올 수도 있습니다.

 

React 프로젝트에 contribute을 하기 위해서는 먼저 React 원격 저장소를 내 원격 저장소로 가지고 오는 작업이 필요합니다. 그 과정을 Fork 라고 합니다.

 

코드를 수정하기 위해서는 내 컴퓨터로 가져오는 작업이 또 필요합니다. 그 과정을 Clone 이라고 합니다. Remote Repository에 있는 코드를 Clone 해서 내 컴퓨터로 가지고 올 수 있어요.

 

이 변경된 내용을 commit을 통해 저장해 준 뒤, Remote Repository에 반대로 올려주는 작업이 필요합니다. 이 과정을 Push 라고 합니다. Local Repository에 기록해 놓은 commit을 Remote Repository로 업로드할 수 있습니다. 이렇게 Push를 완료하고 나면 GitHub에는 Pull request라는 기능이 있어서, 내가 제안한 코드 변경사항에 대해 반영 여부를 요청할 수 있습니다.

 

가져올 때 순서

fork - clone

돌려줄 때 순서

commit-push-pull(from remote or from local)

 

이제 이해를 했네

Local Repository에서 변경된 사항을 Remote Repository 에 업로드 하기 위해서는 Push를 사용했었죠? 그런데 반대 상황도 발생할 거예요. Remote Repository에서 변경 사항이 있을 때 Local Repository 로 가져오는 Pull 작업도 가능합니다

 

전세계 개발자들 대다수는 Git을 사용하고 있어요.

그리고 상당수의 기업들에서 IT개발자들을 채용할 때 개인 Github 계정을 요청하기도 합니다.

작업한 프로젝트들을 내 Github 계정에 올려 놓으면 개발자 구직을 할 때 포트폴리오로도 활용할 수가 있습니다.

 

버전관리 시스템 끝!========

 

개발자 도구 깃  설치 시작과 동시에 끝!

Achievement Goals

• 자신이 사용하는 OS에 git 설치하는 방법을 익히고 실습한다.
• git --version 명령어로 터미널에서 git이 설치되었는지 확인할 수 있다.
• CLI 환경에서 git 명령어를 입력할 수 있다.

Advanced Challenge

• 터미널로 원격 서버에 접속하고 git을 설치하고 삭제 후 다시 설치할 수 있다.

git 삭제 순서

우선 패키지 매니저 homebrew를 사용함

brew list로 설치된 패키지 목록 확인

brew uninstall git으로 바로 실행

목록 확인하니 없음

억 그런데 git 이라고 치면 설치된 것으로 나온다.....멘붕...

 

나중에 다시 알아보자.

 

Git 환경설정

이건 중요하다. 할 때마다 늘 새롭다.

 

Git을 이용할 때에 필요한 환경 설정은 사용자 정보와 에디터 설정입니다.

사용자 정보

Git을 설치하면 가장 먼저, 사용자 이름과 이메일 주소를 설정합니다. 설정에 기록된 사용자 이름과 메일 주소를 앞으로 진행할 Git 커밋 내역에 기록합니다.

터미널 화면에 다음과 같이 입력하세요. (나의 사용자 이름과 내 이메일 주소를 대신해 Github에 등록된 사용자 이름과 이메일 주소를 사용하세요.)

 

$ git config --global user.name "나의 사용자 이름"

$ git config --global user.email "내 이메일 주소"

 

예를 들어 김코딩의 경우라면 다음과 같이 입력할 수 있겠죠.

$ git config --global user.name "kimcoding"

$ git config --global user.email "kimcoding@example.com"

• --global 옵션으로 설정하면, 사용자 홈에 저장되므로 git을 설정할 때 처음에 단 한 번만 입력해도 됩니다.
• 나중에 github의 사용자 이름이나 이메일을 변경한다면, 이 명령어를 다시 입력해야 합니다.
• 만약 여러 프로젝트를 진행하고 있어서,
• 프로젝트마다 다른 사용자 이름과 이메일 주소를 사용하고 싶으면 --global 옵션을 빼고 명령을 실행할 수 있습니다.

에디터

Git에서 커밋 메시지를 기록할 때, 특히 merge commit 확인 메시지가 나올 때 텍스트 에디터가 열립니다.

기본값으로 텍스트 에디터 vi가 열리는데, vi 에 익숙하지 않다면, nano로 변경하는 편이 좋습니다.

$ git config --global core.editor nano

 

이제 환경설정은 모두 다 끝났다.

정말 git 조작해보자. 오래 기다렸다.

 

git 조작 시작!====

Achievement Goals

• 상황에 따라 Github의 기능과 Git 명령어를 사용할 수 있다.
  • Fork
  • clone
  • status
  • restore
  • add
  • commit
  • reset
  • log
  • pull
  • push
  • init
  • remote add
  • remote -v
• Git의 세 가지 영역 및 상태를 이해할 수 있다. (Committed, modified, staged)
• Remote Repository를 페어와 공유하며 협업을 할 수 있다.
• 충돌이 발생했을 경우 해결할 수 있다.

Advanced Challenge (optional)

• Git Repository의 commit되지 않은 변경 사항을 취소할 수 있다.
  • reset HEAD <file>
  • checkout -- <file>
• 협업을 위한 git 개념을 이해할 수 있다.
  • branch, merge의 개념
  • remote repository에서 origin과 upstream의 차이점

 

혼자 작업 workflow

혼자 작업하면서 Git으로 버전 관리 기능 활용하기

전체적인 흐름은 다음 그림과 같습니다.

1. Remote에 있는 다른 Repository에서 Fork를 해서 Remote에 있는 내 Repository에 가지고 옵니다.

 

2. 그리고 이 코드를 수정하기 위해서는 내 컴퓨터로 가져오는 작업이 또 필요합니다. 내 컴퓨터에서 작업을 하기 위해서 clone을 합니다.

 

3. 이제 내 컴퓨터의 작업 공간 (work space) 에서 작업에 들어간 파일들을 git의 관리 하에 있는 상태로 올려줄 수 있습니다. 이 영역을 staging area라고 말합니다. 즉, staging area에 들어오지 않은 파일은 unstaged 혹은 untracked file이라고 말하며, staging area에 있는 파일들은 staged 된 파일이라고 말할 수 있어요. 이 부분에 대해서는 나중에 더 자세하게 알아봅시다.

 

4. staging area에 들어온 파일들은 commit이 가능합니다. commit을 하고 나면 내 remote repository에 push 해서 commit 기록을 remote 에도 남겨줄 수 있습니다.

 

5. push를 완료한 후 이제 remote의 원래 레파지토리에 pull request를 보내면 Remote Repository로 내가 수정한 코드를 업로드할 수 있습니다.

 

여기서 중요한 팁이 있는데요. 터미널 창을 꼼꼼히 읽어 보면 힌트를 다 주고 있습니다! 현재 어떤 파일이 어떤 상황에 있는지 표시하고 있습니다. untracked files (git의 트래킹 되고 있지 않은 파일들) 목록에는 mypage라는 파일이 있고 이 파일을 Commit 하기 위해서는 git add 명령어를 통해서 commit 할 수 있다고 나오고 있습니다. mypage.js 파일은 '변경된 상태'(modified)네요. 그런데, changes not staged, 즉 staging area에는 들어가지 않았어요. 이 시점에서 우리가 선택할 수 있는 행동을 안내하고 있습니다. [add] : add는 파일을 commit 할 수 있는 상태로 만들어 줍니다. 이에 대한 내용은 뒤에서 설명하기로 해요. [restore] : 변경사항을 폐기(discard changes) 하는 명령어예요. 이처럼 git status 를 통해 어떤 파일이 어떤 상태에 있는지, 그리고 해당 파일에 대해 어떤 행동을 할 수 있는지 알 수 있습니다.

git restore

마이 페이지를 열심히 구현하던 중 기존에 있던 코드들을 훑어 보니 코드 작성 방식이 나와 달라서 통일성을 해칠 것 같아요. 내가 작업한 코드를 싹 다 밀어 버리고 새로 작업해야 할 것 같습니다. 처음 Clone을 받았던 상태로 되돌리는 방법이 있을까요? 이 때 사용할 수 있는 명령어가 바로 아까 터미널에서 확인했던 restore입니다. commit되지 않은 Local Repository의 변경 사항을 폐기할 수 있어요. git restore mypage.js 명령어를 통해 Work space의 변경 사항을 폐기하고 다시 처음으로 clone 받아 왔던 상태가 되었습니다.

commit 메시지를 작성하기 위해서는 -m 옵션을 통해 코멘트를 작성할 수 있습니다. git commit -m ‘mypage 구현’ 이라는 메시지로 commit

 

참고로 commit 메시지 작성 방법에 대해서는 굉장히 다양한 기준과 컨벤션이 있기 때문에 좋은 commit 메시지를 작성하기 위한 기준을 구글링해 보시는 것을 추천합니다. 추천 링크 : https://chris.beams.io/posts/git-commit/

How to Write a Git Commit Message

 

 

git의 Local Repository에는 다음 영역들이 있습니다.

Untracked area는 Git이 관리하고 있지 않은 영역입니다.

Tracked area에 들어온 파일들만 Git의 관리를 받을 수 있으며, Tracked area 내부에서도 세 가지 상태로 나누어집니다.

그 세 가지 상태가 바로 Unmodified, Modified, Staged입니다.

 

Unmodified : 기존에 Commit했던 파일을 수정하지 않은 상태입니다.

Modified : 기존에 Commit했던 파일을 수정한 상태입니다.

Staged : commit이 가능한 상태입니다.

 

수정한 파일을 commit 하기 위해서는 staged area에 add 하는 작업이 필요합니다.

이 그림을 통해서 앞 페이지에서 본 터미널 내용을 다시 복습해 봅시다.

Changes to be committed라고 적혀 있는 초록색 파일은 staged 상태의 파일이며,

Changeds not staged for commit이라고 적혀 있는 빨간색 파일은 Modified 상태의 파일입니다.

그래서 add 명령어를 통해 tracked area에 들어간 파일을 수정하게 되면 다시 modified 상태가 되기 때문에

다시 add하는 작업을 통해 파일을 staged 해 주는 작업이 필요합니다.

 

git reset HEAD^ 이라는 명령어로 가장 최신의 commit 을 취소할 수 있습니다. 우리는 방금 올린 하나의 commit 만 취소하면 되기 때문에 git reset HEAD^ 명령어를 입력하는 것이 가장 적합하겠죠? HEAD는 연속된 ^의 shortcut 입니다. 예를 들어 HEAD3은 HEAD^^^와 같습니다. 즉 이 상황에서는 HEAD~1 명령어도 가능합니다. 추가적으로 hard, soft 옵션도 있는데 reset 에 대해서 더 공부하고 싶으시다면 git reset --hard vs --soft 등의 검색어로 구글링 한 후 실습해 보시는 것을 추천드립니다.

 

이 터미널 창을 종료하는 방법은 q 를 입력

 

현업에서 PR이라고 한다.

 

마지막으로

GitHub 웹사이트 상의 해당 Remote Repository에 Compare & pull request 라는 버튼을 눌려서

내가 작업한 것을 기재해준다.

 done!

함께 작업 workflow

전체적인 흐름

1. 내 컴퓨터에서 생성한 디렉토리를 init 명령어를 통해 Git의 관리 하에 들어가게 만들어 줍니다.

2. 내 컴퓨터의 Git 디렉토리를 Remote Repository와 연결시켜 줍니다.

3. pair의 변경 사항과 나의 변경 사항을 Remote Repository를 통해서 공유합니다. 

 

먼저 바탕화면에 weatherapp 이라는 디렉토리부터 하나 만들었습니다. 이 디렉토리는 내 컴퓨터에만 존재하기 때문에 버전 관리를 위해 먼저 Git Repository로 변환시켜 주고 싶습니다. 내 컴퓨터에서 내가 직접 만든 디렉토리를 Git의 관리 하에 들어가게 만들어 주는 명령어는 git init 입니다. 기존 프로젝트를 Git Repository로 변환하거나 새로운 Repository를 초기화하는 데에 사용할 수 있습니다. 이렇게 Local Repository가 생성되었습니다!

 

이제 내 컴퓨터의 weatherapp 디렉토리가 Git Repository로 변환되었어요.(와 좋은 기능이다.)

 

변환한 Local Repository를 Github에서 원격으로도 관리한다면 나중에 협업을 하기에도 편리하겠죠?

원격으로 관리하기 위해서는 Local Repository를 Remote Repository와 연결하는 작업이 필요합니다.

이 때 git remote add 명령어를 사용할 수 있습니다.

 

내 Github에 weatherapp Repository를 하나 만들고 그 Repository 주소를 git remote add origin 명령어 뒤에 입력함으로서 해당 Remote Repository와의 연결이 완료되었습니다. 명령어를 입력했을 때 터미널창에 나타나는 변화는 없습니다.

 

이번에는 origin이 아닌 다른 이름과 연결하고자 하는 상대방의 Repository 주소를 입력해 볼게요.

상대방의 Repository의 이름은 편의상 pair라고 짓겠습니다.

git remote add pair ‘주소’를 입력해 상대방의 Repository와 연결했습니다.

명령어를 입력했을 때 터미널창에 나타나는 변화는 없습니다.

 

페어가 서버 작업을 완료해서 weatherapp Repository의 master 브랜치에 작업한 코드를 올려 놓았다고 합니다. 작업한 내용을 받아와서 확인하고 싶어요.

 

git pull pair master 명령어를 통해 페어의 Remote Repository에 있는 작업 내용을 받아올 수 있습니다.

받아오는 내용은 자동으로 병합(merge) 됩니다.

 

이렇게 항상 문제 없이 수정 내용을 받아와서 자동 병합(merge)시킬 수 있다면 좋겠지만 개발을 하다보면 충돌 상황이 종종 발생합니다. 페어의 작업 내용을 받아오는 와중에 이 때 만일 페어와 내가 동일한 라인을 수정한 파일이 있다면 어떻게 될까요? 이 때는 자동 병합(merge)에 실패하게 되고 충돌이 발생합니다. 터미널 화면에서도 Merge conflict가 발생해서 Automatic merge에 실패했다고 알려주고 있습니다.

 

git status 명령어를 통해 어떤 파일이 충돌하고 있는지 확인할 수 있습니다.

 

충돌이 발생한 파일을 열어 보면 어떤 부분에서 충돌이 발생한 것인지 확인할 수 있습니다.

그리고 충돌이 일어난 부분은 하나 하나 직접 확인 후 수정이 필요합니다.

Accept Current Change를 클릭해서 내가 수정한 내용으로 파일에 반영할 수 있습니다.

Accept Incoming Change를 클릭해서 Remote Repository의 내용으로 파일에 반영할 수도 있습니다.

Accept Both Changes는 변경 사항 모두를 반영합니다.

위 4가지 옵션 이외에도 직접 파일을 수정해서 반영하는 방법도 있습니다.

수정을 마치면 병합 커밋(merge commit)을 생성해 주기 위해서 파일을 staging area로 추가해야 합니다.

 

 

충돌한 파일 수정을 완료했다면 Remote Repository에 업로드 하기 위해서 staging area에 파일을 추가합니다. Merge commit은 자동으로 Commit 메시지가 생성됩니다. (물론 메시지를 수정할 수도 있습니다.) git commit 명령어로 자동으로 생성된 commit 메시지를 남겨 보도록 하겠습니다. 그리고 Remote Repository에 Push 한다면 다음 화면과 같이 Merge branch ‘master’ of 라는 commit 메시지가 기록됩니다. Remote Repository로 push가 완료되었습니다!

 

Git Basic 끝!=====