31–40 of 48 posts
If I read correctly, this is trunk-based development. https://trunkbaseddevelopment.com/ And this is also my experience, I absolutely hate spending time to merge things and resolve the conflicts and bugs. I think this should be the default behavior for small/medium teams. Branching should only be used when trunk-based dev is no longer possible. I really liked this article from the Our Machinery guys, who created the…
> 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…
With you 100%. And yes, I will sue.
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…
Eh. I can use an iPad as a cutting board, but I'm not going to put that down as one of the iPad's achievements.
I tend to think of git as tool to aid organization and not an opportunity to flex my prowess at mental gymnastics. Crazy, I know.
Earlier quoted context omitted.
git checkout -b new_feature_branch is an onerous workflow?
Switching branches does get a bit annoying if you happen to work in multiple branches simultaneously and have to switch halfway through a task, or there's a lot of differences; however, that is also a matter of organization. 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.…
Isn't it incredibly annoying to edit a git change that isn't at the branch (HEAD) tip? 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.
https://blog.sebastian-daschner.com/entries/git-commit-fixup...
Earlier quoted context omitted.
git checkout -b new_feature_branch is an onerous workflow?
Switching branches does get a bit annoying if you happen to work in multiple branches simultaneously and have to switch halfway through a task, or there's a lot of differences; however, that is also a matter of organization. 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.…
Earlier quoted context omitted.
git checkout -b new_feature_branch is an onerous workflow?
Switching branches does get a bit annoying if you happen to work in multiple branches simultaneously and have to switch halfway through a task, or there's a lot of differences; however, that is also a matter of organization. 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.…
Sure, but its not like the different changes just don’t exist if you use only master, branches are a way of managing them separately and only merging when you are ready, if you don’t use branches, you have to have some other way to manage this. If you don’t, and its not a problem, then you could also just not work on three branches at once.
No time spent creating new branches for new features.
No time spent switching between branches to address feedback.
All of my features are guaranteed to be mutually applicable to master, saving me time addressing conflicts.
Any conflicts with upstream are addressed in all of my workstreams at once, without switching between branches or allowing any branch to get stale.
To the third and fourths points - that all “streams” resolve at the same time, that’s an okay point, but isn’t normally a problem in practice with branches. If you’re working on multiple branches than conflict with an incoming commit, it means you’ve touched the same code in multiple branches, and also someone else has too. It tends to indicate bad planning or bad communication or both. And it just doesn’t happen very often.
Here are a few reasons to use branching anyway when you’re alone:
- To do an experiment multiple ways on the same code.
- To avoid use of git stash. Branching is safer and adds no extra difficulty. Stash doesn’t have as good of a safety net (it’s in the manual).
- To write & test your feature without your other in-progress features getting in the way.