New answers tagged

0

What has worked best for us is to make sure we all have identical workspaces with the same local folder structure. Then the references can use relative file paths in the project file. I.E. in the dev Project1 project file you'd see something like: <Reference Include="Project2"> ...


5

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

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


3

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


9

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


5

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

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


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


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


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


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


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


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



Top 50 recent answers are included