New answers tagged

1

Read the version from metadata generated at build time One thing you can do is to read the version from your Git tags at build time. Generate the raw text or code file that is required from your release commit after it is tagged. This metadata is a build artifact, and therefore will not be stored in the repo, but is still integrated into your code, so that ...


3

What am I missing? It breaks the golden rule of rebasing: Never rebase a public branch.


0

You never have merge conflicts merging into develop branch. Why? Because if there are merge conflicts, you don't merge. You merge develop into your branch first, then you merge without any conflicts. If you branch from another branch X (branched from develop) you can of course merge back into branch X. Merging into develop may be more difficult. What I ...


1

Semantic versioning (semver) is intended for for software products that have an API, and for which multiple versions will be available at the same time. It's most useful for software libraries, which have an API made up of exposed classes, functions, etc, but can also apply to software with an HTTP API. Developers of software that depends on something using ...


0

We ended up using submodules, I discovered that you have the option to add a branch name in the .gitmodules file through this SO post. So I add the last line of this code snippet to all my master branches [submodule "SubmoduleTestRepo"] path = SubmoduleTestRepo url = https://github.com/jzaccone/SubmoduleTestRepo.git branch = master And when ...


5

Git LFS is perfectly well-suited for versioning large binary assets. The problem with using git for managing dependencies isn't that git lfs can't handle it, it's that there are better solutions. What git can't do is resolve a tree of transitive dependencies. Dependency X itself depends on version 1.x of dependency Y. There is a version 1.6 of dependency Y, ...


1

I would have two requirements of shared code My own builds are repeatable I am not caught unaware by new bugs or breaking changes / I can actively choose when to advance to a newer version of the dependency These are usually fulfilled by locking down the version of the dependency, and some sort of versioning scheme. Nuget is good here because I will always ...


3

To be honest, I've always struggled to find good workflows to use when dealing with submodules, specifically because of the reason you've pointed out: But to make this work, we would need to change the submodules each time we merge Master to Stable. I am not a fan of having to coordinate a ton of merges across a bunch of repos in order to implement day-...


2

You need to split the idea of a build and a deployment in your mind. I find it best to imagine there is no internet and you are posting out CD ROMs to your customers, who then install and configure them You Build the source code and burn the CD ROM with version X Your customer Deploys the binary to their server and configures it for their environment. ...


3

In my view you should define separate execution environments in separate files, e.g. like Spring's application-test.yml, application-local.yml, application.yml etc. That way you can switch between executions by changing only one thing (the exact invokation command). Whether or not to arrange the description files so that duplicate settings are declared only ...


0

Whoever said that has a particular notion of "good coder" in mind, which probably goes like this: The Good Coder works alone on a Great Program that he or she designed alone. There are no forks of the program, or release branches or anything of the sort, and so there is never any rebasing activity that creates conflicts. When bugs are found in old releases ...


1

Continuous Integration. To understand why CI helps consider that in order to experience a merge conflict the change(s) in that branch need to conflict with one or more changes on master: A B C master *--*--*--*--* \ / feature-x *-------- The longer the branch exists for the more changes will be made on master, and ...


1

While frequent commits will not reduce the absolute occurrences of merge conflicts, but making them easier to resolve (at first sight), the truth is different: Commits don't come independently; usually they are a logical unit of work each. If the logical unit of work consists of several commits on a branch, the total merge conflicts will be the same when ...


0

"Programmers make mistakes all the time" --- John Carmack People who make assertions akin to "I'm a 'rockstar' developer" or "Good coders don't have to deal with merge conflicts..." are more often than not posers who seem to be plentiful in the general software development community and should be summarily ignored as such. Building software that will be in ...


6

As other answers have described, merge conflicts happen regardless of experience or skill, and an adage that claims that they're some kind of weakness that comes from lack of skill is ridiculous. Other answers have noted ways that skilled developers can learn to help make merge conflicts less likely, from preventing formatting chaos to frequent merges to ...


5

It's not so much the existence of merge conflicts, but how much of a problem they cause. The 'damage' from merge conflicts with inexperienced developers is seen as being a huge issue. People invent crazy source control schemes or even stop using source control all together to avoid these 'massive' issues. But with an experienced team, merge conflicts cause ...


21

One colleague of mine ran into a developer who didn't have to deal with merge conflicts. He made some changes, merged them, and a few days later the changes were gone. He found out that someone else (on a different continent as well) had replaced files instead of merging. He put the changes back in, slightly miffed - and a few days later the changes were ...


27

Probably the quote is incomplete: Good coders don't have to deal with merge conflicts... ... because good coders push force. Seriously, though, the only way to avoid merge conflicts is to work alone (and even that doesn't help; happened to me to have merge conflicts with myself on personal projects). In a company hiring experienced developers, there ...


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


Top 50 recent answers are included