Oh, I mean I was talking about Open Source projects. If you just work privately and don’t say at some kind of central place (like a Discord or Matrix server) on what you’re working on, then it can easily happen that just two people do that at the same time without knowing of each other.
And ideally, each commit represents a working state of your software. If your team is disciplined enough with that, you can save yourself the feature branches and merges.
Are you expecting a developer to test everything every time they commit? Thoroughly testing even a small application or feature subset will take up quite a bit of time. You also want devs to commit often, so it is easy to roll back an approach that didn’t pan out, or just to go back and figure out what change caused something to stop working. If you end up committing only a few times per week because everything needs to be thoroughly tested, I’m not convinced it is a good approach.
No, they should not need to test everything, but this strongly depends on your code quality and project setup.
There’s definitely other paths to the goal, but generally for larger projects, I recommend:
Good isolation between components. A change in one component should not have unforeseeable effects in other components.
Automatic unit tests for each component, so devs can test their changes in isolation.
A statically typed, compiled language, so that compiling does a basic integration check between components.
Strong ties between components, where it makes sense. For example, ideally, the communication model between backend and frontend is in a shared module/library, so that if someone does change the model, it leads to compile errors on both sides.
Automatic integration tests + a CI/CD pipeline, which tests the rest of the application after each push. This will let you know as early as possible, if you did push a broken commit.
A multi-project build with all parts of your application in a monolithic repo, so that all components get continuously compiled + integrated with their most recent changes.
This rigidity does have challenges of its own.
For example, a change in the backend might force a change in the communication model and therefore in the frontend, too. And if you’re exclusively backend, you might struggle with updating the frontend accordingly.
Then you’ll need to push onto a separate branch and look at it with your frontend colleague later. But hopefully, you get that arranged within a day or two, so the merge conflicts should still be quite tame.
And obviously, this rigidity has tons of advantages. Not needing to wonder whether frontend and backend, or any other interface, is compatible right now, is just insanely good.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
git rebase -x theirs origin/mainand then look at the lines your changing to see what needs to be retouchedI’m more of a
git push origin/main —forceguy myselfReject “main” branch, embrace master branch
so true, lol
Git porcelain like magit make dealing with conflicts a lot more bearable.
I’ve got one more! I get stress based tension headaches, which represent as migraine symptoms!
Memes help tho.
Merge conflict in general is fine
What’s really bad is if someone drastically changed the implementation of something which you’ve also changed and if you completely need to rework it…
That’s not a merge conflict, that’s a management conflict.
Oh, I mean I was talking about Open Source projects. If you just work privately and don’t say at some kind of central place (like a Discord or Matrix server) on what you’re working on, then it can easily happen that just two people do that at the same time without knowing of each other.
Merge early and merge often.
And ideally, each commit represents a working state of your software. If your team is disciplined enough with that, you can save yourself the feature branches and merges.
Are you expecting a developer to test everything every time they commit? Thoroughly testing even a small application or feature subset will take up quite a bit of time. You also want devs to commit often, so it is easy to roll back an approach that didn’t pan out, or just to go back and figure out what change caused something to stop working. If you end up committing only a few times per week because everything needs to be thoroughly tested, I’m not convinced it is a good approach.
No, they should not need to test everything, but this strongly depends on your code quality and project setup.
There’s definitely other paths to the goal, but generally for larger projects, I recommend:
Good isolation between components. A change in one component should not have unforeseeable effects in other components.
Automatic unit tests for each component, so devs can test their changes in isolation.
A statically typed, compiled language, so that compiling does a basic integration check between components.
Strong ties between components, where it makes sense. For example, ideally, the communication model between backend and frontend is in a shared module/library, so that if someone does change the model, it leads to compile errors on both sides.
Automatic integration tests + a CI/CD pipeline, which tests the rest of the application after each push. This will let you know as early as possible, if you did push a broken commit.
A multi-project build with all parts of your application in a monolithic repo, so that all components get continuously compiled + integrated with their most recent changes.
This rigidity does have challenges of its own.
For example, a change in the backend might force a change in the communication model and therefore in the frontend, too. And if you’re exclusively backend, you might struggle with updating the frontend accordingly.
Then you’ll need to push onto a separate branch and look at it with your frontend colleague later. But hopefully, you get that arranged within a day or two, so the merge conflicts should still be quite tame.
And obviously, this rigidity has tons of advantages. Not needing to wonder whether frontend and backend, or any other interface, is compatible right now, is just insanely good.
Had to deal with that this morning, my god what does git want me to do
It’s the same with my colleagues as with my wife. It’s always a race who comes first.
Ayo
Jetbrains IDE is pretty good at solving conflicts.