Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
What you’ve suggested is fine in my opinion (I’m not a git-god though).
The only issue would be that if his feature was reverted then yours would break (I’m assuming), so if his change is only required because of your feature I’d be tempted to let him commit to your feature branch and then merge to master as a single feature. But if his change is needed regardless of your feature then I’d do as two features.
Hope this helps. -
@joycestick I see your point, and working on the same branch seems easy and straight forward. What I'm concerned about though is mixing backend and frontent on the same branch
-
@ScriptCoded I’m not backendy enough to give an informed view on that. Hopefully someone else can chip in on this thread.
-
Ederbit7386yIf your'e language allows it, create an interface for the missing back end stuff and mock it if possible, then inform your colleague about the interface and make sure he uses it.
-
@Ederbit That seems pretty smooth. We're running JavaScript, but I bet we could do something similar. ATM I'm using mock services, but at some point it would be nice to actually connect stuff :)
-
@alexThunder Hmm, that might work. Seems a little over the top though. Do I really need a total of three branches for one feature?
Related Rants
I'm trying to bring some structure to the IT department, but I need help with something. I'm on my feature branch for some front-end stuff. I realize that there is some back-end missing that my colleague must do. How should we go about tackling this? Should he create another feature branch, fix the things, merge to master, and then i can merge from master?
question
git
branching