[CodeIt] 07월 1주차

커밋 히스토리

• git log
• 현 시점까지 했던 모든 커밋 출력
• commit id, author, date, commit message 등이 나온다
• 더 깔끔하게 보고 싶다면
  • git log —pretty
• git commit 을 할 때, -m 없이 터미널에 입력하게 되면, vim 을 통해 commit message 를 남길 수 있다
• git history → commit 내역
  • 이때 HEAD 는 가장 새로운 commit 을 가르킨다
  • HEAD 가 가르키는 커밋에 따라 working directory 구성

최신 커밋 수정

• git add .
• git commit —amend

두 커밋간 차이 보기

• git diff {이전 commit id} {이후 commit id}

이전 커밋으로 reset

• git reset —hard {commit id}
• hard option → Head가 가르키는 repository 만 바뀜
• mixed option → staging area 도 바뀜
• hard option → working directory 도 바뀜

<aside> 💡 커밋할때 git tag [tag name] [commit id] 로 테그를 달 수 있다

</aside>

BRANCH

• 하나의 코드 관리 흐름

• branch 생성
  • git branch [branch 이름]
• branch 변경
  • git checkout [branch 이름]
• git branch → branch 들 출력
• git branch -d [branch 이름] → 삭제
• git checkout -b [branch이름] → branch 생성과 동시에 이동

Merge

• git merge master (premium branch 에서)
• merge conflict 가 발생 할 수 있다
  • 같은 부분이 변경되어 git이 어느 부분을 반영해야 하는지 사용자에게 물어본다
• merge 자체를 취소할 수 있다
  • git merge —abort
• 여러 파일에서 conflict 가 발생했을 경우, git status 로 충돌난 파일을 모두 확인 가능하다
• 처음 branch 를 원격 레포지토리에 올릴 경우 —set-upstream 옵션이 필요

Origin

git remote add origin <https://github.com/kyuri-dev/Math_Box.git>

• 위 코드의 의미는 리모트 레포지토리의 이름을 origin 이라는 이름으로 등록하겠다는 뜻

HEAD 는 사실 commit 을 직접적으로 가르키는 것이 아닌 브렌치를 가르킨다

 

 

 

 

 

• 이 상태에서 git push 를 하게 된다면?
  • push가 되지 않는다
  • 그렇기에 git pull 을 우선 → conflict 가 발생하는 부분을 로컬 레포지토리에서 보여준다

Git fetch

• 가져오기만 하고 merge는 하지 않는다
• 리모트 브렌치의 내용을 가져와 살펴본 후 merge 하고 싶을때 사용
• fetch 로 코드를 살펴보고 이상한 점이 있을 경우 해결방법
  • 잘못된 코드를 추가한 개발자에게 함수를 지우고 다시 올려달라고 하기
  • 잘못된 부분을 알아서 해결하고 다시 git push 하기

Git Blame

• 어떤 파일의 특정 코드를 누가 작성했는지
• git show [commit id] 를 통해 더 자세한 내용

이미 remote repository 에 올라간 커밋을 취소해야 한다면?

• git history
• git revert [commit id]

여러 commit 을 취소하고 싶다면?

• git revert [commit id]..[commit id2]

Git reset 을 한 뒤 돌아오려면?

• reset 을 한다고 commit들이 삭제되는 것은 아니다
• 그렇기에 이전 git reset [commit id]를 하게되면 돌아간다
• git reflog → 해드가 지금까지 가르켜온 commit 의 id

Git Rebase

• 커밋 히스토리 구조가 다르게 저장된다

Git Stach → working dir 에서 작업하던 내용을 git 이 따로 stack 에 저장해둔다

• git stash list 로 저장된 내용 확인 가능
• 최근 commit 이후 작업 내용은 모두 commit 으로 옮겨지고,
• working directory 내부는 다시 최근 커밋 직후의 상태로
• git stash apply [stash id] → stack 에 있는 내용을 다시 working directory 로 가져와 적용한다

잘못된 branch 로 작업중이 었다면?

• git stash 로 저장, branch 이동, git stash apply
• 적용 후에는, git stash pop [id] 로 삭제

필요한 commit 만 가져오는 명령

• version 2개의 commit 이 있는데, 이중 하나만 가져오고 싶을 경우,
• git cherry-pick [id]

여러 커밋을 하나의 커밋으로

• git reset —soft [id]
• git add .
• git commit

Folk

• Git 을 호스팅하는 서비스에서 제공하는 기능으로, git repository를 사용자의 계정으로 복사하는 기능
• 즉, 새로운 repository 를 생성하는 기능이다.
• 왜 사용하는가?
  • 오픈소스등의 프로젝트에서 코드를 수정할 수 있는 권한관리도 필요하기 때문

 

Github Flow

• 브렌치 전락으로, 핵심 브렌치로부터 작업 브렌치를 생성하고, pull request 를 통해 코드 리뷰 후 머지하는 방식이다
• FEATURE
  • 새로운 기능이나 수정 사항마다 별도의 브렌치를생성하여 작업해야 한다는 것
  • 해당 브렌치에서 작업 완료 후, 메인 브렌치로 머지

 

• 브랜치의 이름은 작업의 내용을 명확히 알 수 있게 직관적으로 지정하는 것이 좋다. 예시: fix/login-issue, feat/add-user-profile

• Git Flow - develop & feature branch
  • Github Flow 의 main branch 는 항상 배포 가능함을 보장해야 한다
  • develop branch 는 항상 배포가능해야 함을 보장하지는 않아도 된다
  • feature branch는 가능한 짧은 시간동안만 존재하는 것을 지향해야 한다
• Release Branch
  • develop branch 에서 생겨는 새로운 분기

CI/CD

CI → Continuous Integration

• 개발팀이 코드 변경사항을 중앙의 코드 저장소에 빈번하게 통합하는 과정을 의미
• 코드 변경사항이 통합될 때마다 자동화된 테스트가 실행되여 개발자는 코드에 문제가 있는 지 빠르게 파악할 수 있다
• 코드 변경 사항을 빠르게 검증하고 문제 발생시 즉시 해결하여 개발의 효율성과 코드 품질을 높이는 것

CD → Continuous Delivery & Deployment

• 코드가 언제든지 안전하게 프로덕션 환경으로 배포될 수 있는 상태를 지속적으로 유지하는 것.