1. git rebase --onto origin/main origin/origin 했다가 까임.
오류메시지는 기억 안 남. origin 뒤에 뭐가 더 있다구 그거 날아갈 수 있으니까 커밋해놓으라구 안내
2. 그래서 git status 명령어로 working directory에 저장 안 된거 커밋해둠. (origin/origin이랑 같이 있던 origin이 새 커밋 만들어지며 상위로 올라감.)
3. 그 다음 git checkout main으로 이동함. (HEAD -> origin 에서 HEAD-> Main이 됨.)
4. git push origin 했다가 까임. ( 이 목적은 뭐였냐면 )( 왜 까였냐면
5. git push origin:HEAD로 함 (명령어 목적은 현재 HEAD가 가리키는게 main이어서 origin, 즉 서버에 HEAD랑 이름 같은 브랜치에 push하라는 뜻이었음) => 까임. main아 너 뒤에 업테이트 9개 있어. 그거 날아갈 듯 이랬던 것 같다. 그러니까 pull해서 업데이트 해와. 하라는 데로 함.
6. git pull (명령어 목적: 반만 이해했다. push전에 local을 server랑 매칭시켜줘야해서 pull을 해야한다는 것을 알아서,사실은 위에 안내
문구에서 시키는대로함) => 예상치 못한 결과가..? origin/main내용이 main위치로 끌어올려질 줄 알았는데, main이 origin/origin위치로 가버렸다. 엥?
7. 자 내 HEAD는 main가리키고 상태는 main -> origin 이고,
(origin/main) 커밋 뒤에 커밋 약 15개, 그리고 (main), (origin/origin) 커밋, 바로 하나 뒤에 (origin).
여기서 git checkout origin 하면 HEAD -> origin 된다.
Switched to branch 'origin'
Your branch is ahead of 'origin/origin' by 1 commit.
(use "git push" to publish your local commits) 라고 한다. 왜냐하면 orgin에 새 커밋 만들고 origin의 remote는 업뎃 안 해서.
8. 아 ! 이해된 것 같다. 내가 지금 진작에 main이랑 origin을 merge해서 한 줄로 만들고, origin브랜치마 업뎃해나가고 있었다. 그리고 중간중간 origin의 서버origin을 업뎃해줬고. 그래서 git main에서 pull을 했으면 전체 서버의 최신버전인 origin/ogirin의 내용이 로컬main에 들어오면서, 로컬 main의 포인터가 origin/origin으로 옮겨가며 위로 끌어올려진거구나!
여기서 만약 main브랜치로 가서 push하면 예상치로는 origin/main이 main, origin/origin으로 옮겨갈 것 같다.
9. head가 main을 가리키게 해서, main에 온 뒤, git push 를 했다.
내 현재 HEAD가 가리키는 브랜치(main)이랑 upstream branch랑 안 맞는단다.(origin의 상위 브랜치니까 아마 서버(origin)중에 가장 최근에 업뎃된 브랜치로 기본 push되는데 이 때 이름 매칭이 안 되면 안내해주는 듯.
그래서 아래 명령어로 시도해보기. ( 위의 이유라면 git push origin main 이렇게 해줘도 될 것 같은데? )
9. 또 까였다. 4-5 랑 같은 이유. none fast-forward라고. 뭘까뭘까.
10. 일단 해당 이유는 모르겠지만 내가 완전 바보같은 생각하고 있던 걸 알았다. 어제 헷갈린 것과 관련된 문제.
HEAD detached at [해시]가 왜 뜨나 했는데, origin(서버)에 있는 브랜치는 로컬의 HEAD로는 당연히 못 가리킨다.. 그래서 뜬금없는데에 붙어있어서 브랜치 이름이 아닌 커밋값으로 뜨는 것.
또 개념 혼자 개념 미스날까봐 확인해보면 서버의 브랜치라서가 아니라 이건 브랜치 분기점이 아니면 다 그렇게 뜬다.
11. 9에서 나온 내용 아직도 끙끙대는 중인데, 나랑 비슷한 문제인 것 같은 사람의 글을 발견했다. https://stackoverflow.com/questions/6199889/rebasing-remote-branches-in-git
Rebasing remote branches in Git
I am using an intermediate Git repository to mirror a remote SVN repository, from which people can clone and work on. The intermediate repository has it's master branch rebased nightly from the ups...
stackoverflow.com
맥락 보면서 다시 보니 rebase해야할 것 같아 시도했는데, 1..4/40 이렇게 옮기는 것 봐서는 origin/main의 포인터를 upstream으로 옮기는 게 맞는 것 같다.
12. 반만 정답이었다. rebase를 하는 건 옳았다. origin/main을 가장 상단으로 올리는 것.
근데, merge conflict를 해결안하고 무시하고 진행하니까. 해당 내역들이 싹 복사되어서 위에 다시 올라와서 커밋 내역들이 중복된다. 시간이 뒤죽박죽인게 위의 사진에서 확인된다.
최상단에 예쁘게 main이 올라가긴 한다.
근데 진짜 엉망이 되어버렸다. 하..
13.
새로 rebase된 내역이 40개가 넘어서 그냥 reflog 하면 다 나오지도 않는다.. 최대 범위인 38개 뒤로 가는걸 하니까.
그나마 다행히 main의 6개의 기존 커밋이 뒤로 rebase된 시점까지만 나오게 할 수 있었다. rebase도 아직 파악이 확실히 안 된것같다.. 아 원하는대로 통제가 안 되네..
14.
이해 못하게 옮겨진 main부터 하나하나 세서 17개 더 뒤로 reset했다. 사랑해 reset! 널 좋아해 reset! 이제 초기의 통제 범위로 들어온 것 같다.
15.
하나하나 해결해가는데 진짜 살 떨린다. 흑흑.. 나름 브랜치 갈라지고 합쳐지는 지점 이해하고 개념 검색하고 이해해가면서 하는데, 작업물 날아갈까봐 마음 속으로 울면서 하고 있다.
16.
main 옮기기 다시 성공.
main에서 origin으로 브랜치 checkout으로 변경하려니 main뒤의 내역이 있다해서 일단 새 커밋으로 남겨줬다. 근데 해당 부분에서 분기 생기며 저장될 줄 알았는데 의도치 않게 위로 올라왔다. 내가 원하던 모양새로 흘러가게 되긴 했는데, 의도한대로 동작한 건 아니어서 또 답답하다.
그래도 결과적으로 목표에 가까워졌다! 둘이 거의 만나간다. conflict가 적게 서버의 브랜치끼리의 merge! 이제 가능할 것 같다.
17.
우선 origin/origin을 로컬의 origin과 동일 선상에 있게 하기 위해 push를 했다.
이름 헷갈리게 만들어서 여기까지 온 것인가 싶지만, 헷갈렸기에 origin이란 이름을 로컬브랜치로 쓴 것 같다..
18.
그리고 main도 17의 과정을 거치게 하기 위해 HEAD를 다시 main으로 옮겼다.
아니 왜 자꾸 다르대.. 트리 상으로는 같고 내 생각에도 로직 상 같은 것 같은데..ㅠㅜ
19.
수정 없이 문득 확인해본 깃허브... 하아...저 안내 문구 하나 보려고 5-6시간을 달려왔다.. 눈물 나 진짜..
orgin 브랜치도 확인해보면 아까아까 만든 "Finish: todolist ...."커밋을 이제야 정상적으로 push가능했어서 잘 들어온 것을 확인할 수 있다.
다만 저 개념이 아직도 이해가 안 간다.
commits ahead and behind. 뜻은 아까 검색하며 좀 봐서 대충 이해는 했다. 그런데 ! 분명 2개정도밖에 차이가 안 나는데 왜 때문에..? 왜....... 왜..
20.
pull request하면 초기 상황이랑 거의 비슷한 양상.
아.. 19번 헛것을 본거구나. origin/main이 위로 끌어올려져서 변경된 줄 알았는데.. 생각해보니 push한 적은 없다. 잘 push된 건 origin.. ㅠ 돌고 돌아 겨우 맨 처음 상태로 오다니.. 더 엇나가지 않은 것에 감사해야하나ㅠ
21. 친절한 git의 안내문구를 따라가보자. 그리고 스택 오버플로우를 곁들인..
commits ahead and behind. 다시 복습.
Ahead is the number of commits on this branch that do not exist base branch.
그렇기에 origin branch에서 "this branch is 42 commits ahead ... "의 뜻은, base branch인 main에는 origin branch의 42개의 커밋이 없단 말.
Behind is the number of commis on base branch that do not exist this branch.
그렇기에 "... ,2 commits behind main. "의 뜻은, base branch인 main에 있는 2개의 커밋이 this branch인 origin에는 없다는 말이다.
처음 상태로 온 것이 맞구나! 재 확인 .. ㅎ readme file이랑 license만 main에 둔 상태로 계속 origin을 upstream server로 사용하며 push해와서 딱 저 설명이 맞아떨어진다.
다만,
Q1. 로컬에서 업데이트되어 보여지는 origin(:서버)의 main과 origin이 rebase되어서 후반부를 가리키고 있는데 이건 어찌된 일?!
rebase에 대해서 다시 생각해야하나보다. 여기서 보면 save커밋은 origin에 아직 안 올라갔으니까 일단 무시하고,
rebase를 거친 뒤에는 맨 아래에 있던 두 개의 커밋인 [55f959e],[96611f4]가 고대로 제일 상위로 끌어올려진 것이다.
라고 상태변화를 확인할 수 있다. 시간대를 보면 새로 만들어진게 아니라 고대로 올라왔음이 명확하다.
rebase개념을 생각하다가 아차 싶어서 이 게시글의 위로 돌아가서 봤는데, 진짜 아차다 아차.. 하.. origin에서 rebase를 해야 main의 마지막으로 옮겨져서 ff가 가능해지는 건데.... 아.. 아.! 아!! 이거다.. 어떻게 되돌리지 !!? 이미 rebase한 상태를 어떻게 하지..
정리하자면, main branch로 가서 rebase를 하는게 아니라 뒤에 있는 origin에 가사 rebase를 했어야 했다. 아까 아까 conflict되는데 괜찮냐했을 때 skip 옵션 줘서 rebase하고 동일 파일들이 엄청 복사되고 그런게 겹쳤던 애들이 뒤로 다 이동되어서 그런거였다. main은 어찌어찌 origin이랑 동일 선상에 맞춰놨으니..
근데 진짜 미스테리는 origin/main은 업데이트가 안 되었는데도 뒤로 빠진 것.. 그냥 시점만 옮기는건가?!
Q2. 그리고 내가 하고 싶은 두 원격 브랜치 병합(서버에서 병합 + 로컬까지 그 내역 끌고와서 전체 과정을 커밋으로 남겨 정리)하는 건 어떻게 해야하는것인가! 다시 생각해보기.
사실 병합해보는 걸 하고 싶어서 계속 디깅했던 건데 미숙한 상태에서 현재까지 한 작업물로 계속 위험하게 하는 것보다 빈 파일로 연습하는게 더 나을 것 같다는 생각이 들었다.
그래서 이 시도는 여기까지 하고, 어차피 빈 폴더였던 main과 origin/main이 뒤로 빠졌으니 그냥 이 친구들을 삭제하고 origin브랜치를 default로 해서 작업하면 될 것 같다.
하여간 정리할 건, remote에 있는 브랜치를 없애려면 git push --delete [로컬서버이름] [로컬의 브랜치 이름[
로컬서버이름은 거의 디폴트값은 origin.
속상하다 실패기록이어서.
학습한게 많으니 만족해야하나.
'Thing about programming > Git' 카테고리의 다른 글
[ Git ] Git / Github 질문에 대한 짧은 생각 + Git 관련 인터뷰 질문 40가지에 대한 답변 (0) | 2022.08.25 |
---|---|
[ Git ] 브랜치 지우기 (0) | 2022.08.02 |
[Git] LF와 CRLF (0) | 2022.07.18 |
[Git] 로컬 폴더 - 깃허브 레포 연결 (0) | 2022.07.15 |