Github Desktop 처음 시작하기
깃허브 데스크탑을 처음 실행하고 내 드라이브에 폴더를 하나 만들어야 한다.
이름과 설명을 쓰는데 문제는 로컬 패스를 잘 설정해줘야한다. 내가 잘보고 잘 보이는 곳에 저장소폴더를 만들어줘야한다. 나같은경우는 desktop 안에 만들어주었다. 이름은 git-for-everyone으로 해줬다.
다 만들면 이런창이 뜨게 된다.
폴더 구조로 들어가거나 finder로 들어가서 자신의 repository를 만든곳으로 가보자 그러면 거기에 만든 repository가 생성된것을 볼 수 있다.
그런데 폴더에 들어가보면 아무겄도 안나온다. 윈도우같은경우 숨겨진 폴더를 보이게 하면되고 맥 같은경우 command + shift + .(점) 키를 눌러주면 숨겨진 폴더들이 보여진다. 폴더명앞에 .(점) 이 있으면 유저한테 숨겨져서 보인다.
여기에 있는 .git 폴더안에 여러가지 파일들이 있는데 이것들이 있어야 git이 내 repository를 보고 감시한다. 만약 이걸 지우게 된다면 깃은 날 더이상 보지 않게 되는것이다. 따라서 이걸 지우면 큰일?! 난다는것.
비주얼 스튜디오에서 열어보자
열고나서 터미널에 ls -al을 치면 숨겨진 폴더구조를 볼 수있다. .git 이랑 .gitattributes가 있는걸 볼 수 있다. 여기서 hello_world.txt파일을 하나 만들어 주었다.
즉시 Github Desktop에 내가 방금 git-for-everyone 레파지토리에 만든 hello_world.txt파일이 보이는걸 알 수 있다. .git 폴더에 있는 파일들이 내 repository를 실시간으로 잘 감시하고 있기 때문이다.
비주얼 스튜디오에서 hello_word.txt안에 텍스트를 쳐보았다.
텍스트를 저장 하고 난 순간 실시간으로 Github Desktop에 내용이 바뀌는것을 확인할 수 있다. 실시간으로 감시하고 트래킹한다.
Commit (커밋) 알아보기
이렇게 하단부에 보면 난 커밋을 한적이 없는데 커밋을 한시간 전에 했다고 뜬다. 그 이유는 Github Desktop이 커밋을 자동으로 했기 때문이다. 언제? repository를 만들때 .gitattributes 파일이 보였을것이다. 이거가 만들어지는 동시에 커밋이 된다. 그래서 repository를 만들면 처음에 커밋을 하게 된다. History를 눌러보면 알 수 있다.
그래서 한번 커밋을 해보자. 아래와 같이 커밋할때 커밋 제목을 필수로 써준다. description부분은 필수가 아니어서 생략해도 된다.
그리고 commit to master버튼을 누르면 커밋이 된다.
커밋을 하고나니깐 No local changes라고 또 변화없다고 말해준다. 나의 hello_world.txt파일은 슝~ 하고 날아가서 저장되어버렸다.
히스토리를 보면 커밋들을 클릭할 수 있고 각 커밋마다 어땠었는지 볼 수 있다.
Working directory, stating area, repository area
1. working directory
워킹 디렉토리는 지금 현재 일하는곳이다. 즉 위와 같이 비주얼 스튜디오에서 hello_world.txt를 만든곳이 working directory 이다.
2. staging area
스테이징에 대해서 알아둬야 한다. 커밋을 하기전에 하나의 working directory엔 여러가지 작업한 파일들이 있을것이다. 근데 다 올려서 커밋하기는 싫을거다. 그때 staging을 잘 알아두면 편하다. Github Desktop에서는 너무나 쉽게 이 작업을 할 수 있다.
일단 두개의 새로운 파일을 만들어 줍니다. hello_hansung.txt 와 hello_seongmin.txt를 만들어 주었다.
그러면 즉각적으로 변화가 감지되어 Github Desktop에 표시가 됨을 알 수 있다. 근데 .DS_Store는 뭐지? 난 저런걸 만든적이 없는데 하고 찾아보니깐 맥 OS에서 윈도우의 tunmb.db같은 뭐시기 메타데이터같은걸 넣어놔서 자동 생성해주는 별 필요없어보이는걸 생성했다. 포렌식 관점에서 유용하게 쓰인다는데 깃에 커밋할때는 안올리고 싶다. 이럴때 스테이징에서 빼주면 된다.
스테이징에 빼주는건 너무나 쉽다. 그냥 저 체크박스를 언체크 하면 된다..... 그리고 커밋할때 날리고싶은 제목을 써주고 커밋하면 된다.
Branches(브렌치)
Github Desktop 에 들어가서 Current Branch를 클릭하면 현재 어느 브렌치에 위치하고 있는지 알려주고 새로운 브랜치를 만들 수 있다.
New Branch를 클릭하고 새로운 브렌치를 만들어보자.
bye-world 브렌치를 만들어 주었다. 브랜치는 마스터의 마지막 commit에서부터의 다른 타임라인을 뜻한다. 만들어주면 비주얼 스튜디오도 자동으로 브랜치를 bye-world로 바꿔준다.!! 이는 대단한 기능이다.... 비주얼 스튜디오의 왼쪽 하단의 구석에 어떤브렌치를 보고있는지 알려준다.
hello_seongmin.txt를 좀 수정해보겠다. bye bye world~!를 쳤더니
Github Desktop이 찰떡같이 알아먹고 Changes에 하나 바꼇다고 알려준다. 잊지 말아야할것이 지금 현재 위치는 master가 아니라 bye-world 브랜치라는 것이다.
커밋해주었다. 제목은 Update hello_seongmin.txt로 디폴드값으로 귀찮아서 그냥 이렇게 커밋했다.
자 인제 나의 bye-world 브랜치가 master 브렌치보다 앞서있다는것을 알게되었다. 이때 master브렌치로 위치를 변경한다면?
비주얼스튜디오가 현재 위치가 bye-world에서 master로 옮겨진걸 찰떡같이 알아듣고 위치를 바꿔준다.
master(main)브렌치에 있는 hello_seongmin.txt파일을 보면 원래 그대로 있었던 파일 내용을 볼 수 있다.
Branch Update
가령 예를들어 마스터브렌치에 hello_seongmin.txt를 아래와 같이 수정했다고 해보자.
Github Desktop이 찰떡같이 알아듣고 수정된부분이 있다고 알려오네요. 커밋해줍니다.
그런데 문제가 있네요. bye-world브렌치는 메인브렌치의 수정사항을 따라가야하는데 바뀐게 없습니다. 메인브렌치로부터 업데이트를 진행해줘서 메인브렌치에서 수정된 부분을 자기도 갖고 싶다고 하네요.
자 그럼 업데이트를 해줘보겠습니다. 메뉴탭에 Branch -> Update from Default Branch를 클릭해주면 끝!!!
근데 마스터 브렌치에서 수정한 내용이 길어서 bye-world브렌치에서 작성한 내용과 충돌이 일어났다..... 이럴땐 그냥 들어가서 수정을 다시 해주어야 한다...
찰떡같은 비주얼 스튜디오가 알아채고 어디가 충돌났는지 알려준다. 고맙다 야.
저 위에 작은 글씨로 Accept Current Change | Accept Incoming Change | Accept Both Changes | Compare Changes
가 보이는데 난 Accept Both Changes 를 눌르고 save했다. 그랬더니 Github Desktop이 아주 만족스럽다는 듯이 충돌이 없다고 알려주면서 머징을 계속하곘냐고 물어본다....
머징을 완료하면 main(master)브렌치에서 -> bye-world브렌치로 내용이 흘러간다. 즉 bye-world가 자기 부모브렌치로부터 내용을 업뎃받은것이다.
Branch Merging(합치기)
어짜피 브렌치는 main브렌치를 쓸건데 어떤어떤이유로 만든 잔가지 브렌치들을 main브렌치에 합쳐서 최종본을 만들 필요가 있다.
master와 bye-world브랜치를 master + bye-world할거다!!
근데 개념을 알아둬야하는게 있는데 master 에서 합치고싶은걸 가져와서 자기한테 바르는(?) 것이다. bye-world브렌치가 몸소 가서 master한테 붙는게 아니라 master가 이리와라 하고 나랑 합치자 해야 합치는거다....
일단 현재 위치를 main(master)브렌치로 옮기자.
그리고 나서 메뉴의 Branch -> Merge into Current Branch...를 클릭한다.
그러고 나면 합치고 싶은 bye-world를 클릭하면 2 commit이 bye-world로 부터 main으로 합쳐진다는 메세지가 나온다.
아래는 성공적으로 합쳐진것을 볼 수 있다.
인제 메인브렌치에 합쳐져서 쓸모가 없어진 bye-world브렌치를 삭제해 보자.
메뉴 : Branch -> Delete를 누르면 삭제할 수 있다.
'Git & GitHub' 카테고리의 다른 글
| [GITHUB]사용법 (0) | 2021.06.28 |
|---|
