SVN 모범 사례-팀 작업

SVN 모범 사례-팀 작업

---

저는 SVN으로 시작합니다. 나는 기본 명령을 알고 기본 원칙을 이해합니다. 팀 환경에서 Subversion으로 작업하기위한 팁이나 모범 사례가 있는지 궁금합니다.

코드를 커밋 할 때 합리적으로 자세한 메시지를 추가하는 이점을 볼 수 있지만 명심해야 할 다른 사항이 있습니까?

모든 훌륭한 답변에 감사드립니다. 많은 도움을 받았습니다.

---

빈번한 커밋을 장려하십시오. 버전 관리를 처음 접하는 팀원은 "올바르게 작동"할 때까지 코드를 저장소에 보관해야한다고 생각할 수 있습니다. 모든 사람에게 가능한 한 빨리 문제를 발견하도록 일찍 그리고 자주 수행하도록 가르치십시오. 코드가 작동 할 때까지 유지하는 대신 팀원이 트렁크를 깨뜨릴 수있는 기능에 대한 분기를 생성하도록 제안하십시오. 그게 ...

분기 및 태깅 관행을 확립하십시오. 기능에 대한 분기 외에도 팀원이 큰 버그 수정을 위해 분기를 사용하도록 권장하십시오. 작업 시작과 끝에 주요 버그 수정에 태그를 지정합니다. 프로덕션 / QA 릴리스에 대한 태그 (및 가능한 분기)를 유지합니다.

트렁크에 대한 정책을 수립하고 고수하십시오. 한 가지 예는 "트렁크는 항상 오류없이 빌드되어야합니다."입니다. 또는 "트렁크는 항상 모든 단위 테스트를 통과해야합니다". 아직 트렁크 기준에 맞지 않는 작업은 반드시 지점에서해야합니다.

---

코드 변경으로 서식 변경을 커밋하지 마십시오.

거대한 파일의 공백 ( Control+ K+ D) 을 재구성하려면 괜찮습니다. 실제 논리적 변경과 별도로 서식 변경을 커밋합니다. 파일에서 함수를 이동하려는 경우에도 마찬가지입니다. 실제 편집과는 별도로 이동을 커밋하십시오.

---

내가 항상 고수하는 핵심 개념 중 하나는 관련 코드 변경 사항을 함께 커밋하는 것 입니다. 결과적으로 동일한 커밋에서 관련없는 코드 변경 사항을 커밋하지 않습니다 . 즉, 하나의 커밋에서 2 개의 버그를 수정하지 말고 (동일한 수정 사항이 아닌 경우) 2 개의 커밋 각각에서 절반의 버그 수정을 커밋하지 마십시오. 또한 시스템의 관련없는 부분에 새로운 개선 사항을 추가하거나 다른 작업에 필요한 사항을 추가해야하는 경우 개선 사항을 별도로 커밋합니다. 아이디어는 누구나 자체적으로 (또는 자체적으로 롤백하기) 원하는 변경 사항은 별도의 커밋이어야한다는 것입니다. 병합을 수행하거나 손상된 기능을 롤백 할 때 많은 골칫거리를 절약 할 수 있습니다.

---

이미 많이 언급되었으며 여기에 몇 가지 더 있습니다.

1. 소스 제어에서 원하지 않는 파일 (예 : 구성, 컴파일 된 파일 등)이있는 경우 무시 목록에 추가합니다 . 이렇게하면 항상 SVN에 알려지지 않은 것으로 표시되는 빈 파일 목록을 예상하여 추가하지 않은 파일을 발견 할 수 있습니다.

2. 커밋 된 변경 사항 및 이상적으로는 패치와 관련 하여 개발자 메일 링 목록 (또는이 대상에 대한 특정 항목)에 이메일을 보내는 커밋 후 이벤트를 추가 합니다.

3. 버그 추적기와 통합 하여 커밋에 대한 참조가 차이점에 대한 링크와 함께 버그 / 기능 요청에 표시되도록합니다. MantisBT 와 같은 버그 추적기가 이를 지원합니다.

4. 지속적인 통합 (예 : CruiseControl.NET ), 빌드 용 NAnt 및 단위 테스트 용 NUnit / VS 와의 통합을 고려하십시오 . 이렇게하면 사용자가 코드를 체크인하거나 예약 된 간격에 따라 코드가 컴파일되고 단위 테스트가 실행되고 개발자는 프로세스에 대한 피드백을받습니다. 이것은 또한 저장소가 고장난 경우 (즉, 빌드하지 않는 경우) 나머지 팀에게 경고합니다.

---

글쎄, 기본 :

• 버전에 대한 품질 보증을 시작하기 전에 태그 생성
• 위험한 변경 (예 : 대규모 리팩터링) 전에 태그 생성
• 코드를 고정하기 위해 릴리스 된 버전에 대한 분기를 만듭니다.
• 사람들이 코드에 대한 작업을 시작하기 전에 업데이트하고 커밋하기 전에 다시 한 번 업데이트하는 것을 알고 있는지 확인하십시오.
• SVN을 사용하면 여러 사용자가 동일한 파일을 여러 번 체크 아웃 할 수 있습니다. 모든 사람이 발생할 수있는 갈등을 해결하도록하십시오.
• 두 명 이상의 사용자에 대해 동일한 SVN 계정을 사용 하지 마십시오 . 끔찍한 일이 발생할 수 있습니다.

---

사람들이주는 대답은 훌륭합니다. 이것의 대부분은 SVN의 모범 사례에 대한 svn 사용자 문서에 요약되어 있습니다.
반복하려면 :

1. 저장소 구조 설정 (아래에 트렁크, 브랜치 및 태그가있는 프로젝트 루트가 있어야 함)
2. 정책 재 분기 (사설 분기, 마일스톤 / 릴리스 / 버그 당 분기 등)를 선택하고이를 고수하십시오. 그보다 적은 분기보다 많은 분기를 권장하지만 사설 분기는 필요하지 않습니다.
3. 태그 재 지정 정책 선택-태그가 많을수록 좋지만 가장 중요한 것은 태그 명명 규칙을 결정하는 것입니다.
4. 트렁크에 다시 커밋하는 정책 선택-트렁크를 가능한 한 "깨끗한"상태로 유지합니다. 언제든지 해제 할 수 있어야합니다.

---

내가 고수하는 모범 사례를 요약하고 싶습니다.

1. 바이너리를 커밋하지 마십시오 . Nexus , Ivy 또는 Artifactory 와 같은 바이너리에 대한 별도의 저장소가 있어야합니다 .

2. 저장소 구조 가 있어야합니다 . 개인적으로 다음 저장소 구조를 사용합니다.

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. 특정 분기 유형 목록을 사용 합니다 . 내 목록은 실험적 , 유지 보수 , 버전 , 플랫폼 , 릴리스 입니다.
4. Use specific types of tags: PA (pre-alpha), A (alpha), B (beta), AR (alpha-release), BR (beta-release), RC (release candidate), ST (stable).
5. Minimize necessity of merging. There should be rules when merging is possible/encouraged and when it is not.
6. Version numbering. There should be established version numbering approach to stick to. Usually it is described in such document as Software Configuration Management Plan, it is a part of high-level project documentation. Personally I use complex version numbering approach. According to this approach, versions have following patterns: N.x.x (maintenance/support branches), N.M.x (release branch), N.x.K (build), N.M.K (release).
7. Commit as frequent as possible. If it tends to be difficult (for example, when there should be too many changes to be made in order to implement feature and even compile code), experimental branches should be used.
8. Trunk should contain the latest development. For example, when there is a choice where to develop new major version (N.x.x) of application, in trunk or in branch, decision should be always made in favor of trunk. The old version should be branched into the maintenance/support branch. It assumes that there is a clear distinction between major versions and their specifics (architecture, compatibility) emerges as early as possible.
9. Strict 'do not break the build' policy on release branches. In the meantime, it should not necessarily be strict for trunk as long as it might have either experimental development or codebase which needs merge issues to be resolved.
10. Use svn:externals. It will allow to modularize your project, establish transparent release management procedure, divide and conquer over different functionality.
11. Use issue tracking. You will be able to point out the issue reference inside the commit message.
12. Disable empty commit messages. It could be done using pre-commit hooks.
13. Define which branches you want to continuously integrate. For example I prefer using continuous integration for trunk, maintenance and release branches.
14. Establish continuous integration policy for different types of branches. As I pointed out earlier, most strict "don't break the build" rules apply to release branches, while trunk and maintenance branches might be broken sometimes. Also there is difference between list of inspections run on the trunk/maintenance and release branches.

You can find outline of my subversion best practices in the form of diagram illustrating main principles of software configuration management approach I use.

---

One thing I've found very useful is the svn:external property which means you can reference directories from other repositories into your own. It's gives really nice ways of organizing your code and data. Some examples are:

1. If you have a separate repositories for code different modules/libraries and reference in the ones you are using. This means that you can have a meta repository for every executable. If it's a small executable that only uses a few modules, you won't need to checkout the entire tree. An effect of this is that you get SVN revision numbers per module.
2. Adding large binary data such as compiled versions of libraries to code repository is generally considered a bad habit, but it can be really convenient. If you just add all versions of all libraries you use to a different repository you can get the best of two worlds. You reference in the versions of the libraries you use into your code repository. When checking out your code repository you'll get both the code and the binaries as well. However the binaries are stored in a large repository which you don't need to backup as rigorously as your source code and the source code repository stays small and contains only text.

---

Use integration with your bug tracking software. If you use Bugzilla, you can set it up so if your comment begins with "Bug XXXX" your SVN comment is automatically added as a comment to the given bug, including a link to you SVN web interface to that revision.

---

Learn about SVN's branching and merging tools and conventions.

The best way to work with other team members is to break work up into complete development features/fixes, then work on individual changes, each in a branch. Then merge the changes back to the mainline branch/trunk when completed/ready/approved to be merged in.

This way individuals can work towards a common goal (either on the same branch or seperate branches) without colliding with other changes.

Your mileage may vary, and this may be overkill for only two or so people.

---

It makes it much easier if you're using good tools that integrate well with SVN. These make it easy to see what's been changed and to then commit all or part of your changes and to frequently update your working copy to the latest version in SVN.

I recommend Tortoise SVN (If you're using Windows) and Visual SVN (if you're using VS).

Also see if you can set it up so that you get e-mail or similar notification any time a change is committed (usually also including the commit message and a list of changed files). Services like CVSDude offer this. I find it helpful to know both that an update has been made and then to have some idea of what's contained in that update before updating my working copy.

---

Besides branching policies et al. (where one size does definitely not fit all), you should have good commits:

• The commit should relate to a single piece of work if possible; a bug fix, a new feature- there should be some 'logic' to what changes you committed
• The commit should have a descriptive comment that will help you locate it browsing the repository history. Most people suggest writing a single sentence at the beginning that describes the whole commit and a more detailed account below
• If possible, you should tie the commit to your bug-tracking system if possible. Trac, Redmine et al. let you create links from bugs to commits and vice versa, which comes in very handy.

---

The golden rule for source control: Check In Early, Check In Often

For tips how to organize your repository:

• How do you organize your version control repository?
• SVN Book Chapter 5. Repository Administration
• Repository layout

---

Consult with your team about their changes, or at least look at the diff very carefully, before fixing any merge conflicts. Ask them to review the merged code themselves to make sure their additions were not lost in the merge.

---

One thing that I have seen that reduces broken commits is to have good pre-commit scripts. For example, you can run any unit tests before the change is committed. This will cause commits to be a little slow, but you save time by avoiding stepping on someone's toes and having to apologize. Of course this becomes a lot harder to manage when you have a large development team and very frequent commits.

---

One of the examples of integration with bug-tracker and commit policy enforcing could be Trac's svn pre/post-commit hook scripts, which can refuse commit if commit message doesn't reference any ticket in bug-tracker and add comments to existing tickets based on message contents (i.e. commit message may contain something like "Fixes #1, #2 and #8", where #1, #2, #8 are the tickets numbers).

---

SVN by itself is a good start and some of the other posters have offered some great suggestions on best practices.

The only thing I would add is that you should be hooking up SVN with CruiseControl or TeamCity to drive a Continuous Integration process. This will send out build emails and let everyone know when someone broke the build.

It will be very telling early on who's following your process and who isn't. Might lead to some friction but your team will be better off in the long run.

---

Best practice to use SVN:

1. When you first came to office and open your Eclipse project, the first step has to be done is to update your project.

2. After taking update, start your work. When you finished your coding, check it properly, whether your application runs properly without any exception. Once you are sure about your code is working fine, it's time to commit the code.

Note :While committing the code, don’t commit directly. Make a synchronization with server and check what are all needs to be committed. Note: Don’t commit the whole folder once. Because you may have done some changes to file for your requirement or you may have deleted some files in your local system. But the settings are different on the server. So check the files individually and commit the code.

3. Don’t commit/update conflict files directly.

4. When to do override and update?

   When you are pretty much sure that you don’t need any of your local changes and want to update the server copy completely. Note down that once if you do the override and update, you will not get any of your local changes.

   Note: Don’t keep the project without updating for more than a day. Also don’t keep the code without committing for many days.

5. Communicate who are all working in same component and discuss what changes they have made every day.

6. Don’t commit the properties and configuration file unless there is some reason. Because the settings will be different on a server and in the cloud.

7. Don’t commit target folders into SVN, only source code and resource folders has to be maintained in an SVN repository.

8. When you lost your code, don’t panic! You can get back the earlier copy from the SVN history.

9. Don’t checkout the project into multiple places of your disk. Checkout it in one location and work with it.

---

---

• Precise comment for every commit

• Don’t break the (mainline) build!

• Commit as soon as a logical unit changes

• Avoid using Subversion as a backup tool

• A little branching/merging as possible

.

More details can be found in SVN best practices.

---

Do DEV work on Branches

1. Frequent commits to your branch
2. Discrete/Modular commits to your branch (see here)
3. Update/Merge-from trunk often. Don't sit on your branch without re-basing

Community Trunk

1. Should always build/work
2. One issue per commit (again see here) Mostly so you or others can back-things-out one at a time
3. Don't conflate refactoring/whitespace changes with logical changes. Your teammates will have a tough time extracting what you actually did from a commit

Remember that the more incremental, modular, discrete and succinct you make your commits, the easier it will be for you (or likely others) to:

• Incrementally back out changes
• Visually realize what you actually did without sifting through tons of white space and variable name changes.
• The commit messages mean more when the ratio of work done to message length is lower.

---

Use this for the comments template:

[task / story xxx][minor / major][comment][follow up comment][URL to bug]

참고URL : https://stackoverflow.com/questions/417599/svn-best-practices-working-in-a-team