work flows
satya - 4/25/2018, 11:25:12 AM
You can design what ever work flows that suits your need
Single person team
Small group of developers
Large group of developers
or any in between
satya - 4/25/2018, 11:25:41 AM
An article on workflows for a small team
satya - 4/25/2018, 2:31:00 PM
Remote and local branches
Assumption: 4 to 5 people are working on the same repo.
Keep the server repo as just one.
Master - Call this a master branch and consider this as what tags releases that go to prod
Integration - This is where the developers work is brought together
//Contributing branches
Developer 1 branch
Developer 2 branch
Developer 3 branch
Feature 1 branch
Feature 2 branch etc.
These branches start of with integration base line at that point in time and merge back into the integration branch.
These smaller branches although could be kept locally, one may want to keep them on the server for safe keeping.
Remember, merging with a branch ALWAYS happens locally!!! Then it will need to be pushed up to be part of the server.
Once the merge is completed the contributing branches can be deleted.
satya - 4/25/2018, 2:40:30 PM
Explain how a feature gets into a release
Developer 1 creates a new branch on the server called "feature-branch-f1".
Developer creates a local branch called f1 and ties these two branches together. (May be both can be done in 1 checkout command).
Developer changes (locally), commits (locally), and pushes "feature-branch-f1" to the server. This loop continues as long as needed.
Developer switches to integration branch. This will bring the latest committed code on integration branch.
Developer merges "feature-branch-f1" to the local integration branch. Any conflicts are resolved locally.
Developer tests the integration branch locally.
Developer pushes the integration branch to server. this push "should" check to see if the parent commit of integration branch locally is the same as the one on the server. (it may not be) because another developer may have pushed their code to the integration branch. If push will fail either these commits cannot be resolved automatically the developer is asked to re-pull the integration branch and repeat until the push succeeds.
Remember, push does not merge on the server. Merge always happens locally.
One can choose delete the "feature-branch-f1" soon after as these commits are now available in the integration branch.
satya - 4/27/2018, 5:43:01 PM
Let me see if this link works
satya - 4/27/2018, 5:48:11 PM
key notes
This describes in a picture what was written earlier.
This is conceptual view of how an integration stream (I) is constructed by multiple developers (D1, D2, D3).
The integration stream is at time merged with the release stream (M).
As stated the merge always happens locally.
So by the time D3 gets to push to the integration team, he/she has the changes of D1 and D2 locally (possibly) and D3 is merged on top and the whole thing is pushed into the integration team.
satya - 4/27/2018, 5:59:32 PM
Here is really how a server side branch is updated (locally) and pushed back up
satya - 4/27/2018, 6:01:36 PM
Question is, should Feature1 branch be on the server as well?
There is no need for the Feature1 branch to be available on the server as no other developer may need to see this!
however for backup purposes the devleoper1 may want to keep a copy of it on the server as well.
Also wonder if such a model supports developing from multiple computers by the same user, say one at work and one at home and stay in sync! I dont' know.