“ 매주 목요일마다 당신이 항상 하던대로 신발끈을 묶으면 신발이 폭발한다고 생각해보라.
컴퓨터를 사용할 때는 이런 일이 항상 일어나는데도 아무도 불평할 생각을 안 한다. ”- Jef Raskin
맥의 아버지 - 애플컴퓨터의 매킨토시 프로젝트를 주도
반응형
| 오픈소프트웨어 |
파일 압축/ 풀기 명령
파일 압축 관련 명령
xz : 확장명 xz로 압축을 하거나 풀어준다.
xz 파일명
xz -d 파일명.xz
bzip2 : 확장명 bz2로 압축을 하거나 풀어준다.
예) bzip2 파일명
bzip -d 파일명.bz2
bunzip2 : "bzip2 -d" 옵션과 동일한 명령어
gzip : 확장명 gz으로 압축을 하거나 풀어준다
gzip 파일명
gzip -d 파일명.gz
gunzip : "gzip -d" 옵션과 동일한 명령어
리다이렉션 man cp >mancp.txt >> cp의 명령어목록을 txt로 만든다.
xz mancp.txt < 파일을 압축한다.
xz -d mancp.txt.xz < 파일을 압축해제한다. -d가 압축해제 명령어
파일 묵기
파일 묶기 (tar)
리눅스에서 '파일 압축'과 ' 파일 묶기'는 원칙적으로 별개의 프로그램
파일 묶기의 명령어는 'tar'이며, 묶인 파일의 확장명도 'tar'
tar : 묶음 파일을 만들어 주거나 묶음을 풀어줌
동작 : c묶기 x풀기 t경로확인
옵션 : f파일 v과정보이기 j tzr+xz z tar+gzip j tar+bzip2
사용예
# tar cvf my.tar /etc/sysconfig 묶기
# tar cvf txtrat.tar
#tar cvfj my.tar.xz /경로/ /경로/ ->묶기 + xz 압축
#tar xvf my.tar -> tar 풀기
Git이란? (분산 버전(이력) 관리 시스템)
출처 : WEBCLUB (https://webclub.tistory.com/317)
출처 : slowalk.com ( https://slowalk.com/2470 )
버전이란 ?
의미 있는 파일의 변화 : 기능개선, 버그 수정, 커스텀마이징 등
버전관리 ( 형상 관리, 소스관리 ) 란?
형상 관리?보다는 버전관리가 좀 더 적합한 표현이라고 볼 수 있음
파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내오는 것
보통 사람들이 사용하는 버전 관리
파일 또는 디렉토리 전체를 별도의 디렉토리에 복사해 둔다.
매우 간단하고 사용하기도 쉬운 방법
로컬 VCS ( Local Version Control System)
사용하는 컴퓨터(local computer)에 간단한 데이터베이스를 만들어 파일 변경 정보를 기록 관리
중앙집중식 VCS
파일을 관리하는 서버 CVCS가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아서 사용 (Checkout)
다른 개발자들과 함께 작업하기에 매우 편리함
중앙 서버에 문제 발생시 작업 중단 모든 자료 손실등 치명적 한계가 있음
분산 VCS(Distributed VCS: DVCS)
Client는 단순한 파일의 마지막 스냅샷을 복사하지 않고 그냥 저장소를 전부 복제
서버에 문제가 생겨도 local또는 다른 client를 통해 완벽한 복원 가능
동시에 다양한 그룹과 다양한 방법으로 협업 가능
예)DVCS(git)
- untracked: git이 이력관리대상에서 제외한 파일
- tracked: git이 이력관리대상으로 포함한 파일이며 다음과 같은 상태를 가진다.
- staged: 이력저장(commit)을 할때 저장되는 파일
- unstaged: git이 관리대상으로 포함한 파일이나 staged 상태가 아니므로 이력저장(commit)을 할때 저장 대상에서 제외되는 파일
- 출처 : 깃(?)똥차게 좋은 GIT 기초 (https://slowalk.com/2470)
GIT 역사
Bitkeeper 상용 DVCS를 시작하였지만, 서로 갈등이 생겨서 개발을 시작함. [리누스 토발즈 (자체 도구 개발)]
- 단순한 구조
- 빠른 속도
- 비선형적인 개발
- 완벽한 분산
- 대형 프로젝트에서도 유용
위와 같은 목표로 개발이 시작되었다.
Git 기초(1)
Git의 핵심 동작 개념을 이해한다면 쉽고 효과적으로 사용 가능
Git 차이가 아니라 스냅샷 ( 차이가 얼마나 있고 머가 있는지 보단 그 순간 수정하고 싶은게 뭔지를 사진개념으로 저장한다 )
기존 시스템
각 파일의 변화를 시간 순으로 관리하여 파일들의 집합을 관리
Git
프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 다룸
파일변경이 없으면 이전 상태에 대한 링크만 저장
스냅샷 스트링으로 저장
Git 기초 (2)
거의 모든 명령을 로컬에서 실행
거의 모든 명령이 로컬 파일과 데이터만 사용
( 오프라인, 온라인 상태에 거의 영향을 받지 않음) <- 다른 시스템과의 차별점
프로젝트의 모든 히스토리가 로컬 디스크에 있기에 대부분의 명령들은 순식간에 실행됨
체크섬(checksum)은 Git의 데이터 관리의 핵심
중복 검사의 한 형태로, 오류 정정을 통해, 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법
Git에서 사용하는 가장 기본적인 데이터 단위이자 Git의 기본 철학
체크섬 : 40자 길이의 16진수 문자열
7b1558c92a7f755d8343352d5051384d98f104e4
파일의 내용이나 디렉토리 구조에 대해 SHA-1 해시로 체크섬 계산
Git은 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장
- 체크 섬( 한번알아보기 ) - 개념 만 어느 정도 알아두면 됨
Git 파일의 3가지 상태 ( 매우 중요 )
- Committed: 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것
- Modified: 수정한 소스 파일이 아직 로컬 데이터베이스에 commit되지 않은 것
- Staged: 현재 수정한 소스 파일을 곧 커밋할 거라고 표시한 상태
Git 디렉토리
Working Directory
지금 작업하는 컴퓨터의 특정 디렉토리 ( Git으로 관리되어야 할 대상 )
리모트 서버 등에서 특정 버전을 가져와 (Checkout=가져온다) 만든 작업용 디렉토리
Git Directory : ( Git의 핵심 )
보통 Working Directory의 sub directory (.git)로 생성됨
프로젝트의 메타데이터와 객체 데이터베이스를 저장 하는 곳
Staging Area : ( 실제 directory가 아니고 특정 파일의 개념적 용도를 말함)
git directory에 저장된 단순 파일 이며 곧 커밋할 파일 정보를 저장
Git 작업 순서 개념도
- 1 Working Directory에서 파일을 수정한다.
- 2 Staging Area에 파일을 Stage 해서 Commit 할 Snapshot을 만든다.
- 3 Staging Area에 있는 파일들을 Commit 해서 Git Directory에 영구적인 Snapshot으로 저장한다
1. 특정 디렉토리에서 Java Javascript C 등의 소스코드 편집, 수정하는 작업
2. Staging Area에 stage 된 수정 파일의 상태는 staged
수정은 하였으나 stage 되지 않는 파일의 상태는 modified
3. Git directory에 저장된 파일의 상태는 committed
Git 설치
CLI vs GUI
Git의 모든 기능을 지원하는 것은 CLI
대부분의 GUI는 GIT의 기능을 전부 구현하지 않고 비교적 단순
리눅스 설치 명령어 : $sudo apt-get install git
윈도우 버전 ( CLI설치 : https://git-scm.com/downloads)
Git 설치 후 최초 설정
사용환경을 설정
한번만 설정하면 되며, 업그레이드 시에도 유지되고 다시 변경할수 있음 (git config)
사용자 정보 등록
묻지 않을 경우에 설정
git config --global user.name "최영환"
git config --global user.email "영환@이메일.컴"
설정 확인
git config --list
도움말 보기
git help <명령> / git <명령> --help / man git <명령>
[체크섬 : 중복 검사의 한 형태로, 오류 정정을 통해, 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법]