'PROJECT MANAGEMENT/SW Version Management'에 해당되는 글 7건

2013.03.14 GITHUB - git log 옵션
2013.03.14 GITHUB - 세가지 상태 (Local Area)
2013.02.20 GITHUB - 파일 수정하고 저장소에 저장하기
2009.03.31 SCM(source code management)
2009.03.31 CVS(concurrent Versions Sysgem)
2009.03.31 Microsoft Visual SourceSafe
2009.03.31 SVN(Subversion)

GITHUB - git log 옵션

PROJECT MANAGEMENT/SW Version Management 2013. 3. 14. 11:08

옵션 설명

-p 각 커밋에 적용된 패치를 보여준다.
--stat 각 커밋에서 수정된 파일의 통계정보를 보여준다.
--shortstat `--stat` 명령의 결과 중에서 수정한 파일, 추가된 줄, 삭제된 줄만 보여준다.
--name-only 커밋 정보중에서 수정된 파일의 목록만 보여준다.
--name-status 수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것
인지도 보여준다.
--abbrev-commit 40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다.
--relative-date 정확한 시간을 보여주는 것이 아니라 `2 주전`처럼 상대적인 형식으로 보여준다.
--graph 브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다.
--pretty 지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이 있다. format
은 원하는 형식으로 출력하고자 할 때 사용한다.

조회 제한 조건

-(n) 최근 n 개의 커밋만 조회한다.
--since, --after 명시한 날짜 이후의 커밋만 검색한다.
--until, --before 명시한 날짜 이전의 커밋만 조회한다.
--author 입력한 저자의 커밋만 보여준다.
--committer 입력한 커미터의 커밋만 보여준다.

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

GITHUB - 세가지 상태 (Local Area)

PROJECT MANAGEMENT/SW Version Management 2013. 3. 14. 10:09

세 가지 상태
Git은 파일을 Commited, Modified, Staged 이렇게 세 가지 상태로 관리한다.

Commited : 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.

Modified : 수정한 파일을 아직 로컬 데이터베이스에 Commit 하지 않은 것을 말한다.

Staged : 현재 수정 한 파일을 곧 Commit 할 것이라고 표시한 상태를 의미한다.

이 세 가지 상태는 Git 프로젝트의 세 가지 단계와 연결돼 있다.

Git Directory, Working Directory, Staging Area

Git Directory : Git이 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳 , Git의 핵심이다.

다른 컴퓨터에 있는 저장소를 Clone 할 때 Git Directory가 만들어진다.

Working Directory : 프로젝트의 특정 버전을 Checkout 한 것이다. Git Directory는 지금 작
업하는 디스크에 있고 그 Directory에 압축된 데이터베이스에서 파일을 가져와서 Working Directory를 만든다.

Staging Area : Git Directory에 있다. 단순한 파일이고 곧 Commit 할 파일에 대한 정보를 저장한다

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

GITHUB - 파일 수정하고 저장소에 저장하기

PROJECT MANAGEMENT/SW Version Management 2013. 2. 20. 16:31

파일을 수정하고 파일의 Snapshot을 커밋해 보자.

파일들을 수정하다가 저장하고 싶으면 Snapshot을 커밋한다.

작업 디렉토리의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)
로 나눈다. Tracked 파일은 이미 Snapshot에 포함돼 있던 파일이다. Tracked 파일들은 또
Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋을 하면 현재 수정 사항
을 저장소에 기록함) 상태 중 하나이다. 그리고 나머지 파일들은 모두 Untracked 파일이다.
Untracked 파일은 작업 디렉토리에 있는 모든 파일이 Snapshot에 포함돼 있는 것은 아니고
Staging Area에 있는 것도 아니다. 처음 저장소를 Clone하고 나면 모든 파일은 Tracked이면서
Unmodified 상태이다. Git은 저장소를 Clone하면 자동으로 파일을 Checkout하고 아직 아무것
도 편집하지 않은 상태다.
마지막 커밋 이후 아직 아무것도 수정하지 않은 상태에서 어떤 파일이 수정되면 Git은 그 즉시
파일을 Modified 상태로 인식한다. 그리고 이 수정한 파일을 Stage하고 Staged 상태인 파일들
을 커밋한다. 이 라이프사이클을 그림2.1처럼 계속 반복한다.

2.2.1 파일의 상태 확인하기
파일의 상태를 확인하려면 보통 git status 명령을 사용한다. Clone한 후에 바로 이 명령을 실
행하면 다음과 같은 메시지를 볼 수 있다:

$ git status
# On branch master
nothing to commit (working directory clean)

위의 내용은 파일을 하나도 수정하지 않았다는 것을 말해준다. 즉, Tracked와 Modified 상태
의 파일이 없다. Untracked 파일은 아직 없어서 목록에 나타나지 않는다. 그리고 현재 작업 중
인 브랜치를 알려준다. 기본 브랜치가 master이기 때문에 현재 master로 나오는 것이다. 브랜
치 관련 내용은 차차 알아가자. 다음 장에서 브랜치와 레퍼런스에 대해 자세히 다룬다.
프로젝트에 README 파일을 만들어보자. README 파일은 새로 만든 파일이기 때문에 git
status를 실행하면 Untracked에 들어 있다:

$ vim README
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# README
nothing added to commit but untracked files present (use "git add" to track)

README 파일은 Untracked files 부분에 속해 있는데 이것은 README 파일이 Untracked
상태라는 것을 말한다. Git은 Untracked 파일을 이전 Snapshot(커밋)에는 없는 파일이라고 본
다. Git은 파일이 Tracked 상태가 되기 전까지는 절대 그 파일들을 커밋하지 않는다. 그래서 일
하는 동안 생성된 파일인 바이너리 파일 같은 것을 커밋하는 실수는 하지 않게 된다. README
파일을 포함해 직접 Tracked 상태로 만들어 보자.

2.2.2 새 파일을 추적하기
git add 명령을 사용하여 새로운 파일을 추적할 수 있다. 다음 명령을 실행하면 Git은 README
파일을 추적한다:

$ git add README
git status 명령을 다시 실행하면 README 파일이 Tracked 상태이면서 Staged 상태라는 것
을 확인할 수 있다:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#

‘Changes to be committed’ 에 들어 있는 파일은 Staged 상태라는 것을 의미한다. 커밋하면
git add를 실행한 시점의 파일이 커밋되어 저장소 히스토리에 남는다. 앞에서 git init 명령
을 실행했을 때, 그 다음 git add (files) 명령을 실행했던 걸 기억할 것이다. 이것은 작업 디
렉토리에 있는 파일들을 추적하기 시작하게 하였다. git add 명령은 파일 또는 디렉토리의 경
로명을 인자로 받는다; 만일 디렉토리를 인자로 줄 경우, 그 디렉토리 아래에 있는 모든 파일들
을 재귀적으로 추가한다.

2.2.3 Modified 상태의 파일을 Stage하기

이미 Tracked 상태인 파일을 수정하는 법을 알아보자. benchmarks.rb라는 파일을 수정하고 나
서 git status 명령을 다시 실행하면 결과는 다음과 같다:

$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#

이 benchmarks.rb 파일은 Changed but not updated에 있다. 이것은 수정한 파일이 Tracked
상태이지만 아직 Staged 상태는 아니라는 것이다. Staged 상태로 만들려면 git add 명령을 실
행해야 한다. git add는 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만
드는데에도 사용한다. git add를 실행하여 benchmarks.rb 파일을 Staged 상태로 만들고 git
status 명령으로 결과를 확인해보자:

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#

두 파일 모두 Staged 상태이므로 다음 커밋에 포함된다. 하지만, 아직 더 수정해야 한다는 것을
알게 되어 바로 커밋하지 못하는 상황이 되었다고 하자. 이 상황에서 benchmark.rb 파일을 열
고 수정한다. 이제 아마 당신은 커밋할 준비가 다 됐다고 생각할 것이다. 하지만, Git에게는 그
렇지 않다. git status 명령으로 파일의 상태를 다시 확인해보자

$ vim benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: benchmarks.rb
#

헉! benchmarks.rb가 Staged 상태이면서 동시에 Unstaged 상태로 나온다. 어떻게 이런 일이
가능할까? git add 명령을 실행하면 Git은 파일을 바로 Staged 상태로 만든다. 지금 이 시점에
서 커밋을 하면 git commit 명령을 실행하는 시점의 버전이 커밋되는 것이 아니라 마지막으로
git add 명령을 실행했을 때의 버전이 커밋된다. 그러니까 git add 명령을 실행 후에 또 파일
을 수정하면 git add 명령을 다시 실행하여 최신 버전을 Staged 상태로 만들어야 한다:

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README
# modified: benchmarks.rb
#

2.2.5 Staged와 Unstaged 상태의 변경 내용을 보기

단순히 파일이 변경됐다는 사실이 아니라 어떤 내용이 변경됐는지 살펴보기엔 git status 명
령은 부족해서 git diff 명령을 사용해야 한다. 일반적으로 우리는 ’수정했지만, 아직 Staged
파일이 아닌것?’과 ’어떤 파일이 Staged 상태인지?’가 궁금하기 때문에 git status 명령으로도
충분하다. git diff는 Patch처럼 어떤 라인을 추가했고 삭제했는지 알아야 할 때에 사용한다.
git diff는 나중에 더 자세히 다룬다.

README 파일을 수정하고 Staged 상태로 만들어 보자. benchmarks.rb 파일은 그냥 수정만
해둔다. 이 상태에서 git status 명령을 실행하면 다음과 같은 메시지를 볼 수 있다:

git diff 명령을 실행하면 수정했지만 아직 staged 상태가 아닌 파일을 비교해 볼 수 있다:

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..da65585 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]
end
+ run_code(x, 'commits 1') do
+ git.commits.size
+ end
+
run_code(x, 'commits 2') do
log = git.commits('master', 15)
log.size

이 명령은 작업 디렉토리에 있는 것과 Staging Area에 있는 것을 비교한다. 그래서 수정하고 아
직 Staged 상태가 아닌 것들을 보여준다.
만약 커밋하려고 Staging Area에 넣은 파일의 변경 부분을 보고 싶으면 git diff --cached 옵
션을 사용한다(Git 버전 1.6.1부터는 좀 더 기억하기 쉽게 git diff --staged로도 사용할 수
있다). 이 명령은 Staging Area와 저장소에 커밋한 것을 비교한다:

$ git diff --cached
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README2
@@ -0,0 +1,5 @@
+grit

꼭 잊지 말아야 할 것이 있는데 git diff 명령은 마지막으로 커밋한 후에 수정한 것을 보여주
지 않는다. git diff는 Unstaged 상태인 것들만 보여준다. 이 부분은 조금 헷갈릴 수도 있는데,
수정한 파일을 모두 Staging Area에 넣었다면 git diff 명령은 아무것도 출력하지 않는다.
benchmarks.rb 파일을 Stage한 후 다시 수정해도 git diff 명령을 사용할 수 있다. 이 경우
Staged 상태인 것과 Unstaged 상태인 것을 비교한다:

$ git add benchmarks.rb
$ echo '# test line' >> benchmarks.rb
$ git status
# On branch master
#
# Changes to be committed:
#
# modified: benchmarks.rb
#
# Changed but not updated:
#
# modified: benchmarks.rb
#

git diff 명령으로 Unstaged 상태인 변경 부분을 확인해 볼 수 있다:

$ git diff
diff --git a/benchmarks.rb b/benchmarks.rb
index e445e28..86b2f7c 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -127,3 +127,4 @@ end
main()
##pp Grit::GitRuby.cache_client.stats
+# test line

Staged 상태인 파일은 git diff --cached 옵션으로 확인한다:

$ git diff --cached
diff --git a/benchmarks.rb b/benchmarks.rb
index 3cb747f..e445e28 100644
--- a/benchmarks.rb
+++ b/benchmarks.rb
@@ -36,6 +36,10 @@ def main
@commit.parents[0].parents[0].parents[0]

2.2.6 변경사항 커밋하기

수정한 것을 커밋하기 위해 Staging Area에 파일을 정리했다. Unstaged 상태의 파일은 커밋되
지 않는다는 것을 기억해야 한다. Git은 생성하거나 수정하고 나서 git add 명령으로 추가하지
않은 파일은 커밋하지 않는다. 그 파일은 여전히 Modified 상태로 남아 있다.
커밋하기 전에 git status 명령으로 모든 것이 Staged 상태인지 확인할 수 있다. 그리고 git
commit을 실행하여 커밋한다:

$ git commit

Git 설정에 지정된 편집기가 다음과 같이 실행되고, 다음과 같은 텍스트가 자동으로 포함된다
(아래 예제는 Vim 편집기의 화면이다). 이 편집기는 쉘의 $EDITOR 환경 변수에 등록된 편
집기이고 보통은 Vim이나 Emacs을 사용한다. 또1장에서 설명했듯이 git config --global
core.editor 명령으로 어떤 편집기를 사용할지 설정할 수 있다:
편집기는 아래와 같은 내용을 표시한다(아래 예제는 Vim 편집기의 경우):

자동으로 생성되는 커밋 메시지는 첫 줄은 비어 있고 둘째 줄부터 git status 명령의 결과가
채워진다. 커밋한 내용을 쉽게 기억할 수 있도록 이 메시지를 포함할 수도 있고 메시지를 전부
지우고 새로 작성할 수 있다(수정한 내용을 좀 더 구체적으로 남겨 둘 수 있다. git commit에
-v 옵션을 추가하면 편집기에 diff 메시지도 추가된다).
메시지를 인라인으로 첨부할 수도 있다. commit 명령을 실행할 때 다음과 같이 -m 옵션을 사용
한다:

$ git commit -m "Story 182: Fix benchmarks for speed"
[master]: created 463dc4f: "Fix benchmarks for speed"
2 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 README

commit 명령은 몇 가지 정보를 출력하는데 위 예제는 master 브랜치에 커밋했고 체크섬은
463dc4f이라고 알려준다. 그리고 수정한 파일이 몇 개이고 삭제됐거나 추가된 줄이 몇 줄인지
알려준다.
Git은 Staging Area에 속한 Snapshot을 커밋한다는 것을 기억해야 한다. 수정은 했지만, 아직
Staging Area에 넣지 않은 것들은 다음에 커밋할 수 있다. 커밋할 때마다 프로젝트의 Snapshot
을 기록하기 때문에 나중에 Snapshot끼리 비교하거나 예전 Snapshot으로 되돌릴 수 있다.

2.2.7 Staging Area 생략하기

Staging Area는 커밋할 파일들을 정리한다는 점에서 매우 유용하지만 복잡하기만 하고 필요하
지 않은 때도 있다. 아주 쉽게 Staging Area를 생략할 수 있다. git commit 명령을 실행할 때 -a
옵션을 추가하면 Git은 Tracked 상태의 파일이라면 자동으로 Staging Area에 넣는다. 그래서
git add 명령을 실행하는 수고를 덜 수 있다:

$ git status
# On branch master
#
# Changed but not updated:
#
# modified: benchmarks.rb
#
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
1 files changed, 5 insertions(+), 0 deletions(-)

이 예제에서는 커밋하기 전에 git add 명령으로 benchmarks.rb 파일을 추가하지 않았다는 점
을 눈여겨보자.

Prodit.ko.pdf 파일 참조

정리된 사이트 : http://blog.naver.com/hoi5man?Redirect=Log&logNo=60173770303

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

SCM(source code management)

PROJECT MANAGEMENT/SW Version Management 2009. 3. 31. 10:17

Revision control

.

Revision control (also known as version control, source control or (source) code management (SCM)) is the management of changes to documents, programs, and other information stored as computer files. It is most commonly used in software development, where a team of people may be changing the same files. Changes are usually identified by a number or letter code, termed the "revision number", "revision level", or simply "revision". For example, an initial set of files is "revision 1". When the first change is made, the resulting set is "revision 2", and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.

Version control systems (VCS) are most commonly stand-alone applications, but revision control is also embedded in various types of software like word processors (e.g. Microsoft Word, OpenOffice.org Writer, KOffice, Pages, Google Docs), spreadsheets (e.g. OpenOffice.org Calc, Google Spreadsheets, Microsoft Excel), and in various content management systems. Integrated revision control is a key feature of wiki software packages such as MediaWiki, DokuWiki, TWiki, etc. In wikis, revision control allows for the ability to revert a page to a previous revision, which is critical for allowing editors to track each other's edits, correct mistakes, and defend public wikis against vandalism and spam.

Software tools for revision control are increasingly recognized as being necessary for the organization of multi-developer projects.^[1]

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

CVS(concurrent Versions Sysgem)

PROJECT MANAGEMENT/SW Version Management 2009. 3. 31. 08:53

Concurrent Versions System

In the field of software development, the Concurrent Versions System (CVS), also known as the Concurrent Versioning System, is a free software revision control system. Version control system software keeps track of all work and all changes in a set of files, and allows several developers (potentially widely separated in space and/or time) to collaborate. Dick Grune developed CVS in the 1980s. CVS has become popular in the open source software world and is released under the GNU General Public License.

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

Microsoft Visual SourceSafe

PROJECT MANAGEMENT/SW Version Management 2009. 3. 31. 08:50

Microsoft Visual SourceSafe

From Wikipedia, the free encyclopedia

Microsoft Visual SourceSafe (VSS) is a source control software package oriented towards small software development projects. Like most source control systems, SourceSafe creates a virtual library of computer files. While most commonly used for source code, SourceSafe can actually handle any type of file in its database, but prior versions have been shown to be unstable when confronted with large amounts of non-textual data (images, binary executables, etc).

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

SVN(Subversion)

PROJECT MANAGEMENT/SW Version Management 2009. 3. 31. 08:48

Subversion (software)

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Subversion

Developed by	CollabNet
Initial release	October 20, 2000 (2000-10-20)
Stable release	1.6.0 (2009-03-20; 10 days ago) _[+/−]
Written in	C
OS	Cross-platform
Type	Revision control
License	Apache License
Website	http://subversion.tigris.org/

Subversion (SVN) is a version control system initiated in 2000 by CollabNet Inc. It is used to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS).

Subversion is well-known in the open source community and is used on many open source projects, including Apache Software Foundation, KDE, GNOME, Free Pascal, FreeBSD, GCC, Python, Django, Ruby, Mono, SourceForge.net, ExtJS and Tigris.org. Google Code also provides Subversion hosting for their open source projects. BountySource systems use it exclusively. Codeplex offers access to both subversion as well as other types of clients.

Subversion is also being adopted in the corporate world. In a 2007 report by Forrester Research, Subversion was recognized as the sole leader in the Standalone Software Configuration Management (SCM) category and a strong performer in the Software Configuration and Change Management (SCCM) category.^[1]

Subversion is released under the Apache License, making it free software.

저작자표시 비영리

파란실버라이트

To remember the time when I started learning Silver Light!

'PROJECT MANAGEMENT/SW Version Management'에 해당되는 글 7건

GITHUB - git log 옵션

GITHUB - 세가지 상태 (Local Area)

GITHUB - 파일 수정하고 저장소에 저장하기

SCM(source code management)

Revision control

.

CVS(concurrent Versions Sysgem)

Concurrent Versions System

Microsoft Visual SourceSafe

Microsoft Visual SourceSafe

From Wikipedia, the free encyclopedia

SVN(Subversion)

Subversion (software)

From Wikipedia, the free encyclopedia

카테고리

태그목록

최근에 받은 트랙백

글 보관함

링크

파란실버라이트

LATEST FROM OUR BLOG

LATEST COMMENTS

BLOG VISITORS

티스토리툴바