Git Workflow Basics
blog.codeminer42.com
Git Workflow Basics
1–10 of 77 posts
Re: Git Workflow Basics
#2At the same time, with this workflow (just like git flow) you're not doing continuous integration. Which is quite bad, imho.
Re: Git Workflow Basics
#3At the same time, with this workflow (just like git flow) you're not doing continuous integration. Which is quite bad, imho. https://www.franzoni.eu/git-flow-is-superflous-and-complex/
Nothing stops you to use continuous integration with this workflow. For instance, Travis-CI and Codeship support branching (they can tell you if the new build will be fine or not).
I didn't mention that in the post because it's intended for beginners and adding that info there could maybe be a little too much :/
Re: Git Workflow Basics
#4This article appears to be a cheap copy of Atlassian's Git workfflows and tutorial
https://www.atlassian.com/git/tutorials/comparing-workflows/
Re: Git Workflow Basics
#5This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations.
Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebase and lose all work associated with it?
This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash.
We won a Ruby award for our work on Git Reflow. There are big improvements coming this week that can make it easy for teams to tweak the workflow to suit any special needs you might have. It works on github and bitbucket and automatically creates pull requests (and makes sure they're reviewed.) Gitlab support coming soon (maybe this month).
Re: Git Workflow Basics
#6At the same time, with this workflow (just like git flow) you're not doing continuous integration. Which is quite bad, imho. https://www.franzoni.eu/git-flow-is-superflous-and-complex/
If standing up a deployment or test environment for a branch that's not yet merged is difficult or impossible, that's what prevents you from doing CI, not whatever branching strategy you use.
The model described in this post is basically the model used with svn, and it brings with it its own vast set of problems that active uses of topic branches are intended to resolve. We've been down this road before and it's not roses and sunshine.
Re: Git Workflow Basics
#7This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…
My apologies if this comes across as overly harsh! This article was really quite well written, and it's only after having been burned through rebases that I've gotten so headstrong against it.
We need more articles like this! Thank you for your work!
Re: Git Workflow Basics
#8This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…
> This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash
Until the original branch is deleted and the refs are garbage collected, anyways.
It seems strange to me to advocate for squash merging on a premise of not losing history. A squash merge is a rebase.
Re: Git Workflow Basics
#9This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…
But some of us use git-rebase every day perfectly fine and never lose information. Yes, you must be careful. No, you should never use it on public commits.
I wouldn't recommend it to others as I don't trust them to read the man page and understand what git-rebase does. Those of us who use git-rebase also know how to recover the refs since before they are GCed, though I've never had to do that.
It's dangerous to pronounce certain powerful features of a system as off limits for day to day private use. That's a different pronouncement than a decision not to share "why everyone should use git-rebase often".
Re: Git Workflow Basics
#10This workflow is scary. A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations. Rebasing can cause the loss of history and developers should be as careful with it as system admins are with `sudo`. I can't recommend any workflow that includes it without treating is as a terrifying and scary thing. How easy is it to accidentally remove a line during interactive rebas…
The rebase would ideally be the last thing you do on your branch, and very carefully.
And I also mention in the post that we should always use what's best for our teams, so if the squash merge works best for you, go for it! :)