Download ZIP: 그냥 순수하게 파일들만 압축해서 다운로드 되어 집니다.
Clone 주소복사: Clone은 순수파일들과 이 프로젝트의 커밋되었던 히스토리 정보까지 모두 다운로드가 되어 로컬저장소(Local Repository)를 만들어 줍니다.
git Global Setup: config 설정 (누가 어떤 수정을 했는지 남기기 위해)
git config --list를 쳐보자, Git에 설정에 대한 정보가 나온다. 이중에 꼭 설정해줄 내용은 사용자이름과 이메일!
git config --global user.name "user name"
git config --global user.email "이메일주소"이 설정을 삭제하고 싶다면?
git config --unset user.name
git config --unset user.email
git clone (Create a new repository)
원격 저장소에 모든것을 로컬PC에 가져오기
(만들고자하는 경로에 이동하여 실행하면, 저장소이름과 같은 폴더가 만들어짐)
git clone <저장소 url> 서버에서 파일을 Clone 하게 되면 내 컴퓨터의 지정된 폴더에 .git이라는 숨겨진 폴더가 생성되고 이 .git폴더를 가지고 있는 폴더가 작업 폴더(Working Directory)가 됩니다. 이 작업 폴더는 자동으로 서버와 링크가 맺어지게 됩니다.
이 .git폴더가 사실 로컬저장소의 역할을 하는 중요한 폴더로서
서버와의 링크 정보와 변경된 히스토리 정보를 모두 가지고 있는 폴더 입니다.
이 폴더를 사람이 수정하거나 추가/삭제를 할 필요가 없습니다. Git에서 알아서 운영합니다.
작업 폴더(Working Directory) 구성
작업폴더는 관리(추척)가 되는 파일과 관리(추적)되지 않는 파일로 나누어져 있습니다. 관리(추적)가 된다는 것은 이 파일의 생성, 수정, 삭제 등의 히스토리 정보를 모두 가지고 있다는 뜻입니다.
파일관리(추적)의 상태
추적은 바로 이전의 커밋을 깃점으로 아래의 4가지 상태로 관리됩니다.
- 추적안함 (Untracked) : 관리대상이 아님
- 추적함(Tracked)
- 수정없음 (Unmodified) : 변경이 없는 파일
- 수정함 (Modified) : 변경된 파일
- 스테이지됨 (Staged) : 스태이지에 올라간 파일
git add
작업 폴더에 처음 파일을 생성한다면 이것은 아직 관리(추적)대상이 아닙니다. 관리대상이 아닐 경우는 아무런 히스토리 정보를 가지고 있지 않습니다. 이제 이 파일을 관리대상으로 삼기 위해서는 git add 명령어를 실행해 줘야 합니다. git add 명령어를 실행하면 이 파일이 스테이지(Staging Area) 로 올라가게 됩니다. 이제부터 이 파일의 수정, 삭제 등의 모든 정보는 Git에 기록이 되어집니다.
파일의 상태는 추적안함 (Untracked), 수정함 (Modified) 이 스테이지됨 (Staged) 으로 변경됩니다.
git add <파일 이름> // 특정 파일만 추가하기
git add . // 모든 파일을 추가하기* 스테이지: 저장소에 커밋할 준비를 하기 위해 변경 내용을 임시로 저장할 위치
git commit
이제 스테이징된 파일들을 로컬 저장소(Local Repository)로 등록을 해야 합니다. 그러게 위해서는 git commit을 해야 합니다. git commit을 하면 현재 스태이징된 파일들을 그대로 스냅샷으로 찍어서 로컬 저장소(Local Repository)에 보관하게 됩니다. 이 스냅샷이 하나의 히스토리 기록이 되는 것입니다. 이 기록을 기준으로 과거로 되돌아갈 수도 있고 미래로 갈 수도 있고 다른 브랜치로도 이동할 수 있는 기준점이 됩니다.
파일의 상태는 스테이지됨 (Staged) 이 수정없음 (Unmodified) 으로 변경됩니다.
git commit -m "참고할 설명 작성"git push
git commit으로 로컬 저장소(Local Repository)에 스냅샷을 찍어 이용하는 것은 내 컴퓨터에서만 가능한 상태입니다. 이것을 서버에 올려서 다른 사람들과 공유를 하기 위해서는 원격 저장소(Remote Repository)에 업로드를 해야 합니다.
그 명령어가 git push 입니다. git push를 하면 로컬 저장소의 커밋(git commit)된 모든 내용이 그대로 원격 저장소로 올라갑니다.
git pull
원격 저장소에 올라온 최신 수정본 파일을 내 로컬 저장소로 업데이트를 해야 할 필요가 있습니다. 그때 필요한 명령어가 git pull 입니다. 일단 한번은 서버와 링크가 맺어있어야 실행이 됩니다.
원격 저장소에서 로컬 저장소로 소스를 가져오는 명령어로는 pull과 fetch가 있습니다. 차이는 가져온 소스를 merge 하느냐 안하느냐의 차이가 있습니다. pull 명령어는 원격 저장소의 소스를 가져오고 해당 소스가 현재 내 소스보다 더 최신 버전이라고 하면 지금의 버전을 해당 소스에 맞춰 올립니다. merge 명령어를 사용하는 것이지요. 하지만 fetch의 경우 단지 소스를 가져올 뿐 merge 하지는 않습니다.
* Push an existing folder
이미 작업한 폴더, 이미 존재하는 폴더에 파일을 원격저장소에 올리기 (가장 많이쓰는 기능)
먼저 해당 폴더에 들어가서 remote 설정을 통해 원격저장소와 연결해야 합니다.
// git 작업을 위한 소스가 존재하는 폴더로 이동
cd 워킹디렉토리 안으로 이동
//.git 파일과 함께, Stage area, git 등의 구조가 만들어짐. 기존 디렉토리를 git으로 관리하겠다.
git init
// 원격저장소 연결
git remote add [원격저장소 이름] git@[깃레포지토리 주소]
git remote add origin git@https://~
// 연결 설정 확인
git remote -v
// 폴더내 모든 파일 staging (.gitignore 파일을 참고하여 넘길파일 / 안 넘길파일을 결정)
git add .
// stage된 파일 commit으로 local git에 반영 (항상 커밋 메세지를 잘 써주세요)
git commit -m "Initial commit"
// 연결된 원격저장소에 올리기
git push -u [원격 저장소 이름] [현재 브랜치명]
git push -u origin master* -u 옵션: master라는 현재 브랜치를 자동으로 origin이라는 원격저장소의 master 브랜치로 연결해서
간단히 git push만 입력하여 반영하거나, git pull을 입력할 때 origin이라는 원격저장소의 master 브랜치를
로컬저장소의 master브랜치로 merge할 수 있게 해주겠다는 의미. 앞으론 git push / git pull로 사용 가능.
$ git push
$ git pull
파일 상태를 짤막하게 확인하기
git status 명령으로 확인할 수 있는 내용이 좀 많아 보일 수 있다. 사실 그렇다. 좀 더 간단하게 변경 내용을 보여주는 옵션이 있다. git status -s 또는 git status --short 처럼 옵션을 주면 현재 변경한 상태를 짤막하게 보여준다.
$ git status -s
M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txtM: 수정한 파일
MM: 왼쪽은 Staging Area의 상태, 오른쪽은 Working Tree에서의 상태
A: Staged 상태로 추가한 파일 중 새로 생성한 파일
??: 아직 추적하지 않는 새 파일
README 파일 같은 경우 내용을 변경했지만 아직 Staged 상태로 추가하지는 않았다.
lib/simplegit.rb 파일은 내용을 변경하고 Staged 상태로 추가까지 한 상태이다. 위 결과에서 차이점을 비교해보자.
Rakefile 은 변경하고 Staged 상태로 추가한 후 또 내용을 변경해서 Staged 이면서 Unstaged 상태인 파일이다.
파일 무시하기
어떤 파일은 Git이 관리할 필요가 없다. 보통 로그 파일이나 빌드 시스템이 자동으로 생성한 파일이 그렇다. 그런 파일을 무시하려면 .gitignore 파일을 만들고 그 안에 무시할 파일 패턴을 적는다. 아래는 .gitignore 파일의 예이다.
$ cat .gitignore
*.[oa]
*~첫번째 라인은 확장자가 “.o” 나 “.a” 인 파일을 Git이 무시하라는 것이고
둘째 라인은 ~ 로 끝나는 모든 파일을 무시하라는 것이다. 보통 대부분의 텍스트 편집기에서 임시파일로 사용하는 파일 이름이기 때문이다.
“.o” 와 “.a” 는 각각 빌드 시스템이 만들어내는 오브젝트와 아카이브 파일이고 ~ 로 끝나는 파일은 Emacs나 VI 같은 텍스트 편집기가 임시로 만들어내는 파일이다. 또 log, tmp, pid 같은 디렉토리나, 자동으로 생성하는 문서 같은 것들도 추가할 수 있다. .gitignore 파일은 보통 처음에 만들어 두는 것이 편리하다. 그래서 Git 저장소에 커밋하고 싶지 않은 파일을 실수로 커밋하는 일을 방지할 수 있다.
파일 삭제하기
Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다. 이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다.
Git 명령을 사용하지 않고 단순히 워킹 디렉터리에서 파일을 삭제하고 git status 명령으로 상태를 확인하면 Git은 현재 “Changes not staged for commit” (즉, Unstaged 상태)라고 표시해준다.
$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: PROJECTS.md
no changes added to commit (use "git add" and/or "git commit -a")
그리고 git rm 명령을 실행하면 삭제한 파일은 Staged 상태가 된다.
$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: PROJECTS.md커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않는다. 이미 파일을 수정했거나 Staging Area에(역주 - Git Index라고도 부른다) 추가했다면 -f 옵션을 주어 강제로 삭제해야 한다. 이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 커밋 하지 않고 수정한 데이터는 Git으로 복구할 수 없기 때문이다.
또 Staging Area에서만 제거하고 워킹 디렉토리에 있는 파일은 지우지 않고 남겨둘 수 있다. 다시 말해서 하드디스크에 있는 파일은 그대로 두고 Git만 추적하지 않게 한다. 이것은 .gitignore 파일에 추가하는 것을 빼먹었거나 대용량 로그 파일이나 컴파일된 파일인 .a 파일 같은 것을 실수로 추가했을 때 쓴다. --cached 옵션을 사용하여 명령을 실행한다.
$ git rm --cached README여러 개의 파일이나 디렉토리를 한꺼번에 삭제할 수도 있다. 아래와 같이 git rm 명령에 file-glob 패턴을 사용한다.
$ git rm log/\*.log* 앞에 \ 을 사용한 것을 기억하자. 파일명 확장 기능은 쉘에만 있는 것이 아니라 Git 자체에도 있기 때문에 필요하다. 이 명령은 log/ 디렉토리에 있는 .log 파일을 모두 삭제한다. 아래의 예제처럼 할 수도 있다.
$ git rm \*~이 명령은 ~ 로 끝나는 파일을 모두 삭제한다.
출처
https://bangu4.tistory.com/102
https://sabarada.tistory.com/71?category=792135