It's where a stream of updates (usually in code) splits to do a new piece of work.
Let's imagine you have some code that is on "version" 42. In the most simplistic stream of development, people will make changes and commit code directly in sequence, so the first developer will commit something and that will be version 43, the next change is 44, 45, 46 and so-on.
But, most projects won't work like that. Now imagine you have three people:
- Alice is in charge of looking after the software in production
- Bob is a developer with a task to add gadgets to the software
- Charlie is a developer who has a list of bugs to fix.
Alice needs to see the code as it is in version 42, and that's no problem for any source control. But it would be best for Alice if version 42 is static and when she goes to source control, the latest code is what is in Production.
- Bob wants to add code
- Charlie wants to add code
- Bob and Charlie do not want to have to cope with the other developer's code which might break their own stuff, or be unstable or introduce unexpected change.
A branch is what they do to separate their lines of development.
The most intuitive branching strategy for Alice, Bob and Charlie is to branch from 42, leaving it untouched for Alice. Bob will branch, creating a copy of the code called (say) 42-Bob and Charlie will branch creating 42-Charlie. You end up with more versions within those branches (42-Bob-1, 42-Bob-2, 42-Charlie-1, 42-Charlie-2 etc)
All three can then carry on with their work, knowing that the code they are working on is theirs and the others won't interfere with their branches.
When Bob and finishes his work and it all goes into production, he will then merge back to "main", creating version 43
When Charlie has a release, she will do the same, merging back in to create version 44, but her merge has a bit more complexity because she was working on code that was at version 42, and there may be things in 43 that have changed, so there needs to be checking to ensure that any such merge is safe to do. Most source control tools have, at a very minimum "Sorry Charlie, Bob changed that file in version 43, here's some info on what he did, can you re-check to see if it's ok to add your updates too?"
There are other branching models - another one for example is to "branch on checkpoint or release" - when version 42 goes live, you create a branch of the code and then dead-head it, disallowing any changes. Alice knows 42 is in production, so she looks at branch 42 if she needs to, with maybe Charlie doing bug fixes in 43, 44, 45 etc, and Bob working in a "new stuff" branch as well (or alongside Charlie maybe)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.