버전 제어를 사용해야하는 이유는 무엇입니까? [닫은]

작가가 이렇게 말한 블로그를 읽고 있었어요

"코드는 버전 제어 시스템에 체크인하지 않으면 존재하지 않습니다. 모든 작업에 버전 제어를 사용하십시오. 모든 버전 제어, SVN, Git, 심지어 CVS도 마스터하고 사용하십시오."

나는 어떤 종류의 버전 제어도 사용한 적이 없으며 그렇게 훌륭하다고 생각하지 않습니다. 나는 그것을 봤고 전에 그것을 보았지만, 당신이 원하신다면 어린이 용어에 넣어야합니다.

내가 지금 이해하고 있듯이 SVN과 같은 것은 사용자 그룹이나 다른 개발자가 동일한 코드에 액세스 할 수 있도록 코드를 온라인에 저장하는 것입니다. 일부 코드를 업데이트하면 새 버전을 제출할 수 있으며 SVN은 이전 코드와 업데이트 한 새 코드의 사본을 보관합니다.

이것이 기본 아이디어입니까, 아니면 완전히 잘못 이해하고 있습니까?

내가 옳다면 다음과 같은 경우에는 많이 사용되지 않을 수 있습니다.

• 다른 사람이 코드를 작업하지 마십시오.
• 다른 사람에게 코드를 제공 할 계획을 세우지 마십시오.

넌 해본 적 있니:

• 코드를 변경하고 실수라는 것을 깨달았으며 되돌리고 싶습니까?
• 코드를 분실했거나 너무 오래된 백업이 있습니까?
• 제품의 여러 버전을 유지해야 했습니까?
• 코드의 두 버전 (또는 그 이상)의 차이점을보고 싶습니까?
• 특정 변경으로 인해 코드가 손상되거나 수정되었음을 증명하고 싶습니까?
• 일부 코드의 기록을 검토하고 싶습니까?
• 다른 사람의 코드에 대한 변경 사항을 제출하고 싶습니까?
• 코드를 공유하거나 다른 사람이 코드 작업을 할 수 있도록하고 싶습니까?
• 얼마나 많은 작업이 어디에서 언제 누구에 의해 수행되고 있는지 알고 싶습니까?
• 작업 코드를 방해하지 않고 새로운 기능을 실험하고 싶습니까?

이러한 경우와 의심 할 여지없이 버전 관리 시스템은 당신의 삶을 더 쉽게 만들어 줄 것입니다.

친구를 잘못 인용하려면 : 문명 시대를위한 문명화 된 도구.

혼자 작업하더라도 소스 제어의 이점을 누릴 수 있습니다. 특히 다음과 같은 이유가 있습니다.

• 당신은 아무것도 잃지 않습니다. 다시는 코드를 주석 처리하지 않았습니다. 간단히 삭제합니다. 내 화면을 어지럽히 지 않으며 손실되지 않습니다. 이전 커밋을 확인하여 복구 할 수 있습니다.

• 마음대로 실험 할 수 있습니다. 문제가 해결되지 않으면 되돌립니다.

• 이전 버전의 코드를보고 버그가 언제 어디서 도입되었는지 알아볼 수 있습니다. git bisect그 점에서 훌륭합니다.

• 분기 및 병합과 같은보다 "고급"기능을 사용하면 여러 병렬 개발 라인을 가질 수 있습니다. 간섭없이 두 가지 동시 기능으로 작업 할 수 있으며 번거 로움없이 앞뒤로 전환 할 수 있습니다.

• "변경된 사항"을 볼 수 있습니다. 이것은 기본적으로 들릴지 모르지만 내가 많이 확인하는 것입니다. 나는 종종 1 인 워크 플로우를 시작합니다. 어제 무엇을 했습니까?

계속해서 시도하십시오. 기본 기능으로 천천히 시작하고 진행하면서 다른 사람들을 배우십시오. 곧 VCS가없는 "암흑 시대"로 돌아가고 싶지 않을 것입니다.

로컬 VCS를 원하면 자신의 Subversion 서버를 설정할 수 있지만 (예전에했던 작업), 오늘은 git. 훨씬 간단합니다. 간단하게 cd코드 디렉토리 및 실행하려면 :

git init

클럽에 오신 것을 환영합니다.

버전 제어는 독주 개발자로만 사용하는 경우에도 절대적으로 필요하다고 말하는 드문 도구입니다. 어떤 사람들은 그것이 당신이 살고 죽는 도구라고 말합니다. 저는 그 주장에 동의합니다.

모르는 경우에도 지금 바로 버전 제어를 사용하고있을 것입니다. "XXX Php 코드 (12 월)"또는 "XXX.php.bak.2"라고 표시된 폴더가 있습니까? 이들은 입니다 이미 버전 제어의 형태. 좋은 버전 관리 시스템이이를 자동으로 처리합니다. 데이터를 체크인 한 특정 시점으로 롤백 할 수 있으며 해당 데이터의 정확한 사본을 볼 수 있습니다.

또한 Subversion과 같은 시스템을 채택하고 원격 저장소 (예 : 소유 한 서버에있는 저장소)를 사용하면 모든 코드를 보관할 수 있습니다. 다른 곳에 코드 사본이 필요하십니까? 문제 없습니다. 확인하세요. 집에서 하드 드라이브 충돌? 문제가 아닙니다 (적어도 소스 코드에서는).

지금 버전 제어를 사용하지 않더라도 나중에 경력의 한 시점에서 사용할 수 있으며 지금 원칙에 더 익숙해지면 이점을 얻을 수 있습니다.

혼자 일하더라도 이런 일이 일어난 적이 있습니까? 앱을 실행했는데 어떤 것이 작동하지 않고 "어제 작동했습니다. 저는 그 수업 / 방법을 건드리지 않았습니다."라고 말합니다. 정기적으로 코드를 확인하는 경우 빠른 버전 차이는 마지막 날에 변경된 사항을 정확히 보여줍니다.

다음은 혼자 작업하더라도 소스 제어의 유용성을 보여줄 수있는 시나리오입니다.

귀하의 고객은 귀하에게 웹 사이트에 대한 야심 찬 수정을 요청합니다. 몇 주가 걸리며 여러 페이지를 편집해야합니다. 일하러 가세요.

클라이언트가 전화를 걸어 사이트에 긴급하지만 사소한 변경을 수행하기 위해 수행중인 작업을 중단하라고하면이 작업을 50 % 완료 한 것입니다. 더 큰 작업을 완료하지 않았으므로 실행 준비가되지 않았으며 클라이언트는 작은 변경 사항을 기다릴 수 없습니다. 그러나 그는 또한 더 큰 변화를 위해 사소한 변화가 당신의 작업에 병합되기를 원합니다.

웹 사이트 사본이 포함 된 별도의 폴더에서 대규모 작업을 수행하고있을 수 있습니다. 이제 신속하게 배포 할 수있는 방식으로 사소한 변경을 수행하는 방법을 파악해야합니다. 당신은 격렬하게 일하고 그것을 완수합니다. 클라이언트는 추가 구체화 요청으로 콜백합니다. 당신도이 작업을 수행하고 배포합니다. 모든 것이 좋습니다.

이제 주요 변경을 위해 진행중인 작업에 병합해야합니다. 긴급한 업무를 위해 무엇을 변경 했습니까? 메모를하기에는 너무 빨리 일하고있었습니다. 이제 시작된 기준선에 비해 두 디렉터리가 모두 변경되었으므로 두 디렉터리를 쉽게 비교할 수 없습니다.

위의 시나리오는 혼자 작업하더라도 소스 제어가 훌륭한 도구가 될 수 있음을 보여줍니다.

• 분기를 사용하여 장기 작업을 수행 한 다음 완료되면 분기를 다시 기본 라인에 병합 할 수 있습니다.
• 전체 파일 세트를 다른 분기 또는 이전 개정과 비교하여 무엇이 다른지 확인할 수 있습니다.
• 시간이 지남에 따라 작업을 추적 할 수 있습니다 (그런데보고 및 송장 발행에 유용함).
• 날짜 또는 정의한 마일스톤을 기반으로 파일의 모든 개정을 복구 할 수 있습니다.

솔로 작업의 경우 Subversion 또는 Git을 권장합니다. 누구든지 둘 중 하나를 자유롭게 선호 할 수 있지만, 버전 제어를 사용하지 않는 것보다 둘 중 하나가 분명히 낫습니다. 좋은 책은 Mike Mason의 " Pragmatic Version Control using Subversion, 2nd Edition "또는 Travis Swicegood의 " Pragmatic Version Control Using Git "입니다.

원저자 : Bill Karwin

단일 개발자 소스 컨트롤이 큰 이점을 제공하더라도. 이를 통해 코드 기록을 저장하고 언제든지 소프트웨어의 이전 버전으로 되돌릴 수 있습니다. 이렇게하면 작동 중이던 소스 코드의 다른 버전으로 항상 복원 할 수 있으므로 실험 할 수있는 두려움없는 유연성을 제공합니다.

마치 첫 번째 코드 줄로 돌아가는 거대한 "실행 취소"버튼이있는 것과 같습니다.

버전 관리는 사용을 시작한 후 없이는 거의 불가능합니다. 둘 이상의 개발자가 동일한 코드 기반에서 작업하는 경우 필수 불가결하지만 단일 개발자에게도 매우 유용합니다.

코드의 변경 사항을 추적하고 이전 버전으로 롤백 할 수 있습니다. 문제가 발생하면 변경 사항을 취소 할 수 있다는 지식을 실험 할 수 있습니다.

보안 (코드 백업의 의미에서)과 코드의 버전 관리 (변경 사항을 자주 커밋하는 습관이 있다고 가정)를 얻을 수 있습니다. 아무도 당신과 함께 코드를 작업하지 않더라도 둘 다 매우 좋은 것입니다.

버전 제어는 혼자 작업하는 경우에도 이전 버전을 확인하는 데 유용합니다. 예를 들어 실수로 코드 나 파일을 삭제 한 경우 다시 가져올 수 있습니다. 또는 이전 버전을 비교하여 새로운 버그가 발생한 이유를 확인할 수 있습니다. 한 사람이 여러 위치에서 작업하는 경우에도 좋습니다.

개인적으로 가장 좋아하는 것은 git입니다.

코드를 만지는 유일한 사람이더라도 버전 제어를 사용하는 데는 여러 가지 이유가 있습니다.

• 지원 -하드 드라이브가 충돌하면 어떻게됩니까? 어디에나 사본이 있습니까?
• 개정 내역 -현재 다른 폴더에 코드 사본을 보관하고 있습니까? 버전 제어를 사용하면 시간 경과에 따른 변경 사항을 추적하고 도구를 사용하여 다양한 수정 사항을 쉽게 비교하고 병합, 롤백하는 등의 작업을 수행 할 수 있습니다.
• 분기 -일부 변경 사항을 테스트하고 수행중인 작업을 추적 한 다음이를 유지하고 주 프로젝트에 병합할지 아니면 그냥 버릴지 여부를 결정하는 기능입니다.

코드를 버전 관리하에두면 어떤 파일을 변경했는지 (또는 기준에 추가하는 것을 잊은) 정말 쉽게 확인할 수 있습니다.

다른 누구도 명시 적으로 언급하지 않은 것으로 보이는 것은 릴리스의 태그 또는 라벨링입니다. 소프트웨어 버전 1을 사용하는 클라이언트가 있고 버전 2 작업에 바쁘다면 클라이언트가 버그를보고하고 버전 1.1을 빌드해야 할 때 어떻게해야합니까?

소스 제어 시스템을 사용하면 만든 모든 릴리스에 레이블을 지정할 수 있으므로 나중에 다시 돌아와서 수정 (그리고 해당 수정 사항을 새 버전 2 코드에 병합)하고 실수로 전달할 수있는 내용을 걱정하지 않고 새 릴리스를 만들 수 있습니다. 준비되지 않았습니다.

소스 제어는 최신 소프트웨어 개발의 핵심 부분입니다. 당신이 그것을 사용하지 않는다면 (더 많은 경험을할수록 더 나은 개인 프로젝트에도) 뭔가 잘못하고있는 것입니다.

일반적으로 취업 면접을받을 때 가장 먼저 묻는 질문 중 하나는 "소스 제어에 무엇을 사용합니까?"입니다. 지금까지 "아무것도"라고 말한 곳은 한 곳 뿐이지 만 그들은 "이제 진짜 곧 ..."을 고칠 계획이었습니다.

다른 개발자가 참여하거나 참여하지 않는다는 사실은 버전 제어 시스템의 필요성과 완전히 직교합니다.

유일한 개발자가 될 수 있지만 여전히 다음과 같은 이점이 있습니다.

• 모든 변경 사항의 기록 추적
• 그 역사를 앞뒤로 돌아갈 수있는 능력
• 소스를 실험하고 여전히 작동하는 버전 (분기)을 가지고있는 능력
• 백업 사본 (특히 소스 제어 서버로 다른 머신을 사용하는 경우, 해당 머신이 정기적으로 백업되는 경우 더 많음)

이제 동일한 코드베이스에서 개발하는 그룹이 있다면 버전 제어가 더 필요하므로

• 사람들은 동시에 같은 파일을 편집 할 수 있습니다 (특정 시스템에 따라 다르지만 대부분의 정상적인 파일은이를 수행 할 수 있습니다)
• 누가 코드를 언제 처리했는지 알 수 있습니다.

더 많은 사람이 참여하면 개발 스타일에 따라 어떤 버전 제어 도구를 선택하는지가 더 관련이 있습니다.

또한 "Subversion"이라고 불리는 오래된 파일을 백업하는 것입니다. 따라서 되돌릴 수있는 (되돌리기) 작업의 여러 버전을 관리하고 다른 구현 (분기)을 관리 할 수 ​​있습니다.

프로그램의 작동 버전이 있음을 알 수 있습니다.

일정 기간 동안 몇 가지 새로운 기능을 추가하기로 결정하고이를 릴리스합니다.

손대지 않았다고 생각한 일부 코드에 영향을 미치는 버그 보고서를 받기 시작합니다.

예를 들어 SVN을 사용하면 이전 버전으로 돌아가 새로운 버그가 있는지 확인할 수 있습니다. 버그를 도입 한 버전을 찾으면 작동 한 버전과 작동하지 않은 버전을 비교하고 변경된 사항을 확인한 다음 검색 범위를 좁힐 수 있으므로 수정하기가 더 쉬울 것입니다.

소스 제어는 유일한 개발자 인 경우에도 많은 용도로 사용됩니다.

좀 더 가벼운 것을 찾고있는 것 같습니다. Mercurial ( 멋진 참고서 )을 확인하십시오 . 소스 코드에서 개인 서신에 이르기까지 모든 것에 사용합니다.

몇 가지 이점 :

• Giant Undo 버튼을 사용하면 지난주의 그 반기 일을 반환 할 수 있습니다. 실제로 실행 된
• 폐기 코드. 이것이 최선의 방법인지 확실하지 않습니까? 가지를 만들고 실험하십시오. 수은과 같은 DVCS를 사용하고 있다면 아무도 알 필요가 없습니다.
• 동기화 된 개발. 저는 4 대의 컴퓨터에서 개발합니다. 나는 그것들 사이를 밀고 당겨서 현재를 유지하기 때문에 어느 곳에 있든 상관없이 최신 버전을 가지고 있습니다.

아직 이전 버전의 프로그램이 필요한 상황이 아니더라도 소스 컨트롤을 사용하면 주요 변경 작업에 대해 더 큰 자신감을 얻을 수 있습니다.

작업 버전을 쉽게 복원 할 수 있다는 사실을 항상 알고 있었기 때문에 소스 제어를 사용한 후보다 적극적인 리팩토링을 수행했습니다.

또한 최근에야 버전 관리에 관심을 갖기 시작했습니다. 버전 제어 시스템에는 코드 저장소 의 개념이 있습니다. 이 저장소와 상호 작용할 수 있도록 다양한 새 셸 명령이 매우 빠르게 학습됩니다.

코드를 파일에 저장 한 다음 이를 프로젝트의 저장소에 커밋 할 수 있습니다 . 코드를 개발하고 변경 사항을 커밋하면 리포지토리에서 일련의 개정판을 개발합니다 . 체크 아웃 하여 이들 중 하나에 액세스 할 수 있습니다개정판 . 혼자 작업하는 경우 코드 파일을 잃어 버리거나 다른 컴퓨터에서 작업하기를 원하지 않는 한 많은 체크 아웃을 할 가능성이 낮습니다. 이 경우 일반적으로 모든 파일의 최신 버전을 확인합니다.

제 부분에서는 리팩토링하기로 결정할 때 더 이상 'project_old'라는 파일이나 폴더를 유지하지 않습니다. 내가 만든 모든 변경 사항은 점진적으로 저장되며 항상 전체적으로 작동 한 프로젝트로 뒤로 이동할 수 있습니다. ssh를 통해 코드를 체크 아웃하기 때문에 지금은 FTP를 거의 사용하지 않습니다. 변경 한 파일 만 다운로드되며 서버에 다시로드해야하는 경우 터미널이 이미 있습니다.

저는 GIT에 대한이 강연이 정말 유익하다는 것을 알았습니다. http://www.youtube.com/watch?v=4XpnKHJAok8

Linus Torvalds가 한 버전 제어 시스템을 다른 시스템보다 사용하기 위해 논쟁을 벌이는 Google 토크입니다. 그렇게하면서 그는 개념을 사용하여 작동 방식을 설명하고이를 구현하는 다양한 방법을 비교합니다.

모든 변경 사항에 대한 기록을 갖기 위해 혼자 작업하더라도 Subversion과 같은 것을 원할 것입니다. 변경 한 이유를 기억하기 위해 한때 코드 조각이 어떻게 생겼는지보고 싶을 수 있습니다.

소스 제어 기능은 자주 체크인 할 때도 유용합니다. 자주 체크인하면 항상 자주 롤백 할 수있는 상태가됩니다. 여러 번 문제를 해결하기 위해 한 가지 길을 내려 가기 시작한 다음 그것이 잘못된 길이라는 것을 깨달을 수 있습니다. 여러 번 잘못된 길을 계속 짖고 끔찍한 솔루션을 구축 할 수 있습니다. 모든 작업을 잃고 싶지 않았기 때문입니다. 자주 체크인하면 "행복"의 마지막 지점이 멀지 않으므로 잘못된 길로가더라도 언제든지 롤백하고 다시 시도하여 더 우아하고 간단한 솔루션을 만들 수 있습니다. 미래에 쓴 내용을 이해하고 유지할 수 있도록 항상 좋은 것입니다.

프로젝트의 규모와 프로젝트의 일부에 대한 마음이 얼마나 자주 바뀌는 지에 따라 다릅니다. 선형 방식으로 작업을 수행하는 소규모 프로젝트의 경우 버전 제어가별로 도움이되지 않을 것입니다 (버전 제어없이 파일을 실수로 삭제하거나 손상하면 울게됩니다).

하지만 몇 주 전에 저는 엄청난 취미 프로젝트를 직접 작성하는 친구를 만났습니다. 그는 "X1", "X2", "test", "faster"등과 같은 접미사가 붙은 자신의 코드를 10 ~ 20 개 복사했습니다.

당신은 당신의 코드의 두 개 이상의 사본을했다면, 당신은 필요한 버전 관리 . 좋은 버전 관리 시스템을 사용하면 변경 한 후에 수행 한 작업을 취소하지 않고 얼마 전에 변경 한 내용을 취소 할 수 있습니다. 특정 변경 사항이 언제 발생했는지 확인할 수 있습니다. 이를 통해 코드를 두 개의 "경로"(예 : 하나는 새로운 아이디어를 테스트하기위한 것이고 다른 하나는 테스트가 끝날 때까지 "시행되고 신뢰할 수있는"코드를 안전하게 유지하기위한 것)로 분할 한 다음 다시 병합 할 수 있습니다.

2019 년입니다. 상대적으로 늦은시기에 Git 사용에 대한 이의가 있습니다. 여기에서 제기하는 이의가 있습니다. 이 논의는 단순히 명명 된 백업 복사본을 만드는 것보다 소스 제어를 사용해야하는 필요성을 크게 명확히했습니다. 한 가지 핵심은 단일 개발자 프로젝트가있는 곳에서도 소스 제어를 사용하는 것입니다. 누구도 완벽하지 않다. 당신은 실수를합니다. 매우 훌륭하고 똑똑하다면 더 복잡한 앱을 개발하게 될 것입니다. 하지만 당신은 여전히 ​​약간의 실수를 할 것이고 이것은 그것을 처리합니다. 이런 오 피트! 저는 Linux를 사용하지 않지만 우리 모두 Linus Torvalds의 뛰어난 기술 지능을 존중한다고 생각합니다. 그는 소스 제어의 중요성을 인식하고 Git의 시작에 중요한 공헌을했습니다. 여기에 제공된 모든 이유에 대한 요약 요점이 있습니다. Torvalds는이를 이해합니다. 소스 제어는 매우 중요합니다. 소스 제어를 사용하십시오. 이 장기적인 주제에 대해 언급 해 주신 모든 분들께 감사드립니다.