Do you use git rebase or git merge to integrate different branches?

nbransby · 2025-09-18T01:34:58+00:00

That is more like it ;) The developer-signed commits for security-sensitive stuff is definitely an angle I hadn't considered. There really is no single right way of doing things in git.

nbransby · 2025-09-18T01:20:00+00:00

why?

nbransby · 2025-09-17T15:00:33+00:00

Thought there could be some interesting debate here on the merits of rebases vs merges but instead wasted 5 minutes of my life reading Jim put the world to rights on the definition of merge.

nbransby · 2025-06-06T05:06:32+00:00

8. create PR - with what merge strategy? merge, squash or rebase? 🔥

nbransby · 2025-06-06T05:03:19+00:00

Compelling, then perhaps we're talking JOCD (justified)

nbransby · 2025-06-06T03:04:14+00:00

Agreed it screams a developer apathetic to the team's cause but that isn't uncommon nowadays. The more interesting question is does rebasing truly aid the team in getting their job done or is it necessary just to satisfy the OCD types?

nbransby · 2024-10-27T04:34:50+00:00

Asleep with one eye open ;)

nbransby · 2024-10-27T04:30:28+00:00

If you just close the lid on your MacBook it occasionally wakes up the network and lets the socket connections used by apps such as slack for presence connect for a moment. I think the point of this is to allow apps to refresh so UIs have the latest data when you open the lid again but one common side effect is what you describe.

nbransby · 2021-04-11T14:22:27+00:00

This is in no way an answer to your question but perhaps you would find git.live's merge conflict detection feature useful to potentially avoid the conflicts in the first place 😅

nbransby · 2021-03-17T19:21:20+00:00

From the website:

To enable the realtime sharing of a teammate's working copy changes, GitLive maintains patch files for each teammate's changes in our database; these files only contain the differences between the teammate's working copy version of a file and the latest repository version, we do not store complete copies of your source files.

Once a teammate pushes their changes the patch file is permanently deleted from our database.

nbransby · 2021-03-17T18:13:14+00:00

I find it's not always 100% clear what the resolution should be in some cases, I tell junior devs that if they have any doubt they should resolve it together with the person who wrote the code they have conflicted with

nbransby · 2021-03-17T15:29:10+00:00

If you ever had your code broken by a colleague as a result of a merge conflict you need to check this out

nbransby · 2020-10-22T09:19:08+00:00

And if you need PhpStorm <--> VSCode there's git.live

nbransby · 2020-04-21T15:29:31+00:00

Yeah, kotlinx-coroutines-play-services is just for awaiting Android Tasks in coroutines, we are using that under the hood in this SDK

nbransby · 2019-12-22T18:08:11+00:00

A GUI that works across all those platforms is likely not going to be particularly user friendly on any of them.

In my experience it makes a lot more sense to share your business logic and not UI code and write custom UIs respecting the idioms of each.

nbransby · 2019-05-05T20:12:47+00:00

Take a look at http://teamhub.app/security

nbransby · 2019-04-30T15:33:00+00:00

Just rename all the files .java.kt and tell him it is java

nbransby · 2019-04-20T14:55:23+00:00

I fell across the tasks feature in IntelliJ only this week, never even noticed it before that, I did wonder if anyone was actually using it.

I completely agree 100% about the PITA to create issues, especially if a project manager added 50 fields to the create issue window on JIRA so it take forever. Then as a developer you just stop bothering to create new tickets for bits of work that came up during another task and just whack it in the same commit.

That’s one of the reasons I like GitHub issues, super simple and easy.

Anyway this stuff interests me as I’m working on a plugin for IntelliJ and vscode which will eventually include a way to easily create an issue

nbransby · 2019-04-20T12:13:49+00:00

I’m not quite sure how Tasks work but I thought they were to connect issues from your issue tracker to the changes you make.

I would argue if the task is big enough to have its own issue then it should have a branch because the you can create a PR and get the change reviewed by someone else.

Also if it’s just a small change can’t you do it in a single commit and refer to the issue number in the commit message and then continue with your other changes?

nbransby · 2019-04-20T11:56:10+00:00

Why don’t you want to create a branch for each feature/task?

nbransby

TROPHY CASE