Hot answers tagged

45

It is hard to know for sure why merge is the default without hearing from the person who made that decision. Here is a theory... Git cannot presume it is ok to --rebase every pull. Listen to how that sounds. "Rebase every pull." just sounds wrong if you use pull requests or similar. Would you rebase on a pull request? In a team that is not just using ...


14

If you read the git manpage for rebase, it says: Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the ...


12

You're correct, assuming you have only one local/changed repository. However, consider there being a second local PC, for example. Once your local/modified copy is pushed somewhere else rebasing will screw up those copies. Of course, you could force pushing, but that quickly becomes complicated. What happens if one or more of these have another completely ...


12

Yes, this is a good idea and fairly standard (but not universal) practice. The specific software engineering goal you are achieving with this is requirements traceability. The idea is you want to be able to trace a requirement through the entire software process: Business requirements Functional requirements Technical requirements Code artifacts QA ...


11

Simple suggestion: don't do that. git branches are not for long-running forks of the code, as discussed here and https://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/. Branches are best treated as transient things used to organize commits by an individual developer on a day-to-day level. So if they have a name that corresponds to ...


11

You don't fix that commit. It's a fact that the bug was introduced, and that's okay. You found it now and know how to fix it, great! Like with any other bug fix, you create a new commit on top of the current state of the project. This retains the history and fixes the bug. Rewriting the history so that the bug never existed is pointless, even dangerous: It ...


5

The big reason is probably that the default behaviour should "just work" in public repos. Rebasing history that other people have already merged is going to cause them trouble. I know you're talking about your private repo, but generally speaking git doesn't know or care what's private or public, so the chosen default is going to be the default for both. I ...


4

I've never worked with wordpress, but I did work on several web applications that had a database, and the usual way to make the database play nice with source control is to use a Schema Migration Framework. The idea is that each developer has a personal development database installed on their own machine(or on a personal server or however you want to work - ...


4

Under the original gitflow specification, there is no requirement that features be local only, only that they SHOULD NOT be pushed to origin: Feature branches typically exist in developer repos only, not in origin. However, it's not a hard requirement. The gitflow API supports publishing and tracking features on origin: git flow feature publish ...


3

It is similar to the question "Why do we say 'today', instead of 'the day that started the last time the clock went from 23:59 to 00:00'?" Having the concept of "latest stable" codified in a branch rather than something you have to search for simplifies things. Whenever you need the latest stable version of the code, you check out the master branch. If you ...


3

Including reference numbers (tickets, features, requirements, etc.) in commit messages is a great idea. But it should never be a substitute for a good message. At my current employer, we're now on our second source control system, our third ticketing system, and our second requirements management system. Needless to say, the old systems' data were never ...


3

If your system tracks all features/bugs then you likely will have a ticket of some sort. But if your system only tracks bugs (for some reason?) and all new development is a free for all. Some significant advantages: Some VCS/ticket systems allow auto hyperlinks for the ticket number when browsing the commits in the issue tracker (this is super useful, see ...


2

You deploy the branch you need to where you need to. Now, obviously you aren't going to deploy a feature branch to production. But deploying the latest build from Master to development shouldn't be a problem. The development branch in git-flow is about being the mainline - that from which the normal process has you branching off of and merging too. The ...


1

You can pull in those branches into you git-tfs hybrid repository, then use git tfs checkintool. This should open up a window that looks similar to the Visual Studio interface, and should allow you to link work items.


1

The downside is that people will write less complete commit comments because someone can go to the ticket for more details. This is only really a problem if you say switch to a different ticketing system and can't keep the history or someone doesn't have ticketing system but does have access to the repository. If the branch is already named for the ticket ...


1

This is a tricky problem but one that many people face. I prefer using the Gitflow setup as a starting point. Development -> New stuff being worked on Master -> Finished stuff needing testing Production -> Stuff that has been published to production. At minor (shorter) features I create a branch from development do the work there then merger the branch ...


1

LGPL says you don't have to put this library with your code and make your code on LGPL. That's the main difference between LGPL and GPL. You just have to make a way for user to be able to use his own version of this library. So, link it dynamically: 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding ...



Only top voted, non community-wiki answers of a minimum length are eligible