보통 회사들에서 git branch전략으로 git flow를 사용하는데 자세한 정보는 많으니 git flow에 대한 얘기는 패스하고 우리 팀에선 git flow를 기반으로 좀 더 깔끔하게 브랜치 관리를 하기위해 노력하는데 거기에 대해 얘기해볼까 한다 보통 팀들의 브랜치는 요런식으로 관리될 것이다 여러 브랜치들이 여기저기 머지되어있고 커밋히스토리도 - xx이슈 수정 - 오타수정 - pr리뷰 반영 - Merge branch 'feat/~~' into develop 등등 불필요한 커밋 내역들이 그대로 남아있다 우리팀에선 rebase와 squash 머지 전략을 적절히 사용하여 브랜치를 깔끔하게 사용하고 있다 github pr에서 머지를 할 때 3개의 옵션이 있다 1. 머지커밋 만들기 2. 스쿼시 머지하기 3. ..
Bisect버그가 발생했을 때 원인, 시점을 찾을 때 사용한다.$ git bisect start$ git bisect bad$ git bisect good $ git bisect bad---------------------------$ git bisect git bisect는 이진검색을 이용하여 버그 발생 시점을 찾아낸다. 해당 커밋에 에러가 없으면 $ git bisect good해당 커밋에 에러가 있으면 $git bisect bad 명령을 입력하면 된다.N개의 커밋이 있을 때, 1+log₂N번 이하의 테스트로 버그가 있는 커밋을 찾아낼 수 있다.
git에서 과거의 커밋을 되돌리는 방법은 두가지가 있다. Reset push를 하기 전 모든 commit을 초기화 할 때 사용reset한 commit 이후의 history가 사라지는 안전하지 않은 방법$ git reset HEAD^: 이전 하나의 커밋 상태로 돌아가기$ git reset HEAD~2: 이전 두번째 커밋 상태로 돌아가기--soft: 커밋만 되돌리고 싶을 때--mixed: 변경한 인덱스의 상태를 원래대로 되돌리고 싶을 때 (default)--hard: 최근의 커밋을 완전히 버리고 이전 상태로 복구$ git reset --hard ORIG_HEAD: 실수로 reset했을 때 Revert push를 이미 했을 때, 해당 commit만 초기화 하고 싶을 때 사용한다.모든 history가 남는 안전..
Stash커밋하지 않은 작업을 스택 영역에 임시 저장하는 기능stash가 필요한 경우는 다음과 같다 - 커밋을 하지 않은 작업이 있는데 다른 branch로 checkout하려니 충돌이 나는 상황 - 작업하기 전 상황을 실행시키고 싶은데 커밋이나 폐기하기 싫은 경우 $ git stash: 임시저장$ git stash pop: 가장 최신 stash를 불러온 뒤 저장소에서 삭제$ git stash clear: 모든 stash 삭제 소스트리에선 상단의 스태시 버튼을 눌러 임시저장을 하고 왼쪽하단의 스태시 목록에서 스태시를 적용하거나 삭제할 수 있다.
$ git rebase -i HEAD~3 $ git merge --squash TARGET_BRANCH Squashmerge할 브랜치의 커밋 이력을 하나로 압축한 별도의 커밋을 만들고 헤드 브랜치에 merge한다. 일반 merge와 다르게 하나의 부모커밋(헤드브랜치 기준)만 갖는다. rebase에 대한 내용은 여기를 참조-i는 interactiveHEAD~3은 3번째 전 커밋까지 (이전 하나의 커밋은 HEAD^) 해당 명령어를 입력하면vi에디터가 보여진다.pick은 해당 커밋을 사용한다는 거고squash는 이전 커밋에 같이 합친다는 내용이다.커맨드를 수정한 후 :wq를 누르면다른 vi창이 뜨면서 커밋메세지를 rewrite할 수 있다. 출처: http://meetup.toast.com/posts/39
새로운 이슈를 처리할 때 새 Branch를 생성하여 작업한 후 기존의 Branch에 병합하는 데 두가지 방법이 있다. Merge (병합)experiment라는 브랜치를 생성하여 작업을 함master로 checkout 후 merge함 $ git checkout master $ git merge experiment Rebase (대화형 재배치)experiment라는 브랜치를 생성하여 작업을 함experiment에서 master를 rebase함$ git checkout experiment$ git rebase master Merge Rebase 특징 - branch를 생성한 시점의 베이스를 기준으로 합병 - branch의 최종 결과만을 가지고 합병 - 지정한 브랜치를 베이스로 기준 삼아 합병 - 트리 그래프에..
git과 JIRA를 연동하면 JIRA 이슈에서 git history를 볼 수 있습니다. git profile에서 Developer settings를 선택합니다. New OAuth App을 선택합니다. Application name을 입력하고Homepage URL과 Authorization callback URL에 Jira Software URL을 입력합니다.※ URL은 lower case로 써야하며 Dashboard URL이 아닌 Base URL을 사용합니다. (https://myjiracloud.atlassian.net/) JIRA에서 Client ID와 Client Secret을 사용해야하기 때문에 페이지를 닫지 않는 것이 좋습니다. Applications를 선택합니다.DVCS accounts에서 L..
Git이란? - 협업을 위한 코드 공유 - 다양한 버전 관리 - 특정 시점 추적 - 변경 추적 Git Flow팀의 구성원들이 늘어나고 개발하는 feature가 늘어나면 그 복잡성과 충돌을 해결하기 위해 branching전략이 필요하게 된다.Master: 최종 release한 안정된 버전. tagging하여 관리.Develop: 다음 release를 위한 개발 중인 최신 빌드Feature: 특정한 기능을 위한 브랜치. develop 브랜치로 부터 가져오고 완성이 되면 다시 develop 브랜치로 merge함.Release: release 점검을 위한 브랜치. 다음 release까지 개발이 최종 완료되었다고 판단하는 시점에서 release브랜치를 생성하고, 그 후 bug fix는 release 브랜치에서 진..