21.2.1

1. 깃과 깃허브의 차이

공통점 : 버전관리 시스템(VSC) -> 변경된 모든 코드를 기억해준다. 여러 버전을 동시에 관리해준다.

나머지는 모두 다르다.

깃 : 로컬 내에서 나의 모든 소스 코드를 관리하는 시스템.

깃허브 : 이를 업로드 하여서 다른 사람고 공유할 수 있는 시스템.

써보다 보니 느낀 점 : 깃은 말 그대로 내가 하고 있는 모든 작업을 지속적으로 관찰하며 기록해주느 느낌. 깃허브는 내가 했던 모든 작업을 인터넷 클라우드 식으로 저장하는 느낌.

실제 html 파일 및 레퍼지토리를 만들어보고 실습하면서 어려운 것이 생기면 찾아보는 식으로 진행했다.

2. reset과 revert의 차이

과거로 돌아가는 두 가지 방법

• reset : 시계를 과거로 되돌리는 방식(콕 찝어서 그 사건 이후의 커밋은 모두 삭제), 이미 푸쉬했다면 쓸 수 없음.
• revert : 특정 사건을 없었던 일로 만드는 방식(콕 찝어서 그 사건 커밋만 삭제해서 없던 일로 만듦.), 푸쉬했더라도 콘플릭트가 나는 한이 있어도 수정이 가능.
  참고 카툰

• 만일 워크 1, 2, 3, 4, 5가 있을 때 4 이후가 지워진다 : 4까진 남고 5부터 싹 지워진다. (hard, mixed에 따라 조금 씩 다름)
• 지금 현재 장소에서 아무리 지워봤자 당사자 파일은 리셋이 되지 않는다.

<이미 커밋 푸쉬한 파일 수정해서 올리기>

• 이미 커밋한 파일을 수정했다면? 그거를 다시 커밋해서 푸쉬해야한다면? 그냥 파일을 수정한 다음 똑같은 과정을 거치면 된다. 그러면 커밋 한 이름 순으로 파일이 덮이게 되고 자연스럽게 모든 작업을 깃허브에서도 볼 수 있게 된다.

(푸쉬 이후)

git init - git add - git commit - git push..

이 과정을 그대로 따라가면 내가 작업한 첫 작업 내용과 새로 푸쉬한 내용을 모두 깃허브 내에서 확인이 가능하다.

3. non-fast-foward 상황 : 즉 수정이 잦다 보니 깃허브로 푸쉬가 안 될 경우 해결하는 법>
   참고 블로그

   원인 : 깃헙에 생성된 원격 저장소와 로컬에 생성된 저장소 간 공통분모가 없는 상태에서 병합하려는 시도로 인해 발생.
   기본적으로 관련 없는 두 저장소를 병합하는 것은 안되도록 설정되어 있음.

해결 : 아래와 같이 git pull 시에 –allow-unrelated-histories 옵션 추가하여 관련 없었던 두 저장소를 병합하도록 허용

git pull origin master --allow-unrelated-histories