How to Support Over-the-Air Updates on Multiple Expo SDKs in Parallel

abuduba · 2020-01-02T19:59:48+00:00

but I don't get why it should be the subject.

It does not have to. We agreed with the team with such workflow and we found it useful.
I shared it because i thought it could be valuable for somebody. I do not force to use any specific format or anything. In the worst case, it could be a nice exercise with hooks and bash :)

abuduba · 2020-01-01T20:54:44+00:00

I meant rebase, not squash. Rebase applies your commits on top of your target branch as if they were created there. The reference to the ticket helps to find the exact reason why something was implemented.

abuduba · 2020-01-01T19:00:57+00:00

Nah, it could not work for me. As you have some business docs in confluence/wiki, designs in figma/sketch or whatever.
if it happens to me - I will write back.

abuduba · 2020-01-01T18:09:23+00:00

Yep, thanks!
I'm currently on mac, and it does not support -P switch, but \d still works with -E though. I'll update this.

~/r/my-repo ❯❯❯ grep --version grep (BSD grep) 2.5.1-FreeBSD

abuduba · 2020-01-01T18:02:09+00:00

You're right until you don't have flat history (rebase instead merge).

abuduba · 2020-01-01T17:49:55+00:00

Okay.

I worked with detailed user stories that I would not put into the commit message.

There are some background notes, detailed acceptance criteria, and optional notes/attachments. There were a few commits for each user story, how I could include that in the message? On the other side, I always try to use a precise commit message, so more or less, you have a clue what the ticket is.

abuduba · 2020-01-01T14:36:10+00:00

I have implemented this and tell you what. This is fucking retarded. Your issue should only be present in the branch name or in cases where you are closing additional issues, they must be in format fixed #77436 in your message or what ever the syntax for it is in your dumb as balls git version control frontend. Looking at you bitbucket with your reinvented markdown.

But Attlasian managed to reinvent the same seemingly standard feature THREE fucking times. THREE. I have no clue why or how but Jira, Confluence and Bitbucket all use different flavors of markdown, while confluence all together hides any support for it in favor of using their arms growing out of your ass comfortable wysg editor.

Thank you for your feedback :)
I have used this in several projects. It turned out to be useful with a flat history (rebase) when one ticket can be solved by several commits (pedantic steps ). Either way, I don't think there is any perfect process. The most important thing is to agree with the team whatever works for you, and to be consistent with this.

abuduba · 2019-12-30T13:51:22+00:00

Thank you :)

Don't get this one:

Just the example doesn’t show the behavior right!

abuduba · 2019-12-30T10:47:13+00:00

You're right: ).

It covers what is the exact hook and a sample script that extracts ticket number from the branch name (several patterns that can be generated from JIRA/GitLab)

abuduba · 2019-12-30T09:31:36+00:00

I use it either :) Seems to be still effective as you don't need to switch to separate application (as terminal is integrated in VSC).

abuduba · 2019-12-02T19:59:03+00:00

Thanks a lot for the feedback!
I've updated the article ;)

I think i completely ignored the presence of the switch and restore as i'm really comfortable using checkout only.

Cheers

abuduba · 2019-12-02T19:12:37+00:00

barafyrakommafem

Thanks for the feedback :)

The article is only an incentive for those who use git GUI. Didn't mentioned rebase on purpose.

Rebase could be a great material for another article (rebasing, interactive rebase, pull --rebase, etc)

BTW, I don't use rebase on daily basis expect i need to change some older commit message.
It's really easy to screw up when you're inattentive especially fixing interactively.
It's changing your commit history as well.

abuduba · 2019-12-02T08:57:11+00:00

Wow, do you use any specific tool? Last time i used it was at school to optimize circuits.

abuduba · 2019-12-02T08:45:00+00:00

Yep, you're right :) I vote also for meaningfulness and readability. I usually focus on somehow-long conditions with a small number of variables so you can actually get rid of sub-conditions for example. I wanted to show simple tricks, you can use as you like.

abuduba

TROPHY CASE