I'm using Visual C++.

I've been waiting to ask this question, but because Markypooch has mentioned the term branching for git in another post:

Quote

(You can branch off the main project and work on smaller features in a way that won't destroy the build when something goes horribly wrong).

So, I though I'd ask now.  I am hoping for responses to be understandable toward a beginner/youngster and comprehensive too.

When everyone is working as a team on a project be it with Git or a regular software development team with source control how is the software worked on as a team.

I think the wording is "checking out parts of the software."

So if two people are needing to work on one part at the same time does one programmer wait for the other programmer or is there some other sort of methodology?

What if one is looking for an error and you don't know where it is and other members have "checked out parts of the program" how do people work/debug the same code.

And how does everyone stay organized in the debugging process?

Do people write portions of functions that one can guarantee more likely to work?

Maybe it is called merging when two programmers work on the same section at once and it is reassembled by hand while staying organized and well documented?

Perhaps we use instructive comments:

//Put a while loop here that...

//This function will take parameters that fit the requirements of...  and will cause the variables to ....

Maybe communication for using the same function:  my part will take and cause... your part will take and cause, and we build it in a fashion that is modular.   

When one person writes a program for themselves they can look at everything for  the bugs and solve them, how does this compare with working as a team?  Is more confidence and ability and organization needed?

Maybe we describe interfaces of modularity and use partiality.

Sincerely and Thankfully (this has been on my mind for a while now,)

Josheir

First, a bit of introduction to work with source control. Details depend on the system you are using, but in a nutshell, there is a server with the master version of the code (as, for instance, github.com). Everybody who needs to work with the code, downloads a copy of the code from that server into their computer and work on that local copy in their computer. Once they are done working on a particular feature, they update the code in the server with their changes, and now the master version has their changes available to anybody that's going to work with that code in the future.

The good thing about source control systems, is that they allow multiple people to work on the same codebase at the same time. When two people have been working on the same codebase at the same time, they didn't see one another's changes because they were working on their local copies. They will see one another's changes when they try to update the master version with their changes, and someone will have to merge both updates. One of them is going to be lucky and update the master version before anybody else, so the master version will be the same that they downloaded. No trouble.

The next person that tries to update the master version with their changes, will find that the master version is no longer the same code they have been working on. Then, that person will have to download the changes and make sure their code works. If they are lucky, the previous person won't have touched the same code as them, the source control system will be smart enough to merge their changes and everything will work out. If not, they will have to go over their code and make sure that the recently updated master version works with their changes before updating again the master version.

1 hour ago, Josheir said:

When everyone is working as a team on a project be it with Git or a regular software development team with source control how is the software worked on as a team.

I think the wording is "checking out parts of the software."

So if two people are needing to work on one part at the same time does one programmer wait for the other programmer or is there some other sort of methodology?

In my experience, you usually try to avoid working on the same part of the code. If I'm working on the same feature with another developer, we either sit together in front of the same computer and work together (that's usually known as pair programming, by the way) or work on different parts of the code.

It happens, however, that you end up touching the same part of the code as somebody else that is working on a different feature. In those cases, if the person modifying the code sits close to you, you just sit together and review the parts of the code that you both have changed to make sure that both features work properly. Otherwise, the other person has hopefully written tests to make sure their feature works, so you fix any compilation issues, run the tests and fix anything that is not working.

1 hour ago, Josheir said:

What if one is looking for an error and you don't know where it is and other members have "checked out parts of the program" how do people work/debug the same code.

And how does everyone stay organized in the debugging process?

Debugging has nothing to do with source control. When you debug, you use the copy of the code in your computer, so you don't use or affect the master version of the code at all.

I agree with everything Avalander said.

Additionally, I would also stress that if you are working in a team and you are doing something which might affect the workflow of others, communication is vital. Whether it's a quick check to make sure you're not both trying to fix the same bug without knowing that the other person is doing the same, or for planning out more large-scale tasks.

It's also important that, when (not if) things don't go exactly as planned, you are able to communicate with others and quickly find the best way forward.

Great, exactly as needed.  Simple and to the point!

Thank you; Sincerely,

Josheir

To nitpick on something Avalander said (it's generally true/correct, but there's one caveat):

Quote

there is a server with the master version of the code (as, for instance, github.com). Everybody who needs to work with the code, downloads a copy of the code from that server into their computer and work on that local copy in their computer. Once they are done working on a particular feature, they update the code in the server with their changes, and now the master version has their changes available to anybody that's going to work with that code in the future

The model Avalander described is called "distributed" source control -- that's how git and some others (like mercurial) work.  There are older source control systems (like CVS and SVN) that do not work like that.  I'll leave it as an exercise for you if you want to research the differences.  The important point is that not all source/version control systems are created equal.

That said, distributed version control systems, such as git, are immensely popular nowadays because the distributed model operates relatively cleanly, and it mitigates (but does not totally eliminate, so be careful!) the risk of completely destroying the code repository.  These days, you'd be hard-pressed to join a software project team that isn't already using a distributed system, so the exercise of researching other version control systems would probably prove to be more educational than practical.  But it's still probably useful to know and understand.

On another note, this may be a bit overkill for you right now, but keep the name "Git Flow" in your memory.  It's a git-based work flow meant for teams of programmers:  https://danielkummer.github.io/git-flow-cheatsheet/

2 hours ago, masskonfuzion said:

The model Avalander described is called "distributed" source control...

I beg to disagree. Distributed source control means that when you clone the repository, you get a copy of the whole repository, with its commit history and stuff, in your local machine. I suggest checking out the link below for differences between traditional and distributed source control systems.

https://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

I beg to disagree with your disagreement. Didn't you describe distributed source control?  Maybe I made a logical leap after reading what you wrote -- You said yourself:

Quote

there is a server with the master version of the code (as, for instance, github.com). Everybody who needs to work with the code, downloads a copy of the code from that server into their computer and work on that local copy in their computer.

I assumed you were implying that when you download from, e.g., github, you're getting the whole repository, plus commit history.  That is, in fact, how github (or any other git repository) works.

Even the git website itself describes git as "distributed" source control:  https://git-scm.com/

I wasn't saying you were wrong before; I was adding detail..  I'm not trolling here, just trying to be precise.

No, I think it's quite clear that Avalander's description fits pretty much every common source control usage. In fact, it could be argued that a true distributed source control model might not actually have a 'master' source copy, since each copy is essentially equal.

Don't get confused by the Git references and the fact that Git is a distributed source control system - if the main shared copy of the code lives on Github.com, that's practically no different to having a CVS or Subversion server somewhere. Coders connect to the server, pull down the files they work on, edit them, and push them back to the server. Git (like Mercurial, etc) just offers more flexibility in that every repository can act as a server if necessary.