Hey DEV.TO community! First off, as a newcomer, I'd like to say that this community has been absolutely exceptional thus far!
I was hoping to get some help today with my Git/Github workflow. I am collaborating on a React JS project with another developer. This is the first time either one of us have ever collaborated on a project, so we are a bit stuck on the workflow.
So far we understand that we pull from the Master branch and each create a new branch for the features we will be working on. We understand that once those features are complete, we merge them into the Master. However.. We are unsure how we can go about merging our branches together in a 'Staging/Dev branch' to determine if they are working correctly with one another, before pushing to the Master.
Is that the right way to do it? Merge them both into a new branch before pushing to Master?
I'd also like to know, if we do merge our branches together in some sort of staging branch (if that is the best workflow), would we then merge that staging branch into our original feature branches that we are currently working on to continue developing with each others code present in our branches?
TL/DR; How do you test two separate branches together to ensure the code is working before merging the branches to Master?
I hope I was able to make my question clear, thanks DEV.TO!
Top comments (6)
Sorry for the lengthy response, but I hope this helps.
Here's the setup I work with. I have a main branch that's protected (so it can't be accidently deleted). I then create a staging branch (which is an exact copy of main, also protected) where I will create new branches from to push/pull new features. Now, if I push a feature and it conflicts with the staging branch, GH will alert you in your pull request. From here you can click the merge conflict button and view the issues. Once resolved, you can merge it into staging.
In your case, let's say your partner merges a feature into staging. You add your pull request and GH finds a merge conflict, it'll be in red at the bottom of your pull request. You can resolve the changes in GH or your code editor.
Now, the staging branch is protected (it doesn't get deleted when we merge to main), so when we merge to main, staging remains open and we can continue to work from it.
If you have more questions or need help setting this up, feel free to hit me up.
Thank you so much Andrea for the in-depth response! This is sort of the direction we were expecting.
I have a couple follow up questions:
Since we already branched from Master, I'm assuming we will create a new staging branch and then both merge into that staging branch?
Once the staging branch has both of our merges, do we do some sort of rebase/merge to update both of our feature branches to include the combined files (aka the staging branch) into our working branches? I'm asking this specifically because I currently have code added to a config file that the other developer will need in order to move forward with his code.
I suppose it would also be possible for this developer to simply merge his local feature branch with my remote feature branch to get these config files? (this is sort of separate to the main question).
Would this work for the second part of my question?
git fetch remoteBranch
git checkout localBranch
git merge remoteBranch
Doing this, does the localBranch need to have all changes committed first and do they risk losing any of their progress so far? For example, my empty app.js file will not overwrite his app.js file that he's been working on after he does the merge?
Yes, you'd need to create a staging branch that you can both push too to ensure it works before going to main. Your partner could also merge your current branch into his using the commands you listed above. It shouldn't overwrite any of his work, just add yours code to his. If there are conflicts, his code editor should notify him. :)
Awesome!!! Once again, thank you tons Andrea! You’ve pretty much solved our collaboration worries :).
Yay! I'm so glad I could help. :) Best of luck on your project.