[git] git의 상황 별 프로세스

# 1. Git 이란 무엇인가?

• ✔️버전관리를위한 소프트웨어

  • 버전관리?
  • 소스 하나 또는 묶음을 하나의 버전으로 간주하여 관리
  • 프로젝트 어떤 부분도 겹쳐쓰지 않게 프로젝트 변경을 관리
  • 파일/폴더를 추가/수정/삭제하여 사람이 직접 묶음을 버전으로 관리
  • -> ex. 최종.ai, ㄹㅇ최종.ai, 이거진짜최종.ai, 하이게진짜.ai … 이렇게 여러버전을 저장할 필요 없이, 저장하면 이전 file 위에 overwrite하거나 여러 version으로 나누어 저장함

• ✔️분산저장소

  • 개발 협업을 위해 사용
    -같은 모듈을 개발하더라도 소스를 서로 공유하면서 개발
    -전체 개발 소스를 공유하며 개발파트를 나누어 공유

• ✔️GitHub는?
  : Git 저장소를 직접 설치하지 않고, GitHub을 통해 사용 가능

  • GitHub-fork : 다른사람의 저장소를 가져와 제 저장소로 만들어놓는 기능
  • 오픈소스를 pull / commit 하여 사용가능

 

2. 깃의 동작 원리

git은 4가지 객체로 구성된다.

: blob, tree, commit, tag

1. blob : 파일의 내용을 담음
2. tree : 디렉토리의 파일명/내용에 해당되는 블락의 정보
3. commit : commit 정보
4. tag : branch와 달리 특정버전 위치에 대해 나중에 찾아갈 수 있도록 이름을 지정해놓은것 뿐!

 

3. Git branch

: 버전들을 묶어서 branch 라고 표현
-> branch는 왔다갔다하며 각각에 대해 내용을 변경, 버전관리

• default branch : master //git branch 명령어로 현재 branch 확인 가능
• 내 컴퓨터 내에 있는 branch : local branch
  외부 서버에 있는 branch: remote branch

branch 생성

$ git branch pong
$ git branch
    pong
    * master
$ git checkout pong
Switched to branch 'pong'
$ git branch
    * pong 
    master

/////////////////////////////

//위를 한꺼번에 하려면,
$ git checkout -b pong

 

4. Git 용어

• 저장소(Repository) : 프로젝트가 live 할 수 있는 디렉토리/저장공간
• 버전관리(Version Control) : 깃의 주목적. 프로젝트 히스토리의 모든 시점의 ^스냅샷^을 유지하므로, 결코 잃어버리거나 겹쳐쓰지 않을 수 있다. 겹쳐쓰면 오히려 에러
• 커밋(Commit) : commit시 그 시점 repo의 ^스냅샷^을 찍어, 프로젝트를 이전의 어떠한 상태로든 재평가/복원가능한 체크포인트를 가질 수 있다.
• 브랜치(Branch) : 메인 프로젝트의 branch off -> 자신이 변경하고싶은 부분을 수정하여 새로운 버전을 생성 -> 프로젝트의 메인 디렉토리인 master에 branch를 다시 merge.

 

5. 주요 명령어

• git init : 깃 저장소 초기화. 초기, 저장소나 디렉토리 안에서 이 명령을 실행한다.
• git config : configure Set up Git - GitHub Help
• git help : git help init 등 깃의 명령어를 사용/설정하는핵심적인 명령어들을 보여준다.
• git add
  • index(=stage area, tree구조)에 object이름과 실제 파일이 추가되고(tracked) objects에 blob타입으로 파일내용이 추가됨
  • git add . 시 전체 파일이 staging 상태로 변하며, tracked 가능한 상태가 된다.
  • 레포에 새 file을 추가하지는 않지만, 깃이 새 file들을 지켜볼 수 있게 함! “스냅샷”에 포함된다.
• git pull : local pc에서 작업할 때, 작업하고있는 저장소의 최신버전을 원할 떄 깃헙으로부터 변경사항을 다운로드한다.

• 협업시 git push 하기 전 git pull 을 한 후 가져오자.

• git commit : 저장소의 “스냅샷”을 찍기 위해 입력한다. git commit -m “Commit Message"의 형식으로 사용한다.
• git push : 로컬에서 작업하고 본인의 커밋을 깃헙에서 온라인으로 볼 수 있기를 원하고,

• 협업시 풀 리퀘스트를 요구하기위하여 하는 작업. 이때 push log를 잘 작성하도록 하자.

• git status : 저장소 상태를 체크하는 명령어. 현재 어느 레포의 어떤 브랜치에서 작업하고있는지, staginge되어있는 파일들이 edit되었는지 등을 알려주는 효자스러운 저장소이다.

• workspace, index(stage) 파일의 내용과 최신 commit obj 사이의 차이를 비교하여 add, commit 할 게 없는지를 확인시켜줌

• git merge : 현재 branch에서의 작업 완료 후 master branch로 병합할 때 사용한다.
  : 여러 개발자가 각자 개발한 버전을 합치는 경우
  +서로 다른 branch 를 하나로 합치는 경우
• git rebase : git merge와 결과가 같으나, merge는 branch 분기를 그대로 두지만(두줄), git rebase는 분기된 것이 일렬로 합쳐진다(한줄)

• git rebase를 하면 조상 커밋객체(base)를 상대 브랜치의 최신 커밋객체(rebase)로 바꾼다.

 

config -> init -> add -> commit -> push

git config —global user.name “pongsoyun”
git config —global user.email “thdbstjdud@gmail.com” // 최초 1회 설정!(global)

mkdir ~/MyProject   // 로컬 디렉토리 생성 후
cd ~/myproject      // 디렉토리로 이동
git init            // 깃 저장소 초기화
git status          // 현재 상태 점검
git add example.cpp  // 현재 디렉토리의 example.cpp 파일 추가
git add .           // 현재 디렉토리의 모든 파일 추가
git commit -m “Add Example” // 커밋해서 "Add Example" 을설명으로하는 스냅샷을 찍는다.

git remote add origin https://github.com/pongsoyun/myproject.git // 로컬과 원격 저장소를 연결한다.
git remote -v // 현재 폴더의 로컬과 원격 저장소 연결상태를 확인(주소)
git push origin master // 깃헙으로 푸쉬

의 과정을 거쳐 푸쉬 완료 -> 팀원들의 feedback 후 pull request -> merge -> pull 하여 로컬의 레포를 최신의 것으로 유지

 

 

 

---

 

기본적으로 사용되는 것을 다시 정리해보면

git remote -v // 현재 위치한 레포와 연결된 깃헙의 url 
git status // 깃의 status를 확인. tracking(modified,,,)/untracking
git log // 깃 커밋등의 액션 로그 확인
git checkout -b feature/signup // feature/signup브랜치를 생성함과 동시에 체크아웃
// 바로 위 git checkout -b feature/signup과 동일한 코드
// git branch feature/signup // branch 생성
// git checkout feature/signup // 해당 branch로 체크아웃
git add . // 모든 파일 add (staging하게 만듬)
git commit -am "commit message" // 스테이징 상태의 모든 파일을 "커밋메시지"로 커밋
git push origin feature/signup // origin (remote 브랜치의 origin) 에 feature/signup 브랜치를 머지하고싶어욧!!

이런 프로세스로 하나의 푸쉬가 끝나게 된다.
이제 깃헙으로 고고~ 하여 풀리퀘(pull request) 보내면 끝!

 

---

 

 

cf

Files Status

• 포장 전인 파일들: Unstaged Files
• 포장하기로 한 파일들 : Staged Files
• 포장 완료 파일 묶음: Commit

• 새로운 커밋

.gitignore 이란?

• .gitignore 파일 내부에 올리고싶지 않은 파일이 있다면 기재한다. root 디렉토리에 생성해주어야한다! 깃이 알아서 제외한다. 착하다
•  

선 머지(Merge) 후 풀리퀘(Pull Request)

협업 시 매우 중요한 부분이다. 
Main 페이지를 다 만들고, dev branch에 feature/main branch를 합치려 할 때 -> 리뷰를 먼저 받고 합쳐야 함
“dev branch에 코드를 합치고 싶어! “
-> 로컬 작업 push
-> “변경사항 확인 플리즈 ㅎㅎ”
-> “Pull Request”
-> Files changed를 보고, 협업자들의 feedback
-> Merge pull request -> dev 브랜치에 합침