Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
846 views
in Technique[技术] by (71.8m points)

project management - Why should my team adopt source control?


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

Let's compare two examples, one development environment that uses source control, and one that doesn't.

  • A: Does Use
  • B: Does not Use

Scenario 1: A project is requested, completed, and rolled out

A + B) Programmers develop the project internally, when it's completed, push it out to testing, and then deliver to the client (whoever that may be)

Not much difference, in the big picture

Scenario 2: After a project is released, the client decides that they don't want feature X

A + B) Developers remove the code that the client doesn't want, test, and deliver.

Again, not much difference.

Scenario 3: Two weeks later, the client decides that they actually DO want feature X

A) Developers reintegrate the code they took out in 2 back into the normal development tree, test, and deliver.

B) The developers search for the old code on their personal machines, the file server, and backups. If they find the code, they must manually reinsert each file. If they do not, they probably have to recode that entire feature.

It's easy to get old code that you took out for one reason or another

Scenario 4: There's a strange bug in the system where a function is supposed to return a boolean result, but always returns false. It wasn't like that two weeks ago.

A) Developers examine all the old versions of the software, and figure out that a return false directive isn't in the proper scope - it's executing inside a loop instead of outside.

B) Developers spend weeks trying to figure out what the problem is. Eventually, they notice the return on the wrong line, and fix it. Not having source control means they had to examine each and every file that was executed, rather than finding the differences from when it was working and now.

Scenario 5: Someone breaks the build. It gets past testing and is only noticed weeks later.

A) The team examines the commit history, finds out who broke the build, makes that person fix it and buy the team dinner.

B) The team has to go back through the entire project to find the error, but can't figure out who put that code in. Developers blame each other, and the team dynamic fails.

It's easy to see who committed what, when, and why.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...