GitHub로 남의 프로젝트에 감놓고 배놓기

Posted by 나에요임마
2017. 8. 5. 00:27 Program/GitHub

GitHub를 사용하여 오픈소스 프로젝트에 어떻게 참여할 수 있는 방법을 정리한다. GitHub에 계정이 있어야 하고 Git을 어느정도 써 본 사람이어야 한다.

원문은 Rich Jones의 How to GitHub: Fork, Branch, Track, Squash and Pull Request 이다.

gun.io

저자 공지사항

GitHub에서 활동하는 개발자 중 저자의 구인구직 사이트에 등록하면 구직하는 사람과 연결해준다고 한다. 관심있는 사람은 둘러보시길!

자 시작!

GitHub에서 저장소를 새로 하나 만들면 아래와 같은 설명을 보여준다.

GitHub

GitHub은 새로운 프로젝트와 새로운 저장소를 만들었을 경우에 대한 설명은 친절하게 해주고 있다. 하지만 다른 프로젝트를 개선하고 참여하는 방법에 대해서는 그다지 좋은 설명을 해주고 있지 않다. 이 글은 그러한 점에서 도움이 될 것이다.

우선 시작하기 전에 고쳐보고 싶은 프로젝트를 하나 골라보자. GitHub에서 프로젝트를 찾아서 코드도 둘러보고 익숙한 개발방식을 갖고 있는지 확인도 해보고 커밋 로그도 살펴보고 참여하는 사람이 어떤 사람인지도 살펴들 보자.

네트워크

GitHub Network

네트워크 그림이다. 'mobile' 이라는 브랜치에서 누군가 열심히 작업을 하고 있기 때문에 'mobile'에 대한 일을 하는 수고는 하지 않는것이 좋을듯 하다.

우선 해야할 일은 프로젝트의 네트워크를 확인해보는 것이다. 네트워크를 확인함으로서 누가 어떤일을 하고 있는지를 살펴볼 수 있다. 네트워크를 한참 들여다보면 고쳐보고자 하던 부분도 이미 다른이가 하고 있는지 알수도 있다. 프로젝트 활동상황도 알 수 있으며 고친 부분이 어떻게 프로젝트에 Merge되는지도 알 수 있다.

이슈 등록

GitHub Issue 이슈가 왔어요!

프로젝트 화면에서 이슈메뉴로 가 봅시다. 얼마나 많은 이슈가 있는지 그리고 내가 고쳐보고픈 부분이 이미 이슈로 등록이 되어있는지 알 수 있다.

많은 사람들이 잊기 쉬운 이 과정이 왜 중요하냐면 고친점을 보내는 사람들은 보통 프로젝트의 관리자 즉 메인테이너가 같은 문제로 고민중이라는 점을 전혀 고려하지 않기 때문이다.

고쳐볼 부분이 아직 이슈로 등록이 안되어있다면 새로 하나 등록하자. 이슈를 등록할때는 메인테이너에게 공손히 프로젝트에 감사하다는 마음을 갖고 고쳐보고자 하는 버그나 개선사항을 적는거다.

메인테이너가 만들어진 이슈에 대한 댓글로 도움이 될 만한 점을 달아줄지도 모른다.

Fork로 저장소 분리

Hardcore Fork

'Fork' 버튼을 누르는 희열!! 복제된 저장소가 내 가슴속으로 들어왔다. 나의 복제된 저장소 페이지로 가보라! Clone해서 내려받을 수 있는 주소가 적혀있을 것이다. 바로 그냥 내려받는거다.

git clone **your ssh/git url**

Fork로 만든 저장소와 원본 저장소 연결

Fork Fork가 이거냥!

이 과정이 꼭 필요한건 아니다. 하지만 단 한번만 이 프로젝트에 참여할 것이 아니라면 이 과정을 해두면 정말 쓸모있다. 아래 명령을 실행하여 원래 프로젝트 저장소를 'upstream'으로 등록해두면 원래 프로젝트의 변경사항을 계속 받아볼 수 있다. 'upstreamname'과 'projectname' 부분을 실제 프로젝트에 맞게 적당히 바꿔서 명령을 실행한다.

git remote add --track master upstream git://github.com/upstreamname/projectname.git

자 이렇게 하면 upstream 이라는 리모트로 등록이 된다.

git fetch upstream

이렇게 하면 원래 프로젝트의 최신 내용을 받아오고

git merge upstream/master

이렇게 하면 최신 내용을 현재 작업하고 있는 브랜치에 Merge하게 된다. 짜잔!

개발용 브랜치

Old Internet 그 옛날의 인터넷이 생각나지 않나요들?

자 이제 고쳐야 할 부분에 집중하기 위해 master 브랜치에서 새로운 브랜치로 checkout할 때가 왔다. Pull Request는 Branch 단위로 하기 때문에 브랜치를 잘 만들어두는게 중요하다. 고쳐야 할 이슈가 여럿이라면 브랜치도 여러개 이어야 겠다. 아래처럼 해서 브랜치를 만들자:

git branch newfeature

해당 브랜치로 바꾸려면 즉 checkout 하려면:

git checkout newfeature

새로 만든 브랜치로 변경했다. 현재 위치한 브랜치를 확인하려면 git branch를 실행해보라.

Hack!

이제 실제 고치는 작업을 하자. 계획했던 고칠점이 맘에 들 때 까지 될대로 코드를 고쳐보고 테스트해보고 행복의 경지에 이르러보자. 음하하하~

커밋 하나로 합치기

Squash 이게 '스쿼시'냥!

여러분도 나처럼 엄청나게 커밋을 해댄다면 커밋 메시지는 안봐도 거지같을게('동작함!', '안돌아감', '열여덟', '후아~', 등등) 뻔하다. 사실 이런 습관은 좋지 않지만 고치고 싶은 생각도 없고 이런 습관을 가진 사람도 많이 봤다.

Pull Request를 보내기 전에 여러 커밋을 하나 혹은 몇 개의 커밋으로 모아서 정리하고 싶을 수도 있다. 하여 git rebase 명령을 써 볼 것이다. 우선 git log로 커밋 메시지를 확인해보고 어떻게 정리할 지 생각해둔다. 마지막 3개의 커밋을 하나로 합치려면 아래와 같은 명령을 실행한다:

git rebase -i HEAD~3

명령을 실행하면 Git은 기본 편집기를 불러내서 아래같은 내용을 보여준다.

pick df94881 Allow install to SD
pick a7323e5 README Junkyism
pick 3ead26f rm classpath from git

각 줄이 각 커밋에 해당하는데 하나로 합치려면 아래와 같이 내용을 수정한다.

pick df94881 Allow install to SD
squash a7323e5 README Junkyism
squash 3ead26f rm classpath from git

내용을 저장하고 편집기를 종료하면, 새로운 내용으로 편집기가 다시 뜰텐데 그때는 새로 하나로 만들어진 커밋 메시지를 입력하는 것이다. 거지같은 커밋이 깔끔하게 정리된 새 커밋으로 재탄생했다. 만쉐이~ 이제 Pull Request를 해도 부끄럽지 않겠다.

Pull Request 보내기

단장하고 커밋해놓은 브랜치를 서버 저장소로 아래와 같은 명령으로 보낸다:

git push origin newfeature

그리고 GitHub 사이트로 가서 새로 만든 브랜치로 이동한다. 보통 기본으로 master 브랜치로 되어있을 것이다.

Pull Request Pull Request를 보내자

브랜치로 이동한 것을 확인하고 'Pull Request' 버튼을 누르자. 다음과 같은 화면이 나오는데 브랜치에서 변경한 내용에 대한 설명을 적어주고 'Submit Pull Request' 버튼을 눌러준다.

Pull RequestPull Request 설명 달기

룰루랄라~ 끝났다. 사실 완전히 다 끝난건 아니다. 'Pull Request' 보낸 커밋에 고칠점이 있다면 메인테이너는 'Pull Request'를 바로 받아주지 않고 해당사항을 고쳐달라고 할 것이다. 메인테이너가 'Pull Request'를 닫지(Clone) 않는 한 해당 브랜치로 커밋을 Push하면 다행히도 'Pull Request' 속으로 들어간다.

Pull Request 받아서 Merge하기

보너스! Pull Request를 받았을 때에는 어떻게 Merge하면 되는가! 그냥 버튼 하나만 누르면 된다. 쉽네. GitHub이 버튼 한 번만 누르면 모든게 자동으로 되도록 잘 만들어놨다. 간혹, 자동으로 되지 않을때가 있는데 그때는 직접 명령어를 써서 Merge해야 한다.

git checkout master
git remote add contributor git://github.com/contributor/project
git fetch contributor
git merge contributor/newfeature
git push origin master

이렇게 하면 다른사람이 수정한 내용을 메인 master 브랜치로 merge하게 된다.

Pull Request를 받아주지 않는 이유

이 부분은 원본 페이지를 확인하시라!

'Program > GitHub' 카테고리의 다른 글

Git 주요 명령어 정리  (0) 2017.12.06
완전 초보를 위한 깃허브  (0) 2017.08.05

완전 초보를 위한 깃허브

Posted by 나에요임마
2017. 8. 5. 00:12 Program/GitHub

원문 : 1. GitHub For Beginners: Don’t Get Scared, Get Started 2. GitHub For Beginners: Commit, Push And Go

[중략] 깃의 필요성 등에 대해 역설함.

컴퓨터를 사용하는 모든 지식 근로자는 깃허브를 사용할 이유가 있다. 만약, 당신이 깃허브 사용법을 이해하는 것을 포기했다면, 이 글은 당신을 위한 것이다.

깃허브에 대한 중 주된 오해 중 하나는 그것이 컴퓨터 언어나 컴파일러나 마찬가지로 코딩과 관련된 개발툴이라는 것이다. 그러나, 페이스북이나 플리커와 같은 소셜 네트워크와 크게 다르지 않다. 프로필을 만들고 공유할 프로젝트를 올릴 수 있고, 다른 계정들을 팔로우하여 다른 사용자들과 소통할 수 있다. 많은 사용자가 프로그램과 코드 프로젝트를 저장하지만, 당신이 자랑할만한 프로젝트 폴더의 텍스트 문서나 다른 형식의 화일을 저장하는 것을 막는 것도 없다.

[중간요약] : 깃허브에 올리는 모든 것은 사용자가 지적재산권을 갖으며, 코드에 대한 어떤 지식이 없어도 깃허브를 사용할 수 있다.

1. 깃이 뭐지?

깃허브의 심장에서 작동되는 소프트웨어인 깃(Git: 재수없고 멍청한 놈, 자식)을 만든 유명한 소프트웨어 개발자 리누스 토발즈에 감사한다. 깃은 프로젝트의 어떤 부분도 겹쳐쓰지 않게 프로젝트의 변경을 관리하는 버전관리 소프트웨어이다.

왜 깃같은 것을 사용해야 하나? 당신과 동료가 동시에 같은 웹사이트에서 페이지를 업데이트하고 있다고 하자. 당신이 무언가를 변경하고 저장한 다음 웹사이트에 그것을 업로드한다. 지금까지는 좋았다. 문제는 동료가 동시에 같은 페이지에서 작업할 때이다. 누군가의 작업은 겹쳐쓰여질 것이고 지워질 것이다.

깃과 같은 버전관리 앱은 그런 일을 방지한다. 당신과 동료는 같은 페이지에 각자의 수정사항을 각각 업로드할 수 있고, 깃은 두 개의 복사본을 저장한다. 나중에, 당신들은 그대로 어떤 작업도 잃어버리지 않고 변경사항들을 병합할 수 있다. 깃은 이전에 만들어진 모든 변경사항의 “스냅샷”을 저장하기 때문에 이전 시점의 어떤 버전으로 되돌릴 수도 있다.

깃을 사용할 때 어려운 점은 90년대 해커와 같이 코드를 타이핑하는 명령어(커맨드 라인 - 맥 사용자라면 터미널)를 사용하여 접근해야하는 것이다. 이것은 요즘 컴퓨터 사용자에겐 까다로운 일일 수는 있다. 이제 깃허브를 들여다보자.

깃허브는 두 가지 방식으로 깃을 더 편리하게 해준다. 먼저, 깃허브 소트프웨어를 다운로드하면, 로컬에서 당신의 프로젝트를 관리할 수 있게하는 비주얼 인터페이스를 제공한다. 두번째는, Github.com에 계정을 생성하면 웹에서 프로젝트를 버전관리할 수 있으며, 평가측정 등의 소셜 네트워크 기능을 사용할 수 있다.

다른 깃허브 사용자의 프로젝트를 둘러볼 수 있고, 그것들을 변경하거나 배우기 위해 자신만의 복사본을 다운로드할 수도 있다. 다른 사용자도 당신의 공개 프로젝트에 대해 같은 걸 할 수 있으며 에러를 발견해서 해결책을 제안할 수도 있다. 어느 경우든, 깃이 모든 변경사항에 대한 “스냅샷”을 저장하기 때문에 어떤 데이타도 잃어버리지 않는다.

깃을 배우지 않고 깃허브를 사용할 수 있지만, 사용하는 것과 이해하는 것은 큰 자이점이 있다. 깃을 이해하기 전에도 깃허브를 사용할 수 있으며, 나도 진짜로 이해하는 것은 아니다. 이 튜토리얼에선, 커맨드 라인에서 깃을 사용하는 것을 배울 것이다.

2. 기본 용어

이 튜토리얼에서 반복적으로 사용하려고 하는 몇 개의 용어가 있다. 나도 배우기 시작하기 전에는 들어본 적이 없는 것들이다. 여기 중요한 것들이 있다:

커맨트 라인(Command Line): 깃 명령어를 입력할 때 사용하는 컴퓨터 프로그램. 맥에선 터미널이라고 한다. PC에선 기본적인 프로그램이 아니어서 처음엔 깃을 다운로드해야 한다(다음 섹션에서 다룰 것이다). 두 경우 모두 마우스를 사용하는 것이 아닌 프롬프트로 알려진 텍스트 기반 명령어를 입력한다.

저장소(Repository): 프로젝트가 거주(live)할 수 있는 디렉토리나 저장 공간. 깃허브 사용자는 종종 “repo”로 줄여서 사용한다. 당신의 컴퓨터 안의 로컬 폴더가 될 수도 있고, 깃허브나 다른 온라인 호스트의 저장 공간이 될 수도 있다. 저장소 안에 코드 화일, 텍스트 화일, 이미지 화일을 저장하고, 이름붙일 수 있다.

버전관리(Version Control): 기본적으로, 깃이 서비스되도록 고안된 목적. MS 워드 작업할 때, 저장하면 이전 화일 위에 겹쳐쓰거나 여러 버전으로 나누어 저장한다. 깃을 사용하면 그럴 필요가 없다. 프로젝트 히스토리의 모든 시점의 “스냅샷”을 유지하므로, 결코 잃어버리거나 겹쳐쓰지 않을 수 있다.

커밋(Commit): 깃에게 파워를 주는 명령이다. 커밋하면, 그 시점의 당신의 저장소의 “스냅샷”을 찍어, 프로젝트를 이전의 어떠한 상태로든 재평가하거나 복원할 수 있는 체크포인트를 가질 수 있다.

브랜치(Branch): 여러 명이 하나의 프로젝트에서 깃 없이 작업하는 것이 얼마나 혼란스러울 것인가? 일반적으로, 작업자들은 메인 프로젝트의 브랜치를 따와서(branch off), 자신이 변경하고 싶은 자신만의 버전을 만든다. 작업을 끝낸 후, 프로젝트의 메인 디렉토리인 “master”에 브랜치를 다시 “Merge”한다.

3. 주요 명령어

깃은 리눅스와 같은 큰 프로젝트를 염두에 두고 디자인되었기 때문에, 깃 명령어는 아주 많다. 그러나, 깃의 기본을 사용할 때에는 몇 개의 명령어만 알면된다. 모두 “git”이란 단어로 시작된다.

git init: 깃 저장소를 초기화한다. 저장소나 디렉토리 안에서 이 명령을 실행하기 전까지는 그냥 일반 폴더이다. 이것을 입력한 후에야 추가적인 깃 명령어들을 줄 수 있다.

git config: “configure”의 준말, 처음에 깃을 설정할 때 가장 유용하다.

git help: 명령어를 잊어버렸다? 커맨드 라인에 이걸 타이핑하면 21개의 가장 많이 사용하는 깃 명령어들이 나타난다. 좀 더 자세하게 “git help init”이나 다른 용어를 타이핑하여 특정 깃 명령어를 사용하고 설정하는 법을 이해할 수도 있다.

git status: 저장소 상태를 체크. 어떤 화일이 저장소 안에 있는지, 커밋이 필요한 변경사항이 있는지, 현재 저장소의 어떤 브랜치에서 작업하고 있는지 등을 볼 수 있다.

git add: 이 명령이 저장소에 새 화일들을 추가하진 않는다. 대신, 깃이 새 화일들을 지켜보게 한다. 화일을 추가하면, 깃의 저장소 “스냅샷”에 포함된다.

git commit: 깃의 가장 중요한 명령어. 어떤 변경사항이라도 만든 후, 저장소의 “스냅샷”을 찍기 위해 이것을 입력한다. 보통 “git commit -m “Message hear.” 형식으로 사용한다. -m은 명령어의 그 다음 부분을 메시지로 읽어야 한다는 것을 말한다.

git branch: 여러 협업자와 작업하고 자신만의 변경을 원한다? 이 명령어는 새로운 브랜치를 만들고, 자신만의 변경사항과 화일 추가 등의 커밋 타임라인을 만든다. 당신의 제목이 명령어 다음에 온다. 새 브랜치를 “cats”로 부르고 싶으면, git branch cats를 타이핑한다.

git checkout: 글자 그대로, 현재 위치하고 있지 않은 저장소를 “체크아웃”할 수 있다. 이것은 체크하길 원하는 저장소로 옮겨가게 해주는 탐색 명령이다. master 브랜치를 들여다 보고 싶으면, git checkout master를 사용할 수 있고, git checkout cats로 또 다른 브랜치를 들여다 볼 수 있다.

git merge: 브랜치에서 작업을 끝내고, 모든 협업자가 볼 수 있는 master 브랜치로 병합할 수 있다. git merge cats는 “cats” 브랜치에서 만든 모든 변경사항을 master로 추가한다.

git push: 로컬 컴퓨터에서 작업하고 당신의 커밋을 깃허브에서 온라인으로도 볼 수 있기를 원한다면, 이 명령어로 깃허브에 변경사항을 “push”한다.

git pull: 로컬 컴퓨터에서 작업할 때, 작업하고 있는 저장소의 최신 버전을 원하면, 이 명령어로 깃허브로부터 변경사항을 다운로드한다(“pull”).

4. 처음으로 깃/깃허브 설정하기

먼저, GitHub.com에 가입한다. 다른 소셜 네트워크에 가입하는 것처럼 간단하다.

로컬 컴퓨터에서 작업하려면 깃을 설치해야 한다. 필요에 따라 윈도우, 맥, 리눅스 용 깃을 설치하라.

이제 커맨드 라인으로 넘어갈 시점이다. 윈도우에선 방금 설치한 Git Bash 앱으로, OS X에선 터미널로 시작한다. 깃에 자신을 소개할 차례이다. 다음 코드를 타이핑한다:

git config --global user.name "Your Name Here"

물론, “Your Name Here”의 인용부호 안에 자신의 이름을 넣어야 한다.

다음엔, 당신의 이메일을 말해준다. 조금 전에 GitHub.com을 가입할 때 사용한 이메일이어야 한다. 다음과 같이 한다:

git config --global user.email "your_email@youremail.com"

이것이 로컬 컴퓨터에서 깃을 사용할 때 필요한 모든 것이다. 원한다면, 깃과 소통할 때마다 GitHub.com 계정에 로드인하는 것을 요청하지 않도록 깃을 설정할 수 있다. 이것과 관련된 풀 튜토리얼은 깃허브에 있다.

5. 온라인 저장소 만들기

이제 프로젝트가 거주할 장소를 만들 시점이다. 깃과 깃허브는 당신의 프로젝트와 그 화일들, 깃이 저장한 화일들의 모든 버전에 접근할 수 있는 디지털 디렉토리나 저장공간을 저장소(repository 줄여서 repo)라고 한다.

GitHub.com으로 돌아가서 사용자명 다음에 있는 작은 책 아이콘을 클릭한다. 혹은, 모든 아이콘이 다 똑같아 보인다면 new repository page로 간다. 저장소에 짧고 기억할만한 이름을 준다. 재미삼아 public으로 해본다.

“Initialize this repository with a README.” 앞의 체크박스는 신경쓰지 않는다. Readme 화일은 보통 프로젝트에 관해 설명하는 텍스트 화일이다. 여기선 연습삼아 로컬에서 자신의 Readme 화일을 만들 것이다.

녹색의 “Create Repository” 버튼을 클릭한다. 이제 프로젝트가 거주할 온라인 공간을 가진 것이다.

6. 로컬 저장소 만들기

온라인에서 거주하는 프로젝트의 공간을 방금 만들었다. 그러나, 그 곳이 작업할 공간은 아니다. 컴퓨터에서 작업할 것이므로, 로컬 디렉토리에 만들 저장소에 실제로 미러링해야 한다.

먼저 다음을 타이핑한다:

mkdir ~/MyProject

mkdir은 make directory의 준말이다. 깃 명령어는 아니고 비주얼 인터페이스 이전 시대에 일반적인 탐색 명령어이다. ~/는 나중에 찾기쉽게 컴퓨터 화일 구조의 최상위 단계에 저장소를 만드는 것이다. 브라우저에서 ~/를 입력하면 로컬 컴퓨터의 최상위 단계 디렉토리가 보일 것이다. 맥의 크롬인 경우 Users 폴더를 보여준다.

깃허브 저장소와 동일하게 MyProject로 이름짓는 것을 주목한다. 당신도 그렇게 해라.

타이핑한다:

cd ~/MyProject

cd는 change directory를 뜻하며, 역시 탐색 명령어이다. 방금 디렉토리를 만들었고, 그 디렉토리로 옮겨 들어갔다.

이제 마침내 깃 명령어를 사용한다. 다음 줄에 타이핑한다:

git init

init은 “initialize(초기화)”를 뜻한다. 이 코드를 입력하면 이 디렉토리를 로컬 깃 저장소라고 컴퓨터에게 말해주는 것이다. 폴더를 열면 - 이 새로운 깃 디렉토리는 전용 저장소 안에 숨겨진 화일 하나이기 때문에 - 어떤 차이를 보지 못할 것이다.

그러나, 컴퓨터는 이제 이 디렉토리를 Git-ready로 인식하고, 깃 명령어를 입력할 수 있다. 이제 프로젝트가 거주할 온라인과 로컬 저장소를 모두 가졌다.

이제는 깃허브에 첫번째 커밋을 만들어서 프로젝트의 첫 부분을 추가하자. 다음 화면과 같은 MyProject라는 저장소를 만들었었다.

다음을 입력한다:

touch Readme.txt

역시 깃 명령어가 아니다. 또 하나의 기본 탐색 명령어이다. touch는 “create 만드는 것”을 뜻한다. 그 뒤에 무엇을 적던지 간에 만들어지는 것의 이름이다. 파인더나 시작메뉴에서 해당 폴더로 가보면 Readme.txt 화일이 만들어진 것을 볼 것이다.

다음을 입력:

git status

커맨드 라인에서 다음과 유사한 몇 개의 텍스트 줄을 응답할 것이다:

# On branch master
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#         Readme.txt

뭐지? 먼저, 당신은 프로젝트의 master 브랜치 상에 있다. “branched off”하지 않았기 때문에 당연하다. 두번째론, Readme.txt이 “untracked” 화일로 리스트되었다. 현재는 깃이 무시한다는 것을 뜻한다. 깃이 주목하게 하기 위해, 다음을 입력한다:

git add Readme.txt

커맨드 라인이 주는 힌트를 보면 첫번째 화일을 추가했다는 것을 알 수 있다. 지금까지의 프로젝트 “스냅샷”을 찍거나, “커밋”할 시점이다.

git commit -m “Add Readme.txt”

-m 플래그는 이미 말했듯이, 뒤따르는 텍스트는 메시지로 읽어야 한다. 커밋 메시지가 현재형인 것을 주목한다. 버전관리는 시간에 대해 유연성을 가지므로 현재형으로 작성해야 한다. 더 이전 버전으로 되돌아갈 수 있으므로 커밋을 했던 것을 적는 것이 아니라, 커밋한 것을 적어야 한다.

이제, 로컬에서 작은 작업을 하고 깃허브에 첫 커밋을 ‘push’할 때이다.

“잠깐, 온라인 저장소를 로컬 저장소와 연결하지 않았다.”라고 생각할지 모르겠다. 당신이 맞다. 로컬 저장소와 온라인 저장소의 첫번째 실제 연결을 만들어보자.

7. 로컬 저장소와 깃허브 저장소 연결하기

먼저, 깃에게 온라인 어딘가가 실제 원격(remote) 저장소인지를 말해주어야 한다. git add명령어를 사용하기 전까지는 깃이 우리 화일을 인식하지 않는 것과 마찬가지로, 원격 저장소도 인식하지 않을 것이다.

https://github.com/username/myproject.git에 “MyProject”라는 이름의 깃허브 저장소가 있다고 가정해보자. 물론, username은 자신의 깃허브 사용자명으로 바꿔야 한며, 저장소 제목도 자신의 깃허브 저장소 제목으로 바꿔야한다.

git remote add origin https://github.com/username/myproject.git

첫 부분은 익숙하다; git add를 이미 화일과 써봤다. 화일이 비롯된(originated) 곳에서 새로운 위치를 가리키기 위해 origin이란 단어를 더했다.(해석이 약간 명료하지 못함. 원문: We’ve tacked the word origin onto it to indicate a new place from which files will originate.) remote는 origin의 설명자(descriptor)이며, origin이 로컬 컴퓨터가 아닌 온라인 어딘가를 가리킨다는 것이다.

역자주: 간단히 말하면, 온라인에 있는 https://github.com/username/myproject.git 저장소를 origin으로 지정한다.

이제 깃이 원격 저장소가 있는 곳과 로컬 저장소가 변경사항을 어디로 보낼지 알게되었다. 확인하기 위해, 다음을 입력:

git remote -v

이 명령어는 로컬 저장소가 알고있는 원격 origin에 대한 모든 항목을 보여준다. 지금까지 함께 하였다면, 단 하나이어야 한다. 두 개가 리스트된 것은 정보를 _push_하고 _fetch_할 수 있는 것을 뜻한다.

이제 깃허브 원격 저장소로 변경사항을 업로드나 “push” 해보자. 쉽다. 입력:

git push

커맨드 라인에서 여러 줄에 걸쳐 연달아 내놓을 것이고, 마지막으로 “everything up-to-date.”과 같은 것을 밷아낼 것이다.

단순 명령어만 입력했기 때문에 주의(warning) 메시지가 나온다. 내 저장소의 master 브랜치를 지정하도록 하려면 git push origin master로 입력할 수 있다. 지금은 하나의 브랜치만 있기 때문에 그렇게 하지 않았다.

깃허브에 다시 로그인한다. 이제 오늘 만든 커밋이 얼마나 되는지 깃허브가 추적하는 것을 알 수 있다. 저장소를 클릭해보면 로컬 저장소에서 만들었던 동일한 Reame.txt를 가지고 있을 것이다.

8. All Together Now!

축하한다, 이제 공식적으로 깃 사용자가 되었다! 저장소를 만들고 변경사항을 커밋할 수 있다. 이것이 대부분의 입문 튜토리얼의 끝나는 지점이다.

[중략] 이 정도면 회사에서 사장이 깃을 사용할 것을 요구하면 당장 디자인 화일을 깃허브에 올릴 정도는 될 것이라고 이야기하면서 디자인 화일 명 하나를 중심으로 여태 해온 것을 반복함.

9. 역자 요약

git config --global user.name "이름"
git config --global user.email "깃허브 메일주소" // 매번 물어보는 귀찮음을 피하기 위해 설정.

mkdir ~/MyProject   // 로컬 디렉토리 만들고
cd ~/myproject      // 디렉토리로 들어가서
git init            // 깃 명령어를 사용할 수 있는 디렉토리로 만든다.
git status          // 현재 상태를 훑어보고
git add 화일명.확장자  // 깃 주목 리스트에 화일을 추가하고 or
git add .           // 이 명령은 현재 디렉토리의 모든 화일을 추가할 수 있다.
git commit -m “현재형으로 설명” // 커밋해서 스냅샷을 찍는다.

git remote add origin https://github.com/username/myproject.git // 로컬과 원격 저장소를 연결한다.
git remote -v // 연결상태를 확인한다.
git push origin master // 깃허브로 푸시한다.

10. Git Resources

11. GitHub Resource


'Program > GitHub' 카테고리의 다른 글

Git 주요 명령어 정리  (0) 2017.12.06
GitHub로 남의 프로젝트에 감놓고 배놓기  (0) 2017.08.05

디버깅

Posted by 나에요임마
2017. 8. 2. 01:30 Program/Visual Studio

*디버깅(Debugging)이란?

 

오류 수정. 컴퓨터 프로그램의 잘못을 찾아내고 고치는 작업. 일단 작성된 프로그램들이 정확한가(즉 잘못 작성된 부분이 없는가)를 조사하는 과정. 이 작업은

① 기계에 넣기 전에 책상 위에서 주어진 문제대로 프로그램이 작성되었는가를 순서도와 메모리의 작업 영역표에 실제 데이터를 넣어서 수동 작업으로 정확한 결과가 나오는가를 검사하는 데스크 상의 검사와

② 컴퓨터를 이용한 표준적 데이터로 메인 루틴을 조사하는(이때 예외 사항이 포함된 데이터와 오류가 있는 데이터도 함께 이용한다) 컴퓨터를 사용한 검사,

③ 실제 데이터를 사용하는 조사 등 세 단계로 나누어 진행된다. 또한 이 작업은 프로그램의 한 스텝 한 스텝씩을 추적해가는 추적(trace) 기능을 이용해도 좋지만, 프로그램 처리 내용이나 기억 장치의 내용을 덤프하여 디버그 보조기(debugging aid)를 이용하는 것이 바람직하다.

 

출처

컴퓨터인터넷IT용어대사전, 전산용어사전편찬위원회 엮음, 2011.1.20, 일진사

한마디로 프로그램 오류를 잡는 건데.. 로직이 복잡해질 수록 오류잡기가 쉽지 않죠.

 

Visual Studio 디버깅 기능을 이용하면 한결 편하게 오류를 찾아낼 수 있습니다.

 

 

 

 

 

우선 디버거 사용법을 위한 간단한 예제를 입력했습니다. (참고로 Visual Studio 버전은 2010입니다.)

 

 


 

그럼 다음엔 디버깅을 시작할 시작점을 찍어 볼까요??

 

알아보고 싶은 코드에 커서를 놓고

 

F9 키를 누르거나 Debug > Toggle Breakpoint 메뉴를 클릭합니다.

 

 

빨간 밑줄친 부분에서 보듯 커서가 있는 부분 좌측에 빨간 점이 찍힌 것을 확인 할 수 있답니다.

 

 

 

이후  F5 키를 누르거나

 

메뉴에서 Debug > Start Debugging을 선택하면 디버깅 모드로 진!!합니다.

 

 

 

디버깅 모드로 진입하면 아래 캡처화면과 같은 화면을

 

 볼 수 있어요~

 

 

①번 노란 화살표는 현재 지점을 가리키는 커서

 

②번은 늘 보던 콘솔 실행화면이죠

 

③번은 변수의 값의 변화를 확인할 수 있는 창입니다

 

④번은 사용자가 직접 변수이름을 입력해서 입력한 변수만 값의 변화를 지켜볼수 있구요

 

⑤번은 메모리의 모습을 보여주는 창이에요!

 

③④⑤창이 보이지 않으면 Debug > Windows 에서 해당 창을 불러올 수 있어요!

 

 

 

여기서 F11 키를 입력하면 한줄씩 실행을 해볼수 있습니다.

 

우선 F11 키를 한번 입력했을 때의 화면입니다.

 

 

① 여기서 노란색 화살표가 이동한걸 확인할 수 있네요. 현재 실행한 부분 바로 밑줄로 커서가 이동합니다.

 

④번 Autos 창을 보면 자동으로 창에 변수이름과 그 값이 뜹니다.

 

 초기화가 아직 안됐으므로 쓰레기값이 들어가 있는게 보이네요.

 

③번과 같이 주소연산자 &(변수이름) 을 입력하면 주소와 함께 그 변수의 값을 볼 수 있습니다.

 

②번 메모리 창 역시 &(변수이름)을 입력하고 엔터키를 누르면 바로 메모리 주소를 보여줍니다.

 

 

 

여기서 잠깐!

 

디버깅 진행 단축키를 알아볼까요~

 

 

F11 키는 코드 한줄씩(변수의 값이 변화가 있는 부분만 되는거 같네요)이동하면서 변수변화를 알려주고 F10 키는 그냥 한줄을 뛰어 넘습니다. printf()같은 라이브러리 함수를 만나면 F10키를 눌러줘야해요!

 

만약 라이브러리 함수에서 실수로 F10키를 눌렀을때 빠져나오려면 Shift+F11로 빠져 나오면 됩니다.

 

 

F11키로 계속 디버깅을 진행시켜보면 변수의 값이 변할 때마다 빨간색으로 표시되는 것을 볼 수 있어요

 

,②,③ 에서 보면 iSum의 값이 변하는 것을 확인 할 수 있죠.

 

②번 창에서 알 수 있는 메모리의 주소가번 창에서 확인 할 수 있네요.

 

int 4 byte니깐 네 칸이 바뀐것을 알수 있습니다.

 

여기서 이상한 점은 변수의 값이 0x 00 00 00 01로 저장되는 것이 아니라 0x 01 00 00 00 의 형태로 거꾸로 저장되는 것을

 

확인할 수 있는데... 이건 intel CPU little endian이라는 데이터 저장방식을 따르기 때문입니다.

 

이 방식이 산술연산에는 더욱 빠른 장점을 가지지만 논리연산은 상대적으로 느리다고 합니다.

 

 little endian, big endian에 대해서는... 다음에 다루도록 하죠.(장담은 못함)

 

 

이번 캡처 화면은 위 화면에서 실수로 F11을 눌렀을 때 나타나는 화면입니다.

 

prinf()함수를 만났을 때죠..

 

printf()를 만나면 누구든 X되는 거에요...

 

이럴 땐 F11을 수십번은 눌러야 벗어날 수 있으니 Shift+F11로 탈출해줍니다.

 

물론 애초에 F10 키로 넘어가는게 좋겠죠.

 

 

 

마지막으로 디버깅을 종료하고 싶을 땐 F5 키를 입력하면 원래 소스코드 화면으로 복귀할 수 있습니다.

 

 

 

오늘의 알아본 기능 단축키 정리입니다.(이것만 올려도 될 것을...)

 

단축키

기능

중단점 (Break Point 지정)

F9

디버깅 시작/종료

F5

디버그 지행

F11

한 줄 뛰어넘기

F10

현재 과정 벗어나기(?)

SHIFT + F11

변수 확인 창이 안 보일 때

Debug > Window 메뉴에서 불러온다

 

'Program > Visual Studio' 카테고리의 다른 글

Visual Studio 2017 사용 시 환경 셋팅  (0) 2018.06.21
AnkhSVN으로 소스관리하기  (0) 2018.01.23
Visual Studio 2013 소소한 팁  (0) 2017.07.19