상황에 따라 Github의 기능과 Git 명령어를 사용할 수 있다.
- Fork
- clone
- status
- restore
- add
- commit
- reset
- log
- pull
- push
- init
- remote add
- remote -v
git repository의 commit되지 않은 변경 사항을 취소할 수 있다.
reset HEAD <\file>
checkout -- <\file>
협업을 위한 git 개념을 이해할 수 있다.
branch, merge의 개념
remote repository에서 origin과 upstream의 차이점
-
Remote에 있는 다른 Repository에서 Fork를 해서 Remote에 있는 내 Repository에 가지고 옵니다.
-
그리고 이 코드를 수정하기 위해서는 내 컴퓨터로 가져오는 작업이 또 필요합니다. 내 컴퓨터에서 작업을 하기 위해서 clone을 합니다.
-
이제 내 컴퓨터의 작업 공간 (work space) 에서 작업에 들어간 파일들을 git의 관리 하에 있는 상태로 올려줄 수 있습니다. 이 영역을 staging area라고 말합니다. 즉, staging area에 들어오지 않은 파일은 unstaged 혹은 untracked file이라고 말하며, staging area에 있는 파일들은 staged 된 파일이라고 말할 수 있어요. 이 부분에 대해서는 나중에 더 자세하게 알아봅시다.
-
staging area에 들어온 파일들은 commit이 가능합니다. commit을 하고 나면 내 remote repository에 push 해서 commit 기록을 remote 에도 남겨줄 수 있습니다.
-
push를 완료한 후 이제 remote의 원래 레파지토리에 pull request를 보내면 Remote Repository로 내가 수정한 코드를 업로드할 수 있습니다.
1.
Git으로 관리되고 있는 git-project 라는 프로젝트가 있다고 가정을 해 봅시다.
김코딩은 이 Repository에 contribute를 하고 싶어요. 먼저 내 계정으로 이 Remote Repository를 가지고 오려고 합니다.
이 때 사용할 수 있는 기능이 Fork입니다. 포크로 집어서 복사해 온다는 의미라고 생각하시면 됩니다.
요약 : git으로 관리하는 프로젝트에 내가 contributor가 되고싶다.
상대의 remote repository에서 나의 remote repository로 fork.
2.
이제 Remote Repository에 있는 파일을 작업하기 위해서는 내 컴퓨터로 복사해오는 작업이 필요합니다. 이 때 사용할 수 있는 명령어가 바로 clone입니다.
git clone 명령어 뒤에 Repository 주소를 입력하면 해당 Repository를 내 컴퓨터(Local Repository)로 가져와서 작업할 수 있습니다.
3.
git-project를 Fork해서 마이페이지 기능을 구현했다고 가정해 봅시다. commit으로 변경 사항의 저장 기록을 남겨두는 것이 좋습니다. commit을 하기 위해서 먼저 현재 Local Repository에 변경된 파일들이 어떤 것이 있는지 확인해 보려고 합니다.
git status 명령어를 통해 staging area와 untracked files 목록에 어떤 것들이 있는지 확인할 수 있습니다.
4.
마이 페이지를 열심히 구현하던 중 기존에 있던 코드들을 훑어 보니 코드 작성 방식이 나와 달라서 통일성을 해칠 것 같아요. 내가 작업한 코드를 싹 다 밀어 버리고 새로 작업해야 할 것 같습니다. 처음 Clone을 받았던 상태로 되돌리는 방법이 있을까요?
이 때 사용할 수 있는 명령어가 바로 아까 터미널에서 확인했던 restore입니다.
commit되지 않은 Local Repository의 변경 사항을 폐기할 수 있어요.
git restore mypage.js 명령어를 통해 Work space의 변경 사항을 폐기하고 다시 처음으로 clone 받아 왔던 상태가 되었습니다.
중간 정리 : staged area에 있는 프로젝트 파일은 프로젝트 remote repository에 있던 파일을 나의 github remote repository로 fork한 것을 또 나의 local repository로 clone하였고 그것을 unstaged area에서 작업한 뒤에 staged area로 commit을 하고 git을 통해 업로드를 한다. 하지만 중간에 clone된 상태로 초기화를 시키려면 git restore (파일명)으로 초기화를 시켜준다. 이 과정은 commit 전에만 가능하다.
다시 commit가능한 상태로 작업을 완료했다면 unstaged work space에 있는 작업한 파일을 staging area로 옮겨주기 위해서는 git add (파일명) 을 터미널에 입력한다. 
그리고나면 staging area에 파일이 올라갔기 때문에 commit이 가능한 상태로 변경되었다.
어떤 사항이 변경됐는지 간단한 메모를 통해서 버전의 변경 기록들을 관리할 수 있습니다.
위 그림처럼 스냅샷을 찍듯이 변경된 이력을 언제, 누가, 어떻게 변경이 되었는지 저장할 수 있어요.
commit 메시지를 작성하기 위해서는 -m 옵션을 통해 코멘트를 작성할 수 있습니다. git commit -m ‘mypage 구현’ 이라는 메시지로 commit 을 남겨 볼까요?
참고로 commit 메시지 작성 방법에 대해서는 굉장히 다양한 기준과 컨벤션이 있기 때문에 좋은 commit 메시지를 작성하기 위한 기준을 구글링해 보시는 것을 추천합니다.
추천 링크 : https://chris.beams.io/posts/git-commit/
git 3가지 영역상태
수정된 파일을 modified라고하고 수정이 끝났으니 add하면 staging area로 가고 commit을 하면 local repository로 간다. unmodified는 gir이 관리하지 않는 내 컴퓨터의 다른 파일에서 넣거나 clone한 첫 파일 이라고 해야하나 .. 헷갈린다 하지만 fork해서 clone으로 내 컴퓨터의 locla repositoy 안의 unstaged area로 가져온 파일은 tracked area에 있을것이라고 생각된다...
아직 Remote Repository에 업로드 되지 않고 Local Repository에만 commit 해 놓은 기록이라면 reset 명령어를 통해서 commit 을 취소할 수 있습니다.
git reset 명령어는 다음과 같습니다.
git reset 를 했을 때 터미널 창에는 변화가 없습니다.
git reset HEAD^ 이라는 명령어로 가장 최신의 commit 을 취소할 수 있습니다. 우리는 방금 올린 하나의 commit 만 취소하면 되기 때문에 git reset HEAD^ 명령어를 입력하는 것이 가장 적합하겠죠?
HEAD는 연속된 ^의 shortcut 입니다. 예를 들어 HEAD3은 HEAD^^^와 같습니다. 즉 이 상황에서는 HEAD~1 명령어도 가능합니다.
(추가적으로 hard, soft 옵션도 있는데 reset 에 대해서 더 공부하고 싶으시다면 git reset --hard vs --soft 등의 검색어로 구글링 한 후 실습해 보시는 것을 추천드립니다.)
마지막으로 commit을 완료했다면 local repository로 업로드가 되었을거고, 그리고 pull request를 하려면 remote repository로 push를 하여(git push orgin branch 명령어 사용) 올리고 pull request를 신청한다.
(git push origin main, git push pair dev 등 git push 뒤에 따라오는 명령어는 상황에 따라 변경할 수 있습니다.)
git log : 이 명령어는 내가 commit한 내역을 볼 수 있다.
Pull Request는 내가 Remote Repository에 Push 해 놓은 변경 사항에 대해서 함께 작업하는 다른 사람들에게 알리는 것을 말합니다. 현업에서는 줄여서 PR이라고 합니다.
내 Remote Repository에 Push를 했더니 GitHub 웹사이트 상의 해당 Remote Repository에 Compare & pull request 라는 버튼이 뜨네요.
해당 화면에 작업해서 Push 해 놓은 내용을 간단하게 요약해서 알려줌으로서 동료들이 코드를 보지 않고도 어떤 내용인지 쉽게 파악할 수 있게 만들어 줍시다.
이렇게 Pull Request를 날려놓으면 여러 동료들의 리뷰도 받을 수 있고 내가 올린 작업을 기존 코드에 병합할 수도 있습니다.
