GIT: 64개의 글
용어 Committed: 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미 Modified: 수정한 데이터를 아직 로컬 데이터베이스에 커밋하지 않은 것을 의미 Staged: 수정한 파일을 곧 커밋한 것이라고 표시한 상태를 의미 설정 설정 정보는 3가지 형태로 관리가 되며, 우선순위는 local > global > system 순입니다. system: /etc/gitconfig 파일에 저장되며 git config --system 명령으로 수정 가능 global: ~/.gitconfig, ~/.config/git/config 파일에 저장되며 git config --global 명령으로 수정 가능 local: 프로젝트 .git/config 파일에 저장되며 git config --local 명령으로 수..
삭제 권한 추가 소스트리에서 원격 origin 특정 브랜치 삭제 로컬에 있는 master 브랜치 이름 변경 변경 확인 푸시하기 원격 브랜치 최종확인
BitBucket 에 로그인 후 Repositories > Create repository 를 선택합니다. Repository 이름을 입력 후 Create repository 버튼을 누릅니다. 이렇게하면 신규 repository가 생성되었습니다. 이제 소스를 올려보겠습니다. 아래와 같이 해당 폴더로 가서 아래 명령어를 수행합니다. git init git add --all git commit -m "Initial Commit" 파일을 추가합니다. git remote add origin https://유저@bitbucket.org/유저/repo.git git push -u origin master 검색 결과, 이와 같은 현상은 github에서 레파지토리를 생성할 때, README.md, gitignore 파..
오늘 다루어볼 내용은 git의 cherry-pick(체리픽)이다. 보통 체리픽을 사용하는 이유는 다른 브랜치의 커밋의 일부만 가져올때 많이 사용한다. 간단하게 예제를 다루어보자. > gb * [1] feature/add-function [2] feature/update-function 위처럼 두개의 브랜치가 존재하고 각 브랜치의 커밋로그는 아래와 같다. > feature/add-function * 13e321a - (HEAD -> feature/add-function) add c.txt (9 minutes ago) * f894b25 - add b.txt (9 minutes ago) * 35402a1 - add a.txt (9 minutes ago) > feature/update-function * cb6..
오늘 다루어볼 내용은 평소에 조금 헷갈렸던 Git reset과 revert이다. 깃에서 되돌리기 위한 방법은 크게 2가지가 있다. 바로 reset과 revert이다. 그렇다면 둘의 차이점은 무엇일까? reset : 시계를 마치 과거로 돌리는 듯한 행위 revert : 특정 사건을 없었던 일로 만드는 행위 git reset "돌아가고 싶은 커밋 hash" 먼저 reset을 알아보자. reset은 특정 커밋으로 돌아가는 행위다. 그말은 특정 커밋 이후의 커밋이력 모두 없어지게 되는 것이다.(물론 옵션마다 상태가 다르긴하다) reset에는 옵션이 3가지가 있다. hard, soft, mixed 각 옵션에 대한 설명은 아래와 같다. hard : 돌아가려는 커밋 이후의 모든 내용을 다 지워버린다. soft : 돌..
Git에서 한 브랜치에서 다른 브랜치로 합치는 방법은 두 가지다. 하나는 이전 포스팅에서 다룬 Merge이고 다른 하나는 Rebase이다. Rebase 상황을 이전 포스팅에서 다루어봤던 merge 상황이랑 비교해보자. Git - fast-forward merge 란? fast-forward & 3-way Merge의 차이점 아래와 같은 상황이 있다. 이 상황에서 3-way-merge를 하면 그래프상태는 아래와 같은 상태가 된다. #current branch master > git merge issue-1 그런데 Rebase를 하면 어떻게 될까? #current branch issue-1 > git rebase master > git checkout master > git merge issue-1 실제로 ..
1. fast-forward merge 아래와 같은 상황이 있다고 가정하자. issue 처리를 위해 master 브랜치에서 브랜치를 따서 작업을 하고 있었다. 갑자기 픽스해서 빠르게 릴리즈해야할 버그 사항이 있어 hotfix 브랜치를 master 기준으로 따서 작업을 했다. 버그를 픽스하고 테스트를 통과해 이제 릴리스 해야하는 상황이다. 이제 master에 hotfix를 머지해야되는 상황이다. 그런데 hotfix는 master를 베이스로 하고 있는 브랜치, 즉 master의 upstream 브랜치이다. 이제 머지를 하면 fast-forward 머지가 되는 것인데, 이것은 단순히 master가 바라보고 있는 커밋을 앞으로 이동하는 것(hotfix 브랜치가 가르키는 커밋을 master가 바라본다.) 뿐이다...
이번 포스팅은 내용설명은 거의 없이 진행할 것이다. 포스팅 내용은 Git에서 자주 사용되거나 유용한 Git 명령들이다. git commit --amend : 완료된 커밋을 수정하고 싶을때나, 변경된 내용을 이미 커밋된 내용에 다시 포함시키고 싶을 때 사용하는 명령이다. "A"라는 커밋을 찍었는데, push 전에 내용이 변경되어 staging에 변경사항이 있는데, 이 변경된 staging 내용을 "A"라는 커밋에 포함시키고 싶을 때 사용한다. 즉, staging 변경사항이 없으면 "A"라는 커밋 내용과 동일하고 커밋메시지만 수정한다. git reset HEAD : 이미 staging에 올라간 파일을 unstaging으로 바꾸고 싶을때 사용한다. 이 말은 git add한 파일을 되돌리는 것이다. fileNa..
이번 포스팅은 굉장히 짧은 포스팅이 될것이다. 포스팅 내용은 ".gitignore" 파일이 먹지않을 때, 해결 방법이다. 분명 .gitignore에 파일 확장자 등을 추가하였는데 계속해서 changes에 나온다면 git의 캐시가 문제가 되는지 확인 해볼 필요가 있다. 아래 명령을 통해 캐시를 삭제해보자. > git rm -r --cached > git add . > git commit -m "clean untracked files" 아마 캐시 되었었던 파일들이 쫙 deleted된걸로 나오고 일부 파일들은 untracked로 나올 것이다. 최종적으로 한번 커밋해주자 ! 출처: https://coding-start.tistory.com/330?category=786242 [코딩스타트]