4. 개발자를 위한 첫 번째 필수 교양

김건희·2022년 12월 13일
0

Fundamental

목록 보기
4/7

4-1. 학습 목표 및 목차

학습 전제


  • 협업 관리 툴을 다뤄본 적이 없다.
  • Git과 GitHub에 대한 개념을 공부해본 적이 없다.
  • GitHub을 이용해 소스코드의 버전 관리를 해 본 적이 없다.
  • pip를 활용해 본 적은 있으나, Jupyter Notebook을 설치해 사용해 본 적이 없다.
  • 마크다운 문법을 공부하거나 활용해본 적이 없다.

학습 목표


  • Git과 GitHub의 차이를 말할 수 있다.
  • Git의 add, commit, push, pull 등의 명령어를 알고, 활용할 수 있다.
  • GitHub을 활용해 소스코드 버전관리를 할 줄 안다.
  • Jupyter Notebook을 활용해 자유자재로 코드/문서 작업을 할 수 있다.
  • 마크다운 문법을 활용해 자유롭게 문서를 작성할 수 있다.

목차

  • Step 1. 개발자를 위한 첫 번째 필수 교양
    • 협업에 필요한 여러 가지 툴들에 대해 알아본다.
    • GitHub의 존재와 그 의미에 대해 알아본다.
  • Step 2. 내 코드의 모든 발자취를 기록할 수 있을까?
    • Git과 GitHub의 차이에 대해 알고, 각각을 설치하며 시작해본다.
  • Step 3. GitHub에 첫 번째 잔디 심기, 어렵지 않아요!
    • GitHub을 처음 사용하기 위해 로컬 저장소와 원격 저장소를 만들어본다.
    • add, commit, push, pull 등의 명령어를 직접 실습을 통해 사용해 보고, 그 필요성을 안다.
  • Step 4. 개발자 문서작업의 시작과 끝! 마크다운을 익혀보자
    • 다양한 마크다운 문법을 알아보며 직접 실습을 통해 익혀본다.

4-2. 필수 교양

(1) 협업을 더 잘, 더 편리하게 하기 위해

안녕하세요! 🤗 오늘은 말 그대로 개발자를 위한 첫 번째 필수 교양을 배워보도록 하겠습니다.

개발자에게 필요한 가장 첫 번째 덕목은 무엇일까요? 많은 의견이 있을 수 있지만, 언제나 빼먹지 않고 이야기되는 것은 바로 협업 능력입니다.

협업 능력은 분야와 직무를 막론하고 어디서든 중요한 스킬이겠지만, 특히 개발자들에게 많이 요구되는 이유는 아마 그만큼 협업을 통해 해결해야 하는 문제가 많기 때문일겁니다. 그만큼 개발 분야에는 협업을 위한 도구들이 많이 사용되고, 계속해서 더 좋은 도구가 개발되고 있습니다.

오늘 자세하게 배워볼 협업 및 버전관리 툴 깃허브(GitHub) 을 시작하기 전에, 커뮤니케이션 및 생산성 앱 중 가장 많이 쓰이면서도 어렵지 않은 몇 가지만 먼저 소개해 드리고 시작하도록 하겠습니다. 앞으로 개발 또는 인공지능 분야를 계속 탐험할 예정이라면 아주 많이 다루게 될 수 있는 도구들이니, 한 번 눈에 익혀두고 가는 것도 좋을 겁니다!

✔️ Slack (슬랙)

  • 링크 : https://slack.com/

    슬랙은 많은 사람들이 효율적으로 소통하는 데에 최적화 된 앱입니다.

팀 단위로 각각의 Workspace를 만들고, Workspace 안에서는 주제 단위로 채널을 만들어 소통할 수 있습니다. 단순한 메세징을 넘어 코드, 파일, 링크, 일정 등 다양한 정보를 주고받을 수 있어요. 또 구글 캘린더, 구글 드라이브, GitHub 등 다양한 다른 프로그램과의 연동을 지원해 협업을 하는 데에 필요한 거의 모든 것들을 빠르게 공유할 수 있는 것이 장점입니다.

✔️ Notion (노션)

링크 : https://www.notion.so/

노션은 협업뿐만 아니라 혼자 업무를 진행할 때에도 생산성을 크게 높여줄 수 있는 문서작성 앱입니다.

표, 카드보드, 리스트 등의 다양한 포맷을 편리하게 사용할 수 있도록 최적화되어 있으며, 다른 사람과 페이지를 공유하여 함께 작업하거나 진행상황을 확인할 수 있도록 도와줍니다. 위 이미지의 오른쪽 부분에서 볼 수 있듯 다양한 템플릿을 제공합니다. 직관적이면서도 보기 좋은 문서를 편리하게 만들도록 도와주는 앱이라고 할 수 있습니다.

✔️ Trello (트렐로)

링크 : https://trello.com/

트렐로는 진행되고 있는 작업을 한 눈에 확인하고 관리할 수 있는 To-Do 앱입니다.

이 또한 다른 사람들과 함께 관리할 수 있도록 해주며, 위 이미지처럼 To Do, Doing, Done 등의 각 보드를 자유롭게 만들어 작업 리스트를 편하게 관리할 수 있습니다. 각 보드 안에는 할 일 별로 카드를 만들어 준 후 카드를 원하는 보드로 옮겨 현재 상황을 편리하게 표시할 수 있다는 장점이 있습니다. 트렐로를 적절히 활용하면 현재 해야 할 일의 우선순위와, 진행되고 있는 일들을 최적화하여 관리할 수 있습니다.

✔️ Zoom (줌) / Google Meet (구글 밋)

Zoom 링크 : https://zoom.us/
Google Meet 링크 : https://meet.google.com/

줌, 구글 밋은 모두 화상회의를 위한 앱입니다.

원격 근무 또는 재택 근무가 점점 많아지면서 사용 빈도가 높아지고 있습니다. 동시에 여러 명이 접속해서 카메라로 얼굴을 보여주거나 화면을 공유할 수 있습니다. 화상회의를 위한 툴은 줌 외에도 스카이프 등 다양하기 때문에 기업 또는 팀의 활용 목적에 보다 부합하는 툴을 사용할 수 있습니다. 다만, 무료 버전의 경우 사용 시간 또는 동시 접속 인원에 대한 제한이 있으니 확인해 보고 사용해야 합니다.

이 외에도 개발자의 생산성을 위한 앱은 무궁무진합니다. 많은 개발자들은 조금이라도 더 효율적으로 소통하고 업무를 하기 위해 노력하고 있죠.

이 글을 읽고 계신 분도 혹시 생산성과 커뮤니케이션, 협업을 더 잘 하는 방법 등에 관심이 있다면 다음과 같은 키워드로 검색해 보는 것을 권합니다.

💡 Keywords

  • 개발자의 생산성
  • 개발자를 위한 생산성 도구
  • 개발자 협업
  • 개발자 커뮤니케이션

개발을 다루는 사람이라면 원하는 자료를 잘 찾는 능력을 갖추는 것 또한 매우 중요합니다. 그러기 위해서는 위와 같이 여러 키워드를 다양하게 검색해 보는 시도도 필요하죠.

더 잘 할 수 있으려면 먼저 무엇이 존재하는지 많이 아는 것도 중요하니까요! 어떤 자료든 많이 검색해 보고, 많이 읽어보시는 것은 언제나 도움이 될 것입니다.

(2) 개발자의 가드닝, 잔디 심기

잔디 심는 개발자, 혹시 들어보셨나요? 바로 다음과 같은 잔디밭 말이죠!

빽빽한 잔디밭.. 👍

위 이미지는 바로 GitHub이라는 사이트의 활동 기록입니다.

바로 위처럼 나타나는 잔디로 인해, 개발자에게 GitHub은 아주 강력한 버전 관리 호스팅 사이트이면서, 개발자로서 나의 열정을 가장 빠르게 보여줄 수 있는 플랫폼이기도 합니다.

위에서 보이는 작은 사각형은 하루하루를 나타냅니다. 왼쪽 끝에서부터 오른쪽 끝까지 각 열마다 일주일을 나타내며, 총 365개의 셀로 1년을 보여줍니다. 조금 후에 배울 commit 이라는 활동을 해서 GitHub 사이트에 그 내역을 전송하면, 오늘을 나타내는 셀이 초록색으로 칠해집니다. commit 을 많이 하면 더 진한 초록색으로, 조금 하면 연한 초록색으로 보이죠. 아무 활동도 하지 않은 날은 그냥 회색 셀로 보입니다.

즉, 위와 같이 모든 셀이 초록색으로 칠해졌다는 것은 1년 365일을 빼먹지 않고 commit 했다는 것을 나타냅니다. commit 을 한다는 것은 어떤 식으로든 코드를 다루었거나 개발과 관련된 문서 작업 등을 했다는 뜻인데, 1년 동안 개발 관련 작업을 단 하루도 빼먹지 않고 했다는 것이죠. 실제로 저렇게 초록초록한 잔디밭을 만드는 것은 절대 쉬운 일이 아닙니다.

그만큼 개발자 사이에서는 "1일 1커밋하기" 같은 운동이 있기도 합니다. 1일 1커밋을 꾸준히 지속한다면 위와 같이 예쁜 잔디밭을 만들 수 있기 때문에, 저것만으로도 자기 자신이 굉장히 성실한 사람이라는 것을 나타낼 수 있기 때문이죠.

어떤가요? 여러분도 여러분만의 잔디를 심어보고 싶지 않으신가요?!

하지만 사실 잔디심기는 GitHub의 부수적인 부분일 뿐입니다. 실제로 GitHub의 용도는 많은 개발자들이 코드를 오픈소스로 공유하고, 여러 명이 한 팀을 이루어 개발을 진행할 때 복잡한 코드 버전들을 효율적으로 관리하기 위한 호스팅 사이트죠.

흠, 이런 설명만으로는 사실 GitHub이 정말 어디에 필요하고 어떻게 활용되는지 감이 오지 않으실 것 같습니다. 하지만 아직 첫 단계이니만큼, 어렵게 생각하지 않으셔도 됩니다.

GitHub은 코드를 다루는 개발자들이 편리하게 협업하기 위한 도구라는 것만 기억하고, 다음 스텝부터 실제 내용을 알아보도록 하겠습니다. 가시죠!

4-3. 내 코드의 모든 발자취를 기록할 수 있을까?

(1) 버전관리와 Git

혹시 슈퍼마리오 게임을 해 보셨나요?

[도토리 평원-1 내에서 차례로 클리어해야 할 다양한 맵들]

슈퍼마리오 같은 게임에선 클리어해야 하는 맵들이 순서대로 있고, 플레이어는 각 맵에서 여러 번 죽어보기도 하면서 하나하나 게임을 깨나갑니다. 만약 World 2의 stage 4를 막 클리어했다면, 많은 경우 지금 게임기를 끄고 다음에 다시 키더라도 stage 4의 다음 맵인 stage 5부터 진행할 수 있습니다. 처음부터 다시 시작할 필요가 없는 거죠.

간단히 말하자면 바로 이런 것이 버전 관리의 대표적인 예라고 할 수 있습니다. 특정 시점의 진행 상황을 저장해두고, 언제 다시 돌아오더라도 그 시점으로부터 다시 시작할 수 있도록 관리하는 것이죠. 만약 되돌아가는 기능도 있다면, 언제든 원하는 과거 시점으로 돌아갈 수도 있을 것입니다.

개발을 하면서 코드를 짜다보면 이러한 버전 관리가 필수적입니다. 코드를 삭제하거나 덧붙인 다음, 되돌리고 싶을 때 영영 돌아갈 수 없는 상황은 너무 끔찍하죠. 아주 간단하고 짧은 코드만을 짠다면 필요가 없겠지만, 코드가 점점 길어지거나 파일이 많아짐에 따라 특정 시점에서의 버전을 잘 기록해두고 관리해야할 필요성이 커지죠. 나 혼자서 하는 작업이 아니라, 다른 사람과 함께 한다면 더더욱이요.

소스 코드의 버전 관리를 도와주는 시스템 중 하나가 바로 Git과 GitHub입니다. 코드의 버전을 관리함과 동시에 다른 사람과 협업하는 것을 편리하게 만들어주는, 개발자에겐 산소와 같은 프로그램이죠. 오늘은 Git과 GitHub을 자세히 알아보고, 그 활용법을 익히며 직접 실습을 해볼 예정입니다.

오늘 과정에서는 앞으로 공부를 하면서 Git과 GitHub를 다루기 위해 꼭 알아야 하는 핵심 내용들을 빠르게 짚고 넘어갈 텐데, 사실 Git과 GitHub는 사용 방법만으로도 두꺼운 책 한 권이 나올만큼 내용이 방대합니다. 따라서 오늘 기초적인 것들을 학습한 후 꼭 책이나 전체 내용을 다루는 온라인 커리큘럼 등을 통해서 보다 깊게 공부해 보시는 것을 추천드립니다.

💡 기본서: Pro Git

💡 Git, GitHub을 온라인에서 공부할 수 있는 좋은 컨텐츠 : 지옥에서 온 Git

그렇다면, 각각의 정확한 개념부터 알아보러 가시죠.

(2) Git과 GitHub

개발을 공부하다보면 애매모호하게 알고 넘어가는 용어들이 참 많습니다. 받아들일 당시에는 어렴풋이 그 의미를 이해했다고 생각하지만, 사실 입문자가 그 본질을 제대로 이해하기에는 어려운 것들이 많기 때문이죠. 그래서 새로운 것을 배울 때 용어를 확실하게 알고 시작하는 것은 그것을 더 깊게 이해하는 데에 큰 도움을 줍니다.

위에서 잠시 언급했던 Git과 GitHub, 이 두 가지의 차이는 무엇일까요? 두 용어를 정의내려보자면 다음과 같습니다.

✒️ Git

개발을 진행하며 작성하는 소스코드가 업데이트 되는 버전을 기록해두고 관리할 수 있는 소스코드 버전 관리 시스템

✒️ GitHub

Git으로 관리하는 프로젝트를 호스팅하고, 시간과 공간의 제약 없이 협업할 수 있는 온라인 서비스

이 두 가지를 조금 더 풀어서 설명하자면 다음과 같이 말할 수 있습니다.

  • Git이 버전 기록을 저장한다면, GitHub에서는 그 기록을 다른 사람과 함께 공유하며 협업할 수 있다.
  • 로컬(Local)에서 작업한 내용을 Git이 저장해 두었다면, 그 기록을 온라인 작업공간인 GitHub에 올려 원격(Remote)으로도 작업할 수 있도록 한다.

여기에서 로컬이란 개인 노트북 또는 데스크탑같은 Personal Computer를 뜻하고, 원격(Remote)이란 웹사이트와 같이 다른 사람과 함께 작업할 수 있는 공간을 뜻합니다.

역사 이야기를 조금 해볼까요? 사실 Git은 리눅스의 창시자 리누스 토르발즈가 만든 오픈소스 툴입니다. 전세계 사람들이 오픈소스인 리눅스를 함께 개발하고 관리하다 보니 여러 명의 개발자가 짠 코드를 일목요연하게 합치고, 각 버전을 나눌 필요가 생겼습니다. 그래서 리누스 토르발즈는 리눅스 프로젝트의 코드 버전을 관리하기 위한 소프트웨어를 짜기 시작했는데, 그게 바로 Git인 것이죠.

GitHub은 Git이라는 도구를 더 쉽게 사용하게 해주는 사설 서비스입니다. 사실 GitHub과 같이 웹사이트 기반으로 Git을 관리하는 온라인 서비스는 GitHub 외에도 GitLab 등 다양합니다.

정의와 함께 설명을 읽어보니 조금 더 와닿게 이해가 되시나요? Git과 GitHub 두 가지의 차이를 스스로 정리해 보면서 보다 잘 이해하고 넘어가기를 바랍니다.

정리 >> Git은 코드의 버전을 관리하며 로컬에서 작업하며 기록을 저장할 수 있다. GitHub은 웹사이트로, Git의 버전 기록을 올려 다른 사람과 협업할 수 있다.

(3) Git, GitHub 셋팅하기

우분투에서 Git 시작하기


두 가지의 개념을 자세히 알아봤으니, 바로 사용해 보지 않을 수 없겠죠.

클라우드에는 이미 Git이 설치돼있습니다. Cloud Shell에서 아래 명령어를 실행하여 버전을 확인해보세요!

$ git --version

버전이 잘 표시된다면 Git을 사용하실 준비가 완료된 것입니다.

GitHub 시작하기


그렇다면 그 다음은? 바로 GitHub을 사용해 보러 가야겠죠!

먼저 GitHub은 위에서 설명했듯 웹사이트 기반의 소스코드 버전관리 시스템이기 때문에, 해당 사이트의 계정을 만들어야 시작할 수 있습니다.

GitHub에 접속해 Sign Up을 눌러 계정을 만들어 봅시다.

GitHub 공식 문서를 통해 시작해도 좋습니다.

* Signing up for a new GitHub account

계정을 만들 때 유의해야 할 것은 중복되지 않는 Username을 잘 선택해야 한다는 것, 그리고 인증 가능한 email을 사용해야 한다는 것입니다. 인증 메일을 확인하는 것을 잊지 마세요!

특히 Username은 내 GitHub 페이지의 도메인 주소가 되기 때문에 신중하게 짓는 것을 추천합니다!

여기까지 준비가 되었다면, 당신은 Git과 GitHub을 활용한 버전관리 세상에 들어갈 준비가 완료된 것입니다.

다음 스텝부터 본격적으로 활용해 보도록 하겠습니다!

4-4. GitHub에 첫 번째 잔디 심기, 어렵지 않아요!

(1) 로컬 저장소

이제 Git과 GitHub까지 준비물은 모두 준비되었습니다.

이제 직접 첫 번째 코드를 로컬 저장소(내 노트북)에서 원격 저장소(GitHub 서버)로 보내고, 위에서 보았던 초록색 잔디🌱를 한 단계 한 단계 천천히 거치며 완성해 보도록 하겠습니다!

가. 로컬의 Git에 GitHub의 계정 정보 등록하기


첫 번째로 해야 할 일은 로컬의 Git과 원격에 있는 GitHub을 연결하는 것입니다.

위에서 설명했던 Git과 GitHub의 설명이 기억나시나요? Git이 로컬에서 버전 관리를 하는 툴이라면, GitHub은 원격으로 관리하며 협업할 수 있는 웹사이트라고 소개했었죠.

이 때 로컬의 Git과 동기화를 해서 온라인으로 관리할 수 있는 원격저장소를 GitHub에서는 레파지토리(Repository)라고 부릅니다.

따라서 우리가 로컬에서 다양한 코드 작업을 한 후, GitHub의 내 계정에 있는 원격저장소, 레파지토리로 잘 전송하려면 로컬의 Git이 원격의 GitHub 계정 정보를 알고 있어야겠죠.

다행히 우리는 다음과 같은 명령어로 간단히 Git과 GitHub을 연결할 수 있습니다.

$ git config --global user.email "my-email@gmail.com"
$ git config --global user.name "my-username"

위에서 my-email@gmail.commy-username 부분은 자신의 email 주소와 username으로 변경해서 입력하면 됩니다. 이렇게 입력해주고 나면 Git 툴이 내가 GitHub 사이트로 코드 정보를 전송할 때 어떤 계정에 있는 레파지토리로 전송해야 하는지 기억합니다.

아래와 같이, Git에 등록한 config의 정보를 모두 확인하고 싶으면 다음과 같이 입력해 봅시다.

$ git config -l

나. 내 컴퓨터에 로컬 저장소 만들기


그 다음으로는 먼저 내 컴퓨터에 Git으로 관리해 보고 싶은 로컬 저장소를 만들어보겠습니다. 로컬 저장소라는 용어라고 칭하니 거창해 보이지만, 사실은 특별할 것 없이 우리가 보통 파일을 관리할 때 쓰는 폴더, 즉 디렉토리를 말합니다. Git은 디렉토리를 기준으로 그 하위에 있는 모든 폴더와 파일에 대한 버전을 기록할 수 있습니다.

다음과 같이 사용자 홈 디렉토리로 이동한 후 workplace 라는 이름으로 새로운 폴더를 만들어보겠습니다.

우리는 이 새로운 폴더에서 작업을 시작할 것입니다.

$ cd ~
$ cd aiffel
$ mkdir workplace

자, 저번 시간에 배웠던 두 가지 명령어가 나왔습니다. 각각의 명령어가 무엇을 뜻하는지 기억하고 있나요?

  • cd : 현재 디렉토리 변경
  • mkdir : 새로운 폴더 생성

다. Git으로 버전 관리 시작하기


우리가 작업을 진행할 새로운 디렉토리 workplace 를 생성하였습니다.

이제 그 디렉토리로 옮겨가보시죠.

$ cd workplace

우리는 이제 이 디렉토리를 Git으로 관리하기 시작할 것입니다. 다음 명령어로 Git을 현재의 디렉토리 내에 심어놓을 수 있죠!

$ git init

init 은 initialization의 약자입니다. 시작한다는 뜻을 갖고 있죠. 이제부터는 Git이 지금 있는 workplace 디렉토리에서 발생하는 모든 변화를 기록해둘 것입니다. ls만 해서는 보이지 않겠지만 다음과 같이 하면 빈 디렉토리였던 workplace 안에 새롭게 생긴 .git 디렉토리와, 그 안에 있는 내용들을 확인해 볼 수 있습니다.

$ ls -a
.  ..  .git
$ cd .git
$ ls 
HEAD  branches  config  description  hooks  info  objects  refs

이게 무슨 뜻일까요? git initworkplace라는 디렉토리를 새로운 Git 로컬 저장소로 만들었다는 뜻입니다. 모든 Git 로컬 저장소는 .git이라는 디렉토리를 가지고 있습니다.

(2) 변화 추적하기

라. README.md 파일 생성하기


README 파일을 들어보셨나요? 리드미 파일이라고도 부르는 이 파일은, GitHub의 레파지토리에서 대문과 같은 역할을 하는 파일입니다.

다음의 Tensorflow 오픈소스 코드가 올라와있는 GitHub 레파지토리를 구경하러 가보죠.

다음 이미지와 같은 README.md 파일을 확인하셨나요?

이렇게 README.md 파일은 레파지토리를 들어갔을 때 그 레파지토리가 담은 오픈소스 코드들에 대해 소개하는 역할을 합니다.

레파지토리 주인이 어떻게 그 파일을 꾸며놓느냐에 따라 그 레파지토리를 구경하는 사람들이 느끼는 첫인상도 달라지겠죠.

md 라는 확장자는 Markdown, 마크다운이라는 파일을 지칭하는데 마크다운이란 개발자들이 가장 많이 사용하는 문서작업 용 언어입니다.

언어라고 하니 거창해 보이는데, 크게 어렵지 않습니다! 마크다운에 대한 내용은 15번째 스텝 (개발자 문서작업의 시작과 끝! 마크다운을 익혀보자 (1) 마크다운 소개)에서 간단히 익혀보고 갈 예정인데, 그 정도만 익혀도 충분할 것입니다.

아무튼, 이렇게 내 레파지토리를 구경 올 사람들에게 내 작업물에 대해 간단히 소개하기 위한 파일이 바로 README.md 파일인 것이죠.

그렇다면 첫 번째 레파지토리에 담길 첫 번째 리드미 파일을 만들어볼까요?

$ cd ~/aiffel/workplace
$ echo "# first-repository" >> README.md

위와 같은 명령어를 입력하면 README.md 파일을 생성함과 동시에 그 파일 내에 # first-repository 라는 한 줄이 입력되게 됩니다.

echo는 출력을 하는 명령어인데, 출력 스트림을 지정하는 >>을 통해 출력 타겟을 README.md 파일로 지정했기 때문입니다.

위 명령어를 실행했다면 다음과 같이 README.md 파일이 생성된 것을 확인할 수 있을 것입니다. cat 명령어를 통해 생성된 텍스트 파일을 열어 봅시다.

참고: Linux manual - cat(1)

$ ls
README.md

$ cat README.md
# first-repository

ls 로 파일 목록을 확인하면 README.md 파일이 목록 내에 출력될 것이고, cat 명령어를 통해 해당 파일에 작성되어 있는 내용을 확인하면 우리가 입력한 # first-repository 가 출력될 것입니다.

마. git으로 변화 확인! 지금 버전에 도장 쾅! 찍기


자, 우리는 방금 git으로 버전을 관리하고 있는 workplace 디렉토리에 README.md 파일을 생성함으로써 변화를 주었습니다.

그 변화가 아무리 미미할지언정 변화는 변화이니, git은 그 변화를 감지했을 것입니다!

Git이 추적하고 있는 변화는 다음 명령어로 확인할 수 있습니다.

$ git status
On branch main

No commits yet

Untracked files:
    (use "git add <file>..." to include in what will be committed)
    README.md

nothing added to commit but untracked files present (use "git add" to track) 

💡 main, master. 깃허브의 정책 변화?

위 실행창에서 On branch main 부분은 On branch master로 뜰 수도 있습니다.

이를 잘 확인하여 다음 스텝에서 살펴볼 git push명령어에서 변경하여 사용 하시면 됩니다.

깃허브의 입장에 따르면, 기존에 사용하던 master 라는 표현은 인종차별을 연장할 수 있다며 main이라는 표현으로 바꾸기로 했답니다.

깃허브, 개발용어 '마스터'→메인으로 바꾼다

위와 같은 내용이 출력되었다면 성공입니다. Untracked files: 라고 하며 아직 추적되지 않은 새로운 파일인 README.md 파일을 잡아내었죠.

그렇다면 우리는 git에 이 변경사항을 저장해 둘 필요가 있겠죠. add 와 commit 두 가지의 명령어로 진행할 수 있습니다.

$ git add README.md
$ git commit -m "new readme file"
[master (root-commit) 438a37c] new readme file 
    1 file changed, 1 insertion(+)
    create mode 100644 README.md

-m은 메세지 옵션입니다. git commit -m 뒤에는 해당 커밋에 대한 설명을 작성하면 됩니다.

add 와 commit 의 개념은 Git을 다룰 때 아주 중요한 개념 중 하나입니다. 두 명령어 모두 현재의 변화를 기록하기 위한 명령어인데, 중요한 차이가 있습니다.

다음 두 가지 글을 먼저 읽어보고 add 와 commit 의 차이를 한 번 생각해 보죠.

차이에 대한 감이 오시나요?

간단히 말하자면 add 는 해당 순간을 스냅샷으로 남겨두기 위한 준비작업, commit 은 해당 순간을 정말 도장처럼 쾅! 찍어서 기록해두는 확정 작업인 셈이죠.

아무튼, 여기까지 우리는 새로운 파일인 README.md 파일이 생성된 순간의 버전을 스냅샷으로 잘 기록하였네요!

(3) 원격 저장소

바. GitHub에 나의 첫 번째 레파지토리 만들기


자, 이제 로컬 저장소에서 새로운 파일을 만들었고, 그 기록을 commit 으로 저장도 해두었으니 이걸 원격저장소, 즉 레파지토리에 옮겨볼 차례입니다.

옮기기 위해서는 먼저 레파지토리를 만들어야겠죠!

다음 포스팅에서 안내하는 순서대로 레파지토리를 만들어 보겠습니다.

  • 깃허브(Github) 원격저장소(Repository) 생성

레파지토리 이름은 원하는대로 마음대로 생성해 보세요! 저는 first-repository 로 생성했습니다.

포스팅에서는 레파지토리를 생성하면서 REAMDE 파일을 함께 생성하도록 안내가 되어있는데, 우리는 이미 로컬저장소에서 README 파일을 만들어 놓았으니 그 부분은 체크 해제해서 진행하면 됩니다.

무사히 생성했다면 다음과 같은 레파지토리가 생성된 화면을 볼 수 있을 것입니다.

레파지토리 이름이 직접 지정했던 이름으로 잘 생성되었나요? 다음 이미지에서 first-repository 위치에 설정한 이름이 뜬다면 성공입니다!

사. 내 로컬 저장소와 원격 저장소를 연결해 보자!


이제 로컬 저장소도, 원격 저장소도 모두 준비가 되었으니 둘을 연결하는 일만 남았습니다.

둘을 연결하는 연결고리는 바로 위의 이미지에서 봤던 내 레파지토리의 주소입니다.

위 이미지에서 HTTPS 라고 적힌 오른쪽에 https://... 라고 적혀있는 레파지토리의 주소가 보이시나요? 저 주소를 로컬 저장소에 있는 git에게 알려주면 git은 GitHub의 원격 저장소의 주소를 알고 두 저장소 간에 정보를 전송할 수 있습니다. 주소 칸의 맨 오른쪽에 보이는 아이콘을 누르면 주소가 클립보드에 복사됩니다.

주소를 클립보드에 저장한 후, 터미널에서 아래 명령어를 입력해서 로컬 저장소에 있는 Git이 원격 저장소의 주소를 알 수 있도록 저장하겠습니다. 아래 명령어는 꼭 로컬 저장소 디렉토리 안에서 실행해야 합니다.

$ cd ~/aiffel/workplace
$ git remote add origin https://github.com/xxx/first-repository.git

origin 은 원격 저장소의 닉네임과 같은 역할을 합니다. 앞으로는 복잡한 https://... 의 주소를 매번 사용하는 것이 아니라, origin 이라는 이름으로 원격 저장소를 지칭할 수 있는 것이죠. 물론 위의 xxx 부분은 본인의 username이 들어가야합니다!

샤. GitHub에서 토큰 생성하기!


이제 로컬 저장소에 저장된 내용을 원격 저장소로 전송해야 합니다.

그런데 연결만 한다고 아무나 원격 저장소로 전송할 수 있다면 어떻게 될까요? 이걸 막기 위해 비밀번호를 사용해야 겠죠?

하지만 GitHub에서는 이제 비밀번호를 사용하지 않습니다. 대신 토큰을 만들어서 사용합니다. 토큰은 시간 제한이 있는 비밀번호라고 생각하면 됩니다. 또 한 가지 다른 점은 내가 만들 수 없다는 거에요. GitHub이 만들어 줍니다.

이제 만들러 가보죠.

GitHub에 로그인 한 상태에서 위 링크를 참고해 토큰을 만들어 주세요! 토큰의 유효 기간을 지정하고 그 기간을 잘 기억해놔야 나중에 당황하지 않을거에요~! 어느날 갑자기 안돼서 당황할 수가 있어요!!

아. 로컬 저장소의 기록을 원격 저장소로 전송하기


이제 모든 준비가 끝났으니 로컬에서 레파지토리로 전송하는 것은 아주 간단합니다.

바로 다음 명령어 두 줄이면 되죠.

$ git config credential.helper store
$ git push origin main
Username for 'https://github.com': [계정에 사용된 이메일을 입력하세요]
Password for 'https://[위에 입력한 이메일]@github.com': [비밀번호(토큰)를 입력하세요]
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 230 bytes | 230.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/jeina7/first-repository.git
    * [new branch]      master -> master

계정에 사용된 이메일을 입력하고, 비밀번호를 입력해야 합니다. 비밀번호 대신 위에서 생성한 토큰을 입력하면 됩니다.

긴 토큰을 입력하기 위해 복사/붙여넣기를 해야하는데요. 터미널에서 붙여넣을 때는 Ctrl+Shift+V를 입력하면 됩니다.

위 커멘드에서 에러가 난다면 git push origin master로 시도 해보시기 바랍니다.

위 명령어는 현재 로컬에 있는 버전 기록과 모든 파일들을 origin, 즉 원격 저장소의 master 브랜치로 push해 밀어넣겠다는 뜻을 가집니다.

브랜치란, 간단히 말하자면 작업을 하는 '가지'를 말합니다. 하나의 작업을 여러 개의 가지로 분기하여 작업을 진행할 수 있습니다.

그리고 push를 할 때마다 매번 로그인을 하지 않으려면 git config credential.helper store 명령어를 단 한 번만 실행해주시면 됩니다.

브랜치의 개념은 다음 글에서 한 번 더 확인해 보도록 하겠습니다.

위 작업까지 모두 마치게 되면 우리는 우리의 첫 번째 Repository를 완성한 것입니다.

다음과 같은 레파지토리의 모습이 확인되시나요?!

클라우드 환경 팁!

이제 앞으로도 원격 저장소에 전송을 할 경우라면 클라우드 환경에서는 한 가지 문제가 있습니다.

$ git config --global 후략...

앞서 계정 정보를 등록하면서 위와 같은 명령어를 사용했는데요. --global 옵션을 사용하면 약속된 폴더에 그 정보가 저장됩니다. 약속된 폴더는 /aiffel 폴더 바깥에 있어요. 그런데 클라우드 환경을 새로 만들면 /aiffel 폴더 밖에 있는 모든 내용이 삭제되기 때문에 --global 옵션을 사용해 저장했던 내용이 사라집니다. 그래서 클라우드 환경에서는 계정 정보가 /aiffel 폴더 안에 저장되도록 만들어야 클라우드 환경이 바뀌어도 계정 정보가 남아있게 됩니다.

아래 명령어를 사용하면 계정 정보를 원하는 위치에 저장할 수 있습니다.

$ cd ~/aiffel/workplace
$ git config credential.helper "store --file ~/aiffel/.git-credentials"

~/aiffel/.git-credentials 이 아닌 다른 파일 이름이나 위치로 저장할 수도 있습니다.

설정 후에는 그 아래 명령어로 설정된 내용을 확인할 수 있어요.

$ git config -l

아래 항목이 나오면 성공입니다.

credential.helper=store --file ~/aiffel/.git-credentials

여기까지 진행해도 실제로 ~/aiffel/.git-credentials 파일은 생기지 않습니다.

아래 명령어로 README.md 내용을 바꿔 원격 저장소에 다시 저장해 봅시다.

$ echo "## git config" >> README.md
$ cat README.md
$ git commit -a -m "change file"
$ git push origin main

아까 입력한 Username(이메일)과 Password(토큰)를 입력하면 원격 저장소에 변화된 내용이 저장되면서 ~/aiffel/.git-credentials 파일이 생성됩니다.

이제 저장된 ~/aiffel/.git-credentials 파일을 확인하러 가봅시다.

$ cd ~/aiffel
$ ls

어떤가요? 파일이 보이나요? 보이지 않는 것이 정상입니다. 이 파일은 . 으로 시작하는 숨김 파일이기 때문에 명령어에 옵션을 붙여야 보입니다.

$ ls -a

파일의 내용을 확인해 볼게요.

$ cat .git-credentials

아래처럼 계정 정보가 나옵니다.

https://[이메일].[비밀번호(토큰)]@github.com

이렇게 파일로 저장되어 다음부터는 이 파일을 이용해 자동으로 원격 저장소에 접근하게 됩니다. 아주 편리하겠죠?!

그런데 여기서 뭔가 이상하다고 생각해야 합니다. 바로 보안 때문이에요. 그 어떤 경우라도 비밀번호를 알아보기 좋게 저장해놓는 일은 없어야 합니다. 누군가 이 파일을 얻게 된다면 여러분의 원격 저장소는 탈취될 수도 있고, 삭제되어 사라져 버릴 수도 있습니다. 위 방법을 사용한다면 편의성을 위해서 보안을 포기하게 되는 것이죠. 그러므로 자신의 판단에 따라 이 방법을 사용할지 결정하세요.

이 방법을 사용하고 싶지 않다면 아래 명령어를 통해 설정을 삭제할 수 있습니다.

$ rm ~/aiffel/.git-credentials
$ ls -a
$ cd ~/aiffel/workplace
$ git config --unset credential.helper
$ git config -l

어떤가요? 비밀번호가 적힌 파일도 사라지고 아까 설정이 사라졌나요? 그렇다면 이제 불편하긴 하지만 안전해졌습니다.

(4) 협업하기

자. 원격 저장소를 로컬로도 가져올 수 있을까?


만약 우리가 지금까지 했던 것처럼 로컬 저장소를 GitHub의 원격 저장소로 전송하는 것이 아니라, 그 반대로 이미 GitHub에 올라와 있는 저장소를 통째로 내 로컬에 가져오고 싶다면 어떻게 해야 할까요?

이 작업 또한 아주 간단합니다.

원격 저장소를 로컬에 가져오려면 역시 그 연결고리가 필요하겠죠. 다음과 같이 레파지토리의 주소를 복사하겠습니다.

우리는 이 저장소를 아까 생성했던 workplace가 아닌 다른 디렉토리인 project에 가져와보겠습니다.

$ cd ~
$ cd aiffel
$ mkdir project
$ cd project

이동 후에, 다음과 같은 명령어를 사용하면 GitHub의 레파지토리를 통째로 가져올 수 있습니다. 명령어는 복제라는 뜻을 가진 clone 을 사용합니다.

❗ (주의) 아래 코드를 실행할 때 ...github.com/xxx/first-repository...에서의 xxx 부분을 본인의 깃허브 username 으로 대체해주세요.

$ git clone https://github.com/xxx/first-repository.git
Cloning into 'first-repository'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.

그러면 제대로 잘 복사가 되었는지 확인해볼까요?

$ ls
first-repository

ls 로 확인하면 레파지토리 이름으로 폴더가 생성된 것을 확인할 수 있습니다. 이동해서 확인해 보죠.

$ cd first-repository
$ ls
README.md

폴더 내로 이동해서 다시 ls 로 확인하면 우리가 아까 만들어놓고 레파지토리로 전송했던 README.md 파일을 확인할 수 있습니다. cat 으로 내용을 확인해 보죠!

$ cat README.md
# first-repository

내용도 우리가 작성한대로 잘 가져와졌군요.

차. 로컬로 가져온 원격 저장소를 수정해서 다시 push 해 보자!


그렇다면 이제 로컬로 가져온 레파지토리 내용을 수정해서 다시 원격으로 전송해 보는 작업을 할 것입니다.

파일에 변화를 주기 위해서 현재 있는 README.md 파일을 한번 수정해 보겠습니다.

$ echo "add new contents" >> README.md

이번에도 echo 명령어를 활용하지만, 아까와는 다르게 이미 README.md 파일이 있기 때문에 새로 생성하는 것이 아니라 현재 있는 파일의 아래쪽에 문자열을 추가하게 됩니다.

다시 한 번 파일 내용을 확인해볼까요?

$ cat README.md
# first-repository
add new contents

내용에 원래 있던 첫 번째 줄과 아래 두 번째 줄이 추가되었군요.

그렇다면 다시 변화가 생긴 것이니, git이 이 변화를 추적하고 있을 것입니다. 확인해봅시다.

$ git status
On branch master
Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
    modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

이번에는 README.md 파일이 새로 생긴 것이 아니라, modified 되었다고 나옵니다. 맞게 잘 추적하고 있는 것 같군요.

이제 다시 아까 했던 작업과 동일하게 add, commit 을 진행하도록 하겠습니다.

$ git add README.md
$ git commit -m "new contents"
[master c82640d] new contents
    1 file changed, 1 insertion(+)

새로운 commit, 즉 새로운 스냅샷이 저장되었습니다.

마지막 단계는 이것을 다시! 원격 저장소로 전송하는 것이죠. 원격 저장소로 보내는 명령어가 뭐였죠!? push !

$ git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 276 bytes | 276.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/jeina7/first-repository.git
    438a37c..c82640d  master -> master

만약 위에 커맨드가 안된다면 git push origin master로 다시 시도해 보세요!

위와 같은 결과가 나오면 모두 완료된 것입니다.

이제 최종적으로 원격 저장소, 레파지토리로 다시 가서 확인해봅시다.

새로운 내용이 잘 추가되었군요!

그렇다면 우리가 처음에 만들었던 workplace 디렉토리에도 이 변화가 반영되었을까요?

(5) 받아오기

카. 로컬 저장소를 원격 저장소의 내용과 같게 업데이트하자!


이제 오늘의 마지막 작업입니다. 원격 저장소의 README.md 파일이 수정된 것을 처음에 만들었던 workplace 로컬저장소에도 업데이트해주는 것이죠.

처음에 만들었던 로컬 저장소의 README.md 파일이 자동으로 업데이트 되었을까요? 다시 이동해서 확인해봅시다.

$ cd ~/aiffel/workplace
$ ls
README.md
$ cat README.md
# first-repository

음, 당연하지만 자동으로 업데이트가 되지는 않았군요. 하지만 다행히 이 로컬 저장소를 수정된 원격 저장소와 같게 업데이트 해주는 것 또한 매우 간단합니다.

$ git pull origin main
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/jeina7/first-repository
    * branch            master     -> FETCH_HEAD
    438a37c..c82640d  master     -> origin/master
Updating 438a37c..c82640d
Fast-forward
    README.md | 1 +
    1 file changed, 1 insertion(+)

push 의 반댓말, pull 로 origin 별칭의 원격 저장소를 로컬 저장소로 "당겨올" 수 있습니다.

역시 명령어가 안된다면 git pull origin master로 다시 시도해 보세요!

잘 가져와졌다면, 다음과 같은 결과가 나와야겠죠!

$ cat README.md
# first-repository
add new contents

add new contents 라는 내용이 추가되었다면 성공입니다!

수고하셨습니다! 👏🏼👏🏼👏🏼

(6) 정리

여기까지 모두 진행했다면, 우리의 GitHub 프로필 페이지에서 초록색 칸으로 색칠이 된 잔디를 확인하실 수 있을 것입니다. 확인이 되나요?

이렇게 잔디가 칠해지려면 commit, push 등의 GitHub 활동을 해야합니다. 즉, 맨 처음에 봤던 그 1년 내내 파릇파릇한 잔디는 이러한 코드 작업을 매일매일 한 것으로 볼 수 있죠.

우리가 지금까지 무엇을 한 걸까요?

그림으로 간단히 정리하자면 다음과 같습니다.

한 눈에 들어오시나요?

workplace 라는 로컬저장소, 다른 말로는 디렉토리를 만드는 것부터 시작해서, add, commit, push 세 가지의 명령어를 통해 원격 저장소로 전송하는 것까지 진행해 보았습니다.

그 후에는 원격 저장소를 다시 first-repository 라는 디렉토리로 복제해와서 파일을 수정한 후 다시 원격저장소로 전송했죠.

마지막에는 수정된 원격 저장소를 workplace 로 가져와서 처음 만들었던 저장소를 업데이트 하는 작업까지 진행해 보았습니다!

그렇다면 이렇게 복잡한 GitHub은 왜 써야하는 걸까요? 위 이미지를 단순화 된 이미지로 재구성하자면 다음과 같을 것입니다.

우리는 위의 작업을 모두 혼자서 진행했지만, 사실 다른 개발자들과 협업을 할 때는 다음 이미지와 같이 진행되는 것이죠.

위에서 봤던 workplace 를 만든 것이 개발자 A, 원격 저장소를 복제해왔던 first-repository 를 다루는 사람이 개발자 B라고 해 봅시다.

협업을 진행하는 두 개발자가 GitHub을 활용한다면, 둘은 서로 업데이트한 파일을 따로 전송할 필요 없이 GitHub에 Push 또는 Pull 하는 것만으로 효율적인 협업을 진행할 수 있는 것이죠. 지금은 크게 중요하지 않아 보일 수 있지만, 여러 개발자가 동시에 개발을 진행하며, 여러 개의 파일에 작업을 하고, 그 버전들이 다양해 질 경우, 각 파일의 버전이 관리되지 않는다면 파일을 관리하는 작업은 굉장히 복잡해질 수 있습니다.

이러한 어려움을 Git과 GitHub은 commit 이라는 버전 관리 작업을 통해 손쉽게 관리할 수 있도록 한 것이죠.

Git을 활용한 버전 관리는 앞서 언급했듯 오늘 배운 것보다 훨씬 다양한 명령어, 작업들을 포함하고 있습니다. 다른 사람이 관리하는 메인 레파지토리는 망치지 않으면서, 손님으로써 작업하기 위해 레파지토리를 fork 한다거나, fork 한 레파지토리에서 작업한 것을 다시 메인 레파지토리에 반영하도록 요청하기 위해 pull request 를 보내는 등 다른 기능들은 너무 방대해서 오늘 다 다루지 못했습니다.

앞으로 GitHub은 개발 공부를 진행하면서 쭉 함께할 친구일테니, 앞으로 더 다양하게 찾아보면서 공부하는 것을 권합니다. 많이 알수록, 더 편리해질 것이니까요!

4-5. 개발자 문서작업의 시작과 끝! 마크다운을 익혀보자!

(1) 마크다운 소개

드디어 오늘의 마지막 단계입니다.

여러 협업툴부터 Git과 GitHub부터까지 개발자를 위한 첫 교양은 거의 다 배웠다고 볼 수 있겠어요!

그러면 오늘의 마지막은, 개발자가 문서작업을 할 때 가장 많이 쓰는 언어인 마크다운까지 배워보고 마무리를 하도록 하겠습니다.

마크다운은 코드만으로 깔끔하게 문서 작업을 할 수 있도록 개발된 언어입니다. 다음 이미지를 보면 바로 이해가 되실 거에요!

마크다운은 위 이미지처럼, 왼쪽과 같이 코드를 치듯 문서를 작성한 후 md 라는 확장자를 가진 마크다운 파일을 렌더링을 하면 오른쪽과 같이 큰 문자, 볼드체, 링크, 리스트 등을 모두 표현해줍니다. 몇 가지 규칙에 맞게 문서를 작성하면 그 규칙 그대로 눈에 보이는 문서의 디자인을 만들어 주는 것이죠.

마크다운 문서는 우리가 위에서 GitHub 실습을 하며 다뤘던 README.md 파일을 만들 때도 사용되고, 주피터 노트북의 마크다운 셀에서 여러 설명 또는 제목을 넣어 문서 작업을 할 때 사용되는 등 그 사용범위가 굉장히 넓습니다. 다양한 포맷을 활용해 깔끔한 문서를 만들수도 있죠.

마크다운이 표현할 수 있는 디자인은 위와 같이 제목, 볼드체 등 여러 가지가 있습니다.

하지만 걱정하지 마세요! 절대 어렵지 않습니다. 한 번 익혀두면 굉장히 편리하게 문서를 원하는대로 디자인 할 수 있을 것입니다.

다음 페이지에 마크다운 문법이 굉장히 자세하게 설명되어 있습니다. 설명을 먼저 읽어보고, 주요한 문법들은 함께 익혀보도록 하겠습니다.

마크다운의 장단점!!
장점 : 간결하다, 별다른 도구 없이 작성할 수 있다.
단점 : 표준이 없다, 모든 HTML 마크업을 대체하지 못한다.

그러면 실제로 마크다운을 사용해 보겠습니다.

다음 내용에서 디자인이 된 부분은 마크다운 렌더링이 된 결과물을, 코드블럭 안에 있는 내용은 실제 마크다운을 입력하려고 할 때 입력되는 코드를 나타냅니다.

(2) 마크다운 작성하기

주피터 노트북에서 셀을 마크다운 셀로 변환한 후 다음 마크다운 문법들을 함께 따라 쳐 보세요!

제목 달기

마크다운에서 가장 많이 쓰이는 것은 아마 제목일 것입니다. 제목은 # 으로 달 수 있으며, # 의 개수에 따라 제목의 크기가 달라집니다.

위와 같이 # 이 많아질수록 작은 제목이 되며, 마크다운에서는 H6까지 지원하지만 어떤 툴로 마크다운을 사용하냐에 따라 H4~H6 까지는 지원이 안 될 수도 있습니다.

(2) 목록, 리스트 만들기

순서가 있는 리스트를 만들고 싶은 경우에는 숫자를 사용할 수 있습니다.

  1. 첫번째
  2. 두번째
  3. 세번째

순서가 없는 리스트는 간단하게 - , * , + 를 앞에 달아주면 됩니다.

  • 빨강
    • 녹색
      • 파랑
- 빨강
  - 녹색
    - 파랑

(3) 구분선 긋기

구분선은 --- 처럼 dash 기호를 세 개 입력하면 됩니다.


(4) 링크 달기

링크는 [보여줄 이름](http://...link..) 의 형태로 나타낼 수 있습니다.

구글

[구글](https://google.com)

(5) 볼드체, 이태리체, 취소선 등 강조하기

글씨 양쪽에 * 또는 _ 로 묶어주면 볼드체 또는 이태리체를, ~ 로 묶어주면 취소선을 나타낼 수 있습니다. (취소선은 브라우저 또는 환경에 따라 다르게 나타날 수 있습니다)

single asterisks
single underscores
double asterisks
double underscores
cancelline

(6) 코드블럭 입히기

코드블럭은 다음과 같이 ``` 세 개로 나타낼 수 있습니다.

print("hello Markdown")

(7) 줄바꿈하기

가장 놓치기 쉬우면서도 모르면 꽤나 골치가 아픈 줄바꿈인데요.

마크다운에서는 그냥 enter로는 줄바꿈이 되지 않습니다. 문장의 맨 끝에 띄어쓰기를 두 번 이상 해야 가능하죠.

띄어쓰기를 하지 않으면 다음의 첫 번째 줄처럼 한 줄로 출력됩니다.

  • 줄 바꿈을 하기 위해서는 문장 마지막에서 2칸이상을 띄어쓰기해야 한다. 이렇게
  • 줄 바꿈을 하기 위해서는 문장 마지막에서 2칸이상을 띄어쓰기해야 한다.
    이렇게

(8) 이미지 삽입하기

이미지는 이미지가 있는 경로를 잘 입력해주어야 나타납니다.

![Alt text](path/to/img.png)

사이즈 조절을 하고싶다면 다음과 같이 HTML 코드로 입력해서 사용할수도 있습니다.

<img src="/path/to/img.jpg" width="450px" height="300px"></img>

이 정도면 마크다운의 기본은 모두 익힌 것 같군요.

역시 이 외에 더 사용해 보고 싶은 문법이 있다면 더 많은 것들을 다룰 수 있게 되도록 직접 찾아보는 것을 추천합니다. 많이 검색할수록, 할 수 있는 것이 더 많아지니까요!

4-6. 마무리

오늘도 많은 것들을 배우느라 수고 많으셨습니다. 오늘은 어떤 것들을 배웠나요?

Step 1. 개발자를 위한 첫 번째 필수 교양 에서는 협업이 필수적인 개발자가 알아두면 좋을 여러 가지 협업 툴에 대해 알아보았습니다.
Step 2. 내 코드의 모든 발자취를 기록할 수 있을까? 에서는 코드의 버전을 관리하는 Git과 GitHub에 대해 알아보고, 직접 설치까지 해 보았죠.
Step 3. GitHub에 첫 번째 잔디 심기, 어렵지 않아요! 에서는 로컬 저장소와 원격 저장소를 오가며 GitHub에 첫 번째 commit을 해 보았습니다!
Step 4. 개발자 문서작업의 시작과 끝! 마크다운을 익혀보자 에서는 개발자가 문서작업을 할 때 가장 많이 사용하는 마크다운 언어의 문법에 대해 공부했죠.
와우, 오늘도 정말 많은 것들을 배웠네요.

이 정도 했다면, 우리는 앞으로 지금까지 배운 모든 도구들을 가지고 어떤 것이든 어렵지 않게 소화해낼 수 있을겁니다. 장담해요!

그러면 오늘 배운 것들은 꼭 다시 익혀보면서 더욱 익숙해지기로 약속하고, 다음 시간에 만나요!

profile
게임광 AI 그루~~

0개의 댓글