add SSH1.png figure, discourage "git config pull.rebase true"

[salt26]

Resolves #15
그리고 기본 Git 설정에서 pull.rebase를 사용하지 않고 default로 pull하도록 하였습니다.
왜냐하면 pull.rebase를 사용할 경우 Git commit history가 직선으로 나타나 Software Engineering 관점에서 history를 이해하기 쉬워진다는 장점이 있지만, merge conflict가 발생할 때 하나의 해결 커밋으로 머지가 되는 것이 아닌, 해당 PR에 존재하는 모든 각각의 커밋들에 대해 일일이 컨플릭트를 수정해야 하는 번거로운 상황이 발생하기 때문입니다. 따라서 Git 초보자에게 pull.rebase true가 권장되지 않는다고 판단하였고, 그래서 내용을 수정하였습니다.

[nick11967]

LGTM

[cseteram]

우선 git pull 시 동작을 변경하라고 언급하는 것은 1) default 전략을 사용할 이유가 전혀 없고 2) diverge가 되어 머지 커밋이 발생하는 경우 이를 Git의 기본 동작에 의존하지 말라는 의도였습니다. 저는 rebase를 선호하지만 ff-only 를 선호할 수도 있고요. 하여튼 default는 쓰는거 아닙니다

• Why is git pull broken?
• 왜 git pull은 망가졌는가? (번역)

다만 현대에 와서는 대부분 PR 기반으로 병합이 진행이 되니 이러한 동작이 크게 문제가 되는 경우는 잘 없다고 생각은 하고 있습니다. 어차피 병합은 GitHub이 해주고 main 브랜치 git pull 시 ff로 동작할 것이니까요. 리베이스가 입문자에게 제시하기에는 조금 어려울 수 있는 개념이라는 것도 이해는 합니다. 따라서 이 부분은 원하는 방향으로 변경하셔도 무방할 것 같습니다. (default를 사용한다면 아예 git pull 모드의 언급을 하지 않는 것이 더 나을 수도 있습니다) 사실 문서를 전반적으로 수정하고 자연스럽게 녹이고 싶은 마음은 드는데 뭔가 동력이 없네요...

해당 PR에 존재하는 모든 각각의 커밋들에 대해 일일이 컨플릭트를 수정해야 하는 번거로운 상황이 발생하기 때문입니다.

보통은 이러한 상황이 크게 문제가 되는 경우가 없지 않나요? 하나의 큰 병합 커밋에서 발생하는 충돌은 각각의 커밋에서 발생하는 충돌을 합친 것이니까요.

[salt26]

해당 PR에 존재하는 모든 각각의 커밋들에 대해 일일이 컨플릭트를 수정해야 하는 번거로운 상황이 발생하기 때문입니다.

보통은 이러한 상황이 크게 문제가 되는 경우가 없지 않나요? 하나의 큰 병합 커밋에서 발생하는 충돌은 각각의 커밋에서 발생하는 충돌을 합친 것이니까요.

원격에서 작업한 내용을 땡겨오다가 충돌이 나면 가끔씩 git rebase --edit-todo랑 git rebase --continue를 치라는 안내가 뜨면서 과거의 모든 커밋들에 대해 하나하나 수정하게 되는 상황이 생기더라고요.. ㅜㅜ
아마 머지의 방향이 반대가 되어서 그런 것 같은데..

[salt26]

제 생각에도 이렇게 설명만 하고 수행해야 하는 action이 없이 넘어갈 바에는 그냥 설명하지 않고 넘어간 다음, 부록에서 다루는 게 좋다고 생각해요. 설정 단계라 아직 pull이나 rebase에 대한 개념도 설명하기 어렵고 말이죠...
그러면 한 번 더 수정을 해볼게요! 여기서 pull 설정하는 건 빼고(암묵적 default), 부록 쪽에 내용을 얹어볼게요!