318
You are completely abusing branches! You should have the customisation powered by flexibility in your application, not flexibility in your version control (which, as you have discovered, is not intended/designed for this sort of use).
For example, make textfield labels come from a text file, not be hardcoded into your application (this is how ...
answered Nov 9 '15 at 16:03
Lightness Races in Orbit
8,4953 gold badges38 silver badges44 bronze badges
264
Ahh, but in fact you are using git in a decentralized manner!
Let us compare git's predecessor in mindshare, svn. Subversion had only one "repo", one source of truth. When you did a commit, it was to a single, central repo, to which every other developer was committing as well.
This sort of worked, but it led to numerous problems, the biggest one being the ...
245
Even though I use Git on the command line – I have to agree with your colleagues. It is not sensible to squash large changes into a single commit. You are losing history that way, not just making it less visible.
The point of source control is to track the history of all changes. When did what change why? To that end, every commit contains pointers to ...
197
The advantages are mostly the same as for groups of developers. By using an always release-ready master branch, and feature branches for developing new features, you can always release off the master. Find an important bug while working on a feature? Switch branch, fix, release, switch back and continue developing.
Or maybe this is a hobby project and you ...
143
If I was going to look at upgrading to a newer version of a third party SDK, the last place I'd look is in the history of the source control system.
If your product is using version 2.0 of an SDK and someone is interested in upgrading to 3.0, I don't think it's reasonable to think that they should look backwards in time in your source control system to ...
132
Don't put your secret information in your code. Put it into a configuration file which is read by your code at startup. Configuration files shouldn't be put on version control, unless they are the "factory defaults", and then they shouldn't have any private information.
See also the question Version control and personal configuration file for how to do this ...
130
Person A is the one who decides when to incorporate new changes from master, so Person A will perform the merge. Person A should certainly attempt to resolve merge conflicts on their own, but if any questions arise then both Person A and Person B should sit together and resolve the conflicts together.
Remember that you work on a team. Teammates should help ...
118
A single, monotonically increasing revision number only really makes sense for a centralized version control system, where all revisions flow to a single place that can track and assign numbers. Once you get into the DVCS world, where numerous copies of the repository exist and changes are being pulled from and pushed to them in arbitrary workflows, the ...
110
I like Amon's answer, but I felt one small part needed a lot more emphasis: You can easily simplify history while viewing logs to meet your needs, but others cannot add history while viewing logs to meet their needs. This is why keeping the history as it occurred is preferable.
Here's an example from one of our repositories. We use a pull-request model, ...
110
The problem with adding a comment to a file that it should be deleted, instead of deleting it in source control and putting the explanation there, is the assumption that if developers do not read commit messages that they will surely read comments in source code.
From an outsider's perspective, this methodology seems to be rooted in a very conservative view ...
106
I've seen this done before, both manually by authors and automatically by scripts and triggers integrated with version control systems to add author, check-in comment, and date information to the file.
I think both methods are pretty terrible for two primary reasons. First, it adds clutter and noise to the file, especially as these comments age and become ...
105
Yes it is bad practice.
You should put the explanation for the deletion in the commit message when you commit the deletion of the files.
Comments in source files should explain the code as it currently looks.
Commit messages should explain why the changes in the commit were made, so the commit history on the file explains its history.
Writing comments ...
105
Oh god yes.
I broke the build my first time. Made me so gun shy I was hiding versions in folders. Of course delaying my check ins just made things worse. I was in hell until I figured out what I needed.
I needed a safe place to play.
I created my own toy project so that I could deliberately cause merge conflicts. Learned how to fix them the hard way. Soon ...
97
I think it's a little disingenuous to say that good developers never have merge conflicts, but they can surely reduce the number of times it happens. It's also very important to remember that software development is a team activity. Actions of other members of the teams can also increase or decrease the likelihood of merge conflicts.
First, it's important ...
94
Having 500 clients is a nice problem, if you had spent the time up front to avoid this problem with branches, you may never have been able to remain trading for long enough to get any clients.
Firstly, I hope you charge your clients enough to cover ALL the costs of maintaining their custom versions. I am assuming that clients expect to get new versions ...
84
As you describe it, you already have some sort of version control, though currently there are some issues with it compared to a typical version control:
An intentional commit in version control indicates that the developer strongly believes that the current state of the system would build successfully.
(There are exceptions, as suggested by Jacobm001's ...
83
Instead of having two code version with a common base you should design your application in a way to make those premium features plug-able and driven by configuration rather than different code bases.
If you are afraid to ship those premium features (disabled by configuration) with the basic version you can still remove that code in a final build/packaging ...
78
Christopher did a very good job of enumerating the disadvantages of a one-project-per-repository model. I would like to discuss some of the reasons you might consider a multiple-repository approach. In many environments I have worked in, a multi-repository approach has been a reasonable solution, but the decision of how many repositories to have, and where ...
76
The longer a branch lives, the more it is able to diverge from the main branch and the messier and more complicated the resulting merge will be when it's finally finished. Ten small conflicts are easier to resolve than 1 massive conflict, and may actually prevent developers from duplicating or wasting effort. Given that, you should merge master into A and B ...
71
It depends on who the audience of a bug report is.
If it is only looked at internally by developers, to know what needs to be fixed, then don't bother. It's just noise at that point.
Non-exhaustive list of reasons to log anyway:
Release-notes include information about fixed bugs (to some threshold which this bug meets) - especially if there is a ...
70
It should be noted in the commit history but the absolute best place to put the notice is in the same place you define the dependency. If you have for example a maven .pom file that declares your artifact dependencies, I'd do something like:
<!-- Do not change the SDK version because it causes Foo crashes. For more detail see Issue #123 -->
Directly ...
69
People want to avoid merge commits because it makes the log prettier. Seriously. It looks like the centralized logs they grew up with, and locally they can do all their development in a single branch. There are no benefits aside from those aesthetics, and several drawbacks in addition to those you mentioned, like making it conflict-prone to pull directly ...
60
This question is pretty old but this is a common question that comes up when dealing with Git and there has some progress on modern solutions to storing large files in a Git repo since the last answer.
For storing large files in Git there are the following projects:
git-annex - This has been around for awhile but frankly it's complexity gets in the way.
...
60
As a general rule, generated files do not belong in the source code repository.
The biggest risk you run when you do put those files in the repository is that they become out of sync with their source and the build runs with different protocol buffer files than you would think based on the .proto files.
A few reasons for deviating from the general rule are
...
answered Mar 27 '13 at 13:32
Bart van Ingen Schenau
62.5k19 gold badges94 silver badges156 bronze badges
58
It depends.
Check out Bart van Ingen Schenau's answer to determine if it's possible to ignore the packages folder at all.
Basically: yes, NuGet is designed so that you can ignore the packages folder and NuGet will pull everything from the Internet if it's missing.
But should you ignore it? I say: it depends.
IMO it's a question of "can we continue working ...
58
There are several problems when commits are directly pushed to master
If you push a work-in-progress state to remote, the master is potentially broken
If another developer starts work for a new feature from master, she starts with a potentially broken state. This slows down development
Different features/bugfixes are not isolated, so that the complexity of ...
54
To start with, this comment:
... having a branch implies an extra complexity and thus extra work ...
is wholly false. I often hear it from people who aren't accustomed to branching, but it's still wrong.
If you have many developers accumulating changes locally, their local changes constitute a de-facto branch of the main repository.
When they finally ...
53
To answer, you have to ask yourself how you expect to use the results of these commits in the future. The most common reasons are:
To see what release a bug was introduced.
To see why a certain line of code is present.
To merge into another branch.
To be able to check out a previous version for troubleshooting an issue a customer or tester is seeing in ...
Only top voted, non community-wiki answers of a minimum length are eligible
