New answers tagged

3

The push bot also interfaces with a continuous integration server, which you can see if you click on the "View Details" next to its merges. That means there are two conditions for a merge: the thumbs up and a passed set of automated tests. Having the bot do the merge means the maintainer doesn't have to wait for the tests to finish, worry about ...


0

One solution I can think of is to use git tag to create a tag for each business, then specify in the build process as a variable (BUSINESS=FOO) to change the customisations. You could even try and automate that so it looks for the business name in the tag. This avoids having to create N number of branches per business, and having to consistently keep them ...


0

Separately stage (and commit) the changes related to the bug-fix. In Git Extensions, this is extremely easy to do. From the commandline, I think you need to do git add -p.


1

An option I use quite a bit is to add TODO comments, then do lots of frequent "partial" commits, by using git add --patch to select the relevant parts of the file. Then use git rebase --interactive to reorder and merge the partial commits into the final feature and fixup commits before pushing them. This keeps your main commit clean, and still allows you ...


2

My editor has a plugin that makes staging individual parts of a file extremely easy. I imagine other programmer editors might have similar plugins, although you can always do it the manual way with git add --patch | -p. Then I use git stash to save off my other changes to test my small commit in isolation. Then after I commit, I just do a git stash pop ...


0

The trick is not to make changes unless you are prepared to put as much effort in as the change deserves. What I do tend to do is add to a todo list (sometimes by adding comment to the code, sometimes in a note on a bug ticket, and sometimes by updating the code in a separate branch knowing the fix will get merged in eventually). If there is no bug ticket ...


8

I think that you have to be very pragmatic when programming. Even if it might be possible to formulate the perfect scheme, workflow, or implementation, sometimes you just need to get work done. Here's what I do: I use git's ability to stage/commit individual hunks and lines, whenever possible, to separate unrelated changes, although, occasionally this can ...


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

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 ...


0

I use a private GitLab to store all my repositories, so I only have one origin I push and pull from while I'm doing day to day development. But, for open source projects, GitHub is a much more vibrant community, so, if I want to accept community contributions to my projects, I use web GitLab's web hook system to ping a server I run which then updates my ...


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 ...


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 ...


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 ...


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 ...


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 - ...


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 ...


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 ...


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 ...


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 ...



Top 50 recent answers are included