Git 기본 명령어 정리와 참고하면 좋은 링크 정보

 작년에 처음 Github를 알게 되면서 Git을 배워볼 기회가 있었다.
개인적으로 진행하는 스터디에 활용을 해보기는 했으나, 당시 회사에서 사용하는 버전관리 프로그램으로 SVN에서 머큐리얼(Mercurial)로 전환하는 시기였다.
그러다 보니 머큐리얼도 학습하게 되었고, 사용하게 되면서 당연히 Git보다는 머큐리얼을 사용하는 비중이 높아졌다.

 하지만 시간이 흐르면서 Github에서 소스 코드를 검색하고, 참고하는 빈도가 증가하는 것을 느끼게 되었다.
 그러면서 드는 생각이 올해는 내가 만든 소스 코드들을 Github에 올려서 전세계 개발자들과 공유하고, 평가 받으며(관심을 끌 수만 있다면..) 핵심적으로는 내가 열정을 갖고 진행하는 것들에 대한 증거를 남기고 싶다는 목표가 생기게 되었다.
 그래서 올 한해 계획을 세우면서 가장 먼저 배우고 능숙하게 다뤄야 하는 기술로 Git을 선정했고, 이번 포스트에서는 Git을 사용하기 위한 기본적인 명령어를 정리해 보았다.

 기본적인 명령어에 대한 구성은 웹 상에서 Git의 기본적인 명령어를 직접 실행해보고, 사용 방법을 배울 수 있는 Code School의 Try Git의 각 단계를 참고 하였다.

 각 명령어에 대한 설명은 Try Git에서 나오는 설명들을 기초로 하였고, 나름 번역을 해보았다.
 Git을 처음 접하는 사람들은 이 포스트를 보는 것 만으로 Git을 사용하기에는 많이 부족할 것이지만 Try Git을 단계별로 학습하면서 참고하면 좋을 것 같다.

Git의 고급 테크닉을 조금 더 능숙하게 다루기 위한 정보를 하나 더 추가 하자면 Git 브랜치 배우기를 추천한다.
Try Git에서 다루지 않지만 Git에서 좋다고 소문난 Rebase와 Cherry pick에 대한 학습에 많은 도움이 되었다.

---

Initializing

Initialize a Git repository

Git 저장소를 생성 한다.

git init

Checking the status

To see what the current state of our project

현재 상태를 확인 한다.

git status

Adding Changes

Notice how Git says 'untracked?' That means Git sees that this is a new file.

추적 되지 않은 새로운 파일이 있다는 의미 한다.

To tell Git to start tracking chang
es made to this file. we first need to add it to the staging area by using git add

파일의 변경 내역을 추적하기 위해 Git의 준비 영역으로 파일을 추가 할 필요가 있다.

git add octocat.txt
git add '*.txt'

Committing All Changes

Notice how Git says 'changes to be committed?' The file listed here are in the Staging Area, and they are not in our repository yet. We could add or remove files from the stage before we store them in the repository.

 git status 명령어로 현재 상태를 확인하면 'changes to be committed'라는 부분을 볼 수 있다.

 여기에 해당하는 파일 리스트는 아직 Git 저장소의 준비 영역에 있는 파일들의 목록이고, 저장소로 보내기 전에 준비 영역에서 추가 하거나 삭제 할 수 있다.

To store our staged changes we run the commit command with a message describing what we've chaged.

준비 영역에서 변경 내역을 저장소로 저장하기 위해서는 남길 메세지와 함께 commit 명령어를 사용한다.

git commit -m "Add cute octocat story"

History

Git's log as a journal that remembers all the changes we've committed so far, in the order we commited them.

Git 로그는 커밋 된 모든 변경 사항에 대한 기록 이다.

git log

Remote Repositories

To push our local repo to the GitHub server we'll need to add a remote repository.

로컬 저장소의 변경 내역을 Github 서버에 push 하기 위해서는 원격 저장소(중앙 저장소)를 추가 해야 한다.

git remote add origin https://github.com/try-git/try_git.git

Pushing Remotely

The push command our local changes to our origin repo (on Github)

push 명령어는 로컬 변경 내역을 origin 이라고 지정한 중앙 저장소로 보낸다.

The name of our remote is origin and the default local branch name is master.

origin은 원격(중앙) 저장소의 이름(닉네임 정도)이고, 기본 로컬 브랜치의 이름은 master 이다.

The '-u' thel Git to remember the parameters, so that next time we can simply run git push and Git will know what to do.

'-u' 파라미터를 추가하면 다음 push 명령어 실행부터는 중앙 저장소와 로컬 브랜치의 이름을 입력하지 않고도 push 할 수 있다.

git push -u origin master

Pulling Remotely

We can check for changes on our Github repository and pull down any new changes.

Github 서버의 변경 내역이 있는지 확인하기 위해서 pull 명령어를 사용해 새로운 변경 사항을 가져온다.

git pull origin master

Differences

Let's take a look at what is different from our last commit by using the git diff command.

로컬 저장소의 최종 커밋 로그와 차이점을 살펴보기 위해서 diff 명령어를 사용 한다.

In this case we want the diff of our most recent commit, which we can refer to using the HEAD pointer

가장 최근의 변경 내역을 비교하려면 HEAD 포인터를 사용해서 조회 할 수 있다.

git diff HEAD

Staged Differences

Another great use for diff is looking at changes within files that have already been staged.

diff는 이미 준비 영역에 있는 변경 내역과의 비교하기에도 좋다.

Staged files are files we have told git that are ready to committed.

준비 영역의 파일은 커밋 되기를 전의 파일을 말한다.

git diff --staged

Resetting the Stage

Unstage files by using the git reset command.

준비 영역의 파일을 삭제하려면 reset 명령어를 사용한다.

git reset octofamily/octodog.txt

브랜치로 하여금 예전의 커밋을 가리키도록 이동시키는 방식으로 변경 내용을 되돌린다. 이러한 관점에서 '히스토리를 고쳐쓴다.'라고 할 수 있다. 이것은 마치 애초에 커밋을 하지 않은 것처럼 예전 커밋으로 브랜치를 옮기는 것과 같다.

git reset HEAD~1

Undo

Files can be changed back to how they were at the last commit by using the command: git checkout -- <target>

마지막 커밋 된 파일로 교체하기 위해서 checkout 명령어를 사용한다.

git checkout -- octocat.txt

위 명령은 로컬의 변경 내용을 변경 전 상태(HEAD)로 돌려놓는다. 하지만 이미 준비 영역에 추가된 변경 내용과 새로 생성한 파일은 그대로 남는다.

Branching out

Code make separate commits to. Then when they're done they can merge this branch back into their main master branch.

새로운 코드는 새로운 브랜치에 커밋을 할 수 있다. 브랜치는 특정 커밋에 대한 참조(Reference)이며, 그 코드가 완료가 되면 다시 master 브랜치와 병합 할 수 있다.

Create a branch call.

branch는 새로운 브랜치를 만들기 위한 명령어 이다.

git branch clean_up

Delete a branch

branch를 삭제하려면 -d 파라미터를 추가하고 브랜치명을 입력 한다.

git branch -d clean_up

Switching Branches

다른 브랜치로 변경 하려면 checkout 명령어와 브랜치명을 같이 입력한다.

git checkout clean_up
git checkout -b clean_up

Removing all the things

Not only remove the actual files from disk, but will also stage the removal of the files for us.

rm은 준비 영역의 파일을 삭제 할 뿐만 아니라 실제 개발자 컴퓨터에 있는 파일도 삭제 된다.

removed all files you'll need to commit your changes.

파일을 삭제한 변경 내역도 커밋해야 한다.

git rm octodog.txt
git rm '*.txt'

Preparing to Merge

The moment has come when you have to merge your changes from the clean_up branch into the master branch.

별도 브랜치의 변경 내역으로부터 master 브랜치로 병합할 때가 오면 merge 명령어를 사용한다.

git merge clean_up

Rebase

브랜치끼리 작업을 접목하는 방법으로 rebase가 있다. 리베이는 기본적으로 커밋들을 모아서 복사한 뒤, 다른 곳으로 떨궈 놓는 것이다.

리베이스를 하면 커밋들의 흐름을 보기 좋게 한 줄로 만들 수 있다는 장점이 있다.

git rebase master

Revert

각자의 컴퓨터에서 작업하는 로컬 브랜치의 경우 reset을 잘 쓸 수 있지만, '히스토리를 고쳐쓴다'는 점 때문에 다른 사람이 작업하는 원격 브랜치에는 쓸 수 없다.

변경 내역을 되돌리고, 되돌린 내용을 다른 사람들과 공유하기 위해서는 revert를 사용해야 한다.

git revert HEAD

Push

All that's left to do is to push everything you've been working on to your remote repository.

모든 것이 완료 되면 원격(중앙) 저장소로 push 한다.

git push

---

참고하면 좋은 정보

http://rogerdudler.github.io/git-guide/index.ko.html
http://git-scm.com/book/ko
http://marklodato.github.io/visual-git-guide/index-ko.html