자신의 깃허브(GitHub) 랭킹 및 통계 확인 방법
많은 개발자는 깃허브(GitHub)를 이용하여 다양한 소스코드를 공유합니다. 재미있게도 깃허브에서의 활동 내역을 통계를 내어 개발자들의 순위를 매겨주는 서비스가 있습니다.
① GitHub Readme Stats
이 프로젝트는 특정 깃허브 저장소의 통계 정보를 알려주는 프로젝트입니다. 자신의 깃허브 계정의 랭킹 정보와 함께 별점(star)을 얼마나 받았는지, PR은 얼마나 작성했는지 등을 통계적으로 알려줍니다. 사용 방법은 간단합니다. 자신의 사용자명(username)을 이용해 API에 넣으면 됩니다.
▶ GitHub Readme Stats: github-readme-stats.vercel.app/api?username={사용자명}&show_icons=true
저는 제 사용자명을 넣어 스탯(stats)을 출력해 보았습니다. 그랬더니 다음과 같이 A++ 랭크가 나오는 것을 확인할 수 있었습니다.
참고로 스탯 정보를 출력하는 테마(theme)도 존재합니다. 다크(dark) 테마를 넣을 때는 다음과 같이 합니다.
▶ 다크 테마: github-readme-stats.vercel.app/api?username={사용자명}&show_icons=true&theme=dark
또한 자신이 주로 사용하는 프로그래밍 언어를 출력할 때는 다음과 같이 할 수 있습니다.
▶ 언어 통계: github-readme-stats.vercel.app/api/top-langs/?username={사용자명}&langs_count=8
저는 많이 사용하는 언어 8개까지만 출력하도록 해보았습니다. 저는 주로 딥러닝(Deep Learing) 교육 목적의 저장소를 많이 가지고 있어서 Jupyter Notebook의 비율이 가장 높게 나오는 것을 알 수 있습니다.
② Rankedin
▶ Rankedin 링크: rankedin.kr/
이 사이트는 국내(South Korea) 개발자들의 오픈소스 커뮤니티 사이트입니다. 본인의 깃허브(GitHub) 아이디를 넣으시면 다음과 같이 별점 합계와 함께 순위 정보가 출력되는 것을 알 수 있습니다. 저는 2020년 12월 기준으로 국내 순위가 159위라고 나오네요. 어차피 등수 자체는 큰 의미가 없다고 생각하지만, 자신의 모든 저장소를 인기 순위대로 볼 수 있어서 좋습니다.
③ Gitstar Ranking
▶ Gitstar 링크: gitstar-ranking.com/
마찬가지로 깃허브 통계 정보를 알려주는 사이트입니다. 자신의 깃허브(GitHub) 계정명을 넣어 랭킹을 확인할 수 있습니다.
이후에 다음과 같이 전 세계에서의 등수가 나오게 됩니다. 저는 별점(star) 기준으로 7,244등이라고 하네요. 저도 본격적으로 오픈소스 활동을 열심히 해서 많은 사람에게 도움이 되는 저장소를 만들어야겠습니다.
④ WakaTime
▶ WakaTime 링크: wakatime.com/
추가로 WakaTime에 대해 언급하고자 합니다. 본 서비스는 개발자(developer)의 대시보드를 제공합니다. 자신이 각각 언어를 이용해 얼마나 많은 시간을 개발을 위해 투자했는지를 분석해준다는 특징이 있습니다. 다만 이 서비스는 별도의 설치 과정이 필요할 수 있어서, 앞서 언급한 서비스와는 다르게 바로 확인해 볼 수는 없습니다.
⑤ Codersrank
▶ Codersrank 링크: https://profile.codersrank.io/
관심이 있으신 분은 이 사이트 또한 참고해 보세요. 깃 허브 및 링크드 인과 연동하여 다양한 정보를 공유할 수 있는 것 같습니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| 깃허브(GitHub)에서 Organization를 생성하여 다수의 사용자에게 Private 저장소 Read-Only 권한 부여하기 (0) | 2020.11.09 |
|---|---|
| 이미 작성된 Git Commit의 날짜와 시간을 변경해보자! (2) | 2019.04.06 |
| 깃(Git) 환경설정(config)에 대해서 알아보자! (0) | 2019.04.06 |
| Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기 (0) | 2019.04.03 |
| Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
깃허브(GitHub)에서 Organization를 생성하여 다수의 사용자에게 Private 저장소 Read-Only 권한 부여하기
깃허브(GitHub)는 기본적으로 소스코드를 public하게 공개할 때 가장 많이 사용하는 서비스다. 하지만 종종 내가 선택한 일부 사용자만(private 하게) 내 소스코드를 read-only 권한으로 볼 수 있도록 해야 하는 경우가 있다. 이때 사용할 수 있는 게 바로 조직(organization) 기능이다. 다음 그림과 같이 [프로필] - [Your organizations] 페이지로 이동하자.
[New organization]을 눌러서 새로운 조직(organization)을 추가한다.
이후에 팀(team)을 위한 가격 플랜을 설정할 수 있다. 앞서 언급했듯이 단순히 특정 사용자만 내 코드를 볼 수 있도록 설정하기 위해서는 무료(Free) 플랜으로 충분하다. 따라서 [Join for free] 버튼을 클릭하자.
이후에 다음과 같이 팀에 대한 기본적인 설정을 할 수 있다. 필자는 Deep Learning Class라는 이름으로 조직 이름을 설정했으며 대표 이메일로는 학교 이메일을 넣었다.
이후에 조직(organization) 멤버를 선택해 추가할 수 있다. 여기에 추가되는 멤버는 조직 내에 포함된 모든 저장소(repository)를 다 볼 수 있다. 일단 여기에서는 멤버를 추가하지 않고 [Skip this step] 버튼을 눌러 넘어간다.
이후에 조직(organization) 관련 정보를 작성할 수 있다. 필자의 경우 교육 목적의 저장소이기 때문에 [Education projects]를 선택했고, 25명 이상의 사람이 조직에 포함될 수 있다고 기재했다.
결과적으로 조직(organization) 생성을 완료하면 다음과 같은 페이지가 등장한다. [Create a new repository] 버튼을 눌러 하나의 저장소를 생성하자.
필자는 다음과 같이 하나의 저장소를 만들었다. 아무나 볼 수 없도록 Private으로 설정했다.
이후에 해당 저장소(repository)의 [Settings] - [Manage access] 탭에 들어가 구성원을 설정할 수 있다. [Invite teams or people] 버튼을 눌러서 한 명의 구성원을 추가해보자.
다음과 같이 GitHub 가입자를 아이디로 검색하여 권한을 부여할 수 있다. 이때 기본적으로 outside collaborator로 멤버가 추가되며, 더불어 [Read] 권한으로 부여하게 되면 해당 사용자는 소스코드를 볼 수 있지만 commit 등은 불가능하다. 따라서 의도했던 대로 코드에 대한 보기 권한만 부여하는 것이다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| 자신의 깃허브(GitHub) 랭킹 및 통계 확인 방법 (0) | 2020.12.04 |
|---|---|
| 이미 작성된 Git Commit의 날짜와 시간을 변경해보자! (2) | 2019.04.06 |
| 깃(Git) 환경설정(config)에 대해서 알아보자! (0) | 2019.04.06 |
| Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기 (0) | 2019.04.03 |
| Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
이미 작성된 Git Commit의 날짜와 시간을 변경해보자!
기본적으로 깃(Git)은 특정한 프로젝트의 소스코드가 언제 변경되었는지 등을 감지하여 이력을 알려준다는 특징이 있습니다. 우리가 소스코드를 변경해서 커밋(Commit)을 진행하면 그 커밋이 진행된 시점을 기억하여, 깃 사용자에게 알려줍니다.
일반적으로 깃의 커밋 날짜는 변경하기 어렵다거나 변경하지 못하는 것으로 알고 있는 사람들이 많습니다. 하지만 실제로는 깃의 커밋 날짜 또한 변경이 가능합니다.
그래서 흔히 말하는 깃 허브 잔디밭의 '1일 1커밋'도 어렵지 않게 조작하여 달성할 수 있습니다.
저는 실습을 위해서 다음과 같이 하나의 깃 프로젝트를 준비해보았습니다.
① 필터링을 이용하는 방법
이 방법은 깃(Git)의 필터링 기능을 이용하는 방법입니다. 다만 모든 커밋 내역을 살펴보며 필터링을 수행한다는 점에서, 프로젝트의 규모가 클수록 오랜 시간이 걸릴 수 있습니다.
git filter-branch -f --env-filter \
'if [ $GIT_COMMIT = {Commit 해시 값} ]
then
export GIT_AUTHOR_DATE="Jan 1 10:00 2019 +0900"
export GIT_COMMITTER_DATE="Jan 1 10:00 2019 +0900"
fi'
또한 여기에서 주의할 점은, 위 소스코드에서 if문 안에 들어가는 내용에서 공백에 유의하셔야 한다는 것입니다. 공백을 지워버리면 제대로 동작하지 않을 수 있습니다.
적용 이후에 실제로 깃 로그(Log)를 확인해보시면 다음과 같이 변경되어 있는 것을 확인할 수 있습니다. 그와 더불어 변경된 커밋 이후의 커밋들의 해시 값까지 모두 변경되어 있는 것을 확인할 수 있습니다.
② git rebase를 이용하는 방법
우리는 git rebase를 이용해서도 특정한 커밋의 날짜를 변경할 수 있습니다.
git rebase {commit 해시 값} -i
기본적으로 rebase 명령어를 이용할 때는 변경하고자 하는 커밋의 이전 커밋을 기준으로 하여 -i 옵션(인터렉티브)으로 에디터 창을 열어주시면 됩니다.
이후에 변경하고자 하는 커밋의 선택 내용을 edit으로 적용하시면 됩니다.
이후에 다음의 명령어로 커밋 내역의 날짜를 변경하시면 됩니다.
GIT_COMMITTER_DATE="{날짜}" git commit --amend --no-edit --date "{날짜}"
저는 다음과 같이 2019년 1월 1일의 날짜로 커밋 내역을 변경했습니다.
결과적으로 변경 내역을 적용하고자 할 때는 git rebase --continue를 입력하시면 됩니다.
변경된 내용을 깃 허브에 푸시하면 어떻게 될까?
실제로 변경된 내용을 깃 허브(Git Hub)에 푸시하면 어떻게 될 지 확인해봅시다.
재미있게도, 잔디밭에도 해당 변경된 커밋의 날짜에 맞게 색깔이 칠해져 있는 것을 확인할 수 있습니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| 자신의 깃허브(GitHub) 랭킹 및 통계 확인 방법 (0) | 2020.12.04 |
|---|---|
| 깃허브(GitHub)에서 Organization를 생성하여 다수의 사용자에게 Private 저장소 Read-Only 권한 부여하기 (0) | 2020.11.09 |
| 깃(Git) 환경설정(config)에 대해서 알아보자! (0) | 2019.04.06 |
| Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기 (0) | 2019.04.03 |
| Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
깃(Git) 환경설정(config)에 대해서 알아보자!
특정한 컴퓨터 환경에서 깃(Git)을 이용할 때에 대한 전반적인 환경설정은 어떻게 다룰 수 있을까요? 일반적으로 우리가 컴퓨터에 깃(Git)을 설치한 뒤에 가장 먼저 하는 것은 깃 계정을 설정하는 일입니다. 저는 리눅스 컴퓨터를 기준으로 하여 깃 환경설정 방법에 대해서 소개하도록 하겠습니다.
깃 사용자를 글로벌(모든 프로젝트에 적용)하게 설정할 때는 다음과 같이 할 수 있습니다.
git config --global user.name "{계정명}"
git config --global user.email {계정 이메일}
이렇게 설정된 사용자에 따라서 후에 실제로 커밋(Commit) 등의 정보가 기록됩니다. 또한 이러한 환경설정 정보를 확인하고자 할 때는 다음과 같은 명령을 이용할 수 있습니다.
git config --list
또한 기본적으로 ~/.gitconfig 경로로 이동하시면 특정 사용자에게만 적용되는 깃 환경설정 정보를 확인할 수 있습니다. 저는 한 번 다음과 같이 root 계정의 깃 환경설정 정보를 확인해보도록 하겠습니다.
실제로 .gitconfig 파일의 내용을 확인했더니 다음과 같이 깃 계정 정보가 기록되어 있는 것을 확인할 수 있었습니다.
깃 환경설정 파일은 자신이 직접 수정해서 그 내용을 바꿀 수도 있습니다.
내용을 바꾸어 저장한 결과, 성공적으로 변경된 내용이 반영되어 있는 것을 확인할 수 있습니다.
또한 자주 사용되는 설정으로 core.editor 설정이 있습니다. 이는 깃(Git) 전용 텍스트 에디터를 설정하는 것입니다. 저는 vim보다는 vi를 선호하므로 vi가 사용될 수 있도록 설정하곤 합니다.
또한 특정한 깃 프로젝트의 .git 폴더로 가면 해당 프로젝트에만 적용되는 환경설정을 진행할 수도 있습니다. 저는 한 번 다음과 같이 실제로 특정한 깃 프로젝트의 .git 폴더로 가서 config 파일을 확인해보았습니다.
다음과 같이 글로벌 설정과는 다른, 해당 프로젝트만의 깃 환경설정이 이루어져 있는 것을 확인할 수 있습니다. 또한 이를 수정하여 프로젝트에 대한 환경설정을 진행할 수 있는 것입니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| 깃허브(GitHub)에서 Organization를 생성하여 다수의 사용자에게 Private 저장소 Read-Only 권한 부여하기 (0) | 2020.11.09 |
|---|---|
| 이미 작성된 Git Commit의 날짜와 시간을 변경해보자! (2) | 2019.04.06 |
| Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기 (0) | 2019.04.03 |
| Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
| Git 로그 다루기 [Git으로 시작하는 협업과 오픈소스 프로젝트 10강] (0) | 2018.12.23 |
Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기
깃(Git)의 rebase 명령은 커밋 내역을 수정하고자 할 때 사용할 수 있습니다. 커밋 메시지를 수정할 때 가장 많이 사용되는 것 중 하나입니다. 가장 먼저 실습을 위해 기본적인 커밋(Commit)을 몇 번 진행하겠습니다.
하나의 깃 프로젝트를 생성합니다.
하나의 텍스트 파일을 추가한 뒤에 커밋(Commit)합니다.
이후에 텍스트 파일에 내용을 작성한 뒤에 커밋(Commit)합니다.
이후에 해당 텍스트 파일을 삭제한 뒤에 다시 커밋(Commit)합니다.
이후에 새로운 텍스트 파일을 생성한 뒤에 커밋(Commit)합니다.
이제 깃 로그를 확인해 보시면 다음과 같이 총 4번의 커밋이 이루어져 있는 것을 확인할 수 있습니다. 저는 중간에 있는 [Delete Example 1.txt] 커밋의 메시지를 수정해보도록 하겠습니다.
커밋 메시지를 수정할 때에도 git rebase 명령어를 사용할 수 있습니다. -i 옵션을 붙이면 상호작용(Interactive) 모드로 에디터가 열리게 됩니다. 저는 HEAD를 기준으로 3개까지의 커밋을 확인하도록 해보겠습니다.
git rebase -i HEAD~3
그러면 다음과 같이 커밋 내역이 차례대로 출력됩니다. 이제 여기에서 수정하고자 하는 커밋에 대한 내용을 에디터에 적어주면 되는 방식입니다.
커밋 메시지를 바꾸고 싶을 때는 reword 키워드를 이용하면 됩니다. 저는 [Delete Example 1.txt] 커밋의 메시지를 수정해보도록 하겠습니다.
그러면 다음과 같이 새로운 에디터가 또 열리게 됩니다. 이제 여기에서 커밋 메시지를 바꾸어주면 됩니다.
결과적으로 다시 로그(Log)를 확인했을 때 다음과 같이 커밋 메시지가 변경된 것을 확인할 수 있습니다.
그렇다면 특정 커밋 자체를 삭제하고 싶을 때는 어떻게 하면 될까요? 마찬가지로 git rebase 명령어를 이용하면 됩니다. 다만, 다른 사람과 함께 작업하는 경우 커밋 자체를 삭제하는 것은 권장되지 않습니다. 충돌이 발생할 수 있어요. 그래도 경우에 따라서는 필요할 수 있는 기능이므로 다루어보도록 하겠습니다.
커밋 자체를 삭제하고 싶을 때는 drop 키워드를 이용하면 됩니다.
결과적으로 삭제 이후에는 해당 커밋 내역이 아예 증발하게 됩니다.
이제 폴더를 확인해 보시면 실제로 해당 커밋 자체가 존재하지 않았던 것처럼 처리된 것을 확인할 수 있습니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| 이미 작성된 Git Commit의 날짜와 시간을 변경해보자! (2) | 2019.04.06 |
|---|---|
| 깃(Git) 환경설정(config)에 대해서 알아보자! (0) | 2019.04.06 |
| Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
| Git 로그 다루기 [Git으로 시작하는 협업과 오픈소스 프로젝트 10강] (0) | 2018.12.23 |
| Git 원격 저장소 관리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 9강] (0) | 2018.12.23 |
Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강]
깃(Git) 프로젝트에서는 README.md 파일을 이용해 소개글을 작성할 수 있습니다. md는 마크 다운(Markdown)의 약자이며 최근 굉장히 다양한 분야에서 사용되고 있는 텍스트 양식입니다. 매우 빠르게 핵심적인 내용을 작성하는 편집 양식이라는 점에서 깃 허브(Git Hub) 또한 공식적으로 이를 채택하고 있습니다.
이번 시간에는 우리의 깃 저장소에서 README.md 파일을 생성하여 프로젝트 소개글을 작성하는 방법에 대해서 소개하고자 합니다.
위와 같이 README.md 파일을 작성하여 간단히 샵(#)을 붙여 글머리를 작성해 봅시다. #은 글머리를 작성할 때 사용합니다.
이제 이러한 내용을 푸시(Push)해서 확인해보도록 합시다.
성공적으로 소개글 정보가 깃 허브(Git Hub)에 들어간 것을 확인할 수 있습니다.
마크 다운은 정말 편집(Edit)을 쉽게 할 수 있는 도구입니다. 다음과 같은 예제들도 확인해 봅시다.
# 글머리
소스코드 블록은 다음과 같이 작성할 수 있습니다.
```c
#include <stdio.h>
int main(void) {
printf("Hello World!");
}
```
링크는 다음과 같이 작성할 수 있습니다.
[블로그 주소](https://blog.naver.com/ndb796)
순서 없는 목록은 다음과 같이 작성할 수 있습니다.
* 깃 강좌
* 깃 Clone
* 깃 Pull
* 깃 Commit
* 깃 Commit ①
* 깃 Commit ②
* 깃 Push
인용 구문은 다음과 같이 작성할 수 있습니다.
> '공부합시다.' -나동빈-
테이블은 다음과 같이 작성할 수 있습니다.
이름|영어|정보|수학
---|---|---|---|
나동빈|98점|87점|100점|
홍길동|97점|78점|93점|
이순신|89점|93점|97점|
강조는 다음과 같이 할 수 있습니다.
**치킨** 먹다가 ~~두드러기~~났어요. ㅠㅠ
푸시(Push) 이후에는 다음과 같은 결과를 확인할 수 있습니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| 깃(Git) 환경설정(config)에 대해서 알아보자! (0) | 2019.04.06 |
|---|---|
| Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기 (0) | 2019.04.03 |
| Git 로그 다루기 [Git으로 시작하는 협업과 오픈소스 프로젝트 10강] (0) | 2018.12.23 |
| Git 원격 저장소 관리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 9강] (0) | 2018.12.23 |
| Git 브랜치 충돌 처리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 8강] (0) | 2018.12.23 |
Git 로그 다루기 [Git으로 시작하는 협업과 오픈소스 프로젝트 10강]
깃(Git)에서 로그(Log)를 제대로 다룰 수 있으면 깃과 관련한 처리 내역을 쉽게 확인할 수 있습니다. 다시 말해 히스토리(History)를 효과적으로 확인할 수 있습니다. 가장 기본적인 로그 출력 명령어인 git log를 이용해보도록 하겠습니다.
깃(Git) 로그를 구체적으로 확인하고자 한다면 다양한 옵션을 이용할 수 있습니다.
▶ stat: 각 커밋에 따른 통계 정보를 출력합니다.
▶ graph: 브랜치(Branch)와 병합(Merge) 정보를 그래프 형태로 출력합니다.
▶ p: 커밋에 적용된 구체적인 사항을 출력합니다.
▶ pretty: 지정된 형식으로 커밋 정보를 출력합니다.
먼저 stat 옵션을 사용한 결과는 위와 같습니다. 각 커밋마다 통계 정보를 출력합니다.
또한 위와 같이 p 옵션으로 커밋에 적용된 구체적인 사항을 출력할 수 있습니다. -3이라는 옵션을 추가해 최근 3개의 정보만 확인할 수 있습니다.
이후에 pretty 옵션으로 커밋 정보를 특정한 형식으로 출력할 수 있습니다. 대표적인 형태들은 다음과 같습니다.
▶ h: 커밋(Commit) 해시 값을 출력합니다.
▶ an: 작성자 이름을 출력합니다.
▶ ar: 작성 날짜를 출력합니다.
▶ ae: 작성자 이메일을 출력합니다.
▶ s: 커밋 주제를 출력합니다.
▶ cn: 커미터 이름을 출력합니다.
위와 같이 graph 옵션과 함께 사용할 수 있습니다. 그래프 결과를 확인해 보면 언제 브랜치가 생성되었고, 언제 병합이 이루어졌는지를 콘솔 창에서 확인할 수 있습니다.
(+ 추가)
특정 파일에 대한 로그만을 확인하고 싶다면 git log {파일 이름}의 형태로 명령어를 입력할 수 있습니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기 (0) | 2019.04.03 |
|---|---|
| Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
| Git 원격 저장소 관리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 9강] (0) | 2018.12.23 |
| Git 브랜치 충돌 처리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 8강] (0) | 2018.12.23 |
| Git 브랜치의 개요 및 사용해보기 [Git으로 시작하는 협업과 오픈소스 프로젝트 7강] (0) | 2018.12.23 |
Git 원격 저장소 관리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 9강]
깃(Git)으로 협업을 하기 위해서는 원격 저장소를 관리하는 방법을 알고 있어야 합니다. 말 그대로 네트워크 공간 어딘가에 존재하는 또 다른 컴퓨터를 원격 저장소라고 말합니다. 우리는 원격 저장소를 여러 개 가질 수도 있고, 각 원격 저장소를 서로 다른 목적으로 활용할 수 있습니다. 원격 저장소로부터 데이터를 받아올 때는 풀(Pull), 데이터를 보낼 때는 푸시(Push) 명령어를 사용합니다.
우리는 깃 허브(Git Hub)를 원격 저장소로 하여 프로젝트를 구축했으므로, 기본적인 원격 저장소는 깃 허브(Git Hub)가 됩니다.
기본적으로 git remote 명령어로 원격 저장소를 확인할 수 있습니다.
더불어 원격 저장소를 추가하고자 할 때는 git remote add 명령어를 사용할 수 있습니다.
또한 원격 저장소를 지칭하는 이름을 바꾸고자 할 때는 git remote rename 명령어를 사용할 수 있습니다.
다양한 깃 명령어를 특정한 원격지 저장소에 대하여 수행할 수 있습니다. git log, git merge 등 다양한 명령어를 쓸 수 있습니다.
마지막으로 원격 저장소를 제거할 때는 git remote rm 명령어를 사용합니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
|---|---|
| Git 로그 다루기 [Git으로 시작하는 협업과 오픈소스 프로젝트 10강] (0) | 2018.12.23 |
| Git 브랜치 충돌 처리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 8강] (0) | 2018.12.23 |
| Git 브랜치의 개요 및 사용해보기 [Git으로 시작하는 협업과 오픈소스 프로젝트 7강] (0) | 2018.12.23 |
| Git에서 커밋(Commit) 내역 수정하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 6강] (0) | 2018.12.22 |
Git 브랜치 충돌 처리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 8강]
이번 시간에는 깃(Git)에서 브랜치(Branch)를 다룰 때 발생할 수 있는 충돌을 처리하는 방법에 대해서 알아보도록 하겠습니다. 충돌(Conflict)이 발생하면 바로 병합(Merge)을 수행할 수는 없고, 충돌을 해결한 뒤에 병합을 수행해야 합니다. 이러한 내용에 대해 자세히 알아볼게요. 한 번 충돌이 발생하는 일을 가정해봅시다. 충돌은 쉽게 말하면 하나의 파일을 여러 명이 수정한 경우를 의미해요.
위와 같이 하나의 브랜치를 만들어서 작업을 수행해 봅시다.
특정한 파일에 하나의 함수 div()를 추가했습니다.
위와 같이 커밋(Commit)까지 진행해줍니다.
이제 마스터 브랜치로 이동해서 똑같은 파일을 다른 내용으로 수정해보도록 하겠습니다.
이어서 로그(Log)까지 확인해보면 현재 마스터 브랜치를 가리키고 있으므로 마스터 브랜치에 대한 정보만 출력됩니다.
반대로 develop 브랜치를 기준으로 확인하면, 마스터 브랜치에 대한 정보는 보이지 않게 됩니다.
이제 한 번 마스터 브랜치에서 develop 브랜치를 병합(Merge) 해보도록 하겠습니다.
그러면 충돌(Conflict)이 발생했다는 메시지가 출력됩니다.
충돌이 발생한 소스코드를 열어서 확인해 보시면 서로 다른 두 개의 브랜치에 대한 정보가 출력됩니다. 저는 기존의 마스터 브랜치 소스코드를 따르도록 하겠습니다.
다시 파일을 저장해주신 이후에 커밋(Commit)까지 진행해 주시면 성공적으로 병합을 수행할 수 있습니다.
이제 다음과 같이 로그를 찍어 보면, 마스터 브랜치가 develop 브랜치를 병합한 형태가 됩니다.
이제 병합이 완료된 develop 브랜치는 제거해주고 푸시(Push)를 진행해 주시면 됩니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| Git 로그 다루기 [Git으로 시작하는 협업과 오픈소스 프로젝트 10강] (0) | 2018.12.23 |
|---|---|
| Git 원격 저장소 관리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 9강] (0) | 2018.12.23 |
| Git 브랜치의 개요 및 사용해보기 [Git으로 시작하는 협업과 오픈소스 프로젝트 7강] (0) | 2018.12.23 |
| Git에서 커밋(Commit) 내역 수정하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 6강] (0) | 2018.12.22 |
| 소스코드 수정하여 Git 저장소에 반영하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 5강] (0) | 2018.12.22 |
Git 브랜치의 개요 및 사용해보기 [Git으로 시작하는 협업과 오픈소스 프로젝트 7강]
이번 시간에는 깃(Git)에서 브랜치(Branch)를 사용하는 방법에 대해서 알아보도록 하겠습니다. 깃(Git)은 동시에 여러 개발자들이 프로젝트에서 각기 다른 기능을 개발할 수 있도록 브랜치(Branch) 기능을 제공합니다. 서로 다른 브랜치는 작업을 함에 있어서 서로에게 영향을 받지 않는다는 점에서 마음 놓고 서로 다른 개발 작업을 수행할 수 있습니다.
Branch 동작 과정.xml브랜치의 동작 과정은 다음과 같은 예시로 표현할 수 있습니다. 기본적으로 Git 저장소를 만들면 자동으로 마스터(Master) 브랜치가 생성됩니다. 이 브랜치는 일반적으로 배포가 가능한 수준의 안정화된 버전을 포함하고 있습니다.
그래서 별도의 브랜치를 만들어 사용하고자 한다면 체크아웃(Checkout) 명령어를 이용해야 합니다.
한 번 예시를 들어보도록 하겠습니다.
현재 우리는 배포 버전이 Master Branch에 있는 상황에서, 새로운 기능을 개발하고 있습니다. 새로운 기능은 Develop Branch에서 개발하고 있으며 이와 동시에 버그가 발견되어 빠르게 버그를 수정해야 하는 일이 발생했다고 해봅시다. 이 때 버그 수정은 Bug Fix Branch에서 진행하는 겁니다. 그리고 버그가 수정되는 대로 바로 Master Branch에 수정 내역을 합치고, 기능 또한 합쳐주어 결과적으로 새로운 배포 버전이 탄생하도록 개발을 진행하는 겁니다.
그러면 합치기(Merge)가 수행되기 전까지는 안정적으로 배포가 이루어지고 있다가, 모든 기능이 합쳐진 이후에 다시 배포할 수 있으므로 개발의 안정성이 매우 뛰어나게 되는 겁니다.
▶ 통합 브랜치: 배포가 가능한 수준의 브랜치로 일반적으로 마스터(Master) 브랜치를 의미합니다.
▶ 토픽 브랜치: 특정한 기능을 위해 만들어진 브랜치로 일반적으로 마스터(Master) 브랜치 이외의 다른 브랜치를 의미합니다.
※ 브랜치 사용해보기 ※
브랜치를 만들 때는 git branch 명령어를 이용합니다. 저는 develop이라는 이름의 브랜치를 만들어 보도록 하겠습니다. 이후에 특정한 브랜치로 전환하고자 할 때는 git checkout 명령어를 이용합니다. 체크아웃(Checkout) 이후에는 HEAD가 해당 브랜치로 이동하게 됩니다.
위와 같이 체크아웃 이후에는 HEAD가 develop 브랜치로 가 있는 것을 확인할 수 있습니다.
이 상태에서 소스코드에 새로운 함수 mul()을 작성해보도록 하겠습니다.
이후에 위와 같이 커밋(Commit)을 진행해 주시면 현재 HEAD가 가리키고 있는 브랜치인 develop 브랜치에서 커밋이 진행됩니다.
git log 명령어로 로그를 확인해 보시면 master 브랜치의 윗 부분에 develop 브랜치가 존재하는 걸 확인할 수 있습니다.
이제 마스터 브랜치로 이동해서 develop 브랜치를 병합(Merge)할 수 있습니다.
병합 결과 위와 같이 마스터 브랜치와 develop 브랜치가 동일한 커밋 내역을 가지게 된 걸 확인할 수 있습니다.
결과적으로 푸시(Push)까지 진행해 주시면 원격지 저장소인 Git Hub에도 반영되는 것을 확인할 수 있습니다.
병합이 끝난 브랜치는 git branch 명령어에서 d 옵션을 넣어 제거할 수 있답니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
| Git 원격 저장소 관리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 9강] (0) | 2018.12.23 |
|---|---|
| Git 브랜치 충돌 처리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 8강] (0) | 2018.12.23 |
| Git에서 커밋(Commit) 내역 수정하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 6강] (0) | 2018.12.22 |
| 소스코드 수정하여 Git 저장소에 반영하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 5강] (0) | 2018.12.22 |
| Git의 동작 원리 [Git으로 시작하는 협업과 오픈소스 프로젝트 4강] (0) | 2018.12.22 |
