I want to totally replace master, actually. But I would rather release / tag the stable code on GitHub first.
Is it about rebase, that I haven't tried?
I also haven't tried stash.
This also raises some general questions,
- Where do you usually draw a flowchart? (I used PowerPoint, but it seems unprecise...)
- How do you usually upload for dev.to?
Top comments (5)
I would fear, that merging at different stages in history would cause conflict, that I have to manually fix.
Is it better to see this?
Or, fix bugs in "feature" branch when it actually appears?
Well, fixing bugs and resolving conflicts is two different things.
A merge conflict is an event that occurs when Git is unable to automatically resolve differences in code between two commits. Resolving conflicts is integral part of merging, you are expected to resolve conflicts when it happens.
A bug is an error, flaw or fault in your software that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. No one wants to fix bugs he doesn't own, but, you can merge any time from master, meaning, you can assume that some point on master was stable, and I would count on that and merge that point of time into your branch. (could be after the bug was fixed or before the bug existed)
Does it make sense?
Thanks. Here is what I do.
In short, TIL
git merge
. I have never tried merging in local before. Not really how to fix merge conflict in remote. This might be related.Git Workflow: Do you commit to master on your solo projects?
dAVE Inden ・ Sep 10 '19 ・ 2 min read
This is a not recommended action, but it is possible. Github probability prevents force push to master (gitlab does)
If you just want feature added to master, the a merge request will suffice if there are no conflicts (do not avoid conflicts).
If there is conflict there are two options.
1 rebase onto master
2 Merge master into feature branch
Handling Merges
Jesse Phillips ・ Jun 22 '19 ・ 3 min read