유닛테스트 : 내 함수(클래스)를 테스트하는 코드를 짜는 것
매우 귀찮다.
잘 짜두면 언제든지 자동화시킬 수 있다.
대부분의 버그는 유닛테스트에서 잡고 들어간다.
유닛테스트를 잘 돌릴 수 있게 코드를 잘 짜야한다. 그게 잘 짠 코드이다.
코드를 짤 때 유닛테스트를 돌릴 수 있게 짜야한다.
유닛테스트를 짜놓고 시작하면 코드를 짜면 더 좋은 코딩 아닌가? = TDD
but 현실적으로 어렵다.
리베이스는 위치 바꾸기
하나로 합치는건 스쿼시
리베이스는 마스터에서 풀 땡기자마자해도되고 작업하던 브랜치에서 해도 된다.
[master 에서 할 때]
git rebase -i master feature/pjh
-i 뒤 master의 의미는 뭘 기준으로? 최신 마스터의 기준으로!
그리고 뒤에 피쳐는 마스터 뒤에 해당 브랜치를 선언해주면 된다.
혹스 master가 아니라 브랜치에서 리베이스하고 싶다면 해당 브랜치에서
git rebase -i master
까지만 쓰면 된다.
pick은 커밋을 선언한 시점
squash는 최초 커밋을 기준으로 그 다음커밋까지 계속 녹인다.
pick 커밋번호 커밋설명
s 커밋번호 커밋설명
s 커밋번호 커밋설명
기준을 잡는게 어렵다면 그냥 맨 처음 커밋을 pick으로 두고 나머지를 squash로 녹여주자.
콘플릭트가 나면 수정을 해주고 다시 add를 해준다.(여기서는 commit)을 안한다.
rebase과 squash는 add만 해주면 된다. rebase와 스쿼시는 커밋들을 하나로 만든것이다.
git rebase --abort 는 리베이스 중단 쎄하면 일단 abort 쓰자.
git rebase --continue 는 이제 그 다음 방법으로 넘어갈 수 있다.
그리고 저장한다
커밋 로그를 보면 이제 세개를 하나로 줄인 커밋 하나만 남겨져있다.
마지막에 보면 실행된 브랜치로 체크아웃 이동이 되있다.
푸쉬까지 올렸는데 수정사항이 생기면?
그럼 다시 수정을 하고 add하고 commit을 하고서 다시 리베이스 해야한다.
master에서 pull 받고서 리베이스하면된다.
그리고서 push 하면? 에러가 난다. 너가 정하라고
git push origin 브랜치이름 -f
라고 하면 push를 억지로 밀어넣는다.
commits에 commit 갯수가 1이 아니면 안된다.
