Git 전략

• Master 브랜치에서는 언제든지 배포할 수 있는 상태를 만들어 놓음.
• Develop 브랜치 기준으로 배포 테스트.
• commit message를 쓸 때에는 내가 작업한 내용들을 적어놓을 것.

 

1. 주의할 명령어 3개(협업할 때 절대 쓰면 안 되는 명령어)

• 절대 같이 쓰는 브랜치에서는 쓰면 안 된다.
• 이 기능들은 남에 작업들을 돌려버리거나 커밋을 바꾸어버리는 행위이기 때문에, 이 명령어들은 혼자 쓰는 브랜치에서만 사용해야 만한다.
• push -f
• rebase
• reset —hard

2. Git의 life cycle

1) Untracked

• git이 파일을 관리하고 있지 않은 상태.
• 최초 add 후에 관리대상이 됨.

2) Unmodified

• 코드 저장이 끝난 상태
• Staged 상태에서 commit을 하면 unmodified 상태가 된다.

3) Modified 

• Unmodified 상태에서 코드를 수정하면 modified 상태가 된다.
• commit을 할 수없다. commit은 staged 상태에서만 가능

4) Staged

• commit이 가능한 상태(이제 코드를 저장해도 좋다는 의미)
• Untracked와 modified 상태의 파일을 add 하면 staged 상태가 된다.

3. Git branch 전략

1) Master

• 배포 가능한 master branch
• 보통 tag를 따서 태그로 배포함.

2) Develop

• 보통 작업할 때 기준이 되는 브랜치
• 개발 서버에도 평소에는 develop 기준으로 배포하여 테스트함.
• 생성 위치 : master

3) Hot fix

• 갑자기 서비스에 문제가 생겨서 고쳐서 배포해야 할 때
• 생성 위치 : master (그렇지 않으면 딸려 나감)
• Merge : master & develop

4) Feature

• 실제로 뭔가 기능(feature)을 만드는 브랜치
• 생성 위치 : develop
• Merge : develop (code review)

5) Release

• 새로운 기능들을 추가하여 배포하기 위한 브랜치
• 생성 위치 : develop
• Merge : master & develop

4. Pull Request(PR)

1) 상황 1 : conflict가 발생하지 않음

1. 그냥 이렇게 간단하게 할 수 있다. 하지만 현업에서는 fetch를 해줘서 내가 작업한 부분을 제외하고 다른 코드들을 받아와 준 후 commit 후 push를 해줘야 한다.
2. 즉,
   1. git fetch project/lamda, or git fetch develop
      1. 이렇게 적어서 최신 파일을 받아와야 한다.
   2. 만약 작업 전에 feature 브랜치로 이동했다면 상관없지만 그렇지 못했다면, 변경한 코드를 stash로 저장을 해두고 옮겨야 한다.
   3. git stash
   4. git checkout -b feature/b
   5. git stash pop
   6. git commit -am “message”
   7. git push origin feature/b
   8. 그 후 github에서 PR을 적는다. 

2) 상황 2 : conflict가 발생 > local에서 해결하고 다시 push

1. 같은 공간을 수정하고 둘 다 commit, push 한 경우.
2. 이때 PR을 만들면 Resolve conflicts 란 버튼이 뜬다. 그리고 이 버튼을 누르면 쉽게 해결이 가능하지만 추천하진 않는다고 한다.
3. local로 돌아가서 merge나 rebase를 통해서 해결을 해줘야 한다고 한다.
4. 그리고 만약 아래 merge나 rebase방법대로 했는데도 push가 되지 않는다면, push -f로 강제 푸시를 해준다.

 

5. Git 특징들

1) HEAD

• Head를 움직이면서 여러 버전의 코드들을 볼 수 있다.
  • 즉, A 브랜치에서 B 브랜치로 갈 때에 이 head를 움직여서 갈 수 있다.
• 지금 작업하는 로컬 브랜치를 가리키는 포인터.
• 현재 브랜치 마지막 커밋의 스냅샷

2) Git pull 충돌 시

1. 하나의 브랜치에서 서로 같은 작업한 후 commit 후 push를 했을 경우,
2. 나중에 push를 하면 충돌이 일어난다.
3. 그 후 git status를 치면, git merge —abort로 git pull을 취소해준다.
4. 다시 git status 확인 후 git pull로 치면 충돌이 일어나고,
5. 충돌이 나는 파일을 수정을 해줘야 한다.
6. 그 후 git add file_name을 쳐서 재 commit을 해준다. (그러면 git pull 충돌 해결)
7. 그 후 git log로 확인.

3) Branch 삭제 시 - 로컬에서 원격까지

• Git branch -d branch_name
• Git push origin —delete branch_name : 리모트 브랜치. 삭제
• Git fetch -p : 삭제된 리모트 브랜치를 로컬에도 반영 (반영이 안되어있을 시만)

4) q : (END) 창 종료 명령어 

5) Migrate GitHub to another hub.

• Git clone —mirror git_url ./migrate_dir_name
  • —mirror는 지정한 directory를 생성하면서 dir.git을 만든다. 그래서 여기 있는 파일을 다른 hub로 migration 할 수 있다.
• Cd ./dir_name
• Git push anotherhub_url —all
• Git push anotherhub_url —tags
• Rm -rf ./dir_name

6) release : tag

• 이 tag를 통해 배포를 하게 된다.
• 릴리즈를 하기 위한 브렌치 같은 것
• github에서 release를 만들면서 하면 편함.
• 방법
  • release 버튼 클릭
  • create & new release
  • tag name
  • 기준 branch : master
  • title and content

 

6. 여러 상황들

1) 전에 작업한 내용들을 한 브런치에 모아 두고 싶을 때

• git cherry-pick [hash value]
  • 이렇게 새로운 브랜치를 만들고 내가 원하는 작업물들을 하나하나 쌓아주면 된다.