자격증/정보처리기사 📌 제품 소프트웨어 패키징 - 사용자 매뉴얼 작성/버전 등록/버전 관리 도구
  • 728x90
    반응형

     

    목차

       

      소프트웨어 사용자 매뉴얼 작성의 개요

      📌 소프트웨어 사용자 매뉴얼은 사용자가 소프트웨어를 사용하는 과정에서 필요한 내용을 문서로 기록한 설명서와 안내서이다.

       

      • 사용자 매뉴얼은 사용자가 소프트웨어 사용에 필요한 절차, 환경 등의 제반 사항이 모두 포함되도록 작성한다.
      • 소프트웨어 배포 후 발생될 수 있는 오류에 대한 패치나 기능에 대한 업그레이드를 위해 매뉴얼의 버전을 관리한다.
      • 개별적으로 동작이 가능한 컴포넌트 단위로 매뉴얼을 작성한다.
      • 사용자 매뉴얼은 컴포넌트 명세서와 컴포넌트 구현 설계서를 토대로 작성한다.
      • 사용자 매뉴얼에는 목차 및 개요, 서문, 기본 사항 등이 기본적으로 포함되어야 한다.
      • 사용자 매뉴얼의 목차에는 매뮤얼 전체 내용을 순서대로 요약한 후 관련 내용의 시작 페이지를 함께 기술한다.
      • 사용자 매뉴얼의 개요에는 소프트웨어의 주요 특징, 매뉴얼의 구성과 실행 방법, 사용법, 항목별 점검 기준, 항목별 설정 방법 등에 대한 내용을 기술한다.

       

      💡 컴포넌트(Component) ? 컴포넌트는 독립적인 업무 또는 기능을 수행하는 단위이며, 실행 코드 기반으로 작성된 모듈이다. 
      💡 컴포넌트 명세서 ? 컴포넌트 명세서는 컴포넌트의 개요 및 내부 클래스의 동작, 외부와의 통신 명세 등을 정의한 문서이다.
      💡 컴포넌트 설계서 ? 컴포넌트 설계서는 컴포넌트 구현에 필요한 컴포넌트 구조도 컴포넌트 목록, 컴포넌트 명세, 인터페이스 명세로 구성된 설계서이다.

       

       

      서문

      📌 서문에는 문서 이력, 사용자 매뉴얼의 주석, 기록 보관을 위해 필요한 내용을 기술한다.

       

      • 문서 이력
      버전 작성자 작성일 검토자 일시 검수인
      v0.1 홍길동 2024-01-06 강감찬 2024-02-05 신세경
      변경 내용 최초 작성
      v0.1 홍길동 2024-02-10 강감찬 2024-03-05 신세경
      변경 내용 제품 등록 방법 변경

       

      • 설치 매뉴얼의 주석 : 주의 사항과 참고 사항을 기술한다.
        • 주의 사항 : 소프트웨어를 사용할 때 사용자가 반드시 알고 있어야 하는 중요한 내용을 기술한다.
        • 참고 사항 : 특별한 사용자의 환경이나 상황에 대한 내용을 기술한다.
      • 기록 보관 내용
        • 소프트웨어를 사용하면서 필요한 기술 지원이나 추가 정보를 얻기 위한 소프트웨어 등록 정보를 기술한다.
        • 소프트웨어 등록시 필요한 정보는 소프트웨어 명칭, 모델명, 문서 번호, 제품번호, 구입 날짜 등이다.

       

      기본 사항

      📌 소프트웨어와 관련하여 기본적으로 설명되어야 할 항목들은 다음과 같다.

       

      항목 설명
      소프트웨어 개요 - 소프트웨어의 주요 기능 및 UI 설명
      - UI 및 화면 상의 버튼, 프레임 등을 그림으로 설명
      소프트웨어 사용 환경 - 소프트웨어 사용을 위한 최소 환경 설명
      - CPU, 메모리 등의 PC 사양, 운영체제(OS) 버전 설명
      - 최초 구동에 대한 설명
      - 소프트웨어 사용 시 발생할 수 있는 프로그램 충돌이나 개인정보 보안 등에 관한 주의사항을 설명한다.
      소프트웨어 관리 소프트웨어의 사용 종료 및 관리 등에 관한 내용 설명
      모델, 버전별 틍직 모델 및 버전별로 UI 및 기능의 차이점을 간략하게 요약한다.
      기능, 인터페이스의 특징 제품의 기능과 인터페이스의 특징을 간략하게 요약한다.
      소프트웨어 구동 환경 - 개발에 사용한 언어 및 호환 가능한 운영체제(OS)에 대해 설명한다.
      - 설치 후 구동하기까지의 과정을 운영체제(OS)별로 설명한다.

       

       

      사용자 매뉴얼 작성 방법

      📌 사용자 매뉴얼은 사용자가 사용 방법을 이해하기 쉽도록 상황 별로 누락 없이 캡처하여 순서대로 상세히 설명한다.

       

      • 사용자 매뉴얼에는 사용자 화면 및 UI, 주요 기능 분류, 응용 프로그램 및 설정, 장치 연동, Network 환경, Profile 안내, 고객 지원 방법, 준수 정보 및 제한 보증 등에 대한 내용을 기술한다.
      • 사용자 화면 및 UI
        • 주의 사항과 참고 사항을 기술한다.
        • 주의 사항 : 소프트웨어를 사용할 때 사용자가 반드시 알고 있어야 하는 중요한 내용을 설명한다.
        • 참고 사항 : 특별한 사용자의 환경이나 상황에 대한 내용을 설명한다.
      • 주요 기능 분류
        • 기능이 실행되는 화면을 순서대로 캡처하여 기능에 대한 사용법을 설명한다.
        • 기능이 구현되는 과정에서 참고할 사항이나 주의할 사항에 대한 메모를 추가한다.
      • 응용 프로그램(Program) 및 설정(Setting)
        • 소프트웨어 구동 시 함께 실행해도 되는 응용 프로그램, 또는 함께 실행되면 안 되는 응용 프로그램에 대해 설명한다.
        • 소프트웨어가 구동될 때 먼저 실행되어야 할 응용 프로그램이 있다면 설명한다.
        • 소프트웨어가 정상적으로 구동되기 위한 설정(Setting)이나 기본값에 대해 설명한다.
      • 장치 연동
        • 소프트웨어가 특정 장치(Device)에 내장되는 경우 연동되는 장치(Device)에 대해 설명한다.
      • Network 환경
        • Network에 접속되어 사용되는 소프트웨어인 경우 정상적인 연결을 위한 설정 값 등을 설명한다.
      • Profile 안내
        • Profile은 소프트웨어의 구동 환경을 점검하는 파일로, 사용자가 Profile의 경로를 변경하거나 위치를 이동하지 않도록 안내한다.
        • Profile과 같이 소프트웨어 구동에 필수적인 파일에 대해 설명한다.
      • 고객 지원 방법(Customer Support)
        • 사용과 관련하여 기술적인 지원이나 소프트웨어에 대한 서비스를 원할 경우 국가, 웹 사이트, 전화번호, 이메일 등 문의할 수 있는 연락처를 안내한다.
      • 준수 정보 & 제한보증(Compliance Information & Limited Warrnaty)
        • Serial 보존, 불법 등록 사용 금지 등에 대한 준수 사항을 안내한다.
        • 저작권자 소유권 정보, SW 허가권 정보, 통신 규격, 개발 언어, 연동 프로그램, 문서 효력, 지적 소유권 정보 등과 관련된 정보를 안내한다.

       

      사용자 매뉴얼 작성 순서

      📌 소프트웨어 사용자 매뉴얼을 다음과 같은 순서로 작성한다.

       

      1. 작성 지침 정의 : 사용자 매뉴얼을 작성하기 위한 지침을 기록한다. 작성 지침은 사용자 환경에 필요한 정보를 제공할 수 있는 형태로 기록한다.
      2. 사용자 매뉴얼 구성 요소 정의 : 소프트웨어의 기능, 구성 객체 목록, 객체별 메소드, 메소드의 파라미터, 실제 사용 예, 사용자 환경 셋팅 방법 등을 기록한다.
      3. 구성 요소별 내용 작성 : 사용자 매뉴얼 구성 요소별로 내용을 기록한다.
      4. 사용자 매뉴얼 검토 : 작성된 구성 요소별 내용이 올바른지, 부족한 부분은 없는지 등을 검토하여 수정 및 보완한다.

       

       

      소프트웨어 패키징의 형상 관리

      📌 형상 관리(SCM : Software Configuration Management)는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동이다.

       

      • 소프트웨어 변경의 원인을 알아내고 제어하며, 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보한다.
      • 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지보수 단계에서도 수행된다.
      • 형상 관리는 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 한다.
      • 관리 항목에는 소스 코드뿐만 아니라 프로젝트 계획, 분석서, 설계서, 프로그램, 테스트 케이스 등이 포함된다.
      • 형상 관리를 통해 가시성과 추적성을 보장함으로써 소프트웨어의 생산성과 품질을 높일 수 있다.
      • 대표적인 형상 관리 도구에는 Git, CVS, SVN 등이 있다.

       

      💡 형상 ? 소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램, 프로그램을 설명하는 문서 데이터 등을 통칭하는 말이다.
      💡 Git : Git은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작옵을 조율하기 위한 분산 버전 관리 시스템이다.
      💡 CVS(Concurrent Versions System) : 특수한 저장소에서 동일한 소프트웨어 프로젝트의 다른 버전을 관리하도록 설계된 오픈 소스 소프트웨어 구성 관리 유틸리티이다.
      💡 SVN은 SubVersion의 줄일말로 중앙 집중 관리식 형상관리 소스 관리 툴이다.

       

       

      형상 관리의 중요성

      • 지속적인 소프트웨어의 변경 사항을 체계적으로 추적하고 통제할 수 있다.
      • 제품 소프트웨어에 대한 무절제한 변경을 방지할 수 있다.
      • 제품 소프트웨어에서 발견된 버그나 수정 사항을 추적할 수 있다.
      • 소프트웨어는 형태가 없어 가시성이 결핍되므로 진행 정도를 확인하기 위한 기준으로 사용될 수 있다.
      • 소프트웨어의 배포본을 효율적으로 관리할 수 있다.
      • 소프트웨어를 여러 명의 개발자가 동시에 개발할 수 있다.

       

      💡 가시성(Visibility) ? 일반적으로 가시성이란 대상을 확인할 수 있는 정도를 의미한다.

       

       

      형상 관리 기능

      📌 형상 관리는 품질 보증을 위한 중요한 요소로서 다음과 같은 기능을 수행한다.

      • 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업
      • 버전 제어 : 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리 하고, 이를 위해 특정 절차와 도구(Tool)를 결합시키는 작업
      • 형상 통제(변경 관리) : 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선(Base Line)이 잘 반영될 수 있도록 조정하는 작업
      • 형상 검사 : 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
      • 형상 기록(상태 보고) : 형상의 식별, 통제 감사 작업의 결과를 기록, 관리하고 보고서를 작성하는 작업

       

      💡 기준선(Base Line, 변경 통제 시점) ? 기준선은 정식으로 검토되고 합의된 명세서나 제품으로, 소프트웨어 개발 시 소프트웨어 변경을 적절히 제어할 수 있도록 도와준다.

      💡 무결성 ? 결점이 없다는 것으로, 정해진 기준에 어긋나지 않고 조건을 충실히 만족하는 정도라고 이해할 수 있다.

       

       

      소프트웨어의 버전 등록 관련 주요 기능

      📌 소프트웨어  개발 과정에서 코드와 라이브러리, 관련 문서 등의 버전을 관리하기 위해 자료를 등록하고 갱신하는 과정에서 사용되는 주요 용어와 의미는 다음과 같다.

       

      항목 설명
      저장소(Repository) 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳이다.
      가져오기(Import) 버전 관리가 되고 있지 않은 아무것도 없는 저장소(Repository)에 처음으로 파일을 복사한다.
      체크아웃(Check-Out) - 프로그램을 수정하기 위해 저장소(Repository)에서 파일을 받아온다.
      - 소스 파일과 함께 버전 관리를 위한 파일들도 받아온다.
      체크인(Check-In) 체크아웃 한 파일의 수정을 완료한 후 저장소(Repository)의 파일을 새로운 버전으로 갱신한다.
      커밋(Commit) 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에는 충돌(Conflict)을 알리고 diff도구를 이용해 수정한 후 갱신을 완료한다.
      동기화(Update) 저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화 한다.

       

      💡 diff 도구 ? 비교 대상이 되는 파일들의 내용(소스 코드)을 비교하며 서로 다른 부분을 찾아 표시해 주는 도구이다.

       

       

      소프트웨어 버전 등록 과정

      📌 소프트웨어 버전 등록은 다음과 같은 순서로 진행한다.

       

      1. 가져오기(Import) : 개발자가 저장소에 신규로 파일을 추가한다.
      2. 인출(Check-Out) : 수정 작업을 진행할 개발자가 저장소에 추가된 파일을 자신의 작업 공간으로 인출 한다.
      3. 예치(Commit) : 인출한 파일을 수정한 후 설명을 붙여 저장소에 예치한다.
      4. 동기화(Update) : 커밋(Commit) 후 새로운 개발자가 자신의 작업 공간을 동기화(Update) 한다. 이때 기존 개발자가 추가했던 파일이 전달된다.
      5. 차이(Diff) : 새로운 개발자가 추가된 파일의 수정 기록(Change Log)을 확인하면서 이전 개발자가 처음 추가한 파일과 이후 변경된 파일의 차이를 확인한다.

       

      💡 버전 관리 프로그램에 따라 방법은 다를 수 있지만, diff <commit> <commit2> 와 같이 지정하면, 지정한 두 커밋(Commit) 사이의 수정 내역을 확인할 수 있다. 이와 가이 이전 개발자들의 수정 내역을 확인하고 싶을 때 diff 명령을 사용한다.

       

       

      🎯 소프트웨어 버전 관리 도구

       

      공유 폴더 방식

      📌 공유 폴더 방식은 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식으로, 다음과 같은 특징이 있다.

       

      • 개발자들은 개발이 완료된 파일을 약속된 공유 폴더에 매알 복사한다.
      • 담당자는 공유 폴더의 파일을 자기 PC로 복사한 후 컴파일 하여 이상 유무를 확인한다.
      • 이상 유무 확인 과정에서 파일의 오류가 확인되면, 해당 파일을 등록한 개발자에게 수정을 의회한다.
      • 파일에 이상이 없다면 다음날 각 개발자들이 동작 여부를 다시 확인한다.
      • 파일을 잘못 복사하거나 다른 위치로 복사하는 것에 대비하기 위해 파일의 변경 사항을 데이터베이스에 기록하여 관리한다.
      • 종류에는 SCCS, RCS, QVCS 등이 있다.

       

      💡 RCS(Revision Control System) : 여러 개발자가 프로젝트를 수행할 때 시간에 따른 파일 변화 과정을 관리하는 소프트웨어 버전 관리 도구로 소스 파일을 동시에 수정하는 것을 방지하고 다른 방향으로 진행된 개발 결과를 합치거나 변경 내용을 추적할 수 있다.
      💡 QVCS : Quma Software에서 발표한 버전 제어 시스템 제품군이다.

       

       

      클라이언트/서버 방식

      📌 클라이언트/서버 방식은 버전 관리 자료가 중앙 시스템(서버)에 저장되어 관리되는 방식으로, 다음과 같은 특징이 있다.

       

      • 서버의 자료를 개발자 별로 자신의 PC(클라이언트)로 복사하여 작업한 후 변경된 내용을 서버에 반영한다.
      • 모든 버전 관리는 서버에서 수행된다.
      • 하나의 파일을 서로 다른 개발자가 작업할 경우 경고 메시지를 출력한다.
      • 서버에 문제가 생기면, 서버가 복구되기 전까지 다른 개발자와의 형업 및 버전 관리 작업은 중단된다.
      • 종류에는 CVS, SVN(Subversion), Clear Case, Perforce 등이 있다.

       

      💡 CVS(Concurrent Versions System) ? 특수한 저장소에서 동일한 소프트웨어 프로젝트의 다른 버전을 관리하도록 설계된 오픈 소스 소프트웨어 구성 관리 유틸리티이다.
      💡 SVN ? SubVersion의 줄임말로 중앙 집중 관리식 형상관리 소스 관리 툴이다.
      💡 CVSNT ? 협업 프로그래밍을 하는 서버
      💡 Clear Case ? 모든 종류의 파일과 디렉터리에 대한 버전 관리 기능을 제공한다.
      💡 Perforce ? 소스 버전 관리 툴의 일종이다.

       

       

      분산 저장소 방식

      📌 분산 저장소 방식은 버전 관리 자료가 하나의 원격 저장소와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리되는 방식으로, 다음과 같은 특징이 있다.

       

      • 개발자 별로 원격 저장소의 자료를 자신의 로컬 저장소로 복사하여 작업한 후 변경된 내용을 로컬 저장소에서 우선 반영(버전 관리) 한 다음 이를 원격 저장소에 반영한다.
      • 로컬 저장소에서 버전 관리가 가능하므로 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용하여 작업할 수 있다.
      • 종류에는 Git, GNU arch 등이 있다.

       

      💡 Git ? Git은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.
      💡 GNU arch ? 분산형 리비전 관리 소프트웨어의 일종으로 소스 트리에서 일어나는 변경들을 추적하며 통합을 비롯해 여러 사람에 의해 또는 서로 다른 여러 시간대에 일어나는 변화들을 처리하는 도구이다.

       

       

      Subversion (서브버전, SVN)

      📌 Subversion은 CVS를 개선한 것으로, 아파치 소프트웨어 재단에서 2000년에 발표하였다.

       

      • 클라이언트/서버 구조로, 서버(저장소, Rpository)에는 최신 버전의 파일들과 변경 내역이 관리 된다.
      • 서버의 자료를 클라이언트로 복사해와 작업한 후 변경 내용을 서버에 반영(Commit)한다.
      • 모든 개발 작업은 trunk 디렉터리에서 수행되며, 추가 작업은 branches 디렉터리 안에 별도의 디렉터리를 만들어 작업을 완료한 후 trunk 디렉터리와 병합(merge) 한다.
      • 커밋(Commit)할 때마다 리비전(Revision)이 1씩 증가한다.
      • 클라이언트는 대부분 운영체제에서 사용되지만, 서버는 주로 유닉스를 사용한다.
      • 소스가 오픈 되어 있어 무료로 사용할 수 있다.
      • CVS의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능하다.

       

      💡 trunk ? trunk는 '몸통', '줄기'라는 의미로 개발 과정에서 가장 중심이 되는 디렉터리이다. trunk 디렉터리 안에 소스 파일과 추가 작업을 위한 서브 디렉터리인 branches 디렉터리가 있다.
      💡 branches ? '가지', '부문' 이라는 의미로 메인 개발 과정과는 별도로 새로운 기능의 테스트와 같이 추가적인 작업을 수행하기 위한 디렉터리이다. branches 디렉터리 하위에 작업 별로 디렉터리를 만들어 그 안에서 개발을 진행한다. 이후 별도의 디렉터리 에서 진행된 개발 결과를 trunk와 병합할 수 있다.
      💡 리비전 ? 커밋의 버전으로, 처음 저장소를 만들면 리비전은 0이 된다. 이후 커밋이 수행될 때마나 리비전이 1씩 증가한다.

       

      • 다음은 Subversion의 주요 명령어 이다.
      명령어 의미
      add - 새로운 파일이나 디렉터리를 버전 관리 대상으로 등록한다.
      - add로 등록되지 않은 대상은 commit이 적용되지 않는다
      commit 버전 관리 대상으로 등록된 클라이언트의 소스 파일을 서버의 소스 파일에 적용한다.
      update - 서버의 최신 commit 이력을 클라이언트의 소스 파일에 적용한다.
      - commit전에는 매번 update를 수행하여 클라이언트에 적용되지 않은 서버의 변동 내역을 클라이언트에 적용한다.
      checkout 버전 관리 정보와 소스 파일을 서버에서 클라이언트로 받아온다.
      lock/unlock 서버의 소스 파일이나 디렉터리를 잠그거나 해제한다.
      import 아무것도 없는 서버의 저장소에 맨 처음 소스 파일을 저장하는 명령으로 한 번 사용하면 다시 사용하지 않는다.
      export 버전 관리에 대한 정보를 제외한 순수한 소스 파일만을 서버에서 받아온다.
      info 지정된 파일에 대한 위치나 마지막 수정 일자 등에 대한 정보를 표시한다.
      diff 지정된 파일이나 경로에 대해 이전 리비전과의 차이를 표시한다.
      merge 다른 디렉터리에서 작업된 버전 관리 내역을 기본 개발 작업과 병합한다.

       

      • Subversion을 이용한 버전 관리

       

      💡 Subversion을 이용해 버전 관리 작업을 시작할 때는 먼저 'import' 명령으로 모든 소스 파일을 서버에 등록한다. 이후 버전 관리는 'checkout' > 작업 > add > update > commit' 과정으로 진행한다. 나머지 명령은 작업 과정이나 자료 송수신 과정 에서 필요에 의해 수행된다.

       

       

      Git (깃)

      📌 Git은 리누스 토발즈(Linus Torvalds)가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마노(Junio Hamano)에 의해 유지 보수되고 있다.

       

      • Git은 분산 버전 관리 시스템으로 2개의 저장소, 즉 지역(로컥) 저장소와 원격 저장소가 존재한다.
      • 지역 저장소는 개발자들이 실제 개발을 진행하는 장소로, 버전 관리가 수행된다.
      • 원격 저장소는 여러 사람들이 협업을 위해 버전을 공동 관리하는 곳으로, 자신의 버전 관리 내역을 반영하거나 다른 개발자의 변경 내용을 가져올 때 사용한다.
      • 버전 관리가 지역 저장소에서 진행되므로 버전 관리가 신속하게 처리되고, 원격 저강소나 네트워크에 문제가 있어도 작업이 가능하다.
      • 브랜치를 이용하면 기본 버전 관리 틀에 영향을 주지 않으면서 다양한 형태의 기능 테스팅이 가능하다.
      • 파일의 변화를 스냅샷(Snapshot)으로 저장하는데, 스냅샷은 이전 스냅샷의 포인터를 가지므로 버전의 흐름을 파악할 수 있다.

       

      💡 브랜치(Branch) ? Git에서는 저장소가 처음 만들어지면 마스터(Maste) 브랜치가 생성되고 브랜치에서 기본적인 버전 관리가 진행된다. 새로운 기능을 추가하는 작업은 새로운 브랜치를 만들어 작업을 수행하며, 작업이 정상적으로 마무리되면 작업 내역을 마스터 브랜치에 병합한다. 이렇게 마스터 브랜치와 별도로 생성하는 브랜치를 토픽(Topic) 브랜치 또는 피어(Feature) 브랜치라고 한다. 각각의 브랜치는 다른 브랜치에 영향을 주지 않으므로 독립적인 여러 작업을 동시에 진행할 수 있다.
      💡 스냅샷(Snapshot) ? 스냅샷은 영문자와 숫자가 혼합된 40자리 문자열로 표시된다.

       

      • 다음은 Git의 주요 명령어이다.
      명령어 의미
      add - 작업 내역을 지역 저장소에 저장하기 위해 스테이징 영역(Staging Area)에 추가한다.
      - '--all' 옵션으로 작업 디렉터리의 모든 파일을 스테이징 영역에 추가할 수 있다.
      commit 작업 내역을 지역 저장소에 저장한다.
      branch - 새로운 브랜치를 생성한다.
      - 최초로 commit을 하면 마스터(master) 브랜치가 생성된다.
      - commit 할 때마다 해당 브랜치는 가장 최근의 commit한 내용을 가리키게 된다.
      - 'd' 옵션으로 브랜치를 삭제할 수 있다.
      checkout - 지정한 브랜치로 이동한다.
      - 현재 작업 중인 브랜치는 HEAD 포인터가 가리키는데, checkout 명령을 통해 HEAD 포인터를 지정한 브랜치로 이동시킨다.
      merge 지정한 브랜치의 변경 내역을 현재 HEAD 포인터가 가리키는 브랜치에 반영함으로써 두 브랜치를 병합한다.
      init 지역 저장소를 생성한다.
      remote add 원격 저장소에 연결한다.
      push 로컬 저장소의 변경 내역을 원격 저장소에 반영한다.
      featch 원격 자장소의 변경 이력만을 지역 저장소로 가져와 반영한다.

       

      💡 스테이징(Staging) 영역 ? 작업 내역을 바로 commit 지역 저장소에 저장하지 않고 스테이징 영역에 저장했다가 commit을 하는 이유는 스테이징 영역에서 작업 내용을 한번더 확인하여 선별적으로 지역 저장소에 반영하기 위함이다. 이렇게 하면 스테이징 영역을 사용하지 않을 때보다 시간은 더 소요되지만 좀 더 안정된 버전 관리 작업이 가능하다.

       

      • Git을 이용한 버전 관리

       

      💡 Git을 이용해 버전 관리 작업을 시작할 때는 먼저 'init' 명령으로 지역 저장소를 만들고, 'remote add' 명령으로 원격 저장소 에 연결한 후 'add --all > commit > push'를 한다. 이후 버전 관리는 'fetch > 작업 > add > commit > push' 과정으로 진행한다. 나머지 명령은 과정이나 자료 송수신 과정에서 필요에 의해 수행된다.

       

       

       

       

      728x90
      반응형
    상단으로