How and which tool should I use for Source Control? [closed]_问答_开发者

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 7 years ago.

Improve this question

A little bit of Background first:

I have been using Team Foundation Server for about few months and know pretty much how to use it. I have been using it for my project on Codeplex. They required TFS and it was in my Visual Studio Installations, so basically I never knew what all it took to get it to work as it seamlessly worked inside Visual Studio and I just had to do Check In and Check Out stuff...

But now I wanted to see what other Alternatives were available and first installed Mercurial command line (which I never used), then searched for a GUI alternative and installed TortoiseHg and followed instruction from documentation on its Website. Then it said to install a 3 way Diff tool... I searched for it and then Found TortoiseSVN; I开发者_JAVA技巧 thought it must be some plugin or something so I searched SO for questions related to my situation when I stumbled upon this SO Question and was pretty mesmerized by so many tools for different work.

Now:

Can somebody explain what all tools are for source control. Do I have to install a different tool for every different task. Isn't there any single package for all of them. And basically what are the tasks we perform in Source Controlling. I only know Check In, Check Out and checking difference from Codeplex Website. What else should I know.
Does every website like Git, BitBucket, etc use different Tortoise (xxx) for their source control.
Are Source Control and Version Control different terms

Please help..

This is a huge topic and will be impossible to provide a single all-encompassing answer. Nonetheless here are a few thoughts, assuming you are looking for more of a Software Configuration Management solution rather than a simple Revision Control System type approach:

Release Management:

In addition to concurrency control (check-in, check-out, etc.) your SCM can/should also provide history, tagging, branching, and other release management type capabilities. That is, it should always provide a single source of truth as to what source files when into which release, service packs, etc. In order to do this, your build environment needs to be well integrated into your SCM.

WIP Management:

A good SCM system will allow to you compare your work-in-progress to the latest checked in revision. It should also let you revert your WIP, shelve it temporarily, or merge another's changes on a file by file basis.

Documentation & Training

Do not underestimate how important it is to use a tool that can give you a ton of help, books, documentation, community support, and even paid support if needed. Also selecting a "popular" tool can mean that some new developers have one less thing to learn.

Continuous Integration:

Automated builds are a must for any serious organization and you should pick an SCM that can be access by your build systems (e.g. Hudson, CruiseControl, Bamboo, etc.)

Security

The SCM system should have a built in authentication system and also be able to use outside authentication providers as many organizations change over time. In addition, it should be able to support developers working outside the firewall, preferrably over http.

IDE and Build Tool Integration

To make all this stuff easier your SCM must be able to be seamlessly linked into your development system and any command line tools you use. This fact is made easier by the fact that almost all non-Microsoft IDE's support all SCM tools.

Source Browsing

Most SCM tools that I've seen have a number of very high quality, third party browsers such as Fisheye. So I discount this as a differentiating factor.

So which tool to use?

If your organization is fairly well contained within your company then pick Subversion. It is very popular, integrates with every IDE/OS/Build tool, works with ToroiseSVN, supports all platforms, supports multiple protocols, several UI, a powerful command line, a huge community, is free, and is rock solid. It also has an excellent free book.

If you have a highly distributed development group and/or expect to receive open-source contributions from many different folks, go with the distributed capabilities of Git.

Beyond these two, save yourself a ton of time and hassle and forget everything else....really. I realize I am being opinionated, but you kinda asked for an opinion.

If I was to advise something to you, it would be

Use mercurial (aka hg), and start by learning it in the command line. That way you will learn all basic concepts, which could be somewhat hidden from you when using only GUI overlay such as TortoiseHG. All with a good simplistic tutorial of course, perhaps widely known hginit which covers some simple usage scenarios.

That would be answer to "What else should I know" part, at least for a start. You can then explore by yourself, having a limited, but somewhat solid base. Or, at least, you will be able to ask more concise questions to learn more, or make more sense of the SO question you quote. Your question is somewhat broader than this, of course, but I would advise not to try to grasp everything at once. Each system has it's own quirks and specialties, but you shouldn't be worried by that fact now. Just as with programming -- you should not try to learn many languages at once, if you don't know any yet.

Ah, and as a finishing touch: Tortoise(xxx) is not exactly a revision control system, thats just a typical name for a shell-integrated Windows client to system xxx. As far as I'm concerned, the "Tortoise" part refers to "shell".

PS. the "Mercurial" advice is due to my personal taste of course, but also by the feeling that learning Hg will enable you to grasp most of the ideas from other systems quite easy (if you ever need to).

From my personal experience I would recommend looking at the new generation of 'Source Control Systems' that are called Distributed Version Control Systems. These are systems like Git (and I think Mercurial but I haven't used that.) that actaully store a full version control system locally and when you commit to the remote repository (push in git terms) you push the changes in your local version control system to the master version control system on the server.

Also Git is designed to make Branching a breeze. In systems like Subversion branching is not as easy but with Git Branching is the recommended practice of making changes. I have used Git, Subversion (SVN) and SourceSafe(the worst Source control System of the three by far!) and this is the major advantage of Git over more traditional Source Control Systems.

For Example if you are fixing a bug or adding a feature in a code base that uses SVN the standard practice would be to

Check out the branch you are going to work in.
Make any bug fixes and test them.
Checkin the changes.

With Git or Similar systems you would

Branch the master branch locally (i.e. development, producton version 1.1, etc.).
Make any bug fixes and test in your locally branched version (i.e. you made a jira-123-bugfix branch for version 1.1).
Merge the branch back into your local copy of the master branch that you created it from and make sure everything is OK.
Then push the changes you made to your local copy of the master branch to the central Git repository.

The advantage of this is that if you have to go back and revist the bug fix you still have your local copy of that branch.

See articles like A Successful Git Branching Model for more info.