프로그래밍 기술을 바라보는 개발자의 관점
우리가 배우는 모든 프로그래밍 기술은, 폰 노이만 구조 이래 기본 원리와 기술 뿌리가 변하지 않았습니다.
기존 소프트웨어 개발 방법을 조금이라도 쉽고, 편리하게 하기 위해 발전된 하나의 기술일 뿐입니다.
깃도 마찬가지입니다.
깃은 소프트웨어 개발에서 어떤 불편한 점을 개선하기 위해 등장했는지를 이해한 뒤,
개선된 기술을 내가 작업하는 프로젝트에 적용 시킬 수 있도록 합시다.
저장, 불러오기, 파일명(식별자)
깃을 배우기 전에, 개발자 관점에서 벗어나 컴퓨터 사용자 입장에서 컴퓨터의 저장과 불러오기, 파일명(식별자)이라는 개념에 대해 명확히 인지하고 다시 한 번 이해해봅시다.
가장 먼저, 모든 프로그램은 데이터를 "저장" 하는 기능이 있습니다.
단순히 문서를 작성하는 프로그램부터, 이미지를 편집하거나, 영상, 음성, 게임 등을 다루는 모든 프로그램들은 데이터를 저장 하는 기능이 있습니다.
이 때 저장되는 데이터를 구분하기 위해 고유한 "파일명"을 사용합니다.
이름을 통해 세상의 사물을 구분하듯이, 파일명을 통해 저장된 데이터들을 식별 할 수 있습니다.
그리고 마지막으로 사용자는 저장된 데이터를 "불러오기" 할 수 있습니다.
불러오기 하는 데이터 대상은 저장할 때 사용한 파일명을 기준으로 식별됩니다.
깃이란?
깃은, VCS(Version Control System, 버전 관리 시스템)의 한 종류입니다.
버전은 프로그램의 일부 내용이 변경되거나 새로운 기능이 추가되는 등 어떤 유의미한 변화가 결과물로 나오는 것을 말합니다.
버전이라는 단어가 낯설겠지만, 사실 우리는 컴퓨터를 사용하면서 이미 버전 관리를 해본 경험이 있습니다.
- 문서를 작성할 때를 떠올려 보세요. 문서 작업하는 도중에 다른 일을 처리하기 위해 문서를 저장하고 다른 작업을 할 수 있습니다. 그리고 다시 저장된 문서를 불러와서 작업을 진행 할 수 있습니다.
- 게임도 마찬가지입니다. 게임이 진행된 상태를 저장하고, 저장된 게임을 불러와 이어서 진행 할 수 있습니다.
- 그림판이나 포토샵으로 이미지를 작업할 때 ctrl+z 단축키를 누르면 한 단계씩 뒤로 갈 수 있게 해 주는 것도 하나의 버전 관리 입니다.
깃은, 소프트웨어 개발에서 프로젝트 단위의 소스코드를 <저장>하고, <이름>으로 식별하고, <불러오기> 하는 편리한 기술일 뿐입니다.
ctrl+z 단축키를 눌러 한 단계씩 되돌리는 것처럼, 내가 원하는 시점마다 소스코드를 저장하고 되돌리는 것을 가능하게 해주는 소스 코드 버전 관리 시스템이 git 입니다.
깃 실습 로드맵
깃을 배운다는 것은 소스코드의 특정 시점과 상태를 저장하고, 저장된 소스코드를 불러오는 방법을 익힌다는 관점으로 접근하여 실습을 시작합니다.
처음에는 협업 없이, 깃을 로컬 저장소를 사용해 혼자서 개발하고 소스코드를 버전 관리하는 방법을 익힙니다.
이때, 프로젝트를 백업된 압축 파일로 저장해왔던 방법과 git을 사용하여 프로젝트를 관리했을때 차이점을 파악하고, 어떤 상황에서 사용했을때 효과적인지 내 프로젝트에 적용하며 감을 익힙니다.
그 뒤에 원격 저장소를 사용하여 프로젝트를 관리하는 방법을 익힙니다.
마지막으로, 깃을 이용해 협업 과정에서 깃을 사용할 때 발생하는 문제에 대한 대처 방법을 익힙니다.
소스코드를 백업 파일 단위로 관리할 때의 문제점
이제까지 프로젝트를 진행하면서 소스코드 파일 단위
문서 버전 관리 예시
1. 문서 내용 일부가 다른 경우
2. 문서 파일 자체가 다른 경우
3. 덮어씌우기 이전 파일이 필요하다면 어떻게 해야 하는가?
소스코드
1. 소프트웨어 개발이란?
* Google "소프트웨어 개발" 검색, 링크1, 링크2
소프트웨어 개발은, 단순히 한두번의 분석과 설계 그리고 구현 작업으로 이루어지지 않습니다.
일반적으로 정해진 일정에서 분석과 설계 작업을 마무리하고 구현하여 프로그램이 완성되어 운영됩지만, 고도화와 끊임없는 요구사항을 만들어진 프로그램에 반영해야 합니다.
2. 문서 파일처럼 관리되는 소프트웨어 개발 프로젝트의 문제점
2.1 미니 프로젝트 예시 - 1. 일정표, 2. 소스코드 파일 관리
2.2 저장
2.3 불러오기
소프트웨어 개발은, 결과물을 검토하고 오류를 수정하고 새 기능을 넣고 성능을 개선하면서 계속해서 새 버전들이 나옵니다. 그런데 작업을 진행하다 보면 이전에 했던 작업을 취소해야 할 경우가 발생합니다.
백업 파일로 프로젝트를 관리한다면, 개발자가 버전마다 일일이 프로그램을 압축해서 백업 파일로 가지고 있다가 문제가 생긴 지점을 찾아 수정해야 합니다. 이 방식은 모든 버전을 개발자가 백업해야 하므로 매우 비효율적입니다. 프로젝트가 진행될수록 백업 파일의 용량도 증가할 것입니다.
그리고 과거 특정 시점의 문제만 수정하여야 한다면, 모든 버전의 수정사항을 전부 확인해야 할수도 있습니다.
기존 프로젝트에서 새로운 기능을 테스트 하고 싶다면, 새로운 복사본을 만들어 새로운 백업 파일로 관리해야 합니다.
2.4 협업과 통합
소소코드를 문서처럼 파일 단위로 관리하기 힘든, 가장 중요한 이유
변경된 소스코드를 하나하나를 확인해서 변경된 부분을 수정해야 하는 문제
e.g. 같은 함수를 여러명이 수정한 경우
프로젝트 폴더를 복사해서 백업하고 관리할 필요가 없다.
