![]() I wonder if that's the same guy you are talking about. ![]() The commit graph is easier on the eyes and more useful. Your merges of master are not seen because your commits were replayed on top of the master branch. It is not a chronological history but it does offer a cleaner history. The other view point is to rebase it, which is what I do and what your CTO advocates. Nobody cares that you merged the master branch three times during your development cycle. It is what history purists want to see, because they value chronological order above anything else. There are people who advocate just merging it into your feature branch because that is what you did. Merging main/master in your current feature branch.Pushing it to a remote allows me to pick it up on another computer or share it with coworkers. You might want to create a fork and push it to the remote of the fork. Push a feature branch to a remote, yes or no?.There seem to be two questions that are mingled together. Thanks everyone for sharing your knowledge! □ Gonna go read up on -no-ff, github flow and trunk-based development. Can someone explain to me which approach is right?ĮDIT: this post seems to advocate a similar idea. This doesn't make sense to me, since it seems that merging branch feature into main and then pushing upstream to origin/main is exactly the same as merging origin/feature into origin/main and then deleting the branch. Therefore, modern best practice is to only have one branch on the remote, and developers keep branches local (unless multiple developers are collaborating on one feature). However, if you develop locally and then merge to main and push upstream, if the earlier commit needs to be undone it is simpler to fix. If you merge a feature branch in that is intertangled with code after the bad commit, undoing the commit becomes messy, and you might need to cherry-pick. His rationale for this is that you want to keep the main branch as clean as possible, in case you need to revert an earlier commit. (He said that backup can be done with other tools, and code review can be done locally.) My CTO explained to me today that while working on a feature branch, I should keep it on my local machine and not create a remote upstream branch.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |