Git Basics

Updated: April 14, 2024

Git

Git은 다음을 의미한다.

Fast version control system
- Version control is a system that records changes to a file or set of files over time so that you can recall specific version later.
- Version Control System(VCS) allows you to revert(옛 상태로 돌아가다) selected files back to a precious state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more.
- Using a VCS also generally means that if you screw(고정하다) things up or lose files, you can easily recover. In addition, you get all this for very little overhead.
- Git은 VCS는 아니다.
Open source
github는 매우 유용한 서비스이지만 git의 일부는 아님
github는 remote(원격) repository(git server) 중 하나이다.
분산 VCS
- All version control activities are local, no connection required
- 팀 공유 작업에 최적화된 도구
다수 개발자 사이에 협력을 용이하게 하는 도구
가장 기본적이고 필수적인 DevOps도구
누가 언제 무엇을 수정하였는지 tracking
- Content (not file) oriented
수정된 내용을 되돌릴 수 있음
Local / Remote Repository

Git distributed architecture

Fast
Internet 없이도 작업
Main repository에 영향을 미치기 전에 개발자간 상의
Crash safe

Git structure

Git has three states that your files can reside(존재하다) in: modified, staged, and committed.

Modifed means that you have changed the file but have no committed it to your database yet.
Staged means that you have marked a modified file in its current version to go into your next commit snapshot.
Committed means that the data is safely stored in your local database.

This leads us to the three main sections of a Git projection: the working tree, the staging area, and the Git directory.

The working tree is a single checkout of one version of the project. These files are pulled out(뽑아내다) of the compressed database in the Git directory and placed on disk for you to use or modify.
- Modified
The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit. Its technical name in Git parlance(말투) is the “index”, but the phrase(문장, 어구) “staging area” works just as well.
- Staged
The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
- Committed

The basic Git workflow goes something like this.

You modify files in your working tree.
You selectively stage just those chages you want to be part of your next commit, which adds only those changes to the staging area.
You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

Git’s view, snap shot stream

The major difference between Git and other VCS is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based chages. These other systems think of the information they store as a set of files and the chages made to each file over time(this is commoly described as delta-based version control).

Git doesn’t think of or store its data this way. Instead, Git thinks of its data more a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snpapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.

This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS.

Git vs Github

Git은 version control 소프트웨어, Github는 remote repository 웹서비스이다.
Github를 사용하면 사용자의 클라이언트 기계(PC)에서 직접 사용자의 Github 계정안의 repository에 파일을 올려 놓거나 다운 받을 수 있으며 사용법은 매우 직관적이고 쉬움.

Git set up

sudo apt-get update
sudo apt-get install git
- Git의 기본 패키지만을 설치
- sudo apt-get install git-all
  - Git의 모든 부가 패키지를 설치
sudo apt-get update

git –version
- 만약 Git을 설치하지 않았다면, 이것이 Git을 설치하는 것을 알려줄 것이다.
git –help
git help -a

Git commands

basics

ls
- 아무 것도 안보인다. 즉, 모두 숨겨진 파일, 디렉토리이다.
ls -al
- ls 옵션
  - -a: .을 포함한 경로안의 모든 파일과 디렉토리를 표시
  - -l: 지정한 디렉토리의 내용을 자세히 출력
  - -d: 지정된 디렉토리의 정보 출력
  - -n: 파일 및 디렉토리 정보 출력시, UID, GID를 사용
  - -R: 하위 경로와 그 안에 있는 모든 파일들도 같이 나열
  - -F: 파일 형식을 알리는 문자를 각 파일 뒤에 추가
- -al은 .을 포함한 경로안의 모든 파일과 디렉토리를 표시하고, 지정한 디렉토리의 내용을 자세히 출력하라는 옵션이다.

mkdir gitDemo
cd gitDemo
ls
git init
git init gitDemo2
ls
ls -a
cd .git ; ls -a
- ., .., HEAD, branches, config, description, hooks, objects, refs 가 출력되었다.
- .git 디렉토리는 codebase에 가했던 모든 히스토리를 포함한 모든 정보와 commit된 파일을 보관한다.
cd ..

vi f1
- f1 first line
ls
git status
- 현재 Git 저장소의 상태를 보여주는 명령어. 다음과 같은 정보를 확인할 수 있다.
  - 추적 중인 파일과 추적되지 않은 파일의 목록
  - 변경된 파일의 목록
  - Starting Area에 올라가지 않은 변경사항
  - 현재 브랜치의 상태(현재 브랜치 이름, 커밋된 이후의 변경 사항 등)
- 현재는 No commits yet상태이고 Untracked files에 f1과 gitDemo2/가 있다.

On branch main
Your branch is up to date with 'origin/main'.

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:   file1.txt
	modified:   file2.txt

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

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

위에서는 file1.txt와 file2.txt는 변경되었지만 Staging Area에 추가되지 않았고, newfile.txt는 추적되지 않은 파일이다.
git add f1
- f1이라는 특정 파일을 Staging Area에 추가한다.
- git add *.txt
  - 현재 디렉토리에서 확장자가 .txt인 모든 파일을 Staging Area에 추가한다.
- git add .
  - 현재 디렉토리와 하위 디렉토리에 있는 모든 변경된 파일을 Staging Area에 추가한다.
- on stage
  - 현재 Staging Area에 있는 변경 사항을 가리킨다.
  - git add 명령을 통해 Staging Area에 올라간 파일들을 말한다.
git status
- commit된 것은 없으나 on stage되어 있음.
- on stage 되었다는 것은 변경을 tracking 시작하여 버전컨드롤 정보를 git chache에 저장.
- commit하면 local repository에 저장
- commit된 파일만 remote repository에 저장 가능하다.
git rm –cached f1
- f1을 없애는 것이 아니라 tracking하지 않는다.
ls
- 파일시스템에는 f1이 사라지지 않았음
git status

git add .
- error: ‘gitDemo2/’ does not have a commit checked out; fatal: adding files failed
git add f1
git status

git commit -m ‘f1 initial commit on master’ f1
- create mode 100644: normal file을 의미
- executable등은 100755이다.

git log
- HEAD는현재의 branch를 가리키는 포인터. 즉, 해당 브랜치에 수행되었던 마지막 commit을 가리키는 포인터
- 해당 브랜치의 마지막 commit 지점에서의 snapshot
git ls-files -s
- Git이 추적하고 있는 파일 목록을 보여주는 명령어. 각 파일에 대해 파일모드, 객체 해시 및 파일 경로가 표시된다.
  - -s: 출력을 특정 형식으로 하라는 옵션. 객체의 상태 및 경로에 대한 정보를 함께 보여줌
  - 100644: 파일 모드
  - 900c5f9cfaa02bda9c07579b29ae4e709599bc84: 파일의 객체 해시
  - 0: 파일의 stage 번호
  - f1: 파일의 경로
- show info about files in the index & the working tree
- 파일시스템에 있는 파일들과 그 파일들을 git add 명령을 통하여 git stage에 올린 후 수정하고 commit한 모든 히스토리를 저장한 공간을 stageing area라고 부르면 그 내역을 담고 있는 Git의 구조체를 “Git index”라고 한다.
- 이는 stage에 올린 파일들, 즉 그 파일들의 수정/commit 히스토리를 관리하기 위하여 만들어진 구조체로서 tree 주고를 갖게 되며, “Git index” 구조체가 git의 commit point들 사이에서 빠르게 필요한 정보를 찾을 수 있게 함.
git show
- Git에서 커밋의 변경 내용을 보여주는 명령어. 기본적으로 가장 최근의 커밋에 대한 정보를 보여줌.
- 커밋의 해시 값, 저자와 날짜, 커밋 메시지, 변경된 파일 목록, 각 파일의 변경 내용

branch

브랜치에서 새로운 파일을 만들어 f1과 다른 경로로 version control 하는 시나리오이다.

ls
git branch br1
git status
- 아직 master branch
ls
git checkout br1
- Switched to branch ‘br1’
- Git의 branch는 파일 시스템 상의 다른 디렉토리가 아니라 commit 히스토리, 즉 여러 파일들의 commit 히스토리를 구분하는 version control 경로 개념
git status
- br1 branch로 옮겨 온 것이 확인됨
git branch
- git status와 유사한 정보를 제공
ls
- subbranch br1에서 parent인 master branch의 f1을 봄
- 상위 branch의 파일들이 보인다.

vi f1
- f1 second line
cat f1
- br1에서 수정한 내용이 보인다.
checkout master
cat f1
- br1에서 수정한 내용이 보임.
git checkout br1

git add f1
git commit -m ‘f1 modified & committed on br1’ f1

git log
git show
- commit … (HEAD -> br1)
  - 해당 commit의 br1
- Author
  - 주인의 이름
- Date
  - 주인의 date, commit 한 사람의 date와 다를 수 있음
- f1 modified and committed on br1
  - commit log message
- diff –git a/f1 b/f1
  - 두 파일(master에서의 f1, br1에서의 f1)을 비교함
- index 900c5f9..a5e7e8f 100644
  - 900c5f9: 변경 이전의 Git index
  - a5e7e8f: 변경 이후의 Git index
- — a/f1
  - 변경 전의 파일
- +++ b/f1
  - 변경 후의 파일
- @@ -1 +1,2 @@
  - 1: diff start line
  - +1: 한줄을 더했다는 것
- 줄을 더한 경우에는 +, 삭제한 경우에는 -

cat f1
- br1에서 변경 사항을 commit 하였으므로 br1에서의 f1은 변경된 f1이 보인다.
git checkout master
cat f1
- 변경된 내용은 보이지 않고 기존의 f1이 보인다.
- master branch에서의 f1에 변경 내용을 반영시키려면 br1을 master에 merge시켜 master에 변경된 f1이 저장되도록 해야한다.
- 즉, git home 디렉토리에 서로 다른 version의 파일을 유지하기 위해 git branch하여 파일 수정 작업을 한 후에 merge 하여 우리가 애초에 시작한 파일의 완료본 파일로 만드는 것이다.