아기개발자의 성장일기

[ 브랜치 목록 조회 ] master에서 develop, feature1, feature2 브랜치를 만들고 feature2 브랜치만 빼고 원격에 올려준 상태에서 진행하겠습니다. 1. local 브랜치 목록 조회 (with no flag) git branch 2. remote 브랜치 목록 조회 (with remote flag) git branch -r 3. 모든 브랜치(로컬 + 원격) 목록 조회 (with all flag) git branch -a [ 머지된 브랜치 목록 조회 ] feature1을 develop에 머지한 상황입니다. develop에 머지된 브랜치 목록을 조회할 때 git branch --merged develop feature2에 머지된 브랜치 목록을 조회할 때 git branch --me..

[1] Gitignore 파일 만들기 touch .gitignore [2] gitignore에 내용 입력 github.com/github/gitignore 여기서 각 환경에 맞는 코드를 복붙해서 위에서 만든 gitignore파일에 복붙해주면 된다. Xcode.gitignore랑 Swift.gitignore이 따로 있지만 Swift.gitignore에는 Xcode.gitignore 내용도 들어있기때문에 Swift.gitignore만 복붙해주면 된다. (참고로 python.gitignore에도 장고 관련 내용들이 들어가있다.) www.toptal.com/developers/gitignore 이 사이트에 들어가서 gitignore 내용을 구해도 된다. [3] 2번의 내용이외에 내가 무시할 것을 설정할때 git..

Remote 저장소를 local 저장소로 강제화(?) 시켜주고 싶을 때 다음 명령어를 사용합니다 저는 소스트리에서 reset 명령어로 local 저장소를 원하는 커밋까지 초기화시켜준후 이 명렁어를 통해 remote저장소도 local 저장소와 같아지게끔 강제 푸쉬시켰습니다 ( 좋은 방법인지는 모르겠지만, develop -> master로 머지하는 중 두개의 코드가 다른데 충돌이 안나는 (진짜 왜그러지ㅠㅠ) 경우 등 좀 복잡해져서 master를 거의 초기화시키고 develop을 머지시켜주는 상황을 만나서 쓰게 되었습니다 ) 참고 https://www.christianengvall.se/git-reset-origin-master-to-commit/

[ 사전 준비 ] develop 브랜치를 base로 feature1과 feature2를 브랜치를 만들어줬습니다. 그리고 develop에서 commit 3개를 해줍니다. feature1은 merge 커밋내역을 확인할 용도로 쓸 브랜치입니다. feature1에서 commit 2개를 해줍니다. feature2은 rebase 커밋내역을 확인할 용도로 쓸 브랜치입니다. feature2에서 commit 2개를 해줍니다. [ Merge ] feature1로 develop을 머지해보겠습니다. 트리가 이렇게 그려집니다. 줄기가 2개! (current branch를 feature1로 골라줬어요) [ Rebase ] feature2로 develop을 rebase 해보겠습니다. 트리가 이렇게 그려집니다. 줄기가 1개! (cu..

1. Rebase 사용 case: master 브랜치에서 branch1을 생성했다. (branch1의 base는 master의 마지막 커밋-) 근데 master 브랜치에서 어떤 VC의 이름을 바꾸고 싶어서 VC의 이름을 바꾸고 커밋했다 그러면 branch1이랑 master랑 VC이름이 달라진당---! 그 때 master 브랜치의 VC 이름바꾼 커밋으로 branch1을 rebase시켜준다 (branch1의 base는 master의 VC 이름 바꾼 커밋-) SourceTree에서 branch1을 현재 브랜치로 하고 원하는 커밋을 오른쪽 클릭하여 rebase 눌러주면 된다 :) + 아니면 merge master into 현재브랜치 해도 될 것 같다 이렇게 merge해주면 충돌이 날 것 같은데, unstaged..

브랜치 관리 전략 중 하나인 'git flow' 5가지 타입의 브랜치를 sourceTree-gitflow 에서 편하게 관리해준다 feature - feature브랜치를 따서 각 기능을 작업한 후, PR을 보낸다. develop에 merge되면 delete시키는 브랜치 develop - 승인받은 feature들만 merge되기 때문에 안전하고 굵직한 코드들이 담긴 브랜치 release - develop에서 바로 master로 가는 것이 아니다. 중간다리 역할을 해주는 브랜치 ( develop -> release -> master ) hotfixes - 급히 수정해서 출시해야할때 사용하는 브랜치 master - 출시용 브랜치 * 설명 처음에는 master와 develop 브랜치가 존재합니다. 물론 devel..