Introduction to Git and Github - Week 1

How to use Version Control Systems(VCS)

 

Git == repository 나눠서, command 입력해가지고 github 에 있는 storage control 하는 software 인듯

github == Code sharing 할수있는 platform

 

Version control

automation script 계속 접할 것임.

그리고 administration role 할때 documentation control 이나 이런게 엄청 중요한 걸 알게 될 거임

새로운 code implement 했을때 잘 못될 경우를 대비해서 VCS 를 쓰는 거임.

 

diff and patch

 

Git == Tracking of chaging

 

 

diffing files

파일 두개 comparison  하개 하는 git command

show the difference between 2 files

2 different version

 

이렇게 cat command로 봤을때 2개 뭐가 다른지 보기 좀 힘듬

diff rearrange1.py rearrange2.py

쉽게 다른걸 볼 수 있음

 

line 5c5,6 가 밑에 껄로 replaced 됬다는 뜻 , c는 the line was changed

11a13,15 = 3 line new in the second file

a == stands for add

 

diff -unified x.py y.py 포맷

- sign == removed

+ == added

 

wdiff == highlight the word which is changed

meld 

KDf3

vimdiff

etc...

 

change.diff 라는 파일 생성

즉 diff -unified old_file new_file 을 change.diff 파일 새로 생성

 

Patch command

 

이런식으로 script 공유 해서 collegue랑 share 한다음 diff command > file.diff 만들어서 share

< == redirect to file

이렇게 patch command 써서 cpu_usage.diff 를 cpu_usage.py scripting file로 update 시킴

왜 귀찮게 diff나 patch 써서 하냐? 그냥 다 복사 하면되지,

1. original code save위함

2. project tree에 뭐 바꿧는지 기록 하기 위함

 

 

 

sys.exit function을 쓰면 return 값을 마지막으로 코드를 종료함

근데 import sys 해야됨

 

이렇게 fixed version 만들었을때 어떻게 patch 하는가

diff command 써 가지고 disk_usage.diff file 생성

diff file 보내고 patch 하면됨 (diff -u disk_usage_original.py disk_usage_fixed.py 는 두 파일 비교해서 다른점 unified format으로 보는거고 > 로 새로운 파일생성)

 

그다음 collegue가 patch command 써서 update하면 됨

 

 

We use this kinda feature through version control system (VCS)

그냥 System just store the file, 근데 log 남겨주고, 그냥 간편하게 관리 하게 해주는 거 

Commit 할때 왜 commit 했는지 comment 도 할 수 있음

Project driving 할때, developer level 별로 access 할 수 있는 repository 가 다르게 관리 함

 

VCS를 쓰면 code of history 를 save 함. log 저장, 그래서 one man IT team 일지라도, automation scripting을 하는 이상 VCS를 쓰는 profit이 많음

 

With a VCS, you can view, 

track and select snapshots from the history of your project. 

So nothing you do is lost, 

and since we can use a VCS to 

store both code and configuration files, we can make the overall IT systems more scalable and reliable.

 

 

Server deploying 할때도 VCS를 쓰면 automate 새로 세팅하기가 쉽게 되어있음을 쓰다보면 발견 할수 있음

 

Git은 좋은게, 어떤 server를 설치할 필요없이, 각자 locally에 다운받아서 internet을 통해 share 가능하다는 점이다

Git clients can communicate with Gitservers over the network using HTTP or SSH and Git own protocol

network 없어도, locally 돌기때문에 사용 가능(이경우 share는 안되는 듯)

SCM == source control management

다른 VCS Software도 많음

Check out the following links for more information:

• https://git-scm.com/doc
• https://www.mercurial-scm.org/
• https://subversion.apache.org/
• https://en.wikipedia.org/wiki/Version_control

 

Installing Git

git 깔려있음

apt , yum on linux to install file

Chocolatey on Windows

Homebrew on Mac OS

 

Integrated Developer Environments == IDEs

interact with git through GUI interface

 

gitforwindows.org 가면 다운로드 받을수 있음

 

.sh file== excution file for bash

 

어떻게 git에서 tracking 하고 saving 하는지 git concept를 알아보자

git config

user.email

user.name

써서 내가 누군지 git 한테 확인 시킴

 

--global == set this value for all git repositories that we'd use

we can also set the different value for different repositories

 

git init

git clone (make a copy of repository which is already existing)

git init 써서 empty git repository 만듬

ls command 써서 확인 가능

직접 만들어 보았다

git repository 안에 들어있는 파일들

Windows file system으로 보면 이렇게 보임

이 repository를 git log나 history 관리하는 database로 봐도 무방하다

이 모든 파일들 git command 써서 확인 및 관리 해야함

 

git clone command 쓰면, 이 git repository 가 copy 되는 개념

working tree 는 현재 버젼 저장 하고 가공하는 sandbox 임

The git directory acts as a database for all the changes tracked in Git and the working tree acts as a sandbox where we can edit the current versions of the files.

 

이 directory 안에만 넣는다고 해서, git이 자동으로 tracking 하진 않음, git add 써가지고 staging area에다가 등록 해줘야함

 

git status command 써서 current working tree status 확인 가능 그리고 pendin gchange 도

 

currently in the staging area

git commit command 써서 commit 가능

 

commit하게되면

이렇게 주석 comment 달수있는 거 나옴

 

Tracking Files

Tracked file == file snapshot 찍는거

untracked file == 그냥 파일 놔뚜는 거

 

Track file은 3가지 state를 가짐

1. modified == change 했는데, 아직 commit안한거

2. staged == modified file이 staged filed 로 바뀌고, staged 상태로 바뀜 , (commit 전 상태)

3. committed == change made and safely saved in database

 

 

Test 까지 해봄

git으로 안하고 그냥 IDE에서 save하면 저렇게 빨간색으로 나오고 staging 안된다고 경고 메세지 나오니까 git add 해서 다시 add 해줘야함

-m 써가지고 editor 안열고 그냥 save가능 , 지금 이 상태는 code snapshot 되어있는 상태인것

working tree == IDE , Staging Area == temp save area , Git directory == file system to store the historical data

 

Git init 써가지고 repository 꼭만들고, 그 안에 파일 넣어서 관리 해야함, 아니면 tracking 못함

git config -l command 로 확인 가능한 정보들

repository share했을 경우 log에 내 email이랑 user.name이 남음

 

리눅스에서, 파일(File)을 사용해 할 수 있는 작업은 크게 세 가지로 나눌 수 있습니다.

• 파일에 저장된 데이터를 읽기. (r = read).
• 파일에 데이터를 쓰기. (w = write).
• 파일 실행. (x = execute)

chmod 명령은 바로 이러한 파일의 권한을 변경할 수 있게 만들어주는 명령입니다. "change"와 "mode"의 앞 글자들을 조합한 이름이죠. (chmod = ch + mod)

 

commit comment 안쓰면, git commit command 작동 안함

editor 써가지고 file 바꾸면, stage 에서 항상 떨어져 나가니까 modified 한다음 항상 git add 써서 staging 해줘야함

 

Commit message 쓸때, 짧고 딱 간단하게 목적만 써놓는게 좋음

 

git log 쓰면 보기 쉽게  identifier 랑 author 뭐 이런 정보 나옴

What HEAD and master mean ?? we will cover later

 

 

corresponding == 해당하는, 상응하는

grasp == 꽉 잡다, 움켜쥐다

robust == 혈기 왕성한

constitute == ~로 여겨지다

aborted == 유산된, 안됨

anatomy == 해부학

impassioned == 열정적인, 간절한