수정된 파일을 commit없이 push하면 github에 수정된 파일이 업로드 될까??
예를 들어,
really 라는 부분을 추가한 후, commit을 안하고 git push를 했다면,
github에 code1.txt는 really가 추가되있지 않은
상태로 남아있다.
즉, git에게 이 변화된 파일을 새로운 버전으로 기억해줘~ 라는 명령어 git commit code1.txt -am "really has been added in the first line" 해주고, git push 해줘야 비로소, 새로운 버전이 업로드된다.
이제부터 원칙을 세워서 제대로 지키지 않으면, 대혼란이 생긴다.
종종, 개인 컴퓨터의 소스코드 ( commit 기록들) 과 github 웹싸이트에서의 commit 기록들이 다른 경우가 생긴다.
이 경우 branch가 갈라지게 된다고 한다.
만약, 개인 컴퓨터의 commit 기록이 더 많다면, 이 기록들을 그냥 github으로 업데이트 해주면 된다.
(한 번 더 push를 해주면 됨)
다시 말해서, 항상 로컬(개인 컴퓨터)에서 작업하고, push만 해준다면, git이 꼬일 일은 없다.
그런데, 팀 프로젝트 ( 협업 ) 일 경우는 어떻게 해야 git이 안 꼬일까??
ex)
person A => 1 commit 하고
Person B => 3 commit 한다면,
total 4 commit이 github 웹싸이트에 쌓이게 된다.
하지만, Person B의 로컬에는 3 commit 기록만이 존재하는데... 이럴 때,
무슨 상황이 발생할 수 있을까?????
이 충돌을 막으려면, 항상 파일을 수정하기 전에 git pull을 해서 현재 버전의 파일들을 가져와야한다.
- git pull
-> push가 서버로 보내는 거라면, pull은 서버로부터 최종 수정본 파일들을 가져오는 것이다.
ex) git pull origin master
origin : (파일을 받아올 서버명)
master : (내 이름)
남이 작업한 거를 포함한 최종 수정본을 서버 쪽에서 다운 받아온다.
이후에 git log를 사용해서 commit 상태를 확인해보면, 이렇게 다른 사람이 커밋한 기록들까지 확인이 가능하다.
(한글이라서 내용이 깨졌다;;;;;)
마지막으로 git log가 길어지면, 강제로 종료해줘야 되는 경우가 생긴다.
이럴 때, :q 을 타입하면 된다.
그게 번거롭다면, 애초에 git log의 간략한 버전인 git shortlog를 사용해줘도 무방하다.
마지막으로, 다른 사람의 저장소(repository)를 이용한다면, git pull은 자유롭게 가능하지만, git push는 권한을 부여받아야 가능하다.
여기까지 git push와 git pull 끝!!
자료 출처 및 참고 자료
이번 블로그는 코드스테이츠의 강의 내용과 ZeroCho 블로그의 일부를 바탕으로 작성했으며, 그 어떠한 상업적 용도도 없음을 밝힌다.
https://www.zerocho.com/category/JavaScript
https://www.youtube.com/watch?v=0MCO9qhkSqA
https://www.geeksforgeeks.org/useful-git-commands-and-basic-concepts/
