Git Life cycle

혼자 공부하며 git을 쓰면서 add => commit => push 만 쓰다 보니 이게 git의 Life cycle 인줄 알았지만 협업을 위한 git Life cycle은 생각보다 컸다.

Ⅰ. Git (init 부터 commit 까지)

1. Git의 시작

git init

명령어 해석 : 이 폴더 안에 변화되는 변경 사항 녹화를 시작하겠습니다.
git init을 하면 파일 내부에 .git파일이 나오면서 이력들을 수집하기 시작한다.

2. Git 상태 확인

git status

명령어 해석 : 어떤게 기록되고 있는지 보여드립니다.

물건 사기 전(commit) 장바구니 상태를 확인하는 느낌입니다.

3. 파일 수정 이력 기록 준비 : Stage에 파일 올리기 (장바구니에 담기)

git add 

git add . (현재 디렉토리에 있는 모든 내용들 다 집어넣겠다.)

4. 파일 수정 기록 : .git 안에 있는 파일에 commit 내역이 저장된다.

⇒ 장바구니안에 있는 물품 구매

git commit -m "메세지"

5. commit 이력 보기

git log

Ⅱ. Branch

브런치를 왜쓰는지?
예를 들어, 작은 사무실에 사장님과 함께 작업을 한다고 치자. (Master branch)
그런데 제안서를 쓰는 도중 혼자 집중해서 작업을 하고 싶어졌다. (계속해서 사장님이 보고 있기 때문)
그래서 방을 하나 만들고 (git branch feature/work)
방에 들어가서 (git checkout feature/work)
작업을 시작한다.
해당 방에서는 폭탄을 터트리든 이상한 짓을 해도 괜찮다.
방에서 작업을 마치고 사장님께 보고한다(PR :: Pull Request)

브런치는 기능단위로 딴다.

git branch feature/login     // 브런치 공간 만들기 (하지만, 현재 작업은 Master)
git checkout feature/login   // 브런치 이동 (이제부터 작업이 login 브런치에서 작업)

git branch                   // 현재 브런치 확인

이제 feature/login 에서 작업을 했고 gitHub로 올릴거다

git push origin feature/login

PR(Pull Request) : Master Branch에게 결재요청 ⇒ Master브랜치에 제가 만든거 추가해주세요.

정리

1. 최초에 리모트에 repo가 있었다..
2. git clone 으로 로컬에 repo 가 강림하시니
3. 마스터브런치 확인 후 내가 작성하려는 기능 feature/login 을 만든다 (git branch feature/login ⇒ git checkout feature/login)
4. 이제 feature/login 작업실로 들어간다.
5. 거기서 작업한다
6. 작업하고 add 날리고 commit 날리고 (여기까지 아직 로컬)
7. 작업 완료 후 remote에 있는 feature 브런치에 올려준다. git push origin feature/login
8. 검토 부탁드립니다 (PR 템플릿 작성) 올리기
9. 검토 완료 후 Master branch 에 Merge된다. (remote에 있는 Master브런치에 되었지만 아직 로컬은 모른다)
10. git pull origin master 를 통해서 코드 업데이트 된 내용을 로컬에서 받는다
11. 근데 feature/main 같은 다른 브런치들은 모르는데?
12. 그 브런치로 가서 git merge master 그렇다면 이제 모든 세상이 알게된다.

💡 절대 마스터브런치에서 작업하지 말것!!! Master 는 신성한 공간

git pull origin master   // 업데이트 된 내용을 쫙 받아온다.

git checkout feature/main // 브런치 이동
git merge master          //  해당 브런치에서 허브에 업데이트 된 내용 머지 시키기