Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

Hot answers tagged

128

Absent any specific need, any file that can be built, recreated, constructed, or generated from build tools using other files checked into version control should not be checked in. When the file is needed, it can be (re)built from the other sources (and normally would be as some aspect of the build process). So those files should be ignored with .gitignore....


23

My rule is that when I clone a repository and press a “build” button, then, after a while, everything is built. To achieve this for your generated documentation, you have two choices: either someone is responsible for creating these docs and putting them into git, or you document exactly what software I need on my development machine, and you make sure that ...


14

These files should not be checked in because the data to generate them is already present. You do not want to store data twice (DRY). If you have an CI system, you could perhaps make that build the docs and store them for that build/publish it to a web server.


4

Sync your branch by merging master into refactor. You'll have to deal with the merge conflicts eventually in any case, and by tackling them early you will decrease the complexity of the conflicts. This is good practice in general: whenever your source branch changes, merge those changes into its dependent branches. You want to keep your branches ahead of ...


4

You fix the merge conflict. A merge conflict doesn't mean you can't merge, it means you can't automatically merge. To reiterate, your IDE is asking you how to combine Public Class Class1 Public Property Property1 As String Public Property Property2 As String <- new line End Class with Public Class Class1 Public Property Property1 As String ...


4

Here's a sample image of a GitFlow branching model (below). See how hotfix is derived from master, and then merged into develop? That's all well and good, I suppose, until feature is merged into develop right after that. We're going to get conflicts during that second merge! What to do when hotfix contains major architectural changes that ...


4

One advantage of having them in some repository (either the same or a different one, preferably automatically generated) is that then you can see all the changes to the documentation. Sometimes those diffs are easier to read than the diffs to the source code (specifically if you only care about specification changes, not implementation one). But in most ...


3

Stop worrying about "polluting" repositories. Commit whatever you like, whenever you like unless it affects other peoples code. And if you are working in one developer feature branches your commits don't affect anyone but you. Embrace the goodness of having all your incremental changes saved for posterity, or ignore them by hiding non-merge commits when ...


3

Ignored. You'll want to have the repo's users be able to rebuild them anyway, and it removes the complexity of being sure the doc's are always in sync. There's no reason not to have the built artifacts bundled up in one place if you want to have everything in one place and not have to build anything. However source repos are not really a good place to do ...


2

You should be doing all your work on feature/bug branches anyway, so you'd only be "polluting" those branches and since only one person is (should be) working on one branch, you're only "polluting" your own branch. If you squash the commits in individual branches before merging to develop/master all that "pollution" goes away. This is what we do at my ...


2

It depends on your deployment process. But committing generated files into a repository is an exception and should be avoided, if possible. If you can answer both of the following questions with Yes, checking in your docs might be a valid option: Are the docs a requirement for production? Does your deployment system lack the necessary tools to build the ...


2

It depends. If those docs: Needs to be part of the repository, like the readme.md, then it's preferred to keep them in the git repo. Because it can be tricky to handle those situations on a automated way. If you don't have an automated way to build and update them, like a CI system, and it is intended to be seen for the general audience, then is preferred ...


1

As a principle of version control, only "primary objects" should be stored in a repository, not "derived objects". There are exceptions to the rule: namely, when there are consumers of the repository who require the derived objects, and are reasonably expected not to have the required tools to generate them. Other considerations weigh in, like is the amount ...


1

By far the easiest way to handle this is to use a local package source. If you make .net standard class libraries you can package them automatically after each build in VS. I guess you could automate further with a post build script. Most people find the whole rigmarole of pushing, waiting for the build, pulling down the new nuget etc to the second project ...


1

Unit Tests should be submitted in the same PR as the code they test. Or, to phrase it a different way submitted code should not be accepted without an agreed* level of unit testing. Going back and adding tests later is a myth, it never happens. To use a popular analogy you wouldn't ask a car mechanic to replace your brakes and then book a further ...


1

Everyone knows what GitFlow is and there is nothing in GitFlow which says your feature branches should be long lived. But trunk based development is comparatively undefined. The problem with any form of collaborative development is that two people working on one thing need to take each other changes into account if they want the whole thing to work. That ...


1

Just imagine a simple case. As a part of your task/ticket, you need to add some extra fields to class User plus some extra validation stuff. During the development, you found some unused directives in some other classes, so you decided to remove them to keep application code cleaner... I'd suggest that the reason for your question is because you are asking ...


1

It sound like you need to create a hotfix branch that you can release to master, which you could incorporate feature1 and feature 2 into. Then you could have those changes pushed into the release when it is ready to be released. Here is a good resource on successful Git branching that describes in a little more detail of the above thoughts: https://nvie....


1

Put the version number in its own file and don't ever merge that file.


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