Git의 rebase --interactive (또는 간단히 rebase -i) 기능은브랜치의 커밋 히스토리를 재정렬하거나 수정할 수 있는 강력한 도구입니다. 이를 통해 커밋을 수정, 삭제, 합치기, 분할하거나 순서를 바꿀 수 있습니다. 주요 명령어는 6가지 pick: 커밋을 그대로 유지합니다.reword: 커밋 메시지를 수정합니다.edit: 커밋을 수정합니다. 이를 선택하면 해당 커밋에서 작업을 멈추고 수정할 수 있습니다.squash: 이전 커밋과 합칩니다. 두 커밋의 메시지를 병합할 수 있습니다.fixup: 이전 커밋과 합치되, 커밋 메시지는 유지하지 않습니다.drop: 커밋을 삭제합니다 [ Fork ]GUI 툴인 Fork 로 실습을 해보겠습니다.pick 은 유지이기 때문에 실습에서 제외..
[ 브랜치 목록 조회 ] 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 저장소와 같아지게끔 강제 푸쉬시켰습니다 (협업하는 경우, 굉장히 위험한 명령어가 될 수 있습니다. 저는 예제용 개인프로젝트라서 진행해줬습니다) 참고 https://www.christianengvall.se/git-reset-origin-master-to-commit/ https://velog.io/@leehaeun0/실무에서-유용했던-git-명령어-4w0oxm3e
[ 사전 준비 ] 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..
- Total
- Today
- Yesterday
- DRF APIException
- github actions
- 플러터 싱글톤
- 구글 Geocoding API
- ipad multitasking
- Flutter Clipboard
- Flutter getter setter
- flutter deep link
- Flutter 로딩
- ribs
- flutter build mode
- cocoapod
- drf custom error
- Python Type Hint
- SerializerMethodField
- Django FCM
- METAL
- flutter 앱 출시
- Watch App for iOS App vs Watch App
- Flutter Spacer
- Flutter Text Gradient
- Dart Factory
- Sketch 누끼
- Django Heroku Scheduler
- flutter dynamic link
- 장고 Custom Management Command
- Django Firebase Cloud Messaging
- 장고 URL querystring
- 플러터 얼럿
- PencilKit
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |