Ugh, not this again. How many threads like this do we need before folks accept that git is not the solution to whatever problem we have?
Could you be more specific?
Git Workflow Basics
71–77 of 77 posts
Re: Git Workflow Basics
#72Wow, a blog post called "Git Workflow Basics" that really does just have simple and useful basics and doesn't try to terrify you out of or into using specific git features that the author decided are infinitely sacred or infinitely profane.
I can't really explain the depth of how pleasant, and how surprising, this pleasant surprise was. Thanks!
Re: Git Workflow Basics
#73Earlier quoted context omitted.
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.
What we are talking about is whether or not you should rewrite public history. The technical reason is based on the fact if others have access to this history or not.
It does not matter if you pushed it to a private repository where some other people still have access to; they might have fetched that history and committed on, which causes unexpected results when you rewrite such a branch.
I tend to use published history / commits for this reason to make it less confusing.
Re: Git Workflow Basics
#74The English needs a massage here. The very first sentence is grammatically incorrect, which doesn't inspire confidence. It's a fine introductory post for learning Git, though, and as such I welcome it.
Re: Git Workflow Basics
#75Re: Git Workflow Basics
#76Personally, 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.
Actually this works perfectly fine in large teams too, if you add another level of branches. In fact, that is how the Linux kernel development works
Re: Git Workflow Basics
#77Could anyone who follows the "rebase all the merges" workflow detail why they choose to work that way? It seems to me that Git's strength is being able to time travel in your repo (especially with something like git-bisect, one of the few tools I'd call downright magical) But if you're rebasing your commits, haven't you lost that? The concerns about a "clean commit graph" seem more aesthetic than functional.
I don't know about rebasing everything , but a commit is a changeset, and a changeset should always have a distinct and succinct purpose. There is no value added in having a single feature spread out over 5 commits. When writing a feature, I use git to save my progress, and once I'm done, I would like to present the feature as a clear and complete changeset. A commit is me saying, "These are the changes I'd like to m…
I really don't understand all the opposition ti this idea.
This is exactly how git should be used, and it is how most successful large open source projects require you to work.