본문 바로가기

Git

 (13)
git rebase -i https://wormwlrm.github.io/2020/09/03/Git-rebase-with-interactive-option.html Git Rebase --Interactive 옵션 알아보기 - 재그지그의 개발 블로그 대화형으로 Git 커밋 히스토리를 수정할 수 있게 해주는 Interactive 옵션에 대해 알아봅니다. wormwlrm.github.io 위 블로그로 redirect 하세요
rebase, pull --rebase [branch1] $ git rebase master 를 하게되면, 우리의 branch1 브랜치 앞과 공통조상 사이에 master 를 끼워넣는 rebase 를 하게 된다. 그러면 pull --rebase 옵션은 뭘까.. pull 은 fetch + merge 이다. 따라서 pull --rebase 는 fetch + rebase 이다. git pull --rebase 는 결국 git fetch 와 git rebase teamone/master 이 두 명령을 순서대로 실행하는 것과 같다.
squash 머지 한 브랜치에서 계속 작업할 경우 이 글의 작업 환경은 아래와 같이 되어 있다고 가정한다. Upstream : 원본 저장소 Origin : 원본 저장소를 내 레포에 Fetch 한 저장소 로컬 저장소 Remote(Upstream) 저장소에서 로컬로 가져와서 C1, C2, C3 를 작업했다. 이제 Origin 에 push 후, Squash merge 를 통해 Remote 저장소에 반영했다. 스쿼시 머지를 한 후, 이후 작업을 진행한다. $ git remote add upstream [원본 저장소 URL] // 로컬환경에 upstream 저장소 정보 추가 $ git fetch upstream [브랜치이름] // upstream 저장소의 브랜치 변경정보 가져옴 /* 작업 */ $ git add . $ git commit -m "C4" 이제 Re..
upstream vs origin 깃을 공부하던 중 upstream 과 origin 리모트 브랜치에 혼란이 생겨 기록한다. origin 브랜치는 우리가 git clone 을 하면 자동으로 origin/master 브랜치가 생기는 것에서 익숙한 이름이다. origin Git 서버의 리포지토리를 Clone 하면 Git은 자동으로 origin 이라는 이름을 붙인다. origin 으로부터 저장소 데이터를 모두 내려받고 master 브랜치를 가리키는 포인터를 만든다. 이 포인터는 origin/master 이라는 이름이며, 수정이 불가능하다. 그리고 Git은 로컬의 master 브랜치가 origin/master 를 가리키게 한다. 이제 이 master 브랜치에서 작업을 시작할 수 있다. upstream, downstream upstream 이란 상..
Rebase 한 브랜치에 다른 브랜치의 내용을 적용시키려면 흔히들 쓰는, 그리고 내가 지금까지 쓰던 명령어는 Merge 이다. Master 브랜치에 내 작업내용 PR 을 적용시키려면, Merge 명령어를 썼다. 그리고 Master 의 변경내용을 내 작업브랜치에 적용시킬때는 pull ( 원격 저장소의 내용을 가져오는 Fetch + Merge) 를 썼다. 오늘은 코드를 깔끔하게 병합할 때 쓰는 Rebase 라는 명령을 알아보도록 한다. 내가 깃을 이용한 협업과 gitflow라는 개념을 처음 알게 되었던 글은 우아한 형제들의 블로그였는데, https://techblog.woowahan.com/2553/ 우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그 {{item.name}} 안녕하세요. 우아한형제들 배민..
.gitignore git을 통해 관리될 필요가 없다고 느껴지면, .gitignore파일에 필요없는 파일의 형식을 지정해주어 커밋할 때 무시할 수 있게 된다. 나는 intellij, MacOs, Java를 이용하여 개발하고 있는데, 자바의 .class파일은 .java파일을 컴파일 시킨 파일로, 굳이 가지고 있을 필요가 없다. 또, intellij의 .idea, 이클립스의 metadata폴더는 개발자도구가 자동으로 생성하는 폴더로, 굳이 git으로 관리할 필요가 없다. 또 빌드를 통해 생성되는 jar, tar, zip, war등의 파일들과 .log의 로그파일, mac에서 사용되는 .DS_Store파일들도 git으로 관리될 필요가 없겠다. gitignore.io 라는 사이트에서 각 개발환경에 따라 자동으로 gitignore파일..
Commit Convention 1. new features, bug fixes, breaking changes의 세가지 changelog를 사용한다. 재량으로 바꿀 수 있지만 기본적인 골격인 이 세가지로 정한다. 2. 커밋의 변화를 찾고 있을 때 포멧의 변경(공백줄의 추가/제거, 들여쓰기), 세미콜론을 빼먹은 경우, 주석 같은 경우는 아래의 명령어를 통해 무시 가능하다. git bisect skip $(git rev-list --grep irrelevant HEAD) 3. 히스토리를 검색할 때 커밋 메세지로 정보를 더 명확하게 전달하여야 한다. 사전에 정한 컨벤션을 따르고, 어디가 바뀌었는지 무엇을 바꾸었는지 명시해야 한다. 4. 컨벤션 (): 모든 커밋 줄은 100줄을 넘어가면 안된다. 각각의 자리에 들어갈 내용은 아래에서 설명한다..
Git .gitignore 이용하기 로그파일, 빌드파일, 암호 같은 경우 원격저장소에 올리기 민감한 정보들이다. 이들을 올리지 않는 방법은 .gitignore을 이용하는 것이다. github에서 repository를 생성할 때 생성할 수도 있지만, 그냥 .gitignore이라는 파일을 만들고 그 안에 무시하고싶은 파일을 지정해주면 된다. .gitignore 는 표준 Glob를 사용하고 몇가지 패턴이 있다. # : 주석 * : 와일드 카드 *.log : 확장자가 log파일은 모두 무시 ! : 무시하게 한 파일을 다시 추적 !go.log : *.log로 log 파일은 무시하기로 했지만, 이 규칙을 무시하고 go.log는 staged에 올린다. / : path 표시 /module : 루트 디렉터리 아래 /module 파일을 무시. 그러나, us..

티스토리툴바