devil and should be avoided at all costs. • Engineer side conversations about branches that are not publicly announced. • Lack of breaking down large tasks into small more consumable tasks.
branch. And in our current state we have the concept of a “master feature branch”. This branch is usually based off of master, with one person committing to it. We then have other developers branching from the “master feature branch” and working on additional features. In order for this to work correctly, the creator of the “master feature branch” will need to take the role of keeping up to date with the upstream (master) and the others branched off should be doing the same, but in their case keeping up with the “master feature branch”.
more side communication to keep things in order. In addition, this process causes engineers to be two removed from master and can case lost commits. Our current process is wrong. Common Issues
Open a Pull Request 4. Code Review and Discussion 5. Merge and Deploy[1] references: https://guides.github.com/introduction/flow/ 1. Master should always be our upstream. Master is our stable release branch, everything on master is considered production ready.
thought on how to handle the git process. • Find one that works for us and follow it. • If we have a process we believe in, we will be successful. • Stand by the process and bring attention when things are not in order.