Hot answers tagged

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


6

I'd say, do not bother with the old snapshots. Commit current state into the repo and start using it as soon as possible. Just backup the old snapshots and in a couple of month you will not even remember they've existed. From experience, when we migrated from CVS to GIT, the old CVS source control was left there for reference, but after a few month nobody ...


6

The basic workflow for TDD is commonly known as "Red; Green; Refactor": Red: Write a failing test Green: Modify the code to make that test pass (without any existing tests failing) Refactor: Tidy up the code to better incorporate the change. There are numerous resources that explain this process in details, eg The Cycles of TDD It's unclear to me as to ...


4

Set up a company-level nuget repository. (I'm assuming .NET from the terminology you're using, but there are equivalents for almost all language frameworks.) Either build one on your own server, or use a service like myget, or simply use your TeamCity server's built-in nuget feeds. Deploy your common code in packages to that repository, as an entirely ...


3

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


3

You will normally keep your tests in a separate folder hierarchy as they usually aren't part of the binary you ship, and it's just simpler to not mix them up, but you keep them in the same repo and branch because they belong together in source. As for where you work, TDD means Test Driven Development, which means you first write a (small) test for the ...


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


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

What you have there is version control. I think we can all agree that it is a pretty crappy form of version control, but you at least do have different versions, even if you don't have commit messages. Why throw away that history? From what I can gather from your description, it's a three-line script and a matter of minutes to import that history into a ...


2

If you only have to update/patch/support a single version, then just starting the repository with your last version is a perfectly good idea. Keep a backup of the old versions, just in case, but I'd expect it to be unlikely you'll need it. However, if you have to support multiple versions of your project, I would recommend making a commit per each of the ...


2

The tests aren't there to ensure you write the code you want to write. They are there to ensure that three years from now, you don't accidentally change the way the code works through a seemingly unrelated change, causing unintelligible defects. Tests are insurance against the future. Never remove the tests.


2

Visual Studio solutions work differently for C++ (compared to C# or VB). With C++ project you do not get "hand held" with your folder layout in the project mirroring that on disk. Instead, with C++ you can put your files anywhere you like, and organise them as you like using filters. eg you can have many folders on disk with lots of C++ or resource files in ...


1

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


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



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