SVN, Branch를 사용하는 방법? 꼬리표? 트렁크?
나는 약간의 인터넷 검색을하고 있었고 "어떻게 명령을 사용 하는가"라는 의미가 아니라 SVN 에 대한 "초보자"안내서를 찾을 수 없었다 . 소스 코드를 어떻게 제어합니까?
정리하고 싶은 것은 다음과 같습니다.
- 얼마나 자주 커밋합니까? 자주 Ctrl+를 누르는 것처럼 s?
- 지점이란 무엇이며 태그는 무엇이며 어떻게 제어합니까?
- SVN은 무엇입니까? 여기에서만 소스 코드 또는 다른 파일을 공유합니까? (버전이 지정된 파일로 간주되지 않습니다..)
나는 브랜치와 태그가 무엇인지 전혀 모른다. 그래서 목적을 알지 못한다. 그러나 나의 추측은 트렁크에 물건을 업로드하고 주요 빌드를 할 때 브랜치로 옮기는 것이라고 생각한다. 그렇다면이 경우 주요 빌드로 간주되는 것은 무엇입니까?
서브 버전 책은 , 저장소를 배치 분기 및 태그에 대한 전략에 대한 정보의 훌륭한 소스입니다.
또한보십시오:
Subversion을 구현할 때도 같은 질문을했습니다. 4-6 개의 프로젝트에 약 20 명의 개발자가 있습니다. 나는``답변 ''으로 좋은 소스를 찾지 못했습니다. 지난 3 년간 Google의 답변이 어떻게 발전해 왔는지 몇 가지 부분이 있습니다.
-유용한만큼 자주 커밋; 우리의 경험 법칙은 수정 작업을 잃어버린 경우 다시해야하는 문제가 될만큼 충분한 작업을 수행 할 때마다 커밋됩니다. 때로는 15 분마다 커밋하고 다른 경우에는 며칠 일 수 있습니다 (예, 때로는 한 줄의 코드를 작성하는 데 하루가 걸립니다)
-우리는 다른 개발 경로에 대해 이전 답변 중 하나에서 제안 된 분기를 사용합니다. 현재 우리 프로그램 중 하나에 대해 3 개의 활성 브랜치가 있습니다.
-태그를 거의 사용하지 않지만 프로덕션 릴리스를 식별하기 위해 태그를 사용해야한다고 생각합니다.
단일 경로를 따라 개발이 진행되는 것을 생각하십시오. 언젠가 개발 상태 마케팅에서 제품의 첫 번째 버전을 릴리스하기로 결정하므로 '1'(또는 '1.0'또는 무엇을 가지고 있는지)이라는 경로에 플래그를 설치하십시오. 다른 때에 약간의 밝은 불꽃이 프로그램을 병렬화하기로 결정했지만 몇 주가 걸리고 사람들이 그 동안 계속해서 주요 길을 가고 싶어하기로 결정했습니다. 그래서 당신은 길에 포크를 만들고 다른 사람들이 다른 포크를 헤매고 있습니다.
도로의 깃발을 '태그'라고하며 도로의 포크는 '분기'가 나뉘는 곳입니다. 때때로, 가지도 함께 돌아옵니다.
-실행 파일 (또는 시스템)을 구축하는 데 필요한 모든 자료를 저장소에 넣습니다. 그것은 최소한 소스 코드와 파일 (또는 Visual Studio 용 프로젝트 파일)을 의미합니다. 그러나 아이콘과 구성 파일 및 기타 모든 것들이 있으면 저장소에 들어갑니다. 일부 문서는 저장소에 들어갑니다. 프로그램에 필수적 일 수있는 도움말 파일과 같은 문서는 물론 개발자 문서를 저장하는 데 유용한 장소입니다.
또한 소프트웨어를 찾는 사람들에게 단일 위치를 제공하기 위해 프로덕션 릴리스 용 Windows 실행 파일도 넣었습니다. Linux 릴리스는 서버로 이동하므로 저장할 필요가 없습니다.
-리포지토리가 항상 빌드하고 실행하는 최신 버전을 제공 할 필요는 없습니다. 어떤 프로젝트는 그런 식으로 작동하지만 어떤 프로젝트는 그렇지 않습니다. 결정은 프로젝트 관리자에게 달려 있으며 많은 요인에 달려 있지만 프로그램을 크게 변경할 때 결정이 내려 진다고 생각합니다.
* How often do you commit? As often as one would press ctrl + s?
가능한 한 자주. 소스 제어하에 있지 않으면 코드가 존재하지 않습니다 :)
빈번한 커밋 (이후 더 작은 변경 세트)을 사용하면 변경 사항을 쉽게 통합하고 무언가를 중단하지 않을 가능성을 높일 수 있습니다.
다른 사람들은 함수형 코드가있을 때 커밋해야한다고 언급했지만 조금 더 자주 커밋하는 것이 좋습니다. 몇 번이나 소스 컨트롤을 빠른 실행 취소 / 다시 실행 메커니즘으로 사용하는 것으로 나타났습니다.
내 자신의 지점에서 일할 때 나는 가능한 한 많이 커밋하는 것을 선호합니다 (문자 그대로 Ctrl + s를 누를 때마다).
* What is a Branch and what is a Tag and how do you control them?
SVN 서적 읽기 -SVN을 배울 때 시작해야하는 곳입니다.
* What goes into the SVN?
문서화, 빌드에 필요한 작은 바이너리 및 일부 가치가있는 기타 것들이 소스 제어로 이동합니다.
커밋 빈도, 커밋 메시지, 프로젝트 구조, 소스 제어 및 기타 일반적인 지침에 대한 리소스는 다음과 같습니다.
- 버전 관리 모범 사례 (나만의 블로그)
- 조기 체크인, 종종 체크인 (코딩 공포) (코멘트에는 많은 조언이 포함되어 있음)
- KDE의 커밋 정책
이 스택 오버플로 질문에는 다음과 같은 유용한 정보가 포함되어 있습니다.
- 두 개 이상의 언어를 혼합 할 때 소스 코드 기반 구성 (예 : Java 및 C ++)
- 좋은 커밋 메시지에 대한 제안 : 형식 / 지침?
- 소스 컨트롤에 변경 사항을 커밋하는 빈도는?
- 버전 관리 학습 및 학습
분기 및 태그 지정과 같은 기본 Subversion 개념에 대해서는 Subversion 책 에서 잘 설명되어 있다고 생각합니다 .
이 주제에 대해 조금 더 읽은 후에 알 수 있듯이이 분야의 모범 사례에 대한 사람들의 의견은 다양하고 때로는 상충됩니다. 가장 좋은 방법은 다른 사람들이하는 일을 읽고 자신에게 가장 적합한 지침과 관행을 선택하는 것입니다.
I don't think it's a good idea to adopt a practice if you do not understand the purpose of it or don't agree to the rationale behind it. So don't follow any advice blindly, but rather make up your own mind about what you think will work best for you. Also, experimenting with different ways of doing things is a good way to learn and find out how you best like to work. A good example of this is how you structure the repository. There is no right or wrong way to do it, and it's often hard to know which way you prefer until you have actually tried them in practice.
Commit frequency depends on your style of project management. Many people refrain from committing if it'll break the build (or functionality).
Branches can be used in one of two ways, typically: 1) One active branch for development (and the trunk stays stable), or 2) branches for alternate dev paths.
Tags are generally used for identifying releases, so they don't get lost in the mix. The definition of 'release' is up to you.
I think the main problem is the mental picture of source control is confused. We commonly have trunk and branches, but then we get unrelated ideas of tags/releases or something to that affect.
If you use the idea of a tree more completely it becomes clearer, at least for me it is.
We get the trunk -> forms branches -> produce fruit (tags/releases).
The idea being that you grow the project from a trunk, which then creates branches once the trunk is stable enough to hold the branch. Then when the branch has produced a fruit you pluck it from the branch and release it as a tag.
Tags are essentially deliverables. Whereas trunk and branches produce them.
As others have said, the SVN Book is the best place to start and a great reference once you've gotten your sea legs. Now, to your questions ...
How often do you commit? As often as one would press ctrl + s?
Often, but not as often as you press ctrl + s. It's a matter of personal taste and/or team policy. Personally I would say commit when you complete a functional piece of code, however small.
What is a Branch and what is a Tag and how do you control them?
First, trunk is where you do your active development. It is the mainline of your code. A branch is some deviation from the mainline. It could be a major deviation, like a previous release, or just a minor tweak you want to try out. A tag is a snapshot of your code. It's a way to attach a label or bookmark to a particular revision.
It's also worth mentioning that in subversion, trunk, branches and tags are only convention. Nothing stops you from doing work in tags or having branches that are your mainline, or disregarding the tag-branch-trunk scheme all together. But, unless you have a very good reason, it's best to stick with convention.
What goes into the SVN? Only Source Code or do you share other files here aswell?
Also a personal or team choice. I prefer to keep anything related to the build in my repository. That includes config files, build scripts, related media files, docs, etc. You should not check in files that need to be different on each developer's machine. Nor do you need to check in by-products of your code. I'm thinking mostly of build folders, object files, and the like.
Eric Sink, who appeared on SO podcast#36 in January 2009, wrote an excellent series of articles under the title Source Control How-to.
(Eric is the founder of SourceGear who market a plug-compatible version of SourceSafe, but without the horribleness.)
Just to add another set of answers:
- I commit whenever I finish a piece of work. Sometimes it's a tiny bugfix that just changed one line and took me 2 minutes to do; other times it's two weeks worth of sweat. Also, as a rule of thumb, you don't commit anything that breaks the build. Thus if it has taken you a long time to do something, take the latest version before committing, and see if your changes break the build. Of course, if I go a long time without committing, it makes me uneasy because I don't want to loose that work. In TFS I use this nice thing as "shelvesets" for this. In SVN you'll have to work around in another way. Perhaps create your own branch or backup these files manually to another machine.
- Branches are copies of your whole project. The best illustration for their use is perhaps the versioning of products. Imagine that you are working at a large project (say, the Linux kernel). After months of sweat you've finally arrived at version 1.0 that you release to the public. After that you start to work on version 2.0 of you product which is going to be way better. But in the mean time there are also a lot of people out there which are using version 1.0. And these people find bugs that you have to fix. Now, you can't fix the bug in the upcoming 2.0 version and ship that to the clients - it's not ready at all. Instead you have to pull out an old copy of 1.0 source, fix the bug there, and ship that to the people. This is what branches are for. When you released the 1.0 version you made a branch in SVN which made a copy of the source code at that point. This branch was named "1.0". You then continued work on the next version in your main source copy, but the 1.0 copy remained there as it was at the moment of the release. And you can continue fixing bugs there. Tags are just names attached to specific revisions for ease of use. You could say "Revision 2342 of the source code", but it's easier to refer to it as "First stable revision". :)
- I usually put everything in the source control that relates directly to the programming. For example, since I'm making webpages, I also put images and CSS files in source control, not to mention config files etc. Project documentation does not go in there, however that is actually just a matter of preference.
Others have stated that it depends on your style.
The big question for you is how often you "integrate" your software. Test driven development, Agile and Scrum (and many, many others) rely on small changes and continuous integration. They preach that small changes are made, everyone finds the breaks and fixes them all the time.
However on a larger project (think government, defence, 100k+LOC) you simply can't use continuous integration as it's not possible. In these situations it may be better to use branching to do lots of little commits on but bring back into the trunk ONLY what will work and is ready to be integrated into the build.
One caveat with branching though is that if they aren't managed properly, it can be a nightmare in your repository to get work into the trunk, as everyone is developing from different spots on the trunk (which is incidentally one of the largest arguments for continuous integration).
There is no definitive answer on this question, the best way is to work with your team to come up with the best compromise solution.
Version Control with Subversion is the guide for beginners and old hands alike.
I don't think you can use Subversion effectively without reading at least the first few chapters of this.
For committing, I use the following strategies:
commit as often as possible.
Each feature change/bugfix should get its own commit (don't commit many files at once since that will make the history for that file unclear -- e.g. If I change a logging module and a GUI module independently and I commit both at once, both changes will be visible in both file histories. This makes reading a file history difficult),
don't break the build on any commit -- it should be possible to retrieve any version of the repository and build it.
All files that are necessary for building and running the app should be in SVN. Test files and such should not, unless they are part of the unit tests.
A lot of good comments here, but something that hasn't been mentioned is commit messages. These should be mandatory and meaningful. Especially with branching/merging. This will allow you to keep track of what changes are relevant to which bugs features.
for example svn commit . -m 'bug #201 fixed y2k bug in code' will tell anyone who looks at the history what that revision was for.
Some bug tracking systems (eg trac) can look in the repository for these messages and associate them with the tickets. Which makes working out what changes are associated with each ticket very easy.
The policy at our work goes like this (multi-developer team working on object oriented framework):
Update from SVN every day to get the previous day's changes
Commit daily so if you are sick or absent next day(s) someone else can easily take over from where you left off.
Don't commit code that breaks anything, since that will impact the other developers.
Work on small chunks and commit daily WITH MEANINGFUL COMMENTS!
As a team: Keep a Development branch, then move pre-release code (for QA) into a Production branch. This branch should only ever have fully working code.
The TortoiseSVN TSVN Manual is based on subversion book, but available in a lot more languages.
I thinks there is two way about committing frequency:
- Commit very often, for each implemented method, small part of code, etc.
- Commit only completed parts of code, like modules, etc.
I prefer the first one - because using source control system is very useful not only for project or company, the first of all it's useful for the developer. For me the best feature is to roll back all code while searching the best assigned task implementation.
참고URL : https://stackoverflow.com/questions/464417/how-to-use-svn-branch-tag-trunk
'Programing' 카테고리의 다른 글
| 161803398은 '특수'번호입니까? (0) | 2020.06.01 |
|---|---|
| SQL에서 조인 순서가 중요합니까? (0) | 2020.06.01 |
| ActionBarActivity에 비해 AppCompatActivity의 향상된 기능은 무엇입니까? (0) | 2020.06.01 |
| 가변 대 불변 개체 (0) | 2020.06.01 |
| ASP.NET Identity의 IUserSecurityStampStore 란 무엇입니까 (0) | 2020.06.01 |