Record
개념
-
목차
- 스터티
- 참조
- 브런치
- 깃허브 협업
- 기타
- Git 여러 commit 하나로 합치기
- Git 임시 저장
- Git switch
- Git restore
- Git Merge
- Cherry Pick
- Git log
- 파일 변경 없이 commit하기
- update-index
스터티
참조
-
git 강제 Push 하기 (error: failed to push some refs to) https://www.hahwul.com/2016/02/02/coding-git-push-push-error-failed-to/
- git push -u origin master –force
-
git - 원격저장소 Url 변경하기 https://youngjinmo.github.io/2019/09/git-change-remote-branch-url/
- git remote set-url origin https://github.com/youngjinmo/youngjinmo.github.io.git
-
git add로 추가한 내용을 취소하는 방법, 첫 커밋 이후 git add한 내용을 취소하는 경우 https://www.lainyzine.com/ko/article/how-to-cancle-git-add/
- git rm –cached README.md
- git reset HEAD [FILE…]
- git restore –staged [FILE…]
-
깃허브 저장소에 100MB 이상의 대용량 파일 업로드 하기 https://hwiyong.tistory.com/318
-
- it-lfs https://git-lfs.github.com/
-
- ‘git lfs install’을 입력한다.
-
브런치
- Master Branch
- Release(배포)출시 할 수 있는 브랜치
최종 배포(Release) 이력을 관리하기 위한 최상위 브랜치입니다. 배포 가능한 상태만을 관리합니다.
- Release(배포)출시 할 수 있는 브랜치
- Develop Branch
- 다음 출시 버전을 개발하는 브랜치
Master에서 분기되어 기능 개발을 위한 브랜치들을 병합하기 위해 사용 합니다. 이 브랜치를 기반으로 개발을 진행. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘master’ 브랜치에 병합(merge)합니다.
- 다음 출시 버전을 개발하는 브랜치
- Feature branch
- 기능을 개발하는 브랜치 (Local)
feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’ 브랜치로부터 분기합니다. feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 주로 자신의 로컬 저장소에서 관리합니다.
- 기능을 개발하는 브랜치 (Local)
- Release Branch
- 이번 출시 버전을 준비하는 브랜치
Feature branch에서 Develop 브랜치로 어느정도 배포가 진행되고 배포할 수있는 시점(모든 기능이 정상인 상태 or 목표개발기간종료) 이 되었을때 Release Branch를 생성합니다. 그 이후 테스트를 통해 최종적으로 버그 수정이라든가, 문서 추가등 실질적으로 Release 출시 하기 직전에 하는 단계들을 위한 브랜치 입니다. 만약 버그수정이 있다면 수정하고 Develop 에다가도 병합해줍니다. 기능에 대한 병합작업은 하지 않는 단계이며 마지막 검토 정도로 생각하면 될것 같습니다. 기능에 대한 개발은 계속해서 Develop 이나 Feature Branch에서 이어나갑니다. 그리고 모든 버그나 문서 수정이 완료 되면 Master Branch로 병합 및 버젼 Tag를 부여하여 출시 합니다. 또 배포를 준비하는동안에 Release 브랜치가 변경되었을 수 있기때문에 배포 완료후에 Develop 에다가도 병합합니다. ```
- 이번 출시 버전을 준비하는 브랜치
- Hotfix Branch
- 출시 버전에서 발생한 버그를 수정 하는 브랜치
배포를 했지만 갑작스럽게 수정해야하는 경우에 master에서 바로 수정하지 않고 Hotfix 브랜치를 분기하고 고친후 병합합니다. <master에서 수정하는일은 거의 없음, 분기후 수정>문제가 되는 부분만을 빠르게 수정한다. 존재의 이유는 갑작스럽게 수정해야 하는 부분이며 Patch 버젼(1.2.1)을 새롭게 변경해 줍니다. 그리고 배포가 끝난후 다시 develop에다가도 병합해 줍니다.
- 출시 버전에서 발생한 버그를 수정 하는 브랜치
깃허브 협업
==> 신규 협업 프로젝트 생성
0. center, origin, local
1. fork
center upstream 을 my origin 에 복제
2. my origin 을 local master branch 에 생성
$ git clone [remote]
3. center upstream 등록
$ git remote add upstream [center]
확인 방법 git remote -v
==> 신규 개발을 위한 순서
4. 새로운 기능 개발을 위한 branch 생성
$ git checkout -b [branch name]
# 위의 명령어는 아래의 두 명령어를 합한 것
$ git branch [branch name]
$ git checkout [branch name]
확인 방법 git branch
5. 새로운 변경 사항은 my origin 에 push
$ git commit -am "Write commit message"
# 위의 명령어는 아래의 두 명령어를 합한 것
$ git add . # 변경된 모든 파일을 스테이징 영역에 추가
$ git add [some-file] # 스테이징 영역에 some-file 추가
$ git commit -m "Write commit message" # local 작업폴더에 history 하나를 쌓는 것
$ git push origin [branch name]
6. pull requests
my origin 을 center upstrem 에 request
7. center merge
==> master Fast forward Merge - Merge 과정 없이 그저 최신 커밋으로 이동한다.
$ git checkout master
$ git merge hotfix
==> master 3-way Merge
$ git checkout master
$ git merge iss53
==> 작업 branch 삭제
$ git branch -d hotfix
==> 중앙 저장소 동기화
8. branch 위치 master branch 이동
$ git checkout master
9. center 에서 local pull
$ git pull upstream master
10. 작업중 branch에 변경 사항 반영
$ git checkout v20220313
$ git pull upstream v20220313
10. local master branch 를 my master origin 에 pull
$ git checkout master
$ git pull upstream master
Rebase
-
Merge는 branch를 통합하는 것이고, Rebase는 branch의 base를 옮긴다는 개념의 차이
2개로 갈라진 branch를 정렬한다.
1. B 지점을 base로 가진 branch가 D, E 커밋을 진행 한다.
2. C 지점으로 base를 이동하기 위해 branch에서 C 지점으로 rebase를 한다.
3. C 지점으로 rebase 되면 기존 D, E 커밋은 새롭게 정렬되어 C 지점 이후로 변경된다.
git checkout experiment
git rebase master
git rebase --continue
기타
브런치 삭제
git branch -D #q
.gitignore 변경 반영하기
github에 프로젝트를 업로드 하는데 제외하고 싶은 파일/폴더가 있을 경우 .gitignore 파일을 사용한다. 그런데 이미 repository에 올라와 있는 파일을 .gitignore 에 추가하고자 할 경우에는 추가적인 조치가 필요하다. 이미 올라와있는 파일은 현재 tracking되고 있기 때문에 이 tracking을 제거해줘야 하는 것이다. tracking을 제거하는 방법은 어렵지 않다. 다음과 같은 방식으로 .gitignore 수정을 진행한다
.git이 있는 최상위 폴더로 이동
git rm -r --cached tracking
git add .
git commit -m "gitignore 다시 적용"
git push origin 브랜치명
test 폴더 지우기
.git이 있는 최상위 폴더로 이동
git rm -r --cached /src/test
(최상위 폴더로 부터 test 폴더의 경로.)
git add .
git commit -m "gitignore 다시 적용"
git push origin 브랜치명
파일 안바뀐것으로 처리하기
- 처리하기
git update-index --assume-unchanged 파일이름
- 해제하기
git update-index --no-assume-unchanged 파일명
- 목록 확인
git ls-files -v | grep ^h
- unchanged 로 지정된 목록들무시하고 워킹트리에 대한 인덱스 새로 갱신시키기
git update-index --really-refresh
fetch
git fetch upstream
git merge upstream/develop
git fetch --prune
명령어는 원격 저장소로부터 최신 변경 사항을 가져오는 동시에 로컬에 존재하지 않는 브랜치를 삭제합니다. 이를 통해 로컬에 존재하지 않는 브랜치가 원격 저장소에서 삭제된 경우, 이러한 변경 사항을 로컬에 반영할 수 있습니다.
예시
git clone https://github.com/mamma1234/logispot.git
cd logispot
git remote add upstream https://github.com/Logispot/logispot.git
git fetch upstream
git merge upstream/develop
git checkout -b oms
git fetch upstream
git merge upstream/oms
git push origin oms
Git 여러 commit 하나로 합치기
git rebase -i HEAD~3
pick을 s 혹은 squash 변경
#을 붙여서 커밋 메시지에 반영되지 않도록 하고 새롭게 커밋 메시지를 작성
git push -f origin master
Git 임시 저장
git stash
git stash apply
git stash drop
git stash clear
git stash list
Git switch
git switch develop
git switch -c feature/xxx
Git restore
-
git의 파일 조작 (특정 커밋으로 되돌리기, Unstaging 시키기 등) 만을 위한 기능을 지원
-
특정 파일을 특정 커밋으로 복구
- git restore aa.txt
- git restore –source HEAD aa.txt
- git restore –source 7abc7def aa.txt
-
staged 파일 복구
- git restore –staged aa.txt
- 이전 방법 git reset HEAD aa.txt
- git restore –staged aa.txt
Git Merge
- Fast Forward Merge
- Commit Merge
-
Conflict Merge
- Merge Commit
- 일반적으로 많이 사용하는 Merge 방식이고 각 상황에 따라 Fast-forward, Recursive 방식으로 병합되며 Fast-forward는 새로운 커밋 메시지 없이 커밋 내용이 적용되며 Recursive는 합병할 때 새로운 커밋 메시지와 함께 커밋 내용이 적용되는 방식이다.
- Squash Merging
- git merge –squash <분기된 브랜치명="">분기된>
- 이전 커밋 내용을 모두 합쳐서 하나의 새로운 커밋 메시지로 만들고 난 다음 이전 커밋 내용을 모두 지우는 병합 방식이다.
- Rebase Mergin
- git rebase
- git checkout
- git merge <분기된 브랜치명="">분기된>
- 커밋 내용을 Base가 되는 브랜치에 재배치하고 추가로 커밋 메시지 없이 병합을 진행하는 방식이다.
- git rebase
merge options
- git merge –ff : fast-forward 병합커밋 만들지않고 브랜치 태깅만 변경하게 됩니다.)
- git merge –no-ff : 병합커밋을 만듭니다.
- git merge –squash
Cherry Pick
- 체리픽 커밋은 다른 브랜치의 커밋을 내가 작업한 브랜치로 합치는 커밋
git cherry-pick b8ffcad
Git log
git log --oneline
-
마지막 태그 이후 로그 git log $(git describe –tags –abbrev=0)..HEAD –oneline –pretty=format:’%h %s’
-
트리형태 로그 git log –color –graph –pretty=format:’%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset’ –abbrev-commit
강제 Pull
- 로컬에 있는 내용 무시하고 git 에서 내려받기
git fetch --all
git reset --hard origin/master
git pull origin master
file list
– tag 사이 file list 가져오기 git diff –name-status 20221206a..20221212a
– tag 목록 가져오기 git describe $(git rev-list –tags –max-count=2) –abbrev=0
– tag 목록 사이 file list 가져오기 git diff –name-status $(git describe $(git rev-list –tags –max-count=2) –abbrev=0)
파일 변경 없이 commit하기
git commit –allow-empty -m “commit message”
update-index
assume-unchanged
git update-index –assume-unchanged
git update-index –no-assume-unchanged
git update-index –really-refresh
git ls-files -v | grep ‘^[a-z]’ |