Working in cloned local repos with multiple branches, best practices?
I am new to working with Github branches so I'm looking for some general 'best practices' guidance on how programmers who are working together in the same remote repo should operate when it comes to pushing changes, when and how this should happen so as to minimize the chance of conflicts and accidental overwrites of others' existing work.
So far, our remote repo has just two branches, a 'main' and a 'Features'.
Both programmers will start out cloning the remote repo to their local machines. One will be working on the 'backend' code, and the other on the 'frontend', but both will be pushing their work to 'Features'.
If one programmer pushes something, say 'backend' work, to 'Features', and then subsequently the 'frontend' programmer finishes his work and goes to also push it to 'Features', Github will see that the 'Features' branch has since changed ( the 'backend' files that now exist on the remote repo being pushed to now differ from the backend files in the frontend programmer's local cloned repo), and the 'frontend' programmer will be prompted decide how to handle the difference before he is allowed to finish his push, correct?
If not 'merge', what would the correct action be, so that the 'frontend' programmer's local unchanged backend files don't overwrite the already-pushed/changed backend files that now exist on the remote repo?
Merging 'Features' to main branch
As a separate issue, when it comes to merging Features to the main branch (which will function as our 'production' branch), it would be a 'best practice' to only ever do this once both the programmers have finished pushing to 'Features' (meaning they won't be pushing anything else to it).
Then, in order to merge Features into main, either one of the programmers, after ensuring they have pulled the most recent finalized version of 'Features' to their local clone, would perform a merge of Features to main, and then push main itself to the remote repo.
Is this a correct order of events?
So far, our remote repo has just two branches, a 'main' and a 'Features'.
Both programmers will start out cloning the remote repo to their local machines. One will be working on the 'backend' code, and the other on the 'frontend', but both will be pushing their work to 'Features'.
If one programmer pushes something, say 'backend' work, to 'Features', and then subsequently the 'frontend' programmer finishes his work and goes to also push it to 'Features', Github will see that the 'Features' branch has since changed ( the 'backend' files that now exist on the remote repo being pushed to now differ from the backend files in the frontend programmer's local cloned repo), and the 'frontend' programmer will be prompted decide how to handle the difference before he is allowed to finish his push, correct?
If not 'merge', what would the correct action be, so that the 'frontend' programmer's local unchanged backend files don't overwrite the already-pushed/changed backend files that now exist on the remote repo?
Merging 'Features' to main branch
As a separate issue, when it comes to merging Features to the main branch (which will function as our 'production' branch), it would be a 'best practice' to only ever do this once both the programmers have finished pushing to 'Features' (meaning they won't be pushing anything else to it).
Then, in order to merge Features into main, either one of the programmers, after ensuring they have pulled the most recent finalized version of 'Features' to their local clone, would perform a merge of Features to main, and then push main itself to the remote repo.
Is this a correct order of events?
A friendly place for developers to meet other devs, ask questions, get help, and just have a good time 🙂.
36,263Members
Resources
Was this page helpful?
