에이블디 공식 블로그

안녕하세요 여러분! 에이블디입니다! 이번 시간에는 지난시간에 이어서 README를 좀 더 잘 작성하기 위해 마크다운(markdown) 문법에 대해 알아보도록 하겠습니다! README 파일의 확장자가 .md인 것은 마크다운이라는 형식으로 작성되기 때문인데요, 마크다운은 사용이 쉽고 HTML 태그에 비해 간단하기 때문에 편리하게 README를 작성할 수 있습니다. 단 마크다운은 마크다운을 지원하는 프로그램이나 사이트에서만 사용할 수 있습니다. 그럼 지금부터 깃허브에서 README 파일을 작성할 때 자주 사용하는 몇 가지 마크다운 문법을 살펴보도록 하겠습니다! 1. 제목 제목을 입력할 때는 텍스트 앞에 #을 붙입니다. #을 한 개에서부터 여섯 개까지 붙여서 제목의 글자 크기를 정할 수 있는데요, #과 텍스트 ..

안녕하세요 여러분! 에이블디입니다! 이번 시간에는 README(리드미) 작성하는 법에 대해 배워보려 해요! 공개된 깃허브 리포지토리는 전 세계 누구나 볼 수 있기 때문에 깃허브 활동을 많이 할수록 방문자도 늘어나겠죠? 하지만 프로필과 컨트리뷰션 그래프만 살펴보는 것으로는 그 리포지토리의 주인이 어떤 활동을 했는지 구체적으로 알기 어렵습니다. 그래서 많은 깃허브 사용자는 방문자가 편하게 자기 리포지토리를 살펴볼 수 있도록 안내문을 만들어 첫 화면에 띄워 두는데요, 이 안내문이 적혀있는 문서를 README 파일이라고 합니다. 그럼 README 파일을 작성해 볼까요? README 파일은 마크다운(markdown) 문법을 사용하기 때문에 확장자는 .md를 사용합니다. 마크다운에 대해서는 다른 시간에 풀어드리도록..

안녕하세요 여러분! 에이블디입니다! 이번 시간에는 깃허브로 자신을 나타낼 수 있도록 깃허브 프로필을 작성하고 관리하는 방법에 대해 배워볼 거예요! 깃허브 프로필을 보고 협업이나 일자리 제안을 받을 수도 있기 때문에 개발자로서 자신의 개발 경력을 드러낼 수 있는 가장 좋은 방법 중 하나이기 때문에 배워두면 좋겠죠? 그럼 바로 프로필부터 작성해 볼게요! 'https://github.com/아이디'로 접속하면 해당 아이디 사용자의 프로필 사진을 비롯해 리포지토리 목록과 커밋 현황 등 다양한 정보가 있는 화면이 나타나는데요! 자신의 깃허브 화면에서 화면 왼쪽 위에 있는 프로필 사진을 눌러 프로필을 수정해 보도록 할게요! 위와 같은 화면이 나타났다면 프로필 이미지 아래에 있는 'Edit' 버튼을 눌러 나오는 'U..

안녕하세요! 에이블디입니다! 이번 시간에는 지난 시간에 이어 풀 리퀘스트(pull request)에 대해 알아보겠습니다! 위의 이미지처럼 아직 깃허브 리포지토리에는 work-Jayden 브랜치에서 만들었던 jayden.txt 파일이 없습니다. 그 이유는 푸시한 브랜치는 풀 리퀘스트(pull request)를 통해 머지해야 깃허브 리포지토리에 반영되기 때문인데요, 지금 바로 풀 리퀘스트하는 방법에 대해 알아보겠습니다! 깃허브 리포지토리 화면에서 위의 이미지에 보이는 빨간 박스 안의 'branches'를 눌러주세요! 브랜치 설명 옆에 있는 'New pull request'를 눌러주세요. 풀 리퀘스트 메시지를 작성한 후 'Create pull request' 버튼을 누르면 협업 중인 리포지토리에 풀 리퀘스트가..

안녕하세요! 에이블디입니다! 이번 시간에는 지난 시간에 이어 깃허브로 협업하는 방법 중 하나인 협업에서 브랜치를 사용하는 법을 배워볼게요! 협업을 하다 보면 팀원들이 각자 다른 기능을 맡아서 작업하는 경우가 많은데요, 팀원 1은 '기능 A'를 만들고, 팀원 2는 '기능 B'를 만드는 것처럼 각자 다른 기능을 맡아 작업하게 됩니다. 이럴 때는 각자의 작업이 master 브랜치에 있는 파일들과 섞이지 않도록 새 브랜치를 만들어서 프로젝트를 관리합니다. 그리고 각 팀원이 만든 새 브랜치 역시 깃허브 리포지토리에 푸시할 수 있습니다. 그럼 바로 실습해 보도록 할게요! 이번 실습에서는 팀장인 Jayden이 새로운 기능을 만들기 위해 자신의 로컬 리포지토리에 work-Jayden이라는 브랜치를 만들고 커밋한 다음 ..

안녕하세요! 에이블디입니다! 이번 시간에는 지난 시간에 이어서 컴퓨터에 협업을 위한 작업 환경을 구성하고 간단한 실습을 하려고 합니다. 지난 시간에 깃허브 리포지토리에 공동 작업자를 추가한 것 기억나시죠? 예를 들어 공동작업자에 팀장과 팀원 두 명이 있다고 가정하면, 팀장과 팀원 1, 팀원 2가 번갈아 커밋을 올리거나 내려받으면서 작업할 수 있습니다. 오늘 실습은 두대 이상의 컴퓨터에서 하나의 깃허브에 접속하는 것이기 때문에 두대의 컴퓨터가 준비가 되지 않는 환경이라면 글을 읽고 이해하시면 되겠습니다! 먼저 각 작업자의 컴퓨터에 로컬 리포지토리(지역 저장소)를 만들어야 합니다. 그리고 공동 작업에서 사용할 이름과 이메일 주소를 지정합니다. 리포지토리(저장소)마다 다른 이름이나 메일 주소를 사용하기 위해 ..

안녕하세요! 에이블디입니다! 이번 시간에는 깃허브로 협업하는 방법에 대해 하나씩 알아보도록 하겠습니다! 하나의 작업을 여러 사람이 협업하기 위해서는 각자 로컬 리포지토리에서 작업한 내용을 깃허브 리포지토리에 공유할 수 있어야 합니다. 깃허브의 공개 리포지토리는 주소만 알면 누구든지 접속해서 올라와 있는 소스를 살펴볼 수 있습니다. 또 깃허브 회원이라면 누구나 오픈 소스 프로젝트의 소스를 다운로드할 수 있습니다. 하지만 누구나 리포지토리에 커밋을 푸시할 수는 없습니다. 공개 리포지토리든 비공개 리포지토리든 여러 사람들이 협업한다면 승인된 공동 작업자에게만 커밋을 올릴 수 있는 권한을 주어야 합니다. 그래야 프로젝트 소스가 무분별하게 수정되는 일을 막을 수 있기 때문이죠. 팀 작업을 하려면 팀원 중 누군가 ..

안녕하세요! 에이블디입니다! 오늘은 지난 시간에 이어 깃허브 리포지토리의 정보를 가져오는 방법에 대해 알아볼 거예요! pull 명령이 깃허브 리포지토리의 커밋을 가져와서 무조건 로컬 리포지토리와 합치는 것이라면, 오늘 배울 fetch 명령은 깃허브 리포지토리에 어떤 변화가 있는지 그 정보만 가져오는 명령어예요. 팀 작업을 할 때 다른 사람이 수정한 소스를 한번 더 훑어보고 로컬 리포지토리와 합치고 싶다면 pull 대신 fetch를 사용해서 커밋을 가져온 다음 로컬 리포지토리와 합치면 됩니다. 그럼 바로 실습해 볼까요? 터미널 창에서 지난 시간에 만들어 둔 abled-office 디렉터리로 이동하셔서 git fetch 명령을 입력해 주세요! $ cd ~/abled-office $ git fetch 깃허브 ..

안녕하세요! 에이블디입니다! 여러분, git pull 명령은 깃허브 리포지토리의 최신 커밋을 로컬 리포지토리에 합쳐주는 기능이란 거 이젠 다들 아시죠? 하지만 깃허브 리포지토리의 최신 커밋을 합치지 전에 깃허브 리포지토리에 어떤 변화가 있는지 먼저 확인한 후에 풀을 해야 하는데요, 이럴 때 먼저 깃허브 리포지토리의 정보만 먼저 가져올 수 있습니다. 이번 시간에는 일단 로컬 master 브랜치와 원격 master 브랜치의 상태 차이에 대해서 알아보겠습니다! 일단, 깃허브 리포지토리의 커밋 목록을 확인해 볼게요! 지난 시간까지 실습을 잘 따라오셨다면 위의 이미지처럼 'add office work'가 가장 최신 커밋일 거예요! 터미널 창에서 abled-home 디렉터리로 이동한 후 git log로 커밋 상태를..

안녕하세요! 에이블디입니다! 이번 시간에는 푸시와 풀을 실습하는 시간을 가져볼 텐데요! 집과 회사에서 일하는 것처럼 상황을 가정해서 깃으로 놀이를 한다고 생각하고 진행해 보도록 하겠습니다! 먼저 지난 시간에 만들었던 abled-home 디렉터리에서 test-github.txt 파일을 열고 세 번째 줄에 'home work'라는 내용을 추가하고 저장해 주세요! $ cd ~ $ cd abled-home $ vi test-github.txt 내용 추가가 완료되었으면 test-github.txt 파일을 스테이징하고 'add home work'라는 커밋 메시지와 함께 커밋해 주세요. 그리고 git push 명령을 사용해 커밋을 리모트 리포지토리에 푸시합니다. $ git commit -am "add home wor..