소규모 개발 그룹 (1-2 프로그래머)에게 버전 관리가 필요합니까?
한 두 명의 개발자에게 버전 관리가 중요하다는 점에 대해 토론하려고합니다.
보다 구체적으로, 저는 공유 프레임 워크를 사용하는 두 명의 PHP 개발자가있는 부서에서 일합니다. 그는 개발 시스템에 Subversion을 설치하면 우리에게 가치가 추가되지 않는다고 주장하지만, 때로는 이전 코드를보기 위해 롤백 할 수있는 것이 좋으며 특히 설명하기 어려운 오류가 발생했을 때 수업 중 일부를 가리 킵니다.
Subversion은 디버깅을 포함한 다양한 이유로 변경 사항을 만들고 추적하는 가장 쉬운 방법을 제공한다고 생각합니다. Subversion은 시간을 절약 할 수 있습니까?
난 그냥 여기에 쌓아두고 YES라고 말할거야. 마찬가지로 26 17 @ 말했다
어떤 종류의 소스 제어가없는 것은 순수한 광기입니다.
이것이 진실입니다. 소스 제어 유무에 관계없이 작은 프로젝트를 수행했습니다 (내 선택이 아님). 없이, 그것은 단지 빤다. 프로젝트의 정식 버전은 없으며, 누가 무엇을 가지고 있고 변경을 병합하는 것이 고통스러운 운동인지 알 수 없습니다.
실제로, 약 5 줄 이상의 코드는 어떤 종류의 버전 제어하에 있어야합니다.
항상 혼자서 프로젝트를 수행하는 경우에도 항상 일종의 소스 제어를 원합니다.
코드 히스토리의 상태를 언제든지 볼 수 있으려면 변경 히스토리가 있어야합니다. 고객이 새로운 버전으로 업그레이드하기보다는 버그를 수정하기 위해 패치를 원할 때 잘못된 변경을 롤백 할 수있는 것부터 이전 릴리스에 대한 지원을 제공하는 것까지 프로젝트 히스토리를 되돌아 보는 데는 여러 가지 이유가 있습니다. 소프트웨어.
어떤 종류의 소스 제어가없는 것은 순수한 광기입니다.
그렇습니다.
단일 프로그래머라도 버전 관리가 필요합니다. 코드를 모든 스냅 샷과 비교할 수있는 단순성은 매우 가치가 있습니다.
내 충고-가자!
[버전 컨트롤없이 살아 왔을 때. 이제는 더 이상 할 수 없습니다.]
나는 한 명의 프로그래머이며 때로는 롤백하거나 이전 버전과 비교하기를 원하므로 귀중한 것으로 생각됩니다.
또한 사용자 및 그와 같은 것들의 문서를 버전 화합니다.
개발을 추적 할 수있는 좋은 방법입니다.
버전 관리 는 엉덩이 를 저장합니다. 버전 제어를 사용하지 않는 전문 개발자는 소프트웨어 과실 범주에 해당하는 몇 가지 사항 중 하나입니다.
고독한 개발자라도
- 기능이 작동했을 때 돌아올 수 있습니다
- 백업 자동 유지 관리 : 체크인하고 백업합니다.
- 매듭에 묶인 상태에서 지역 변경 사항을 취소하십시오.
- 프로덕션 환경, 테스트 환경 또는 특정 고객 환경에서 실행중인 버전으로 돌아가 디버깅 할 수 있습니다.
- 올바르게 사용하면 귀중한 디버깅 도구가 될 수있는 특정 문제에 대한 수정과 관련된 모든 변경 사항도 볼 수 있습니다.
하나 이상의 개발자 인 경우는 변경 사항이 다른 프로그래머가 만든 덮어 쓰지 한 프로그래머를 유지할 것입니다 당신이 얼마나 신중 상관없이 발생합니다.
이것들은 버전 관리 사용 여부에 대한 논쟁에서이기는 데 도움이되는 기본 사항입니다.
저는 "한 사람의 밴드"프로그래머이며 전체 응용 프로그램을 복사하여 "backup"이라는 폴더에 넣은 다음 나중에 "20080122-backup"과 같은 이름을 지정했을 때 버전 제어를 사용하기 시작했습니다. 많은 사람들이 이런 식으로 시작한다고 생각합니다. 따라서 문제는 버전 관리를 사용해야하는지 여부가 아니라 올바른 방법으로해야합니까, 아니면 절반 만 만든 수제 팩스를 함께 해킹해야합니까?
Subversion-절대로 아닙니다. 중앙 집중식이며 병합 지원이 그리 좋지 않습니다.
버전 관리- 절대 그렇습니다! 솔로 개발자조차도 필요합니다!
작고 빠르게 움직이는 모바일 팀에는 분산 버전 제어가 필요하므로 다음 중 하나를 선택하십시오.
- 자식
- 수은제
- darcs
예, 학습 곡선이 있습니다. 배급하면 배울 수 있습니다. 네, 나중에 고맙습니다.
그리고 분산 저장소가 어디에 있습니까? 몇 가지 아이디어가 있습니다.
- 개인 USB 메모리 스틱에 넣습니다 (그리고 USB 스틱 한 개로 제한하지 말고 은행의 안전 금고와 같은 여러 위치에도 배포하십시오)
- A와 화재, 지진이나 토네이도가 동시에 소스를 해칠 수없는 안전한 장소 (오프 사이트, 다른 위치, 그물의 다른 쪽))에서 다른 백업
- 중앙 서버, 하나 또는 github와 같은 것
- 개발자 컴퓨터의 여러 사본
- 스테이징 서버 근처의 스테이징 저장소
- 생산 현장 근처 어딘가에 생산 리포지토리
버전 제어는 프로그래머 수가> 0 인 경우에만 필요합니다.
어떤 시스템이든 작동하고 편안하지만 개발을하는 경우 버전 관리가 필요합니다 (이상적으로 백업에 대해 걱정하기 전에 소스가 두 대 이상의 컴퓨터에있는 방식으로 설정 됨).
그 외에도-일찍 커밋하고 자주 커밋 할 수있는 시스템을 찾으십시오.
나는 모든 프로젝트, 심지어 1 개발자 프로젝트조차도 지속적인 통합을보고 있어야한다는 견해를 향하여 거의 이상하다. 정기적으로. 왜? 이 a)는 VCS에 빌드 가능한 시스템이 있다는 확신을주고 b) 실제로 테스트 및 배포를위한 깨끗한 빌드가 있는지 확인합니다.
특히 Subversion에 대해서는 잘 모르지만 개발자가 하나 인 프로젝트라도 모든 프로젝트에서 버전 관리를 사용해야한다고 생각합니다. 몇 가지 옵션 (CVS, SubVersion, git, Bazaar, Visual SourceSafe)을 살펴보고 팀의 요구에 가장 적합한 옵션을 확인하십시오.
Version Control is the most important tool that a programmer has, even more important than the actual programming languages. No matter how many users you have, source control should always be required. I don't know how many times I've made a breaking change and then needed to go back and work on old code or at least just see how the original code functioned. I work in small teams and we use SVN Notifier to let us know when things are commited. This allows us to review each others work and you don't get the dreaded "Have you checked your code in yet?" questions all the time. Using source control from the beginning will eliminate many headaches (overwrites, lost code, fights over who changed what) that you may face.
Absolutely. There's really no other way to deal with rollbacks to a known good state when the coding path you ventured down turns out to be dense with wolves.
And you can back it up.
I have a project that only I work on and Version Control makes my life so much easier. For example, say I decide to implement a new feature. For whatever reason though, I decide to trash it - maybe I wrote it wrong, maybe I changed my mind about implementing it, whatever. All I have to is revert to a previous version from SVN instead of manually reverting each file involved.
Subversion isn't. But source control is.
Regardless if you are a single developer, or a group of developers you must do the following before you start coding ANYTHING:
- Set up a version control system. Use whatever system you like, git, SVN, Mercurial. It doesn't matter as long as you know how to use it.
- Set up a collaborative documentation system. Use a Wiki or a trac, or any other such system you know how to use.
- Set up the build system. Use Make, ANT, Maven, or any other build system you know how to build.
- Write the first test cases.
Don't code a single line of the main app until you have done these four
Anyone who isn't doing version control is simply doing it wrong.
Version Control can have the following advantages:
- Rollback is always handy as you mentioned
- With some you can pin a previous version and run off of it without rolling back
- Helps prevent two people from working on a page at the same time which can cause several problems
But then again it also has its downfalls if you dont choose a good one
I strongly recommend source code control no matter what the size of the team. I have had too many late night sessions where I broke my code and did not have source code control to go to for older working versions.
YES!
Sorry for yelling :-)
Version control is not only usefull for rolling back versions. It will give a lot of safety against rolling out older versions of files or accidentally overwriting newer versions with older versions etc.
One thing I'm only now getting used to that's really usefull is the ability to branch and merge different versions. If you have a deadline coming up but you're working on a new feature that's not ready for prime time you can just branch before you started adding that feature. Create a deliverable version without that feature and merge those two after the deadline passes without problems.
Of course version control is necessary even for a one man project.
The option to save contexts and not just changes in the code is the great thing that source control does, you go from "file this and that changed in line blah" to "I added a new option to do ..." which is really valuable.
Don't listen to me though there's a great article that rands wrote about this
YES, but only for developer teams where size is > 0
When i shut down my IDE/text editor/whatever and come back the next day to realize i want to undo may last boneheaded mistake, Source control is there for me to fall back on, or use to branch and perform some wild experiment on my code. Without source control I cannot do these things so freely.
For teams of size > 1 you have a central backup, you have team wide undo, it's easier (possible) to work distributed, which when team size exceeds 1 is really what you're doing anyway no matter how far away your team mates are.
Version Control YES, you always need to perform version control.
SVN? no.. me, I use Git.
When I wish to go to the shops, I take my car to transport the shopping home. It is not necessary to put gas in my car. I could choose to push the car instead, but why would I?
Likewise with choosing not to use version control....
I would argue for git, for two primary reasons
- trivial to set up repo. cd into the directory, git init, and you're done
- logging! using a vcs of any kind makes it easy / obvious / simple to log why you're making changes. having a dvcs in particular makes it really fast and easy to see when, what, and why one made changes. Since a dvcs has long information locally, it's fast and easy to look up, unlike svn on remote machines.
[these are apparently true for Mercurial as well. They sure the heck aren't so easy for subversion.]
Everyone who is saying that source control for 1-2 developers is a must is completely, completely right. Trust us :-)
Back in college I had a professor who made us use source control. We all kicked and screamed, because CVS seemed way too complicated and sounded like overkill for student projects. Eventually we all came around, and even for simple projects from then on I'd put them all in source control. I've continued that to this day, and have saved myself from many hours of frustration.
Simple answer YES.
Not to reiterate, but it cannot be said enough. You SHOULD HAVE source control. Subversion is ridiculously easy and almost zero overhead once it is setup. It literally shouldn't take more than 5-20 minutes to setup. You have other choices too, like GIT. So just pick one, and put your source in there - end of answer. :)
There will be some time-loss when you set up the system and instuct the other developers - especially if they are not familiar with versioncontrol (or subversion in specific).
But the benefits of being able to roll-back to a previous (working) version and the possibility to do a easy diff of checked in files will be more than worth it.
The biggest problem is that the rewards -like most things- come after the 'hard work'. :)
Note, a different, but more lightweight solution may be enabeling 'Shadow Copy' on Windows, if that's your server os (although I guess it won't be). The plus of this is that you won't be bothering your co-developers with learning subversion, but you will be able to revert to a older version when needed...
Version control should be the first thing you think about when starting a project. Second is automatic builds, third is testing, fourth is incorporating your tests with your builds.
VSS is fine but mucho dinero.
try mercurial (hg) instead of svn
Yes, if you are a professional developer then you absolutely need to be using version control!
'Programing' 카테고리의 다른 글
| 복제를 위해 GitHub.com에 연결할 수 없음 (0) | 2020.05.29 |
|---|---|
| Java의 문자열에서 파일 확장자를 자르려면 어떻게해야합니까? (0) | 2020.05.29 |
| Bogosort (일명 Monkey Sort)보다 나쁜 정렬 알고리즘이 있습니까? (0) | 2020.05.29 |
| 페이스 북 아키텍처 (0) | 2020.05.29 |
| JavaScript 클로저가 가비지 수집되는 방법 (0) | 2020.05.29 |