용어 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 명령으로 수..

오늘 다루어볼 내용은 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 [코딩스타트]

아래 명령어는 특정 브랜치만 clone하는 방법이다. git clone -b {branch_name} --single-branch {git_repository_host}

현상 github에서 저장소 생성 후 저장소 주소를 remote에 입력(git remote add origin https://github…..)했고, 로컬에서도 정상적으로 초기화(git init)했는데도 git pull 또는 git merge 명령이 동작하지 않고 git push origin master시 [rejected] master -> master (non-fast-forward)이런 에러가 발생하는 경우 원인 깃허브에 생성된 원격 저장소와 로컬에 생성된 저장소 간 공통분모가 없는 상태에서 병합하려는 시도로 인해 발생. 기본적으로 관련 없는 두 저장소를 병합하는 것은 안되도록 설정되어 있음. 해결방법 아래와 같이 git pull 시에 –allow-unrelated-histories 옵션 추가하여 ..

remote: Permission to 403 remote: Permission to ~ denied to id(xxx). fatal: unable to access 'https://github.com/~': The requested URL returned error: 403 a라는 github 아이디로 '최초' 글로벌 유저를 등록 후 b라는 github 아이디로 글로벌유저를 등록 후 git push를 하게 되면 기존에 최초 등록한 a아이디를 바라보고 있기에 에러를 발생시키는 것이었습니다. spolight 검색을 통해 keychain Access.app 또는 키체인 접근을 실행합니다. 오른쪽 상단에 검색창에 github.com 을 검색합니다. 리스트에 보이는 github.com 더블클릭 후 계정과 암호를..