Git & GitHub Page 블로그 만들기 - 2강
git --help <- git의 모든 명령어에 대한 설명을 출력한다.
1강에서 배운 명령어를 리마인드해본다.
echo "# github_practice" >> README.md -> README.md 파일을 만든다.
git init -> git을 시작한다.
git add README.md -> stage에 올린다.
git commit -m "first commit" -> 커밋한다. add와 commit을 해야 아래처럼 푸시할것이 생긴다.
git remote add origin https://github.com/yunkangmin/github_practice.git -> 아직 안함
git push -u origin master -> 아직 안함
git bash에서 git_practice 폴더가 있는 곳에서 아래 명령어를 차례로 입력한다.
git remote add origin https://github.com/yunkangmin/github_practice.git <- 로컬 git에 url 원격 저장소를 origin이라는 이름으로 추가해서 연결한다. 원격 저장소 이름이 'orgin'이 된다. 위와 같이 긴 url을 안쳐도 된다. alias라고 보면 된다.
git push -u origin master -> origin을 원격저장소에 푸시한다.
git remote -v -> 원격 저장소와 연결이 되었는지 확인한다. '-v'는 버전을 의미한다. 아래와 같이 origin이라고 뜨면 연결이 된 것이다. remote repository를 참조해야 되는 상황이 생기면 항상 git remote라는 키워드를 사용한다. 'origin'은 remote repository를 참조하기 위한 대명사이고 'remote'는 origin이 참조하는 remote repository와 특정 커맨드를 사용하기 위해 사용하는 git 커맨드라고 생각하면 된다. 아래를 보면 alias인 'origin'과 url이 같이 표시된다.
https://github.com/yunkangmin/github_practice에서 새로고침을 하면 아래와 같이 나온다.
푸시를 하면 README.md 파일이 웹 페이지처럼 뜬다.
아래와 같이 commit을 눌러본다.
1개의 파일이 변경됬고, 1개의 추가가 있었고 0개의 삭제가 있었다고 보여준다. 1개의 추가는 '# 오늘의 깃헙'이라는 문장을 추가했다고 보여준다.
앨와 같이 '+'을 클릭하면 나의 생각을 적을 수도 있다. 리뷰를 쓰는 것이다. (코드리뷰)
소스트리를 실행한다.
아래는 로컬 레포지토리를 추가하는 방법이다.
원격 저장소를 클론하는 방법도 있다.
github에서 내 레포지토리인 'git_practice' 레포지토리의 url을 복사한다. 아래 첫번째 입력칸에 붙여넣고 탐색을 누르면 아래 입력항목들이 자동으로 채워진다. 2번째 입력항목에는 로컬에 원격 레포지토리를 클론할 때 로컬에 저장할 위치이다. 그 다음 클론 버튼을 누른다.
고급옵션을 누르면 복제깊이라는 게 있다. 클론을 하면 다른 사람의 로그들이 그대로 온다. 오픈소스의 경우 로그들이 굉장히 많고 크게 의미가 없는 경우가 많다. 예를 들어 딥러닝 프로젝트같은 경우 우리가 기여할게 아니고 그냥 참고만 할거라면 로그들이 필요가 없다. 그래서 복제깊이를 1이라고 하면 로그중에서 제일 위에 있는 로그만 가져오겠다는 의미이다. 지금은 그대로 둔다.
클론을 하면 아래와 같이 뜬다.
그림 아래 40자리 해시코드가 뜨는데 이 것은 각자의 레포지토리의 버전이 겹치지 않게 하기 위함이다. 보통은 옆에 있는 7자리 해시코드를 많이 쓴다. 그리고 상위 항목이 있는데 이 것은 그전 버전의 7자리 해쉬값을 의미한다. 원격브랜치를 체크해제해서 원격 브랜치를 안보이게 한다.
VSCode를 열어보자.
경로를 복사한다.
git bash에서 복사한 경로에서 역슬래쉬를 슬래쉬로 바꾼 뒤 아래와 같이 입력한다.
cd C:/Users/yun/Documents/github_practice
code .
VSCode가 켜진다. 새 파일을 만든다.
아래와 같이 test.txt라는 파일을 만든다.
아래와 같이 입력한 뒤 저장한다.
소스트리를 가보면 아래와 같이 커밋하지 않은 변경사항이라고 뜬다.
스테이지에 올라가지 않은 파일이라고 뜬다.
아래와 같이 파일상태를 누르고 스테이지에 올라가지 않은 파일에서 "test.txt" 파일을 선택한 뒤 '선택 내용 스테이지에 올리기' 버튼을 클릭하면 "스테이지에 올라간 파일"에 "test.txt" 파일이 뜨는 걸 확인할 수 있다.
아래와 같이 "-"를 누르면 스테이지에서 내린다.
스테이지에 올라간 파일을 커밋할 준비가 된 것이다.
소스트리 하단에 아래와 같이 "make test file"이라고 입력후 커밋 버튼을 누른다.
다시 History에 가보면 아래와 같이 커밋한 내용이 뜨는 것을 확인할 수 있다.
아래 커밋 항목을 더블클릭하면 체크아웃이 된다.
지금 현재 마지막 버전으로 체크아웃을 했다.
VSCode를 확인해본다.
github_practice 폴더에는 test.txt는 보이지 않고 처음에 만들었던 README.md 파일이 처음으로 돌아와있다.
다시 최근 버전으로 체크아웃을 한다.
master에서 브랜치를 만들어본다.
아래 그림에 보면 "새 브랜치 체크아웃"이 보이는데 브랜치를 생성함과 동시에 체크아웃을 하겠다는 뜻이다. 체크를 안하고 생성한다.
아래 2개 중 아무거나 더블클릭하면 test_branch로 체크아웃이 된다. 왼쪽에 있는 test_branch를 더블클릭해본다.
현재 아래와 같이 test_branch가 체크아웃 된 것을 확인할 수 있다.
test_branch에서 개발을 진행해본다.
VSCode에서 test2.txt 파일을 만든다.
아래와 같이 입력한 뒤 저장한다.
소스트리에 가서 해당 파일을 스테이지에 올린 뒤 커밋을 한다. "brach first commit"이라고 입력한 뒤 커밋한다.
현재 test_branch가 master보다 한 칸 앞에 있다. 사실 그림은 일직선이지만 2갈래로 나눠진 것이다.
다시 바로 아래 있는 master 브랜치를 더블클릭한다.
VSCode에서 test3.txt 파일을 만든다.
아래와 같이 입력한 뒤 저장한다.
소스트리를 확인해 보면 아래와 같이 분기가 생긴다.
파일상태에서 스테이지에 test3.txt 파일을 올리고 커밋한다.
master와 test_branch가 각각 진행되고 있는 걸 확인할 수 있다.
VSCode에는 현재 master 브랜치가 체크아웃 되있으므로 아래와 같이 뜬다.
소스트리에서 다시 test_branch로 체크아웃하면 아래와 같이 뜨는 것을 확인할 수 있다.
master 브랜치는 test3.txt를 만들었고 test_branch 브랜치에서는 test2.txt를 만들었다. 서로 다른 파일을 만들었기 때문에 두 브랜치를 서로 합쳐도(Merge) 된다. 두 브랜치에서 같은 파일을 수정했을 때만 위험하다.
master 브랜치로 체크아웃 한 뒤 바로 아래 test_branch 우클릭한 뒤 병합을 클릭한다.
test_branch를 master 브랜치에 합치겟냐고 묻고 있다. 확인을 누른다.
확인을 누르면 다시 합쳐졌다고 뜨고 master가 맨위에 뜬다. 머지도 하나의 버전 변경이기 때문에 기록이 남는다. 자동으로 커밋 메시지도 작성이 되있다. test_branch는 이미 기능을 다했다. 기능을 다 썻는 데도 그래프에 남겨두면 나중에 버전관리 시에 힘들 수도 있다.
master 브랜치에 체크아웃이 되있는 지 확인한 뒤 아래와 같이 클릭하여 test_branch를 삭제한다.
※ 아래와 같이 안된다고 창이 뜨는 것은 test_branch에 체크아웃이 되있는데 test_branch를 삭제하려고 해서 그런 것이다. master 브랜치에 체크아웃을 하고 test_branch를 삭제해야 한다.
History를 보면 브랜치를 합친 기록만 있고 다른 브랜치가 관리되고 있지 않지 않은 것을 확인할 수 있다.
이 master 브랜치를 원격 레포지토리로 올려본다.
아래와 같이 원격 브랜치를 체크하여 원격 브랜치가 보이게 한다.
'origin/master' 표시는 현재 서버에 해당 표시만큼 올라가 있다는 의미이다. 그 위부터는 로컬에서 작업한 것이다.
맨 위에 있는 master를 서버 master에 푸시해보자.
푸시를 하면 아래와 같이 'master'와 'origin/master'가 같은 위치에 있다. 원격 저장소와 로컬이 똑같은 상태라는 것이다.
원격 저장소를 한 번 확인해보자.
아래와 같이 파일들이 늘어난 것을 확인할 수 있다.
커밋을 누르면 아래와 같이 커밋목록이 나온다.
master 브랜치에서만 브랜치를 만들 수 있는 것이 아니라 브랜치에서 브랜치를 만들 수 도 있다.
git bash에서 git status를 입력해보자.
아래와 같이 "커밋할 게 없고, 작업폴더가 깨끗하다"라고 메시지가 출력되는 것을 확인할 수 있다.
git log를 쳐보자.
소스트리와 다르게 그래프가 없이 밋밋하다.
아래는 소스트리이다. 소스트리는 깃이 어디서 어떻게 분기가 되었고 합쳐졌는지 보기가 편하다.
하지만 git bash에서도 그래프를 볼 수 있다.
git log --all --decorate --graph --oneline <- git log를 모든 브랜치를 꾸며진 상태로 그래프모드로 볼 것이고 커밋 설명을 한줄로 보겠다는 의미이다.
CLI에서는 alias라고 해서 많이 쓰는 명령어를 따로 설정해줄 수 있다.
아래와 같이 입력해본다.
git config --global alias.adog "log --all --decorate --graph --oneline" -> "git에 설정할 것데 내 컴퓨터 전체에 'adog'이라는 명령어는 앞으로 "--all --decorate --graph --oneline"을 의미하는 것이다"라는 뜻이다.
아래와 같이 명령어를 입력한다.
git adog
CLI에서 브랜치를 만들어보자.
git bash에서 아래와 같이 입력한다.
git branch <- 현재 브랜치 목록을 보여준다. '*'은 현재 체크아웃해서 작업하는 브랜치를 나타낸다.
git branch hellobranch <- 'hellobranch'라는 브랜치가 만들어진다.
소스트리를 가보자.
'hellobranch'가 만들어진 것을 확인할 수 있다.
git은 .git안에 모든 내용이 다 저장되어 있기 떄문에 CLI에서 브랜치를 만들든 소스트리에서 브랜치를 만들든 .git안에 모든 내용이 다 저장되기 때문에 어떤 환경이 되더라도 이렇게 연동이 된다.
git bash에서 아래와 같이 입력하면 브랜치가 삭제된다.
소스트리에서 아래와 같이 커밋 되돌리기를 눌러보자. 'make test file'에서는 'test.txt'파일을 생성하고 커밋했었다.
최상단에 "Revert 'make test file'"이라는 커밋이 하나 추가된 것을 확인할 수 있다.
VSCode를 보자.
아래와 같이 README.md파일과 test2.txt와 test3.txt 파일이 있다. test.txt파일은 없다. 우리가 되돌린 것은 test.txt를 만든 것을 되돌린 것이기 때문이다(해당 커밋만 되돌림). 나머지 커밋들은 살아 있다. 사실 이렇게 되면 헷갈리게 된다. 사실 revert 보다는 수정을 해서 커밋하는게 좋다.
소스트리에서 아래와 같이 머지했을 때의 해시값을 복사한다.
git bash에서 아래 명령을 실행해본다.
git reset --hard da668b2
헤드가 어디로 갔다고 출력된다.
※ git reset --help를 치면 웹 브라우저가 뜨면서 명령어 설명이 나온다.
다시 소스트리에서 해시값을 복사한 뒤 git bash에서 아래와 같이 입력한다.
git reset --hard efbea1c
소스트리에서 탭을 번갈아 누르면 git bash에서 실행한 명령이 업데이트되어 반영된다. master가 아래로 내려간 것을 확인할 수 있다. 지금 원격 저장소가 같이 보이는데 원격 브랜치를 체크해제한다.
아래와 같이 로컬만 보이고 이전 버전으로 돌아간 것을 확인할 수 있다.
현재 원격 버전과 차이가 있으니 다시 원격 버전을 받아온다. 아래와 같이 원격브랜치를 체크하고 최상단 커밋을 클릭하고 'Pull'을 클릭한다.
아래와 같이 선택하고 Pull 버튼을 클릭한다.
과거로 돌아간 뒤 다시 원상태로 돌아오는 명령어는 checkout도 있지만, 그냥 git pull해서 원격 저장소에 있는 것을 받아오는 방법도 있다.
오픈소스 기여하는 방법
원격 저장소 fork 하기
어떤 원격저장소에서 내 원격 저장소로 fork를 하는 것이다. fork를 하고 로컬에서 clone을 한 뒤 내 로컬에서 관리를 하고 origin과 upstream(origin의 origin) 2개다 remote를 만든다. 그러면 로컬은 origin, upstream 둘 다 연결이 된다. 로컬은 수정권한이 내 원격 저장소인 origin 밖에 없다. 내 원격 저장소에 수정한 다음 이 수정한 것을 upstream으로 요청을 날린다(Pull Request).
왜 Pull Request가 필요할까? 모든 사람이 쉽게 Push를 한다는 것은 프로젝트 관리가 안된다는 것이다.
Github Workflow
master는 배포버전이다.
'IT공부 > GIT' 카테고리의 다른 글
이클립스 git merge 방법 (0) | 2020.07.06 |
---|---|
Git & GitHub Page 블로그 만들기 - 3강 (0) | 2020.06.14 |
Git & GitHub Page 블로그 만들기 - 1강 (0) | 2020.06.13 |
Git Bash 한글 설정 (0) | 2020.06.13 |
Visual Studio Code 설치방법 (0) | 2020.06.13 |