📘 Git & Git Hub

[meɪ]·2021년 8월 17일

3. Today I Learned. Basic

목록 보기

2/11

Preface

📌 개발 공부 1개월 차인 to-be 개발자의 자습 블로그🙂ﾠAug 15 ~ 21, 2021

현재 상태
멘붕의 연속. terminal 화면이랑 명령어도 아직 안 익숙한데 Git 명령어로 작업물을 관리해야 하다니...
지금은 개인 작업물이지만 머지 않아 team project를 하게 될 텐데 이때 절대 실수하면 안 된다......ㅜvㅜ

Git & Git Hub

➕ afterthought

이 역시 손에 익으면 별 게 아니게 될 것이도다... 누가 너더라 해커 하라는 거 아니잖아. 기운내라 짜식아
도와주신 분들 없었으면 난 어떻게 됐을까.

1. intro

Git은 VCS(Version Control System)을 위해 사용되는 주요한 tool이다.
push만 잘 해두었다면 작업물을 원하는 순간으로 되돌릴 수 있다.

centalized version control이 아니라 distributed version control이기 때문에 작업자들이 server 안정성의 영향을 덜 받으면서 작업할 수 있고, offline에서도 작업할 수 있다.
어쨌든 작업물은 server에 보관되는데, 대표적인 server가 Git Hub이다.
Git으로 관리한 작업물을 Git Hub에 올리고 협업 관계자와 소통할 수 있는데, 이를 요약하면 다음과 같다.

Git watches my files all the time and keeps my records.
Git allows me to keep alternative versions of the same file.
Git allows me to work with other people on the same file.
Git Hub is a Git provider in the cloud. I and my co workers can sync our gits into Git Hub.
There is a lot of open source project from Amazon, Facebook, Airbnb, etc
※ git hub ≒ gitlab ≒ bitbucket

Git은 명령어를 기본으로 한 '명령어 program'이며 명령어는 git + 명령어 + 속성으로 작성한다.
Git 공식 homepage에서 documentation 하위에 있는 'Reference' menu에 명령어와 속성 값이 정리되어 있다.
terminal에서 git 명령어 + --h를 입력해도 명령어의 속성 값을 확인할 수 있다.

Git의 GUI pgrogram으로 SourceTree나 GitKraken을 쓰기도 한다. (나는 Fork!)

Git Hub에서 open source를 참고하기도 하고, 간단한 오타 수정부터 (흔히 '이삭줍기') 번역 혹은 오류 개선 등 내가 참여할 수도 있다.
유명한 open source는 PR을 할 때 template이 있는 경우가 많다.

2. setup

ﾠﾠ1) terminal에서 git --version을 입력했을 때 version이 나오면 이미 Git이 설치되어 있는 것
ﾠﾠﾠﾠ만약 없다면 공식 homepage에서 download
ﾠﾠ2) Git을 설치하면 Git에 대한 모든 환경 설정이 .gitconfig file 안에 저장되므로 terminal에서 git config --list라고 입력하면 Git의 모든 설정 확인 가능
ﾠﾠ3) editor에서 줄바꿈을 할 때 운영체제에 따라 호환이 되지 않아 git history나 git blame 명령어에서 문제가 있을 수 있므로 git config --global core.autocrlf input 입력
ﾠﾠ4) git init으로 Git 초기화 / 시작
ﾠﾠﾠﾠGit을 초기화하면 기본적으로 master branch가 생성됨
ﾠﾠﾠﾠmaster branch가 commit한 걸 관리하는 것임
ﾠﾠ5) project directory에서 ls -al 하면 '.git'이 나오는데 이는 Git이 해당 project를 관리하고 있다는 의미이고, .git은 숨겨진 file임
ﾠﾠﾠﾠls라고만 하면 숨겨진 file은 나오지 않음
ﾠﾠ6) rm -rf .git 하면 Git이 삭제되어서 더 이상 Git project가 아니게 됨
ﾠﾠ7) 현재 file의 상태가 궁금하면 git status

3. workflow

summary
- working directory
  : 내가 작업하고 있는 file
  - git init
  - git commit -m "first commit"
  - git branch -M main
  - git remote add origin https로_시작하는_git_저장소_주소
  - git push -u origin main
local
- working directory
  : 내가 작업하고 있는 file
  - untracked : git init을 안 해서 Git이 track하고 있지 않는 자료
  - traked : Git이 track하고 있음
    - unmodified : 이전 version 이후 수정 이력이 없는 file이어서 staging area로 이동될 수 없음
    - modified : 이전 version 이후 수정 이력이 있는 file이며, 이런 file만 staging area로 이동될 수 있음 (git add . 혹은 git add file명.확장자를 입력해 staging area로 이동)
      - git add *는 모든 file을 staging area로 옮기는 명령어인데, 만약 이 명령어를 입력하기 전에 수정 이력이 있는 file을 삭제하면 git add *를 입력해도 수정 이력이 있는 나머지 file들이 staging area로 옮겨가지 않음. 이때 git add .를 입력하면 삭제되지 않은 나머지 file들이 staging area로 이동됨
      - 변동 사항이 있어도 staging area로 옮기고 싶지 않다면, echo file명.확장자 > .gitignore 명령어로 해당 file을 .gitignore file에 추가하면 됨
        ※ create-react-app을 설치하면 .gitignore file이 자동으로 생성되며, 이 안에 기재되어 있는 내용은 Git이 track하지 않도록 하는 장치임
      - 어떤 file의 내용이 어떻게 수정되었는지 알고 싶다면 git diff 입력, 그 중에서도 staging area에 있는 내용만 보고 싶다면 git diff --staged 혹은 git diff --cached 입력
      - git diff --staged 명령어는 변경 내역을 terminal에서 볼 수 있는데, 이 내용을 editor에서 보고 싶다면 git config --global -e을 입력해서 [diff] tool = vscode [difftool "vscode"] cmd = code --wait --diff $LOCAL $REMOTE를 작성한 후 저장, 다시 terminal에서 git diftool 혹은 git difftool --staged 입력
- staging area
  : 어느 정도 작업하다가 version history에 저장할 준비가 되어 있어서 file들을 옮겨놓는 곳
  - git add로 staging area로 이동
    - 한 줄, 한 줄씩 staging area로 이동시킬 수도 있음
  - git rm --cached file명.확장자로 다시 working direcotry로 이동
  - git commit은 commit 명령어인데 이것보다는 git commit -m "commit message"를 더 많이 사용
  - 모든 작업물을 한 번에 commit하고 싶다면 git commit -am "commit message"
  - commit 내역을 보고 싶다면 git log
    ※ Git 전반에 해당되는 내용이지만, 특히 commit message는 조직마다의 convention이 있으니 그 규칙을 따를 것
- .git directory (혹은 .git repository)
  : version의 history를 가지고 있음
  ﾠcommit으로 새 version을 만들어 .git directory에 올리고, checkout으로 원하는 version으로 돌아갈 수 있음
  - verison에 담겨있는 정보
    - 각각의 commit엔 snapshot된 정보를 기반으로 고유한 hash code가 부여되는데, 이를 통해 version 관리 가능
      - 변경 사항만 저장하는 delta base가 아니라 project 전체를 저장하는 snapshot이기 때문에 다른 version의 project로 이동할 수 있는 것임
    - commit에는 message뿐만 아니라 누가 언제 commit 명령어를 사용했는지 기록되어 있음
  - commit들은 일종의 history 창고이기 때문에 너무 큰 변동 사항을 한 번에 commit하는 것도, 너무 사소한 변동 사항을 자주 commit하는 것도 지양하고 Git 사용 목적에 부합할 수 있게 의미 있는 작은 단위를 commit해야 함
  - commit message에 사용되는 Init, Add, Fix 등의 양식은 현재형으로 작성
  - commit할 땐 commit message에 해당하는 내용만 담아야지, commit하는 김에 다른 작업도 포함해버리면 review할 때 혼선이 오기도 하고 history 관리도 어려움
remote
- push로 remote에 보냄
- pull로 remote에 있는 거 받아옴

결국 다음과 같은 이유로 Git을 사용해 작업물을 관리하는 것이다.

mostly common used
free
open source
lightning fast
work offline
undo mistakes
easy and fast branching/merging

4. git flow

1) git clone

pwd // 현재 위치 확인
cd desktop
cd <project folder> // folder를 만들고 싶으면 mkdir <folder명>
git init // 이 위치에서 git을 사용할 수 있도록 초기화/시작
git status // 현재 상태 확인
git clone <Git 주소> // 혹은 git remote add origin <Git 주소>로 원격 저장소 추가
// git clone은 remote의 code가 local인 나에게 들어온 것
ls // directory와 file 확인
cd <merge받은 directory 이름> // file을 생성하고 싶다면 touch <file명.확장자>
.code // 다른 terminal에서 code 입력하고 있었으면 이 명령어로 editor로 이동, 'cmd + J'로 editor의 terminal tab 열기
npm install
// master를 main으로 변경하고 싶다면 git branch -m master main
git branch // branch 상태 확인
git branch <feature/내가작업중인기능> // branch 생성 ex. feature/login
// branch가 특정 시점부터 새로운 시공간이 만들어져서 (like 평행 우주) 각자의 작업이 서로에게 영향을 주지 않으며, <feature/내가작업중인기능>은 작업자끼리 약속한 이름임
// ※ 다른 기능 작업할 거면 git checkout main 후 git branch <feature/작업할기능>으로 branch 이동 및 생성하는 것이 선행되어야 함

clone 받은 후 모든 작업은 brnach를 생성해서 그 위치로 이동하여 진행해야 한다.
main에서 하면 안 된다.

2) git push

push하기 전에 현재 위치를 확인해야 한다. main (master) branch에서는 작업도 하면 안 되지만 push는 더 하면 안 된다.

git add . // 특정 파일을 staging하기 원한다면 git add <file명.확장자>.
// git commit은 commit message가 여러 줄일 때 사용하고 보통은 아래의 명령어로 commit함
git commit -m "<commit meassage>"
git push origin <feature/개발중인기능>
git log // commit 현황 확인

commit을 여러 줄 쓰고 싶다면 vi 하고 i 눌러서 작성 → ESC → :wq로 commit message를 저장하고 밖으로 나온다.
commit 작성 양식은 조직에 따라 다르다.

분류 : 한줄 제목
- 구현 내용 상세 설명 1
- 구현 내용 상세 설명 2

Add : layout이나 기능 추가
Remove : 내용 삭제 (folder나 file 삭제)
Modify : 수정 ex. JSON data의 format 변경, button 색깔 변경, font 변경 등)
Fix : bug/오류 해결
Refactor : code refactoring (review 반영, 스스로 refactoring, 중복/불필요한 code 제거, 성능 개선 등)
Docs : 문서에 관련된 수정 작업 (README.md 등)

3) pull request

"remote의 master(main) branch야, 나 준비돼서 merge 요청했으니까 당겨줘."의 의미이다.
Git Hub에서 PR을 작성하면 되는데, 이때 convention을 준수해야 한다.

4) git pull

지금까지 한 거 commit하고, remote main에서 merge된 거 pull 받고, local에서도 merge를 해야 team 작업물을 최신화할 수 있다.
conflict 해결도 마찬가지 과정이다.

git checkout main
git pull origin main
git checkout feature/작업중인기능
git merge main
git add .
git commit -m "Fix: conflict 해결"
git push origin feature/작업중인기능

main이 많이 진행된 상태에서 branch가 너무 예전 상태이면 conflict 생기니까 main을 먼저 pull 받고 branch를 push하는 게 conflict가 덜 생긴다.
merge 후엔 내가 하던 작업물을 삭제해도 된다.

git log --graph --all --decorate로 merge 현황을 시각적으로 볼 수 있다.