git 기초

git 기초

버전 관리 시스템 git

git이란 “분산형 버전 관리 시스템”
버전 관리 시스템? 이전에 작성한 내용들(버전들)을 보존하면서 관리하는 시스템

학습목표

* Git의 환경설정
* 버전 관리 시스템의 필요성 이해
* Github와 Git의 관계 이해
* Repository에 대한 이해
    - local Repository와 Remote Repository의 차이 이해

git intro

버전 관리를 사용하는 이유?

1. 파일이 변경되면 변경 이력을 저장할 수 있다
2. 이전 버전으로 돌아갈 수 있다
3. 어떤 변경 사항이 발생했는지 알아보기 쉽다
4. 협업하기에 좋다    → github, gitlab 등의 원격 저장소를 이용한 협업 가능
5. 백업용

 
특정 시점에 생성되는 백업 복사본: 스냅샷
→ 스냅샷을 만들어주는 작업: commit

Git Repository

내가 작업하는 소스 코드 폴더가 버전 관리 받으려면 git의 관리 하에 둬야 한다
→ Git Repository
→ 내 컴퓨터의 저장소(개인 저장소)인 local Repository와 원격 온라인 저장소(공유 가능)인 Remote Repository

Fork

예를 들어 오픈 소스인 React 프로젝트에 contribute 하고 싶다면?
→ “React 원격” 저장소를 “내 원격” 저장소로 가지고 오는 작업이 필요
→ 이 과정이 Fork

Clone

fork를 하고 나면 나의 Remote Repo에 React 코드를 가져온 상태
→ 이제 이 코드를 수정하기 위해 내 컴퓨터(local Repo)로 가져오는 작업이 필요
→ 이 과정이 Clone

Push

내 컴퓨터에서 소스 변경 작업을 완료했다면 이 변경 내용을 commit을 통해 저장 후에
Remote Repo에 업로드하는 작업이 필요
→ 이 과정이 Push
→ Push가 완료되면 Pull request 기능(깃허브)을 통해 내가 제안한 코드 변경사항에 대한
반영 여부를 요청 가능

Pull

push와는 반대로 Remote Repo의 변경 사항을 나의 Local Repo로 가져오는 작업
→ 이 과정이 Pull
 

---

Git 설치하기

> sudo apt install git    # git 설치
> git –version        # git 버전 확인

Git 환경 설정

사용자 정보와 에디터 설정 작업이 필요

사용자 정보

설치 후 가장 먼저 사용자 이름, 이메일 주소를 설정
→ 기록된 사용자 이름, 이메일 주소가 git commit 내역에 기록되기 때문
→ 보통 깃허브에 등록된 사용자 이름, 이메일 주소를 사용
 

> git config --global user.name “사용자 이름”
> git config --global user.email “이메일 주소”
ex)
> git config --global user.name “kimcoding”
> git config --global user.email “kimcoding@naver.com”

# --global 옵션을 쓰면 사용자 home에 저장되므로 git 설정시 최초 1번만 입력하면 됨
→ 만약 이메일등을 변경한다면 다시 입력해야 함

# 여러 프로젝트에서 다른 정보를 사용해야 한다면 --global 옵션을 빼고 사용하면 됨

에디터

git에서 commit 메시지를 기록할 때 텍스트 에디터가 열린다.
기본값은 vi

다른 에디터로 변경하는 경우 ex) nano
> git config --global core.editor nano    # nano 에디터로 기본값을 변경

설정값 확인

> git config --list

 

SSH 등록하기

github에 ssh 공개키(비대칭키)를 등록하는 방법과 ssh를 이용해 git clone하는 방법

SSH 키 생성

> ssh-keygen    # ssh 키 페어를 생성

~/.ssh/ 경로에  두 파일 `id_rsa`와 `id_rsa.pub`를 생성하는 과정
id_rsa    # 공개되면 안되는 개인키
id_rsa.pub    # 공개하는 공개키

키 페어를 생성 후에 공개키(id_rsa.pub)를 복사해서 github에 등록

공개키(Public Key) 복사

cat ~/.ssh/id_rsa.pub    # 공개키 값을 출력

Github에 공개키 등록

github 사이트에서 로그인하여 설정(settings)→ SSH and GPG keys → SSH Keys 항목에서 New SSH key → title은 임의로 Key에는 복사된 값을 붙여 넣고 Add SSH key

SSH 등록 테스트

Clone을 통해 확인 가능
→ 받고자 하는 Repo에서 초록색 code 버튼→ Clone SSH 항목에서 값을 복사
→ 나의 프롬프트에서 정상 동작 확인

> git clone git@github.com:codestates/im-sprint-simple-git-workflow.git

다음 과정이 정상적으로 동작하지 않는다면?

Github CLI 사용으로도 가능

Github CLI 사용을 위한 인증

OAuth (Device Authorization) 인증 과정으로 진행(가장 쉬움)

1. GitHub CLI 설치

> curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg
> echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main"
> sudo apt update
> sudo apt install    gh # 만약 이게 안된다면 snap install gh

2. gh auto login 명령어로 로그인 시도
→ 화살표 키로 다음 항목 선택 후 엔터

? What accout do you want to log into? GitHub.com
? What is your preferred protocol for Git Operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

3. login with a web browser 옵션 선택
one-time code가 등장하고 이를 복사 붙여넣기해서 등록하기

---

Git workflow

학습 목표

* Github의 기능과 Git 명령어 사용
    - fork
    - clone
    - status
    - restore
    - add
    - commit
    - reset
    - log
    - pull
    - push
    - init
    - remote add
    - remote -v

* Git의 3가지 영역 및 상태를 이해(committed, modified, staged)

* Remote Repository를 페어와 공유하며 협업하기

* 충돌 발생 시 해결법

* Git Repository의 commit 되지 않은 변경 사항을 취소하기
    - reset HEAD <file>
    - checkout -- <file>

* 협업을 위한 git 개념 이해
    - branch, merge의 개념
    - remote repository에서 origin과 upstream의 차이점

혼자 작업 workflow

git의 버전 관리 기능 활용하기

전체적인 흐름도
1. Remote에 있는 other Repo에서 Fork를 해서 Remote에 있는 내(origin) Repo에 가져옴
2. 코드 수정 작업을 위해 Local Repo로 가져오기 위해 Clone
3. 내 컴퓨터 작업 공간(work space)에서 작업에 들어간 파일들을 git 의 관리 영역에 올려주기
→ 이 영역: staging area
→  staging area에 있는 파일은 staged file, 들어오지 않은 파일은 unstaged(untracked file)
4. staging area에 속한 파일들은 commit이 가능
→ commit 을 하면 내(origin) Remote Repo에 push 해서 commit 기록을 Remote에도 남길 수 있음
5. Push 완료 후 이제 remote의 원래 Repo(other Repo; 내가 Fork해서 가져온 그 Repo)에 Pull request를 보내면 other Remote Repo로 내가 수정한 코드를 업로드 가능

fork

내 저장소(origin Remote Repo)로 contribute 하고 싶은 other Remote Repo 가져오기

clone

내 저장소(origin Remote Repo)에서 코드 작업을 위해 내 컴퓨터로 복사해 오는 작업

> git clone 해당Repo주소    # 해당 Repo 주소란 https://~//Repo 까지를 의미. 즉 주소창 복사

status

git status 명령어로 현재 staging area와 unstaged(untracked) file 목록에 어떤 것이 있는 지 확인

> git status

# git status 를 통해 어떤 파일이 어떤 상태에 있는지, 그리고 해당 파일에 대해 어떤 행동을 할 수 있는지 알 수 있습니다.
# [add] : add는 파일을 commit 할 수 있는 상태로 만들어 줍니다.
# [restore] : 변경사항을 폐기(discard changes) 하는 명령.

restore

내가 작업한 코드를 싹 다 밀어 버리고 새로 작업해야 할 것 같다. 처음 Clone을 받았던 상태로 되돌리는 방법이?
→ git restore
→ commit(혹은 staged) 되지 않은 local repo의 변경 사항을 폐기

> git restore mypage.js    # git restore <파일명>

add

commit을 하기 위해 먼저 Git의 관리 영역 하로 파일 들을 이동시켜줘야 함
→ untracked files을 staging area로 추가하는 작업
→ git add

> git add mypage.js    # git add <파일명>
> git add .    # staging area에 모든 파일을 한번에 추가. unstaged 상태의 모든 파일을 한번에 추가하는 것이나 이 때는 올리지 말아야 할 파일까지 모두 add될 수 있으므로 주의!

commit

변경 작업이 끝났을 때 변경 사항을 저장
→ git commit
→ 어떤 사항이 변경되었는지 간단한 메모를 통해 변경 기록 관리 가능(-m 옵션)

> git commit -m ‘mypage 구현’        # git commit -m ‘메시지 내용’

만약 git add 명령어로 파일을 staging area에 올린 상태에서 파일을 또 수정한다면?
→ git add 를 한번 더 해주면 된다

git의 3가지 영역 및 상태

tracked area 내부에서의 3가지 상태
→ unmodified, modified, staged

Unmodified : 기존에 Commit했던 파일을 수정하지 않은 상태
Modified : 기존에 Commit했던 파일을 수정한 상태
Staged : commit이 가능한 상태. 수정한 파일을 commit 하기 위해서는 staged area에 add 하는 작업이 필요

### reset
방금 commit한 기록을 취소하고 에러를 수정하고 싶은 경우?
→ 아직 Remote Repository에 업로드 되지 않고 Local Repository에만 commit 해 놓은 기록이라면 reset 명령어를 통해서 commit 을 취소 가능
→ git reset

> git reset HEAD^    # 가장 최신의 commit을 취소
# HEAD는 연속된 ^의 숏컷을 뜻함 → HEAD^3 은 HEAD^^^ 의 의미

push

내 Local Repository의 commit 기록들을 Remote Repository로 업로드
→ git push origin branch 명령어
→ 상황에 따라 뒤의 명령어는 바뀔 수 있음; git push origin main, git push pair dev 등

> git push origin master        #git push <origin> <branch>
                    # 리모트에 있는 origin의 master 브랜치에 업로드하는 것

log

현재까지 commit 된 내역들을 확인
→ git log

pull

내가 Remote Repo(origin)에 push해 놓은 변경 사항에 대해서 함께 작업하는 사람들에게 알리는 것
→ pull request 현업에는 줄여서 PR이라고 함

---

함께 작업 workflow

전체적인 흐름도

1. 내 컴퓨터에서 생성한 디렉토리를 init 명령어를 통해 git의 관리 하에 둠
2. 내 컴퓨터의 git 디렉토리를 remote Repo와 연결
3. pair의 변경 사항과 나의 변경 사항을 remote Repo를 통해서 공유

init

기존 디렉토리를 git repo로 변황
→ local repo 만드는 것
→ 기존 프로젝트를 Git Repository로 변환하거나 새로운 Repository를 초기화하는 데에 사용

> sampledir git init    # <파일명> git init

remote add origin

local repo를 remote repo와 연결하는 작업
→ git remote add 명령어

> git remote add sampledir    # git remote add origin <repo 브랜치>

remote add pair

pair(동료)의 remote repo에 연결

상대방이 pair라는 이름의 repository를 쓰는 경우
> git remote add pair myShareDir    #git remote add <상대방의 repo 이름> <repo 브랜치>

# 참고로 pair 자리<상대방의 repo 이름>는 별칭(별명)이다. 자기가 원하는 이름으로 저장해두면 된다

remote -v

연결된 remote repo들 확인
→ 현재 local repo와 연결된 모든 remote repo의 목록

> git remote -v

pull

동료의 repo의 해당 브랜치에서 작업 내용 가져오기

> git pull pair master    # git pull <shortname> <branch>

→  받아오는 내용은 자동으로 병합(merge)된다.

충돌 해결하기

로컬에 커밋한 내용과 리모트를 풀 받은 내용이 다를 때 자동으로 병합된다
→ auto merge 됨.
같은 부분을 변경한 내용이 존재해서 자동으로 병합할 수 없는 경우?

ex)
<<<<
console.log(‘내 변경사항’)
======
console.log(‘페어의 변경사항’)
>>>>


해결한 방법?
> git commit -a
> git push origin master

 
→ 터미널 화면에서도 Merge conflict가 발생해서 Automatic merge에 실패했다고 알려줌
→ git status 로 상태 확인 후 충돌이 일어난 부분은 하나 하나 직접 확인 후 수정이 필요

#해당 4가지 옵션은 visual studio code 에서만 해당
> code 충돌파일명

Accept Current Change를 클릭해서 내가 수정한 내용으로 파일에 반영
Accept Incoming Change를 클릭해서 Remote Repository의 내용으로 파일에 반영
Accept Both Changes는 변경 사항 모두를 반영
Compare Changes

위 4가지 옵션 이외에도 직접 파일을 수정해서 반영하는 방법도 존재

 
→ 수정을 마치면 병합 커밋(merge commit)을 생성해 주기 위해서 파일을 staging area로 추가

> git add .        # 또는 수정한 파일명
> git commit    # -m 옵션 없으면 자동 생성 메시지
> git push origin master        # push 작업

-------------------------

페어프로그래밍을 위한 깃플로우에 대해 
- 드라이버와 네비게이터를 바꿀때마다 페어의 코드를 가져와 최신화 시키는 과정

1. 진행 할 스프린트의 레파지토리를 복사해 온다 – 포크
2. 복사해온 스프린트레파지토리를 명령으로 각자의 로컬로 가져옴.
git clone <REPO URL - 내 깃허브 SSH>
3. 페어의 레파지토리와 나의 로컬을 연결
- 페어가 작업한 결과물을 가져와 베이스로 코드를 작성해야 하므로
git remote add <pair - 상대 이름> <REPO URL for PAIRS FORK - 페어의 깃허브 SSH> 
git remote -v 
4. 드라이버가 코드를 작성하고
commit git add <change file - 바뀐 파일 이름>
git commit -m '커밋메세지에 쓰고 싶은 말' 
5. 작업한 코드를 자신의 깃헙레포지토리에 푸시
git push origin master(or other branch name) 
6. 드라이버 네비게이터 역할 바꿈
- 드라이버는 직전에 작성된 코드를 자신의 로컬로 가져옴
git pull <pair - 상대 이름> master (or other branch name) 
7. 새로운 코드를 작성하고 commit 한다
git add <change file - 바뀐 파일 이름> 
git commit -m '커밋메세지에 쓰고 싶은 말' 
8. 자신의 깃헙레포에 푸시한다.
git push origin master (or other branch name) 
9. 또 다시 드라이버 네비게이터 역할 바꿈
- 드라이버는 직전에 작성된 코드를 자신의 로컬로 가져옴
git pull <pair - 상대 이름> master (or other branch name) 
10. 반복!

--------------

#### 깃헙 잔디: gitHub에 1일 1커밋하는 습관을 가지는 게 좋다
→ private로 하면 잔디가 안 생기고 public으로 만들어야 잔디가 생김

### origin vs upsteam?
다른 사람의 github 저장소를 fork한 경우

```jsx
&#160;
&#160;
내가 fork해서 가져온 내 저장소→  origin
fork 했던 그 저장소→  upstream

GUI 환경에서 git 을 사용하는 프로그램 들

sourcetree        # 가장 범용적이나 Mac, Windows 만 지원
github desktop    # 리눅스도 지원하지만, 좀 추상화시켜둠
smartGit        # 가장 좋은 프로그램?이였지만 유료화됨

이 외에도 다양한 GUI 프로그램이 있다. 필요하면 다운받아서 쓰면 된다

gitHub 로 블로그 만들기

github으로도 블로그 만들 수 있다. 깃 잔디 관리 측면에서 좋다
→ 구글링

gitHub 잔디 관리 측면에서 clone coding 연습

→ 인프런 닷컴(inflearn)

---