Im trying to understand subversion / git [closed]_问答_开发者

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

I am trying to understand and learn how to use subversion or git. Which do you recommend?

It seem so complicated and confusing.

I do a lot of PHP web development projects. I have a habit backing up project folders like project_name_version_date

What is the b开发者_如何学JAVAest way to learn for beginner?

How do you upload updated project from local machine to live website to a different server, how that be done from subversion / git? and reupload to new version again?

Can 2 or 3 people work on the same project at the same time? do they load the code files from the server? wouldn't it conflict each other... like they had removed the class objects, functions, etc.

What is the best way to learn for beginner?

http://svnbook.red-bean.com/nightly/en/svn.intro.quickstart.html
http://book.git-scm.com/

How do you upload updated project from local machine to live website to a different server, how that be done from subversion / git? and reupload to new version again?

With version control, you have a central repository and one or more working copies (git adds in a local repository at every working copy to allow distributed storage/management).

In your case, your live website and your development copy are both working copies - you checkout from the central repository to each of these locations. You then work on the development copy, and commit those changes to the central repository. Once you are ready to release, you simply perform an update on the live working copy which pulls all the changes from the central repository.

Can 2 or 3 people work on the same project at the same time? do they load the code files from the server? wouldn't it conflict each other... like they had removed the class objects, functions, etc.

Yes - each person has a working copy which they make changes to.

Conflicts are likely, and will happen from time to time - but SVN and Git can deal with a lot very easily. For example, changes to code in different places of the same file are simply merged in. Changes to code at the same place in the same file will typically require manual intervention.

Perhaps the worst conflicts that can occur are what SVN calls 'tree conflicts' - changes in the folder structure. This can be a real PITA to fix - but you have to really go out of your way to cause them.

That said, the potential for conflicts (and difficulty in resolving them) in non-version controlled environments is far, far greater.

There are some practices which help prevent major conflicts from occurring:

Modular code
Clear delineation of work - stop programmers treading on each others toes
Update your local copy before committing
Commit small, commit often - how small? Hard to say, you start to get a feel for this... but think in terms of functions and functionality.

I think Git is probably better to start with if you don't use anything else already - the distributed system means that you are more able to resolve conflicts at the local level before pushing up to the central repository. All of my projects are use SVN (at the office and at home), but I'm starting to use Git through the Drupal project, and like what I've seen so far.

GIT is the newer paradigm for version control. SVN has been around for a while but GIT and Mercurial are gaining traction as they allow for "distributed version control." This means that there is no central server for your code. Everyone has the entire history and can send "patches" to each other to share code. However, git and mercurial do support a workflow very similar to having a central repository. Integrating git and "gerrit" is really great for working on a project with multiple people.

I suggest skipping svn because svn is an older technology that will actually hinder your understanding of git / mercurial because it is a different paradigm and uses different processes. GIT / mercurial works awesome just locally (no server and you are the only one using) and also for large teams.

GIT is more powerful but harder to use while mercurial has the basics in a more usable form factor.

I will suggest , go for git , you can access your repository on web also. With subversion, as far my knowledge goes, there is no such provision. But this should not be only reason. I have used both, git is very useful. Git's main advantage is that you don't have to be connected to master repository always. You can read more in this question which has been explained in nice way Why is Git better than Subversion?

As you are new to the whole Version/Source Control concept. I suggest you read a bit about VC in general.

The best way to learn would be to actually use a VCS for your day to day projects. Yes many people can work on the same things at once. And then 'conflicts' can happen. But the modern VCS lets you do something called merging.

I suggest you start with learning about git. As you are new to the whole thing it shouldn't be very hard for you. But IMHO learning SVN(which is a 'centralized version control system) and then moving in to git (which is a distributed version control system) tends to complicate things. A lot of people feel distributed VCS are the future. So i suggest you start learning either git or Hg, both are good VCSs.

Good Luck!

You should read a tutorial on Subversion and stay very far away from Git until you are reasonably experienced in SVN.

The best way to learn is follow a hands-on tutorial and then try the same things out yourself during your normal development workflow.

And certainly many people can work on the same project, that is one of the main reasons we use version control.

I would strongly recommend checking out http://hginit.com/ It uses Mercurial which is very similar to Git, but the important thing to gain from hginit is how distributed version control (and version control in general) work both independently and as part of a team. Once you understand the concepts in hginit, which distributed source control tool tool you pick is not nearly as important.

Subversion and git are very different in the way they deal with code, but the goal is the same.

Subversion is a centralized solution to source control. Git is a distributed solution to source control. In both cases, you can use them by yourself only or an arbitrarily large team can use them.

Subversion is centralized, meaning there is only one server. All the code lives on that machine. It's a little simpler conceptually to deal with this.

Git is distributed, meaning there are a lot of servers (everyone is a server and a client). This makes it a little more complicated to understand which one is the "right" server.

Right now, you are creating a copy of the files you want to keep somewhere else on the disk and using that as a backup. When you do this, you are doing several steps at a time (at a conceptual level):

Deciding which files you want to backup

Most source control needs your help to tell it which files to track. This is known as the add command in both git and subversion.
Backing up those files so that future changes do not impact them

This is done by commiting the changes to the files your source control is tracking for you. In subversion this is done with commit. In git, add makes git aware of the changes you make to the files and commit makes the changes saved in a permanent manner.
Labeling the copy of the files in a manner that makes sense to you

This is done in multiple manners in the different source control technologies. Both have a history of the commits, the concept of branches/tags and different repositories (though code doesn't normally change between repositories in subversion).

In Subversion, the code is on a single server. Everyone gets it from there (originally with checkout, afterward with update). In git, you fetch remote changes from another repository.

Git has somewhat superior conflict resolution (two people changing the same thing at the same time) to subversion, but you can still get into plenty of merge headaches if you are not careful. Git rebase can be helpful, though I've only used it in an individual manner so I have not had much conflict resolution practice yet.

Git has some tools that some people swear by (bisect and grep) that I have found to be somewhat useful. Your mileage may vary :)

It's largely a matter of comfort, but since you are a beginner (and presumably willing to spend some time learning a new skill), I will recommend git. As someone who has used svn and git, I think your workflow looks like it would be helped by git.

Here's some questions you need to answer for yourself when thinking svn vs. git:

Are you in a company where policy prevents you from using git? (If yes, use svn).
Do you have a workflow wherein you like to create a 'topic branch' to develop a feature, and then merge it into main when you believe that feature works well? (If yes, git is better, because it actually encourages you to create branches, and merge them back very easily, whereas svn is total hell as far as creating branches and merging them into main is concerned).
Do you prefer to commit often in small chunks so that you have a nice clean record of changes that you can selectively unroll? (I would argue that this style of development is supported better by git).
Look at this command: http://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html . I cannot tell you how many times I have had to do a custom release wherein I pull specific features and 'compose' an image / website / app for a quick demo. If you think you will be doing this often, think how you would do it in subversion. I can predict in advance that it's not going to be a picnic :)

There are tons of other reasons, but if your workflows look like what I have described, then you should go with git.

You can learn git from this great resource: http://progit.org/book

And remember, if you are stuck with svn and would still like to use git, that is easy too!

http://progit.org/book/ch8-1.html