21–30 of 48 posts
Our workplace uses gerrit, and while it sort of supports this workflow I personally use a lot of short-lived branches, one for each gerrit review, simply in order to get at them easily to make changes.
With respect to git, this is yet another successful workflow conducted through git. While git may have its flaws, one cannot deny that many different workflows are enabled by it.
And with respect to this particular workflow, I think it says that drewdevault makes largely self-contained commits with good commit messages and that constantly work. I have been on projects using branched development with people who sometimes make commits that break things, but that then fix them in other commits, with a does-it-really-matter-before-it's-merged-anyway attitude. And I have been on projects where the default commit message is absolutely lousy. (And I am currently involved in a project where both of these are true).
But to be able to successfully rebase and reorder and cherrypick commits says a lot to me about highly disciplined organization. I would expect many workflows to be enabled by such habits.
People are quick to dismiss this, but I think it's a fish-in-water kind of thing, where they are so used to the normal git flow, they can't see any way that it might be non-ideal. I am excited about the promise of patch-based VCs. In theory they are clearly a better, more flexible model, that is a closer match to how we actually think of changes. As an example, the branch-free model of this post just falls out natura…
You might take a look at stgit. http://www.procode.org/stgit/
>When I’m ready to present some or all of my changes to upstream, I grab git rebase and reorganize all of these into their respective features, bugfixes, and so on, forming a series of carefully organized, self-contained patchsets.
That seems like a lot of extra work to "not use" branches.
I do less work than that and don't use branches. I just tag the releases.
Whenever I want a certain commit to triger CI/CD for build/testing and preprod deploy, I just tag a git commit as "release-[most recent git commit 8char fingerprint]" using a little script and some cli aliasing.
Then push. Release is built, and I can keep pushing to master unfinished features. But because the working version is tagged, Ops can always rebuild, redeploy, or roll back to known good commits.
> I’ll just apply them to master, rebase them behind my WIP work, and then use git push origin HEAD~5:refs/heads/master to send them upstream, or something to that effect. if you're going through the trouble of carefully rebasing to change the order of commits, and remembering exactly how many commits behind HEAD you should push, and remembering what state the remote is in (what is master is actually pointing at HEAD…
I think the success of such a workflow says a lot of positive things both about drewdevault and git. With respect to git, this is yet another successful workflow conducted through git. While git may have its flaws, one cannot deny that many different workflows are enabled by it. And with respect to this particular workflow, I think it says that drewdevault makes largely self-contained commits with good commit message…
There's a massive flaw in this approach if the repo is not private (collaboration is mentioned in the post in terms of "review some incoming patches") in that you can't push works in progress to the remote as you are doing it all in master. If you did push those then when you tidy it up you will cause problems for other collaborators.
If you can't push WIP out then you have the only copy, and you're losing some of the distributed advantages of git: distributed backups of your WIP changes being one of those.
> But to be able to successfully rebase and reorder and cherrypick commits says a lot to me about highly disciplined organization.
Yeah, rebases and cherry-picks are great features. Just use branches as the starting point.
No time spent creating new branches for new features. No time spent switching between branches to address feedback. I'm sorry but these are non-issues with git. The approach you've outlined makes collaboration on features impossible. Cherry-picking and rebasing does not scale for either teams, or lots of parallel workstreams.
git checkout -b new_feature_branch is an onerous workflow?
No time spent creating new branches for new features. No time spent switching between branches to address feedback. I'm sorry but these are non-issues with git. The approach you've outlined makes collaboration on features impossible. Cherry-picking and rebasing does not scale for either teams, or lots of parallel workstreams.
git checkout -b new_feature_branch is an onerous workflow?
It's happened to me though; one scenario is that you created a couple of merge requests for the same repo over the course of a day, and the next day feedback from code review or testing comes in. You end up having to switch to various branches to fix the reviews.
But that's really not that big of a deal. The context switch is worse than the git checkout call.
1) If you branch a lot, keeping up with upstream changes can be tedious: you have to rebase each branch separately just to keep up. With this method, to keep up, you rebase just once, on your one branch.
2) If you branch a lot, merging each branch can cascade into a bunch of rebasing. As you build your feature, you might clean up unrelated code. Your "implement feature" commits could be interspersed with "fix unrelated code" commits. If you're creating a branch for each cleanup commit, as you submit them for review earlier than your feature, you have to rebase all your branches one by one. With this method, you rebase just once.