자습노트

상황 : - 잘못한 커밋 -> Master Branch Merging -> 커밋1 -> 커밋2 -> 현재 - 현 상태에서 커밋1은 제외하고 싶음 여러 뻘짓을 해봤지만 아래 방법이 가장 깔끔했다. ``` Master에서 Pull로 최신화를 한 뒤 새로운 Branch를 만든다. 새로운 Branch에서 잘못 된 커밋이 섞인 Branch의 Commit을 Cherry-pick한다. ``` What I did, What was wrong? 1) Rebase로는 안되는가? 사실 현재와 커밋2 사이에는 여러 커밋이 더 있었다. 먼저 git rebase -i HEAD~커밋2 전 커밋까지 rebase를 했다. 이 후에 커밋2가 rebase할 때 빠진거를 깨닫고 다시 rebase를 하려고 하니 현재 상태와 커밋2간에 conflict이 났다. 왜인지는 잘 모르겠다. * 터미널에서 git rebase -i HEAD~(커밋갯수)를 하면 Interactive 모드가 실행된다. 메시지 창에서 커밋 내역을 조작할 수 있는데, 커밋 Hash 앞에 접두사에 pick을 붙이면 그 Commit은 히스토리에 남긴다는 뜻이고, 접두사에 squash를 붙이면 history에는 남기지 않겠다는 뜻이다. 하나의 pick 을 가진 채로 나머지 commit들은 모두 squash해버리면 pick으로 살린 커밋에 sqaush가 붙은 커밋들의 내역이 모두 들어간다. * HEAD~2 는 현재 포함 2개의 커밋이라는 것. 2) Reset으로는 안되는가? Reset으로 잘못한 커밋까지 되돌아가서 (git reset --mixed HEAD~5) 반영하고 싶은 Commit을 다시 올릴려고 했으나 Master를 Merging했던 브랜치도 reset이 되면서 merging 내역들도 unstage 되는 불상사가 일어났다. 더불어 터미널에서 git log를 해보니 얘는 master branch의 로그들을 출력하고.. 그래서 master에 이미 올라간 내역도 자칫...

<'www.example.com'.strip('cmowz.') 의 결과가 example이라는 걸 아시면 이 글을 안 봐도 됩니다.> 보통의 레퍼런스에 의하면 strip(arg) 메소드는 어떤 String의 양 끝단에 위치한 arg를 지우는 메소드라고 설명이 많이 되어있다. arg가 없으면 공백을 제거. 근데 신기하게도 위와 같은 결과가 example이 나오는 것을 보고 좀 알아봤더니 몰랐던 면모를 알 수 있게 되었다. strip()은 재귀적으로 호출하며, 인자에 들어가는 항목들을 String이 아닌 Char로 보고 재귀한 결과에 누적해서 적용한다. 만약 arg가 'abc'라면 가장 바깥쪽에 있는 문자가 a인지 검사하고 a를 strip한다. 그리고 그 결과에 b가 있는지 검사하고 b를 지운다. 그리고는 c로 넘어가서 c를 검사하고 지운뒤 결과를 내보낼 것 같지만? 사실은 그렇지 않다. strip을 하면 'abc'가 [a, b, c]로 인식이 된다. 그리고 매번 target string이 a,b,c를 포함하고 있는지 계속해서 결과마다 확인하고 strip을 하게 된다. 즉 a로 strip-> 그 결과를 다시 a로 strip-> a가 없다면 b로 strip -> 결과가 없으면 그게 target string이 되고 다시 a strip check -> b strip check -> c strip check 이런식으로 매 결과마다 누적해서 strip이 적용된다. (reduce함수를 생각하면 되겠다)