A Better Git Flow
render.com
A Better Git Flow
1–10 of 115 posts
Re: A Better Git Flow
#2My two cents: I just always squash commits when merging to master/main. That way the main branch has clean commit messages and it's easy to revert later. I think cherry-picking commits after the fact can also be very time-consuming, especially if you do a lot of refactoring or "clean as you go" as I like to call it. However, I could see it being worth it for open-source.
Re: A Better Git Flow
#3> do the work first, clean up the commits later
I'm not sure this gives the right impression. Yes rename/squash/interactive rebase if necessary to tidy, however I still believe you should strive to create clear, separate commits as you go.
If you have to regularly make major changes to history before review, I could be a sign that your process/approach is disorganised.
Re: A Better Git Flow
#4Why commit at all if you're going to reset? Sounds like the intermediate commits are just used as a backup method. The real trickery is mentioned in the last part, if commits don't break up tidily along file boundaries you'll have to commit hunks somehow and then go back and test whether the code works.
Either way, in the end it's up to developer discipline to make clean commits, git doesn't really help all that much although in my (long) source control history before git I never thought of committing hunks.
Re: A Better Git Flow
#5I think this makes a lot of sense. I usually use git in a completely different way when developing than I do when I'm pushing up code for others into a shared branch.
When developing my priority is to easily get back to a last known working state. This allows me to try out risky changes, and throw them all away if it doesn't work out.
When pushing my changes for PR, those working states I saved before may not be the best logically. I usually re-write my commits to break it into more logical chunks, that are easy to revert and easier for other teammates to digest.
Re: A Better Git Flow
#6What a waste of time and effort. Squash when merging to master and be done with it. Every PR/commit merged to master should be a clean logical unit. That means not fixing a bug in a branch where I'm doing something else. Those will be two separate PR's. The second problem shouldn't exist IMO.
Re: A Better Git Flow
#7uhh...git rebase -i anyone?
Re: A Better Git Flow
#8uhh...git rebase -i anyone?
Yeah, this basically how git was supposed to be used to begin with.
Re: A Better Git Flow
#9It makes sense sometime, but not always. Group commits by files.
For example,
Most of one core change is in multiple files, it will be very bad to commit by files group
Re: A Better Git Flow
#10This to me seems more like a logical separation than anything technical.
I use GitHub and always squash commits before merging a PR. This keeps the commit log clean and also has the side effect that you have the PR number in the merge commit.
Having said that I also suggest keeping PRs small. If you are going to reformat a code base, make that a separate commit. Updating a library, separate commit. Adding a library you need for a new feature: create a PR for the library update, base your implementation off that branch and rebase against main when the first PR is merged.