wrkbrs

과거의 특정 커밋에 포함된 내용을 수정해야할 때가 있다. git rebase를 사용하면 가능하기는 한데, 수정 후 remote에 올릴 때 결국 git push --force(또는 조금이라도 안전하게 하려면 git push --force-with-lease)를 써서 기존의 내용을 덮어써야 하므로, 기존의 내용을 공유하고 있던 공동 작업자가 있는 환경에서는 뒷처리가 복잡하다. 따라서 가급적 과거의 이력을 바꾸기보다 그냥 현재 상태에 수정 사항을 적용하는 것이 바람직하지만, 그래도 꼭 해야겠다면 뭐.. 해야지. 큰 흐름 작업의 큰 흐름은 다음과 같다. 수정하려는 커밋의 바로 이전 커밋을 base로 다시(re) 설정, 즉 rebase 한다. 내용을 수정하고 git add, commit --amend로 커밋도 수..

Git을 사용하다보면, 이미 커밋한 히스토리를 변경 또는 삭제하고 싶은 경우가 자주 발생한다. 이때 사용할 수 있는 명령어가 바로 $ git rebase -i이다. -i는 --interactive 의 약어로 말그대로 git rebase 명령어를 대화형으로 실행하겠다는 의미이다.$ git rebase -i [수정을 시작할 커밋의 이전 커밋] 이렇게 명령어를 실행하면 "수정을 시작할 커밋의 이전 커밋" ~ "현재 커밋(HEAD)" 범위에 있는 모든 커밋들의 리스트가 출력된다. 예를 들어 $ git rebase -i HEAD~3 를 실행하면 HEAD~2, HEAD~1, HEAD 커밋들이 출력된다. 사용자는 rebase 하기 전에 그 리스트를 입맛에 맞게 직접 수정함으로써 이전 커밋들의 히스토리를 변경할 수 있..

git revert, reset을 통한 소스 복구 방법입니다. 복구하려는 2~3개 커밋 전이라면 revert를, 그보다 훨씬 전이라면 reset을 통해 복구하면됩니다. revert를 통한 복구 복구 시점 이후에 커밋이 많지않거나 merge 커밋이 없는 경우에 사용. 실제로 사고 발생시 merge 커밋이 없는 경우가 거의 없기 때문에 잘 사용하진 않음. 1) git revert -n [커밋id] 2) git commit -m "커밋 메시지" 3) git push [target] 예) git revert -n a123 git revert -n b456 git revert -n c789 git commit -m "Revert roll back" git push origin [branch] reset을 통한 복..

1. reset과 revert 작업을 진행하다가 실수로 중요한 파일을 삭제했거나 제대로 병합이 안됐을 경우, 잘 작동이 되던 이전 버전으로 돌아가야 합니다. 이것이 바로 버전 관리를 하는 이유이며, 이 때 사용하는 명령어가 git reset과 git revert라는 명령어입니다. git reset을 명령어는 특정 커밋으로 되돌아갈 수 있는데, 되돌린 버전 이후의 버전들은 히스토리에서 삭제됩니다. git revert는 reset처럼 특정 버전으로 되돌아갈 수 있지만, 되돌린 버전 이후의 버전들의 이력은 남아있다는 점에서 차이가 있습니다. reset과 revert 명령어를 통해 과거 버전으로 돌아갈 수 있지만 그 밖에 잘못된 병합을 취소할수도 있는 기능이 있습니다. 이 글에서 이전 버전으로 되돌리기, 병합 ..

Git을 사용하다보면 원격 저장소에 있는 branch를 로컬 저장소로 가져와야하는 경우가 있다. 협업하고 있는 다른 팀원의 branch를 가져와서 작업을 해야하는 경우 혹은 혼자서 2대의 PC를 사용하고 작업파일을 Git으로 관리하는데 branch를 따서 작업하는 경우 등이 여기에 해당한다. 저장소를 그대로 clone을 하던지, pull을 하면 원격 저장소의 branch도 같이 받아질 것이라 생각했지만 그렇지 않았다. $ git checkout -t [원격 저장소의 branch 이름] 명령을 이용하면 원격 저장소의 branch를 가져오는 것과 동일한 기능을 한다. git remote update 먼저 원격의 브랜치에 접근하기 위해 git remote를 갱신해줄 필요가 있다. $ git remote upd..

source tree를 쓰고 있지만 명령어로 칠때가 더 편함.... git branch //로컬 저장소의 브랜치 목록 git branch -r //원격저장소의 브랜치 목록 gir branch -a //모든 브랜치 목록 git checkout remote이름/branch이름 ex) git checkout origin/branch1 원격 저장소의 브랜치로 작업 트리가 변경되며, 여기서 수정한 내역은 저장되지 안됨. git checkout -b 생성할브랜치이름 원격브랜치이름 ex) git checkout -b branch2 origin/branch1 branch2가 생성되면서 원격 저장소에 있던 branch1으로 작업 트리가 변경되며, 로컬에서 수정한 내역이 저장됨. git checkout -t remote이..

repository를 clone하면, 자동적으로 origin/master 포인터가 clone한 내용을 가리키고 있는 것을 볼 수 있다. 이 origin/master가 어떤 의미가 있을까? 리모트 브랜치는 리모트 저장소에 있는 브랜치를 말하고, 리모트 브랜치의 이름은 (remote 저장소 이름)/(branch 이름)의 형식을 갖는다. git 서버의 저장소를 clone을 하면, git은 자동적으로 origin이라는 이름을 붙인다(아래 예제에서는 git.courcompany.com이라는 저장소를 clone하지만, 이름을 지정하지 않으면 Local에는 origin으로 clone됨). 그리고 origin으로부터 저장소 데이터를 모두 내려받고 master 브랜치를 만든다. 이 상황에서 누군가 git.courcomp..

Goal Gitflow Workflow에서 사용하는 Git Branch 종류를 이해한다. Gitflow Workflow에서 사용하는 Git Branch 사용법을 이해한다. Git Branch 종류 (5가지) Gitflow Workflow에서는 항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)을 포함하여 총 5가지의 브랜치를 사용한다. 아래는 Gitflow Workflow 방법에서 사용하는 브랜치의 흐름이다. 1. Master Branch 제품으로 출시될 수 있는 브랜치 배포(Release) 이력을 관리하기 위해 사용. 즉, 배포 가능한 상태만을 관리한다. 2. Develop Branch 다음 출시 버전을 개..

Git 명령어 Fetch -> 리모트 저장소에 있는 모든 데이터를 로컬로 가져옴. Git branch [브랜치명] => 새로운 브랜치 생성 Git checkout [브랜치명] => 브랜치 checkout(다른 브랜치로 이동) Git commit => ———> 한줄로 git checkout -b newData Git local branch 생성 , branch 이동 생성 : git branch [브랜치명] 생성 후 이동 : git checkout -b feature-01 Git remote branch 생성 git push origin feature-01 branch local remote 연동 git branch --set-upstream-to origin/feature-01 Git branch 삭제하기..

Goalgit add를 취소할 수 있다.git commit을 취소할 수 있다.git push를 취소할 수 있다.untracked 파일을 삭제할 수 있다.git add 취소하기(파일 상태를 Unstage로 변경하기)아래와 같이 실수로 git add * 명령을 사용하여 모든 파일을 Staging Area에 넣은 경우,Staging Area(git add 명령 수행한 후의 상태)에 넣은 파일을 빼고 싶을 때가 있다.// 모든 파일이 Staged 상태로 바뀐다.$ git add *// 파일들의 상태를 확인한다.$ git statusOn branch masterChanges to be committed:(use "git reset HEAD ..." to unstage) renamed: README.md -> RE..