Ruby Coin

Rails 와 프론트 엔드 기술을 이용해 흥미 위주의 빠른 웹 개발 방법론

코스 전체목록

닫기

자기 서버에 원격 저장소 만들기 (My Server)

수업소개

여기서는 자기 서버에 직접 서버를 구축하는 방법에 대해서 알아봅니다. 

수업

댓글

댓글 본문
  1. qwer
    ssh: connect to host *ip주소* port 22: Connection refused
    다음과 같은 오류가 나타나서 구글에 찾아봐도 해결방법을 못찾았습니다.
    해결방법 아시는 분은 답글로 알려주시면 좋을 것 같습니다, 감사합니다.
  2. 주니어개발자
    이 내용은 윈도우 환경에선 실습할 수 없을까요
  3. chehwun.kim
    (Windows환경)
    $ git push --set-upstream origin master
    실행 중 ssh://'user name'@'host'에서 fail이 발생하는 경우 SSH Key를 통해 비밀번호 없이 로그인하는 방법을 사용하시면 됩니다.
    SSH Key 설정하는 방법은 아래 Link 참고하시구요.
    https://opentutorials.org......742
  4. kslee
    ssh git@13.124.42.13

    ssh : ssh 명령어입니다.
    git : 접속하려는 사용자아이디입니다. (접속하려는 서버의 접속아이디를 확인하셔야 합니다.)
    @ : 이메일의 @ 'at' 과 같은 의미입니다.
    13.124.42.13 : 접속하려는 서버입니다. (접속하려는 서버의 아이피 주소를 확인하셔야 합니다.)

    추가로 접속포트가 22이므로 방화벽에서 외부 접속 오픈해야 할 것입니다.
    대화보기
    • test
      본인 ip치셔야되용
    • commesary hoe
      ssh git@13.124.42.13 은 무슨 의미인가요?
      cmd 창에 똑같이 쳐보니 실습이 안되네요..
    • Deuklyoung Ko
      SSH-key 관련 egoing님 다른 강의 입니다.

      https://opentutorials.org......742
    • 김수현
      저스틴님 도움되실까해서 수업 들은 내용 아래에 입력했습니다.
      빠뜨린 부분도 있지만 도움이 되실 것 같습니다.

      그리고 각 목록마다에도 같은 내용을
      김수현이라는 이름으로 정리한 내용을 입력해 놓았습니다.

      원리부분의 수업은 입력하지 않았습니다.
    • 김수현
      설치 및 실습방법
      Git을 설치한다. > 윈도우에 설치시에는 다음 다음만 하지말고 설치도중 하나 다르게 해야 하는 부분이 있음(담담해도 수업진행에는 지장 없지만, add시 마다 약간의 에러메시지가 나옴)
      Git배쉬를 실행한다.
      실행창에서 Git이라고 입력하고 엔터를 친다.
      git 관련 명령어들이 나온다 > 설치 성공 확인 됨
      저장소 만들기
      https://codeonweb.com......rd/ <--- 온라인상에서 수업을 듣고 실행하려면 회원 가입후 git에 들어간다

      pwd(입력 엔터) > 현제위치를 알려줌
      cd documents
      mkdir gitfth < 의미(git from the hell)
      ls -al
      git에게 버젼관리할 디렉토리를 알려준다 < 프로젝트를 저장할 디렉토리로 이동 < git init
      ls -al 현디렉토리의 파일목록
      .git이라는 디렉토리가 생겼다는 것을 확인 < 버젼관리 파일들이 저장되는 곳
      git이 관리할 대상으로 파일 등록
      vim이라는 에디터를 사용할 것임(모든 곳(리눅스,윈도우, 맥)에 설치되어 있는 에디터)
      단점 : 사용하기 까다롭다
      f1.txt라는 파일을 만든다, 숫자 1을 입력한다 ==> vim f1.txt > i를 입력 > 입력모드로 바뀜 > 숫자1입력> Esc키 > :wq
      ls -al 파일 생성 확인
      f1.txt 내용을 보려면 > vim f1.txt해도 되지만 cat f1.txt해도 됨
      새로 생성된 파일을 git으로 관리해야 함. 그전에
      git status
      언트랙트 파일이라고나옴 (추적되고 있지 않다는 뜻)
      git add f1.txt < 이제부터 파일을 관리해 줘라
      왜 add를 사용하냐 하면, 임시로 저장되는 파일+추적해야 하는 파일이 디렉토리에 생성되기 때문에
      어느 파일을 추적해야 할지 알려줘야함

      버전 만들기 (commit)
      첫음 사용할 경우 버젼들이 자신이 만든 것이라는 등록을 해줘야 함
      git config --global user.name (자신의 닉네임)
      git config --global user.email (자신의 이메일 주소)
      이것은 맨처음 한번만 하면됨 > 앞으로 버젼은 위 닉넴임과 이메일을 포함하여 기록/추적함
      다른 사람이 봤을 경우 누가 작업했는지 알 수 있게 됨
      git commit
      빔이 실행됨
      현제 버젼에 대한 메시지를 적음 (#은 무시되는 내용임)
      어떠한 변화인지? 왜 변경되었는지에 대해 이유를 적는 것이 버젼 메시지임
      커밋메시지라고도 함
      입력하려면 > i
      숫자 1 입력
      esc
      :wq
      버젼이 잘 만들었는지 확인
      git log
      버젼메시지+누가+언제 만들어졌는지 등의 정보가 나옴

      실습차원에서
      몇번의 버젼을 만들어 보자
      ls -al
      vim f1.txt
      숫자 2로 변경하고
      esc > :wq
      git status
      git add f1.txt 커밋하기전에 꼭 해줘야 함
      (버젼을 생성할 때도 git add 하는 것임)
      git commit
      i
      2
      esc
      :wq
      git log

      Stage area
      cp f1.txt f2.txt 카피하기
      ls -al
      git status
      git add f2.txt
      git status
      git commit
      i
      2
      esc
      :wq
      git log
      나가고 싶은 경우 q누름?
      vim f1.txt
      source부분을 f1.txt라고 변경
      esc > :wq
      vim f2.txt
      source부분을 f2.txt라고 변경
      esc > :wq
      cat f1.txt
      cat f2.txt
      git status
      왜 깃이 add라는 과정을 포함하고 있는가?
      선택적으로 커밋할 것만 선택하고 커밋할 수있다.
      git add f1.txt
      git status
      git commit
      i > 4 > esc > :wq
      git log
      git add하면 커밋 대기상태로 감 > 이상태를 스테이지 에어리어라고 함
      git add 하면 스테이지 에어리어에 파일을 올리는 것임
      스테이지라는 개념과 레파지토리라는 개념을 가지고 있음
      커밋이 저장된 결과가 저장되는 곳이 레파지토리임

      변경사항 확인하기
      앞에서 버젼을 만드는 방법에 대해 살펴봤습니다.
      1. 차이점을 알 수 있음+과거 어느 시점의 내용을 알 수 있음
      2. 과거로 돌아갈 수가 있음

      그러면 차이점을 확인하는 것부터 살펴보자
      git log 지금까지의 역사가 보임
      git log -p 각각의 커밋과 커밋사이의 소스상의 차이점을 확인할 수 있음
      dev/null 버젼 3에서 파일이 생김 버젼2에서 는 없었다는 것을 나타냄

      버젼들은 고유한 ID값이 있음
      ID를 카피한 다음
      git log ID하면
      ID 이전의 메시지만 보임
      2번과 4번사이의 차이점
      git diff 4번ID..2번ID
      git log -p 와 git diff 명령을 통해 소스상의 차이점을 알아 볼 수 있다

      편리한 기능하나
      vim f1.txt
      i > 5 > esc > :wq
      git diff
      내가 지금 어떤 작업했는지를 확인할 수 있음
      커밋을 하기전에 자기가 작업한 내용이 문제가 있는지 없는지 마지막으로 리뷰할 수 있는 기회를 제공
      git add f1.txt
      git diff
      아무것도 안보임
      git diff는 add하기전에 이전 커밋과의 차이점을 점검하는 명령임
      조금 더 자세하게 들어가면 내용이 다름
      git commit
      i > 5 > esc > :wq
      git log
      과거의 버전으로 돌아가기
      또다른 효용 과거로 돌아갈 수 있다.
      커밋을 취소하는 명령 > 어려움+주의해서 해야 함
      5에서 3으로 돌아가고 싶은 경우 > 2가지 방법 있음
      reset Vs revert
      디렉토리의 전체 내용을 복사한 후 > 정 돌아가기 힘들다 할 경우 > 다시 복사 붙여넣기 해서 복원할 수도 있음
      사고를 방지해야 함 (신중히, 연습이 많이 필요)
      5와 4를 삭제후 3으로 돌아가고 싶은 경우
      git reset ID(돌아가고 싶은) 79621d01fdfcfd6ceb5d915a15567139711cc8b8 --hard
      git log
      4번과 5번이 사라짐
      vim f1.txt
      q
      vim f2.txt
      q
      git은 왠만하면 없애지 않음 없는 것 처럼 보이지만 남아 있다.
      나중에 복구할 수 있음 > 그렇게 하기위해서는 깃의 원리를 이해해야 한다.
      원격 저장소를 배우면 협업을 할 수 있게 됨
      공유한 이후에는 절대로 reset을 하면 안됨
      여러분의 컴퓨터에 있는 버젼에 대해서만 reset작업을 해야 함
      --hard는 위험 soft를 사용하길 권함

      또다른 방법
      git revert라는 방법이 있음
      커밋을 취소하면서 새로운 버젼을 생성하는 것
      어떤 방법으로 하든간에 커밋을 되돌릴 수 있다정도로만 아직 이해할 것

      명령의 빈도와 메뉴얼 보는 방법
      빈도수가 가장 높은 단어들 중국에서 6개단어가 10%차지
      어떤 분야건 비슷한 패턴
      중국어 단어가 영어로 무엇인지 물어보는 것을 배움
      영어단어 무엇이 중국어로 무엇입니까? 표현 익힘
      모르는 것을 알아낼 수 있는 방법만 알면 이론적으로 어떤 분야던 공부할 수 있다고 생각
      마찬가지로
      여러가지 분야에서 사용되는 부품 있다. 깃의 여러가지 명령가 그것
      그 부품도 빈도수가 다르다.
      commit 8% 1등
      push > put > clone > chekout
      add 7%육박
      branch
      log
      diff
      fetch > merge
      init
      status
      reset
      tag > rebase > rm > show > bisect > grep > mv
      지금까지 배운 것만해도 40%에 해당

      모르는 것이 있는 경우 어떻게 찾아 볼 수 있는가 배울 것임
      파일이 바뀌면
      vim f1.txt > i > 다음줄에 3 > esc > :wq > git add f1.txt > git commit > 7 > esc > :wq > git log
      이렇게 했는데 이것 귀찮다. 어떻게 하는지 알아내려면 메뉴얼을 찾아서 알아낼 수 있는 것임
      git commit --help
      커밋 메시지에 대한 도움말을 볼 수가 있음
      git menual이라는 페이지로 이동함
      options가 나옴 -a(길게 쓰면 --all) 수정하거나 삭제한 파일을 자동으로 스테이지에 올린다라는 뜻
      무슨 말이냐면
      vim f1.txt > i > 담줄에4 > esc > :wq > 그담 지금까지 git add f1.txt를 했지만
      그렇게 하지 않고 git commit -a라고 하면 우리가 수정하거나 삭제한 파일은 자동으로 add를 시켜준다는 뜻임
      add 생략 가능
      10이라고 입력하고 빠져나오면(esc > :wq)
      그런데 에디터를 켜는 것도 귀찮다 > 어떻게 해야 하는가?
      메뉴얼을 보면 압니다. git commit --help
      -m이라고 적혀있죠? 그리고 메시지
      커밋 메시지로 사용하겠다.
      또한번 파일을 수정해보자
      vim f1.txt > i > 담줄5 > esc > :wq >git commit -am "11"
      에디터를 켜지 않고 커밋을 할 수 있게 됨
      인라인에서 커밋할 수 있는 방법임
      메뉴얼을 보는 방법을 아려줬지만, 실제로는 많은 트레이닝이 필요함
      틈틈이 메뉴얼을 보는 것을 해서 익숙해질 필요는 있음
      모르는 것이 있을 경우 커뮤니티 같은데서 질문을 하는 것
      내가 어떤 명령이 필요한데 > 그 명령을 어떻게 해야 하나요?
      상세하게 친절하게 질문 > 답변을 받을 수 있을 것임
      그담에 검색을 통해서 알아내는 것
      이 세가지
      1. 메뉴얼을 보는 것
      2. 커뮤니티에 질문하는 것
      3. 검색
      이것이 문제를 해결하는 핵심적인 방법임

      이렇게 하면 시간이 알아서 실력을 향상시켜줌

      수련해봅시다.
      1. 버젼을 생성하는 방법
      2. 버젼을 이용해서 차이점을 보고, 과거로 돌아가는 방법
      여기까지가 모든 버젼관리 시스템이 가지고 있는 본질(공통점)적인 것 > 혁신적인 것은 덜 중요
      여기까지 하고 수업을 멈춰도 좋은 타이밍임

      중요한 것은 백업 > 아직 설명하지 못함
      버젼관리하고 있는 디렉토리 전체를 구글드라이브나 드롭박스 같은 서비스에 저장 ( .git디렉토리를 포함한 모든 것들을)
      혹시 문제가 생겨도 완벽하게 복구할 수가 있음
      혼자서 개발하는 상황이라면 이것으로 충분함
      협업이 필요한 상황이 올 경우 > 더 많은 것이 필요
      불편함이 원동력이 돼서 나머지 수업이 필요할 것임
      피아니스트가 엄청나게 많은 반복을 하는 것처럼 > 수련이 필요

      git의 혁신 - branch
      branch 나무에 가지를 (비유적)표현
      분리 > 중지/합침 > 계속 버젼관리
      나눠졌던 것을 합칠 경우 까다롭다(손으로 할 경우)
      버젼관리 시스템을 사용하면 쉽고 세련되게 가능해짐
      용어
      분기되는 것 : 브렌치를 만든다
      분기된 브렌치 + 원래 브랜치 > 2개의 브렌치를 갖게 되는 것
      다른 프로그램에서 > 위험+어렵고+용량 많이 차지 >> 있다는 것 알고 있어도 쓸만한 것이 아니라고 생각해 왔을 것
      GIT이 가지고 온 혁신중에 하나는 브랜치 기능을 쓸만한 수준까지 올렸다는 것임
      버젼관리 시스템을 꿰뚫고 있는 것이 아니기 때문에 > git이 혼자 만든 프로그램인지 아니면 다른 무언가의 영향을 받은 것인지는 모르겠음
      과거 suv라는 프로그램의 사용했던 문제들을 획기적으로 개선했기 때문에 git의 혁신
      브랜치에 대해 나쁜 인상 > 이제 바꿀 때
      과거에 어려웠던 여러가지 것들이 가능해짐
      git은 브랜치라는 개념으로 모든 것을 다루고 있음
      원격저장 이런 개념을 살펴볼 때도 브랜치라는 것을 꼭 알고 있어야 함
      선택이 아니라 필수

      branch 만들기
      git init > 현 디렉토리에 저장소가 만들어짐(.git디렉토리)
      f1.txt라는 파일을 또 만들어서 a라고 쓰고 나오겠음(vim f1.txt > i > a > esc > :wq)
      git add f1.txt (버젼관리 시작)
      git commit -m "1"
      한번더 수정하자 (담줄에 b)
      git add 사용 안하고 > git commit -am "2"
      -a를 쓸경우 조심할 것 : 한번도 에드를 하지 않은 파일은 이렇게 하면 안됨, add명령으로 한번 해줘야 > 자동으로 add할 수 있음

      이렇게 계속 버젼관리를 할 수 있는데 어떤 문제가 생길 수 있냐하면
      작업하고 있었던 소스는 그대로 두면서도 고객사에게 제공하는
      특별한 기능 커스텀된 기능이 추가되는 경우 > 원래 소스를 더럽히지 않으면서 (원래소스 변경없이)
      고객을 위한 커스마이징된 코드를 개발할 수 있음(이런 경우 브렌치가 딱 맞는 경우)
      또다른 경우 - 누군가 개발해 달라고 했는데 > 폼을 보니 > 필요 없는데 개발해 달라고 하는 느낌이 듬(쉽게 버릴 수 있는 방법-분기)
      또는 어떤 경우 - 서버에 반영하면서 > 문제점이 없는지 체크를 해야 하는 경우 > 메인을 위한 작업/테스트를 위한 작업 > 분기
      여러 경우가 있음

      브랜치를 만들어보자
      git branch
      master라 나옴 + 앞에 *이 나옴 (무슨 뜻?)
      현제 master라는 브렌치를 쓰고 있다라는 뜻
      git을 사용하는 순간부터 master를 기본 브랜치로 사용하게 되어 있음 > 약속 같은 특별한 이름의 브랜치임
      새로운 브랜치를 만들어보자 (git branch 하고 exp_실험한다는 의미에서 많이 사용함, 또는 feature(특정한 기능을 추가할 경우)
      아무튼 앞에 접두사를 사용 조직/개인이 결정할 문제 > 아무튼 exp라는 브렌치를 만들고 사용하는 것을 보일 것임
      git branch exp
      git branch
      브렌치들이 나옴 *가 현제의 브렌치임
      그러면 exp브렌치로 들어가려면?
      git checkout exp (숙박같은 것을 할 경우 checkout이라고 함)
      git branch를 해보면 *exp로 변경되어 있음
      ls -al > f1.txt가 보임
      git log > 1과 2가 나옴
      이것은 master브렌치와 exp브렌치는 같은 상태라는 것
      브렌치는 현상태의 브렌치를 그대로 복사한다라고 생각하면 됨
      그럼 여기서
      f1.txt(담c)변경 > 커밋 3으로 변경(git commit -am "3")
      아니 git add f1.txt > git commit -m "3"
      git log > 현제 1,2,3을 가지게 됨
      git checkout master
      git log > 1,2만 있고, 파일내용도 다름
      git checkout exp
      git log > 1,2,3 > cat f1.txt > abc
      f1.txt가 어느 브렌치냐에 따라 파일내용이 다름

      똑 같은 것인데 실습삼아 다시해보자
      ls -al
      왼쪽은 터미널 / 오른쪽은 현디렉토리의 파일을 보여주는 화면(8:40)
      vim f2.txt파일 추가 > a라고 하고 저장 > git add f2.txt
      git log > 4번할 차례임 > git comm -m "4"
      git checkout master > 여기 있는 2개의 파일은 어떻게 될까?
      보면 f2.txt가 감쪽같이 사라짐
      그리고 다시 git checkout exp로 하면 다시 나타남
      정말 좋은 기능임 + 아주 가볍고
      저장소를 추가적으로 거의 쓰지 않음
      그래서 브랜치는 훌륭한 기능 > 댓가는 공부를 해서 익혀야 하는 것
      진도 나가기 전에 혼자서 브랜치를 여러개 만들어 보자
      checkout도 하고 파일도 수정하고 브랜치를 손에 익게 하고 그다음 내용 보자

      branch 정보확인
      브렌치를 만들면 상당히 복잡해지고 > 믿어지지 않을 만큼 어렵다가 됨
      효용에 대한 댓가에서 오는 것 아닌가 하는 느낌임
      브렌치를 만들었을 때 현제 어떤 상황인지 판단할 수 있게 하기 위한 여러가지 확인 방법들을 살펴보자
      지금 어떤 상황이냐하면
      git branch
      브랜치들이 나오고 > 차이점을 확인할 때는...(0:50) >
      git log
      이것 만으로는 뭐가 master고 뭐가 baranch인지 확인이 안됨
      git log --branches하면 모든 저장소를 보여줌
      git log --branches --decorate
      뭐가 추가 되나요?
      (master)/(exp)라고 나옴 > 버젼뒤에 브렌치이름이 나옴 > Head:현제브렌치에 checkout되었다를 나타냄
      나중에 Head는 깃의 원리를 보시면 Head라는 파일이 있고 현제 브렌치가 exp라고 적혀 있음
      알어도 되고 몰라도 되지만 나중에 원리 수업에서 알게 됨
      q를 하고 나가 겠습니다.(윈도우에서는 그렇게 하지 않음-그냥 그자리에서 다음 명령 대기 상태임)
      조금더 고도화를 시켜서 조금 더 편하게 하려면
      git log --branches --decorate graph
      빨간색으로 줄이 생김
      이 상태에서는 잘 들어나지 않음 (각자의 길을 걷고 있을 때 드러남. 지금은 master가 변하지 않은 상태임)
      그러면 master도 새로운 커밋을 만들어보자(3:25)
      git checkout master
      vim f3.txt라고 해서 파일을 만들자 > a라고 적고 > 서밋을 만자(git add f3.txt > git commit -m "5")
      git log > 1,2,5만 나옴
      기본적으로 현 브렌치에 대한 커밋만 보여줌
      git log --branches (모든 브렌치를 보여주고 뭐가 뭔지 구분이 안됨)
      git log --branches --decorate --graph
      이제야 효용이 드러남
      2라는 곳에서 exp가 분기 되었다는 것이 보여짐
      그런 형태를 graph라는 것을 볼 수 있음
      그리고 q로 나가보자(윈도우와 다름)
      그리고 화살표기 위로 가는 것 누르면 이전 명령이 나옴
      git log --branches --decorate --graph --oneline까지 해주면 > 한줄로 요약해서 현 상태를 보여줌(6:12)
      전체적인 상황을 조망해 볼 수 있게 됨
      다시 q해서 나감(윈도우<>)
      그리고 git에서 컴멘드라인을 쓰는 이유는 가치가 있기 때문
      모든 면에서 좋은 것은 아님
      무엇을 하고 싶냐에 따라 적절한 것을 선택할 필요가 있음
      소스트리라고 하는 gui형태의 프로그램이 깔려 있음
      그 프로그램을 실행할 때는 stree(7:10) > 현제 디렉토리 저장소가 소스트리라고 하는 git의 gui로 나타남
      그렇게 나타난 결과가 이것임(7:26)
      (8:4) 버젼과 버젼의 차임점을 비교할 때는...
      git log master..exp사이에 차이점이 무엇이냐
      master에 없고 exp에 있는 것들을 표시해줌
      반대로 git log exp..master라고 하면 > exp에 없는 master에만 있는 것을 보여줌
      만약 소스코드까지 필요한 경우(8:50)
      git log -p master..exp
      (9:30) git diff master..exp
      앞에 있는 것이 master고 뒤에 있는 것(아래) exp임
      이렇게 브렌치를 나누는 방법
      브렌치의 차이점을 비교하는 방법
      살펴봤음

      branch 병합
      영어로 merge(병합)라고 함
      git log --branches --decorate --graph --oneline
      exp를 master로 병합하는 방법을 살펴보자
      마스터로 체크아웃을 한다
      마스터에서 머지를 하는 것
      git merge exp
      머지했다는 메시지가 나옴
      :wq(2:50)
      git log --branches --decorate --graph --oneline

      Auto-merging f1.txt
      CONFLICT (content): Merge conflict in f1.txt
      Automatic merge failed; fix conflicts and then commit the result.
      2개의 부모를 갖음
      ls -al > 파일 목록을 보니 master가 드디어 f3.txt를 가지게 됨
      그러면 exp도 완전히 master와 같게 만들어 보자
      git checkout exp
      (5:30) CONFLICT 나는 경우가 있음
      똑같이 하지 않았기 때문임 > 충돌을 해결하는 방법에서 알려줄 것임
      master를 exp로 가져오고 싶다
      git merge master
      git log --branches --decorate --graph --oneline
      이렇게 하면 exp와 master는 완전히 똑 같은 상태가 되는 것임
      q해서 나옴
      이제 더이상 exp는 필요 없음
      지워도 됨
      git checkout master
      git branch -d exp(7:10)
      브렌치 삭제됨
      git log --branches --decorate --graph --oneline
      exp는 사람짐
      이렇게 해서 병합이 무엇인가에 대해 살펴 봤음

      branch 수련
      https://git-scm.com < git의 공식홈페이지
      공식메뉴얼이 있음 > Documentation > Book > 각각의 언어별로 있음
      브랜치와 Merge 의 기초 > 패스포워드라는 방식과 아닌 방식으로 머지하는 방법이 나옴
      그 것을 비교하는 내용임. 이 문서를 보고 수련을 했으면 좋겠음.
      설명이 이해하기 어려운 것이 있음. 그래서 말로 설명해 드리겠음. 각자 수련해 보시기 바람.

      기능의 추가/버그의 수정(<---어떤 일들이 생김)
      깃에서는 바로 브랜치를 만듬(이슈 하나를 해결하기 위해서)
      어떤 명령을 사용할까?
      git checkout -b iss53
      이것은 git branch "iss53" + git checkout iss53을 의미함(한줄로 적은 것임) (3:10)
      내용을 수정하고 커밋을 하게되면 그림이 어떻게 바뀔까?
      $ vim index.html
      $ git commit -a -m 'added a new footer [issue 53]'
      이렇게 바뀌겠죠? 분기
      그런데 급하게 처리해야 할 일이 생긴 것임. 그 일을 해결하기 위해 master브렌치에서 브랜치를 새로 생성할 것임.
      $ git checkout master
      $ git checkout -b hotfix <--hotfix 라는 브렌치를 새로 만듬
      그리고 파일을 처리하고 커밋을 하면
      $ vim index.html
      $ git commit -a -m 'fixed the broken email address'
      그림의 모양이 바뀔 것임
      hotfix의 일을 끝내고 master브렌치로 병합을
      $ git checkout master
      $ git merge hotfix
      그 때 어떤 메시지가 뜨냐하면 Fast-forward
      이것이 여러분이 머지를 했을 때 경험하는 첫번째 상황임
      영어로 빨리 감기라는 뜻임
      빨리 감기라는 것이 무엇일까?
      hotfix브렌치 변경후 병합까지 master브렌치는 어떤 변화도 없었음
      이상태에서 master브렌치로 hotfix브렌치를 병합한다는 것은
      master브렌치를 hotfix브렌치로 빨리 감기를 하면 병합작업이 끝난다 > 이런 형식의 브렌치를 Fast-forward라고 부름
      그리고 그 결과의 그림은 이렇게 됨(위에 올라탄 그림-master브렌치는 hotfix브렌치를 가리키게 됨)
      그렇기 때문에 별도의 commit을 생성하지 않음.(별도의 커밋을 생성하는 것이 기본이지만)
      마스터가 가리키는 커밋이 누구인지를 바꾸기만 함 > 그래서 이것을 Fast-forward라고 부름
      그리고 hotfix가 끝났고 브렌치가 많으면 지저분 하므로 지움($ git branch -d hotfix)
      그리고 다시 이슈를 처리함
      $ git checkout iss53
      Switched to branch "iss53"
      $ vim index.html
      $ git commit -a -m 'finished the new footer [issue 53]'
      [iss53 ad82d7a] finished the new footer [issue 53]
      1 file changed, 1 insertion(+)
      커밋까지 함
      그러면 그림이 이렇게 됨
      일이 끝났으므로 > 마스터로 머지함.
      이때 메시지가
      $ git checkout master
      Switched to branch 'master'
      $ git merge iss53
      Merge made by the 'recursive' strategy.
      README | 1 +
      1 file changed, 1 insertion(+)

      제귀적인 전략 > 이슈53이 변하고 + 마스터도 변했음
      이런 경우 패스트 포워드를 할 수 없음
      그러면 깃은 내부적으로 어떻게 동작하냐 하면
      1. 마스터와 이슈53의 공통의 조상을 찾음.
      2. 3way merge라고 하는 내부적 방법을 이용하여 머지를 함.
      3. 두개를 합쳤다라고 알려주고 두개를 합쳤다라고 하는 별도의 커밋을 만듬(자동으로)
      그래서 차이점은? > 커밋을 생성(Fast-forward)하지 않고 생성하고 임('recursive' strategy)
      이 아티클은 그런 이야기를 담고 있음.

      branch 병합 시 충돌해결
      깃이 얼마나 많은 부분을 자동화해주는가? 기특하다
      git branch exp
      git branch -d exp
      다시 만들어야 겠음
      합치지 않았는데 정말 지울 거냐?
      그러면 강제로 지워야 함
      git branch -D exp(55)
      git branch exp
      vim master.txt라는 파일을 만듬
      내용을 a라고 할 것임
      git add master.txt
      git commit -m "6"
      git checkout exp
      vim exp.txt > 내용은 a
      git add exp.txt
      git commit -m "7"
      git checkout exp
      vim common.txt
      파일안의 내용 변경 (exp)
      같은 곳을 변경... 뭔가 문제가 심각해짐
      같은 부분을 수정하고 병합하면 에러남
      그리고 커밋 12
      git checkout master
      git merge exp
      컨프릭트 에러남
      git status
      언 머지드 패스라도 나옴
      커먼.txt가 양쪽에서 바뀜 나옴
      vim common.txt
      그러면 새로운 내용이 나옴
      기호를 해석할 수 있는 능력이 있어야 함
      ============
      여러분에게 충돌해결을 위임한 것임
      동시에 가지고 있는 것으로 하고
      다른 것은 삭제함
      git add common.txt
      git status
      git commit
      :wq
      git log
      vim common.txt
      컨플릭트가 나면 이런식으로 처리하면 됨

      stash
      감추다 숨겨두다라는 뜻
      브랜치를 활발하게 사용할 경우 사용
      브랜치에서 작업하던 내용이 다 끝나지 않았는데
      다른 브렌치로 checkout해서 다른 일을 해야 하는 경우
      작업이 끝나지 않은 작업을 커밋할 수는 없고 커밋을 안하면 체크아웃할 수가 없고
      이런 경우 stash라는 것을 이용 > 작업했던 내용을 어딘가 숨겨 놓을 수 있음
      브랜치의 가장 최신 커밋(해드의 버젼)으로 이동해서 현제 브랜치의 상태를 깔끔하게 만들고
      다른 브랜치로 체크아웃할 수 있다.

      브랜치를 활발하게 사용하지 않는 경우 필요 없음 (그냥 그런게 있다 정도로 남겨 뒀다 필요시 사용할 것)
      git init
      vim f1.txt > a > git add f1.txt > git commit -m "1"(큰따음표 안해도 됨)
      이 상태에서 새로운 브랜치를 만들겠습니다.
      git checkout -b exp
      vim f1.txt > 담줄b > 아직 작업이 끝나지 않았는데...
      어떤 경우 master브랜치로 체크아웃해야 하는 경우에
      이상태에서 체크아웃하게 되면 어떤 문제가 생길까요?
      git checkout master
      git status했을 때 f1.txt가 add하지 않았다고 나옴
      exp에서 수정한 내용이 master에 까지 영향을 줌
      그러면 다시 git checkout exp
      git status > 여전히 add안했다고 나옴
      아직 수정했지만 커밋하기에는 부족한 소스를 어떻게 해야 할까?
      git stash --help
      git stash라고 하거나 save를 붙여준다 > git stash [save]
      Saved working directory and index state WIP on exp: d82c224 1 <--메시지가 조금 다름
      WIP : 워킹 인 프로세스 <-- 라는 이야기 (작업중이라는 뜻)
      워킹디렉토리와 인덱스에 있는 변경사항들이 save되었다
      git status > 커밋할 것이 아무것도 없는 것으로 나옴
      즉 vim f1.txt는 수정했던 내용이 사라짐
      이상태에서 git checkout master를 하게 되면 작업/내용확인 맘 편하게 할 수 있음
      그 작업이 끝나면 git checkout exp로 해서 작업을 계속 진행하면 됨
      감추어 놓았던 내용을 복원(5:30) --> git stash --help
      git stash apply
      f1.txt가 살아나 모디파이 되었다고 나옴 > 스태쉬한 것이 살아난 것을 볼 수가 있음
      git stash list
      git reset --hard HEAD <--- 수정했던 내용을 날림 < 가장 최신의 커밋 상태로 돌아감
      git status > 아무것도 커밋할 것이 없다고 나옴
      스태쉬한 내용을 잃어 버린 것일까? > 아닙니다. stash list > 여전히 남아 있음
      이상태에서 git stash apply > 다시 살아 남 > 무슨 이야기냐 하면 스태쉬의 내용은 명시적으로 삭제하지 않으면 살아 있다는 것
      vim f2.txt > a > git add f2.txt > f2.txt를 git stash하면 git status > 수정된 사항이 나오지 않음
      git stash list라고 하면 2개가 나옴
      방금 처리한 스태쉬는 위에것 [0]이 방금 처리한 내용임
      git stash apply > 제일 위에 있는 스태쉬를 적용함
      그러면 스테쉬 내용을 순차적으로 적용하려면 어떻게 해야 하는가?
      git stash drop > 가장 최신의 스테쉬를 삭제
      에러 같은 경우는 컴퓨터 상황 때문에 생기는 것 > 무시 > git stash list > 하나만 남아 있음
      git stash apply; git stash drop; <-- 적용/삭제를 한번에
      이것이 커멘드라인의 편리함임
      git status해보면 > 모두 살아 난 상태이고
      git stash list > 아무것도 나오지 않음
      불편함 > 한번에 하는 명령은? git status > git reset --hard
      git status > 다 지워서 아무것도 안나옴
      vim f1.txt > 담b > git add f1.txt > git stash > git status > 변경사항이 없어짐
      git stash pop <-- 스태쉬가 어플라이+드랍 모두 됨
      git stash --help
      git reset --hard
      vim f1.txt > 담b > vim f2.txt > a > git status > f1.txt(수정 -- 추적되고 있는 파일) , f2.txt(언트렉드 파일)
      이상태에서 git stash하게 되면 > git status > f2.txt는 언트렉이기 때문에 스태쉬가 되지 않음.
      git stash <-- 버젼관리가 되는 파일에 대해서만 스태쉬를 함

      끝이 열려 있는 수업과 학습
      요즘 사회는 변화 > 끝없이 배워야 > 무한 > 조금 안 것과 = 책을 다 본 것 > 차이가 없다.
      배우는 것을 그만두고 써먹어야 한다.

      원격저장소
      [ 수업소개 ]
      영어로 remoute repository
      local repository와 대비되는 개념임
      원격저장소 2가지의 중요한 의미
      1) 백업
      2) 협업
      프로젝트가 커지는 과정에서 굉장히 중요한 의미가 있음
      혼자 개발한다면 > 드롭박스 , 구글드라이 클라우드 스토리지 서비스를 이용
      버젼관리하고 있는 디렉토리 통체로를 백업을 하면 > 원격저장소의 효용을 이미 가지고 있는 것
      혼자서 개발시 이것으로도 충분
      다른 사람과 협업을 한다고 한다면
      그것으로는 어림없기 때문에 꼭 해야 함

      [ 원격저장소의 기초 ]
      혼자 프로젝트하는 것을 시뮬레이션 해보겠다.
      git init local
      ls -al
      cd local
      vim f1.txt > a > git add f1.txt > git commit -m 1
      이렇게 버젼을 만들다가
      백업/협업을 하고 싶은 경우 > 원격은 상대적인 개녕임 > 커밋하고 있는 저장소를 지역저장소라고 하고
      그 지역저장소와 연결되어서 동기화 되는 저장소를 원격저장소라고 하고 > 일반적으로 원격저장소는 같은 컴퓨터 안에 있지 않고
      인터넷을 통해서 서로 다른 컴퓨터에 연결이 되어 있음. 그렇지 않으면 백업으로써 의미가 없고 협업도 같은 컴퓨터로 안함
      하지만 인터넷으로 연결하는 것은 다소 복잡 + 복잡성 때문에 응용력이 떨어질 수 있음.
      한대의 컴퓨터안에서 다른 디렉토리에다가 원격저장소를 만들고 그 원격저장소에 커밋하는 모습을
      여러분들에게 보여드리겠습니다. 그런데 이작업은 제가 해본 결과 현시점에서 맥에서는 잘 안됨
      안되는 경우도 있고 > 이와 같은 방법으로 운영되는 경우가 거의 없기 때문에 혹시 안되더라도 하고있다라고 생각하고 들어주면 됨
      실습이 중요한 수업이 아님

      local 디렉토리에서 원격디렉토리에 동기화하는 모습을 보여주겠음(3:5)
      부모 디렉토리로 가서 git init --bare(벌거벗은, 맨살, 작업은 할 수 없고 저장소로서의 기능만 수행 가능 저장소를 만드는 옵션임)
      git init --bare remote(이름)
      현제 디렉토리에 remote라는 디렉토리가 생겼고 > cd remote > ls -al
      여러파일들이 생겨 있음 > .git디렉토리에 들어가는 목록들임
      .git의 내용만 존재(워킹디렉토리는 없음)
      원격저장소는 순수하게 유지하기 위해서 어떠한 작업도 않게 하기위해서 bare라고 하는 옵션을 주어서 수정/작업이 불가능하게 하는 것이 일반적 + 다르게 하면...힘듬
      원격저장소를 만들경우 bare를 사용한다로 알아둘 것

      cd .. > cd local > 원격저장소에 연결시키고 push를 해보겠음
      git remote add (저장소의 주소)
      현제디렉토리의 주소는 pwd
      (/c/Users/user/documents/remote)
      경로를 복사하고 로컬만 리모트로 바꾸면 될 것임
      git remote add /home/git/git/remote
      git remote add origin /home/git/git/remote <-- 경로를 항상 이렇게 쓰는 것은 귀찮은 일(origin > 별명같은 것임)
      아무 것도 안나오면 잘된 것임
      잘 됐는지 확인 > git remte -v
      푸쉬/패취 이것은 몰라도 됨
      저장소를 지우고 싶다 > git remote remove origin(이렇게 하면 지워지는 것임, 사용설명서를 보면됨)
      git push (현제 브랜치는 마스터임, 원격저장소에 똑같은 이름의 브랜치를 푸쉬하고 싶은 경우임)

      메시지가 나옴 > matching(깃이 알아서 처리) + simple(명시적으로 어디에서 어디로 푸쉬를 하겠다고 지정한 것에 대해서만 푸쉬를 하겠다고 하는 보수적인 옵션임)
      기존의 매칭방법에서 심플방식으로 바꿨다라고 되어 있음. 여러분은 심플방식을 사용하는 것이 좋음. 좀더 엄격한 모델이다. 이렇게 생각하면 될 것 같음.

      여기에 있는 것을 카피엔페이스트하면 깃의 설정을 시스템에 전역적으로(global) 푸쉬의 형식을 심플로 바꾼다는 뜻임
      git config --global push.default simple
      그리고 다시 푸쉬를 하면 (git push)
      위 박스안의 부분은 윈도우에서는 나오지 않음

      아까 메시지는 없어졌고 git push --set-upstream origin master <-- 이 메시지는 현브렌치(git branch)를 오리진의 마스터브렌치로 푸쉬한다라는 뜻임
      마스터에서 깃푸쉬하면 자동으로 오리진의 마스터로 푸쉬하겠다(--set-upstream)의미
      원격저장소로 가서 git log를 해보면 > cd .. cd remote > git log
      이렇게 해서 지역저장소의 것을 원격저장소에 푸쉬해서 동기화 시키는 방법에 대해 살펴봤음.

      이번 시간에 가장 중요한 것(11:20)
      1) git init --bare 원격저장소
      2) 업로드(푸쉬) 푸쉬명령어를 사용하면 된다.

      선택해서 수업을 듣는 방법에 대해서 설명(12:3) <-- 모든 수업을 다 들을 필요가 없기 때문
      MyServer라는 수업 <-- 자신의 서버가 있어서 운영하는 방법 <-- 더 어려움 + 깃허브 수업은 꼭 들을 필요가 있음
      Github라는 수업이 있음 <-- 블라인 서비스를 제공하는 서버를 이용하여 운영하는 방법

      원격 저장소를 지역 저장소로 복제(Github)
      git 소스코드를 지역저장소로 가져오기
      https://github.com/ 에 가서 git이라고 검색해 보자
      git/git이라고 나오는 부분이 있음
      https://github.com/git/git <-- 주소를 직접 입력해도 됨
      배우고 있는 git이라고 하는 오픈소스프로젝트의 저장소를 보고 있는 것임
      다운로드하지 않고도 다른 사람에게 공유할 수 있음
      커미츠라고 되어 있는 부분(왼쪽위 타이틀 부분)이 프로젝트의 커밋수를 나타냄
      이브랜치가 5개의 브랜치로 구분되어 있다
      마스터가 매인일 것이고,
      todo 해야될 일을 모아 놓았을 것이고
      깃이라고 하는 것은 이런 식으로 브렌치를 나누어서 하고 있다
      다시 백하겠습니다. 이소스에 접근할 수 있는 사람이 (컨트리뷰터스)
      아래로 쪽 내려가면 프로젝트의 소개가 나옴
      위에 보면 와치(몇명이 지켜보고 있는지), 스타(몇명이 좋아요를 했는지), 포크(아주 중요한 부분임, 포크를 누르면 프로젝트가 여러분의 것이 됨)
      아래 제목줄의 컨트리뷰터가 되지 않아도 여러분 맘대로 수정할 수 있게 됨 - 포크하면
      하지만 git/git개정의 소스코드를 바꾸는 것이 아니라 복재된 소스코드를 맘대로 수정할 수 있는 것 <-- 개발자 문화의 굉장히 중요한 측면
      포크를 한번 해보겠습니다.
      로그인을 해야 함
      포크를 하면 git/git의 주소가 바뀜 > 포크하는데 시간이 걸림
      회원가입하지 않아도 됨 > 포크는 어떻게 하는지 보여주는 것임
      egoing/git으로 바뀜 (이고잉이라는 사용자의 git으로 바뀜, 이 프로젝트는 git/git에서 왔다고 되어 있음)
      프로그래머의 세계에서는 독특한 미래지향적인 면이 있어서
      포크는 자신에 대한 평판을 의미함 > 다른 사람이 포크해 가기를 기대함/그리고 노력함
      개발자들의 문화 /오픈소스/ 생산수단이 개방적이고 열려있는 문화를 가지고 있는 것

      타이틀 오른쪽 아래의 클론 오어 다운로드에서 클론 위드 http확인하시고
      주소를 카피합니다.
      여러분의 적당한 디렉토리로 이동하겠음
      gitsrc라는 디렉토리를 만들고
      그곳에 코드를 넣을 것임
      git init을 사용했는데...이번에는
      git clone 을 사용할 것임
      git clone 원격저장소의 주소 gitsrc (9:00)
      gitsrc디렉토리에 클로닝을 하게 됨
      이것을 하는 것은 로그인이 필요하지 않음
      ls -al
      gitsrc라는 디렉토리가 있음
      들어가 보면 이렇게 많은 파일들이 있음
      여러분이 이것을 직접 분석하는 일은 굉장히 어려운 일임
      git log
      깃의 첫번째 커밋이 무엇인지 한번 가보자
      git log --reverse (꺼꾸로 로그를 볼 수 있음)(10:5)
      첫번째 ID를 복사해서 q해서 나간후
      git checkout ID (과거로 돌아가는 방법)
      복잡한 메시지중 ID의 이름이 바뀜
      지금은 브렌치가 커밋이 된 것임
      그리고 git log를 해보면...하나만 나옴
      그 이후에 있는 것은 삭제된 것이 아니라 안보이게 된 것
      그리고 소스코드를 보면 이렇게 몇개되지 않음
      분석할 만한 규모임
      깃의 첫번째 모습은 이정도의 모습으로 되어 있다.
      원격저장소를 사용하는 기본적인 방법중에서 오픈소스 자신의 컴퓨터로 끌고 오는 방법에 대한 수업이었기 때문에 여기서 깁게 나가지는 않지만
      원리수업 어딘가에서는 깃의 첫번째 커밋에 해당되는 깃의 원형 어떻게 동작했고 어떠한 코드로 이루어 졌는지에 대해서 나름대로 분석해볼생각임
      초창기 + 복잡한 것이 제거된 + 본질을 다 가지고 있는 빠르고 덜 고통스럽게 볼 수 있을 것이다.라고 생각함
      관심있는 사람의 깃의 원리 수업도 관심을 가져주시길 바람

      정리해 보겠습니다.
      원격저장소의 내용을 로컬저장소로가지고 오고 싶은 경우
      git
      init과 clone이 있는데 그중에서 클론을 사용하면 됨
      git clone 원격저장소의 주소 gitsrc (저장하고 싶은 디렉토리를 지정)

      원격 저장소 만들기(Github)
      이것을 하려면 github에 회원가입해야 함
      New Repository
      gitfth(저장소 이름을 적음)
      퍼블릭체크
      리드미부분은 프로젝트에 대한 설명을 만드는 부분임
      크리에이티브 리파지토리
      그러면 화면이 나오고 > 화면의 구성을 보자
      https를 선택 > 주소가 리모트리타지토리의 고유 주소임
      저 주소를 이용하여 클론할 수가 있는 것임
      1. 원격저장소를 만들고 > 복제하여 로컬저장소를 만든 다음에 > 로컬저장소에서 작업을 하는 것
      2. 로컬저장소에서 이미 작업을 해왔음 > 원격저장소로 올리는 것
      여기서는 2번째 것을 해보자

      mkdir gitfth
      cd gitfth
      clear
      git init . <--- 프로젝트를 생성하고
      vim f1.txt <-- 새로운 파일을 만들고
      a 내용
      저장한 후
      git add f1.txt > git commit -m '1'
      첫번째 커밋을 만든 상태
      이상태에서 github로 돌아가 보자
      첫번째 줄을 복사해 보자
      git remote add origin https://github.com......git <--원격저장소 지정
      아무말도 없으면 잘 된 것임
      확인 > git remote
      origin이라는 원격 저장소가만들어진 것을 확인할 수 있음
      git remote -v <-- 상세보기가 됨
      여러개의 원격저장소를 로컬저장소에 지정 할 수 있음
      똑같은 주소를 별명만 다르게해도 됨
      git remote add friend https://github.com......git
      git remote -v <-- 상세보기가 됨
      작업한 내용을 a,b,c라는 저장소에 저장할 수 있는 것
      관습적으로 origin이라는 원격저장소는 로컬저장소와 연결되어 있는 기본적인 원격저장소(메인, 주로 동기화 저장소)
      필요없는 friend를 지웁시다.
      git remote --help
      git remote remove friend(name)
      git remote -v

      그다음 git push
      깃에서는 로컬저장소를 기준으로 말함
      git push -u origin master (업로드) 마스터브랜치를 푸쉬하다 -u는 한번만 쓰면됨 로컬브랜치와 원격브랜치를 동기화 > 담부터는 > git push만 하면 자동으로 푸쉬시켜줌
      그렇게 하기위해 -u옵션을 사용한 것임
      유저네임을 물어봄 > 유저네임을 입력
      비밀번호 물어봄 > 입력
      푸시가 됨
      깃허브 화면에서 리로드 > 작업내용이 원격저장소로 업로드 된 것을 볼 수 있음
      이번에는 로컬에서 커밋을 해보자
      vim f1.txt > 담b >git commit -am 2
      git push -u origin master 이렇게 하지 않고 (-u로 이미 동기화 하기로 약속됨 > 그 담부터는 그냥 git push > ID > 비번)

      (10:10) 다른 컴퓨터에서 일해야 하는 경우
      원격 저장소를 컴퓨터에 복제하면 됨
      이미 배운 거나 다름 없음
      클론 오어 다운로드 클릭 > https:주소 카피> 로컬컴퓨터에서
      새로운 컴퓨터라고 생각하고
      cd .. > mkdir gitfth2 > cd gitfth2 > ls -al > clear > git clone 카피주소 .(현제디렉토리)
      클론됨 > ls -al > 원격저장소가 지역저장소로 옮겨진 것을 확인할 수 있음
      이상태에서 git remote -v
      원격 지역 연결됨 확인
      원격 저장소와 지역 저장소의 동기화 방법 (Github)
      하나의 원격저장소를 2개의 지역저장소가 사용하는 방법
      집에서 작업 + 회사에서 작업 > 복습의 성격
      ls -al
      git clone 원격저장소의 주소 git_home (저장하고 싶은 디렉토리를 지정) <-- 집에 있는 컴
      git clone 원격저장소의 주소 git_office (저장하고 싶은 디렉토리를 지정) <-- 회사에 있는 컴
      집에서 프로젝트를 할 경우
      vim f1.txt파일의 내용 변경 > 담c > git commit -am 2
      git log
      3으로 했어야 하는데 > 바꾸면 됨 > git commit --amend (--amend개정하다라는 뜻,
      커밋 메시지를 변경가능/커밋할 내용을 누락시켰을 경우에는 add를 한 후 다시 이것을 하면 마지막 메시지를 바꿀 수 있는데
      그것은 원격저장소로 올리전에 해야 함(지역저장소에 있는 경우 > 자신의 컴퓨터에 있는 경우에만 해야 되고 그 이후에는 여러분은 하면 안된다고 생각하면 좋음
      이유: push이후 내용은 수정하지 마라)
      3이라고 내용을 변경하고 :wq
      git log > 2가 3으로 변경된 것을 확인할 수 있음
      git push > ID + 비번 > 요런식으로 푸쉬가 되고
      깃허브에 보니 커밋이 추가되었고 방금 커밋한 것이 올라와 있음(3:55)

      작업을 끝내고 회사로 갈 것임
      회사에서 작업하기 전에 항상
      git pull(당겨온다 )master에 있고 마스터는 오리진에 연결되어 있을 것임
      여러분들이 클로닝을 했기 때문에 그런경우 그냥 git pull만 하면 됨
      원격저장소의 내용을 로컬저장소로 가져오게 됨
      그때 ID와 패스워드를 묻지 않는 것은 여러분이 공개 저장소를 쓰기 때문임
      그럼 여기서 작업을 할 것임
      ls -al > git log > vim f1.txt > d > git commit -am '4' > git push > ID 패스워드 입력

      다시 집으로 와서 (5:17)
      git pull > 또 수정하고 푸시하고 > 회사로 가고 반복하면서
      여러분들이 일을 해나가는 것
      가장 중심적인 것은 백업이 된다는 것
      버젼과 소스코드 모두를 다 올리기 때문에 > 모든 저장소들은 모든 것을 각자 다 가지고 있기 때문에
      요정도 수준의 백업만 되어 있어도 3개가 동시에 파괴될 소지는 현저히 떨어지기 때문에 > 소스코드를 잃어 버린다는 것은 거의 지구수준의 재앙이 아니면 불가능
      이것이 원격저장소의 효용이고 > 여러분이 수련해야 할 시점임 > git pull > git push
      어떤 작업을 할 경우 > 반드시 >(git pull로 당기는 것을 먼저하고 작업이 끝나면 꼭 git push를 하는 것을 여러분이 습관화 시키셔야 함)

      로그인 없이 원격 저장소 이용하기 (Github)
      Secure Shell(ssh)라는 것을 통해서 원격저장소에 접근하는 방법을 살펴보겠습니다.
      여러분이 직접 원격저장소 서비스를 운용할 수도 있다는 것 알아두시길
      깃허브의 클론 오어 다운로드에서 주소를 제공할 때 https와 SSH 2가지를 제공하고 있음.
      지금까지 https를 사용했음 > 단점은 업로드/접속시마다 아이디와 패스워드를 사용해야 한다는 것임.
      이번에 ssh라고 하는 다른 방식을 이용할 것임 > 할 때마다 로그인을 하지 않아도 된다는 장점을 가지고 있음(1:51)
      물론 ssh는 자동로그인을 위한 수단이 아님
      위 2가지 각각의 통신방식이 있는데 ssh통신 방식은 자동으로 로그인 해주는 편익을 제공하는 것일 뿐임
      이것을 하기위해서 알고 있어야 할 것들 해야될 일들을 지금부터 살펴보자
      운영체제와 상관없이
      ssh-keygen
      화면에 자료가 나옴
      경로를 잘 보시고요
      그담 엔터 그리고
      엔터
      엔터
      뭐가 생성이 되냐하면 ssh를 통해서 다른 컴퓨터로 접속할 수 잇는 비밀번호가 생김
      일반적으로 사용하는 것은 아이디와 비밀번호를 기억한 후 이용 그러나 지금 생성한 비밀번호는 기계적으로 굉장히 복잡한 과정으로 비밀번호를 만든 것이기 때문에
      여러분이 1234라고 비밀번호를 생성하면 정말 쉽게 뚫을 수 있음 방금 생성한 비밀번호는 절대 뚫을 수가 없음(현제기술로 왜냐하면 굉장히 복잡하기 때문)
      그 비밀번호가 어디에 저장되었는지는 바로 여기 위에서 괄호안의 경로 있지요? 그곳임 .ssh/id_rsa > .ssh/id_rsa.pub
      여러분이 이름이 다르다면 그 이름에 해당하는 것이 생겼을 것임
      cd ~(홈 디렉토리를 의미) 위디렉토리로 이동하면 되는데 귀찮아서 이렇게 적음
      cd ~/.ssh
      ls -al
      2개의 파일이 생겼음( id_rsa / id_rsa.pub)
      id_rsa <--- 프라이빗 키
      id_rsa.pub <--- 퍼블릭 키

      id_rsa.pub <--- 퍼블릭 키를 여러분이 접속하고자하는 리모트 컴퓨터의 일정한 장소에 넣어주면됨
      그러면 로컬컴퓨터가 (퍼블릭키를 가지고 있는 컴퓨터에)자동로그인 함
      로컬컴퓨터의 프라이빗 키는 절대로 외부에 로출되면 안됨(8:6)

      그러면 어떻게 퍼블릭키를 리모트컴퓨터에 저장할 것인가?
      규칙에 따라 저장을 하면됨 > 깃허브는 쉬움
      cat id_rsa.pub
      나오는 내용 정교(정확)하게 카피
      깃허브사이트에 감 > 오른쪽 위 원안에 녹색 Y자모양 아이콘을 클릭하면 > settings 메뉴 > 여러 가지 나옴
      왼쪽 메뉴에서 > SSH and GPG keys > 이곳을 통해서 공개키를 저장할 수 있음
      New SSH key 클릭 > 타이틀:지역저장소의 이름 입력 > 예:home dev mac > key : 카피한 내용을 붙여넣기함(10:30)
      그리고 아래에 있는 Add SSH key 버튼을 누름
      그러면 아래에 새롭게 하나가 추가등록됨
      이러면 원격저장소인 깃허브에 퍼블릭키를 저장한 것임(10:49)

      그러면 깃허브에 새로운 저장소를 만들어보자
      Create a new repository > repository name: gitfth_ssh > creating repository 버튼 클릭
      그러면 윗부분에 주소가 나오는데 ssh부분을 클릭 > 주소를 복사 (오른쪽 아이콘 클릭)
      그리고..
      아래에 or create a new repository on the command line
      지역 저장소가 없는 상태에서 원격저장소를 기반으로 하고 싶을 때 하라고 되어있는 내용임

      그런데 다르게 합시다.
      카피후에... 로컬컴에서
      git clone 방금카피주소 붙여넣기 gitfth_ssh
      메시지 나오면? yes입력 <-- 한번도 접속하지 않은 곳에 접속하려고 하는데 정말 접속할 것인지 묻는 것임
      그리고 방금 생성한 gitfth_ssh로 이동
      cd gitfth_ssh
      그리고 파일 수정
      vim f1.txt > a > git add f1.txt > git commit -m 1
      git push
      푸시가 잘 되면 > 아이디 비밀번호입력 묻지 않고 수행함
      성공한 것임
      안에서 컴퓨터들 끼리는 복잡한 과정을 거쳐서 자동으로 해결한 것임 > 우리에게 이 과정은 감추어진 것임
      비밀번호를 입력하지 않고 통신하는 방법을 살펴봤음
    • 김수현
      저스틴님 위 참조하시면 되실 것 같습니다.
      대화보기
      • Yoo Moon Il
        아.. 제가 뭔가를 놓친것 같기도 하고요 아님 내용이 살짝 점프한 느낌도 드는데요.. 원격 저장소를 만들때 잘 이해가 안됩니다. 저같은 경우는 한 공유기 안에 사설 ip두대의 컴퓨터를 가지고 테스트 하고 있는데요. 제 질문은요:

        1) 일단 서버로 사용할 컴터에 git 설치하고 디렉토리 하나 만들고 git init한 후 "ssh 아이디@서버로사용할컴퓨터아이피주소" 해야 하나요? 아니면 그냥 아무 디렉토리 가서 "ssh 아이디@서버로사용할컴퓨터아이피주소" 해야 하나요?
        2) 아이디는 제가 임의로 정하는 건가요?
        3) IP주소는 공인 IP인가요? 네이버에 내 ip해서 나오는 주소요.... 아니면 사설 IP주소 인가요?

        강의 맨 처음 시작하는 부분 ssh서버 만드는 부분이 잘 이해가 안됩니다. 조금만 추가 설명이나 참고 자료 부탁드려도 될까요?
      • 폭스킴
        **화면분할윗부분:서버에ssh로접속할컴퓨터**
        ssh 아이디@서버로사용할컴퓨터아이피주소
        (비밀번호 입력)
        cd git(작업할 디렉토리)

        **화면분할아랫부분:로컬컴퓨터**
        git init local
        cd local
        vim f1.txt
        git add f1.txt
        git commit -m 1

        **화면분할윗부분:서버에ssh로접속된컴퓨터**
        git init --bare remote
        cd remote

        **화면분할아랫부분:로컬컴퓨터**
        git remote add origin ssh://아이디@서버로사용할컴퓨터아이피주소/home/git/git/remote/
        git remote -v
        git push
        git push --set-upstream origin master
        (비밀번호입력)

        **화면분할윗부분:서버에ssh로접속된컴퓨터**
        git log

        **화면분할아랫부분:로컬컴퓨터(집과사무실로가정)**
        cd..
        mv local home
        cd home
        cd..
        git clone ssh://아이디@서버로사용할컴퓨터아이피주소/home/git/git/remote/ office
        (비밀번호입력)
        cd office
        ls -al
        git log
      • egoing
        Justin님 안녕하세요. 제가 코드를 공유 못해서 대단히 죄송합니다. 급하게 처리하기에는 다소 벅찬 작업이라서 우선 공부하시는 분들께 도움을 요청했습니다. 공부하시는 분들이 댓글로 코드를 달아주시면 제가 그걸 나중에 본문에 반영하도록 할께요. 생활코딩이 도움이 될 수 있도록 노력하겠습니다!

        https://opentutorials.org......elp
        대화보기
        • Justin
          이고잉 님~~ 수업 정말 감사드립니다~~ 정말 열심히 듣고 있어요. 제가 어려운 부탁 하나 드려도 될까요? 저는 화면을 볼 수가 없는 시각장애인인데요. 그래서 텍스트를 음성으로 변환해 주는 스크린리더 소프트웨어를 사용합니다. 혹시 수업에서 사용된 git 코드들을 여기 페이지에 제공해 주실 수 있으실까요? 비디오에서 타이핑하시는 내용들을 볼 수 없어서 그렇습니다. 사용하신 git 코드들을 텍스트로 제공해 주시면 정말 저와 같은 시각장애인들이 수업 내용을 이해하는 데에 큰 도움이 될 것 같습니다. 정말 많이 감사드립니다!!
        graphittie 자세히 보기