Personally, i prefer having a develop branch which all the development happens on, with developers creating feature branches from that, and then merge develop with master, when a new version is achieved.
Git Workflow Basics
61–70 of 77 posts
Re: Git Workflow Basics
#62Personally, i prefer having a develop branch which all the development happens on, with developers creating feature branches from that, and then merge develop with master, when a new version is achieved.
Keep in mind that i only work on small teams with smallish projects, this workflow would probably not work for big projects with a bunch of developers working simultaneously.
Re: Git Workflow Basics
#63Earlier quoted context omitted.
"commits other people have access to" That's authorization.
You said: > anything accessible without any authorization. Even if it does require authorization, it's considered public in regard to this discussion.
It's not public if the public can't read it (requires authorization).
Why is this a conversation?
Re: Git Workflow Basics
#64This 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…
What is the harm in rewriting history in your private "topic branch"? This is not uncommon for the use case the author was describing. It certainly creates a cleaner logical history.
Re: Git Workflow Basics
#65This 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…
> A rebase should not be part of any everyday workflow and must be reserved _only_ for exceptional situations
Git rebase is absolutely a vital part of the developer toolkit. If you're not using it, you're missing out on a big timesaver and git feature.
I think you must be talking about rebasing public commits/history. In the article he is specifically talking about private history and has a nice big warning against rebasing public history. Linus has explained the distinction pretty well before: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/... .
Re: Git Workflow Basics
#66This 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 FUD. Many people use git-rebase flawlessly, without any of the issues you've encountered.
Wouldn't your tests catch when lines get elided by manual merge conflict resolution? Have you see mjd's Git Habits[0], which lays out a foolproof way of rebasing without losing lines?
Re: Git Workflow Basics
#67This 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…
> If you screw up a rebase, the history is re-written… https://git-scm.com/docs/git-reflog > …or force-pushed by accident Well, you could nuke git folder "by accident" as well :) Jokes aside, don't force-push to "other's" branches).
If you really feel like you do have to force-push to someone else's branch, please use
git push --force-with-lease origin/other_branch
Re: Git Workflow Basics
#68So, commenters do not seem particularly impressed with this workflow. What is a good workflow around git?
There are plenty; there's no one right workflow, because different teams have different requirements.
At work, we use deploy branches for a few repos, and integration branches for others. Personally, I use rebase for my own projects.
Re: Git Workflow Basics
#69Earlier quoted context omitted.
You said: > anything accessible without any authorization. Even if it does require authorization, it's considered public in regard to this discussion.
It's not public if the public can't read it (requires authorization). Why is this a conversation?
Because you've applied a different definition of public that doesn't fit the context. Public in the context in which it was used in this thread regarding git commits simply means commits you have pushed to a repo that another developer can access even if authorization is required to access it.
Re: Git Workflow Basics
#70Earlier quoted context omitted.
It's not public if the public can't read it (requires authorization). Why is this a conversation?
Because you've applied a different definition of public that doesn't fit the context. Public in the context in which it was used in this thread regarding git commits simply means commits you have pushed to a repo that another developer can access even if authorization is required to access it.
That's not what public means, though, in any context.