tome export
This commit is contained in:
parent
52278c3a53
commit
7a52afab5f
960 changed files with 3670 additions and 2229 deletions
|
|
@ -82,15 +82,15 @@
|
|||
],
|
||||
"body": [
|
||||
{
|
||||
"value": "\n <p>Yesterday, I <a href=\"https:\/\/twitter.com\/scottkeckwarren\/status\/1594752744165847040\">saw a tweet<\/a> where the writer said they were \u201cfalling into the branch, pull request, and merge after actions pass I use at work even though I'm the only one working on it\u201d.<\/p>\n\n<p>After reading this, my question is, \"Should you, or do you need to, create branches if you're the only person working on a project?\".<\/p>\n\n<p>These days, I use trunk-based development as much as possible, so I hardly ever create new branches, whether working on a project myself or with a team.<\/p>\n\n<p><a href=\"/presentations\/git-flow\">I used to use Git Flow<\/a> and create branches for every new feature and bug fix, but I remember, whilst demonstrating two work-in-progress features to a client, switching between the different branches caused my local site to break. Whilst it wasn\u2019t a major issue, it wouldn't have seemed professional.<\/p>\n\n<p>In a team environment, feature branches are intended to keep different changes and different people's work separate.<\/p>\n\n<p>But is this needed if you\u2019re the only in the team?<\/p>\n\n<p>Assumingly, you're only working on one change at a time, so what's the benefit of creating a separate branch?<\/p>\n\n<p>If you need to switch to a different task, another approach could be to revert your work-in-progress commits, move them onto another local branch temporarily, or wrap them within a feature flag so that the changes are committed but not active.<\/p>\n\n<p>The other part of the tweet said, \u201cI like the little integrations to make sure the tests pass\u201d.<\/p>\n\n<p>I\u2019m comfortable working on a single branch and committing and pushing small changes often.<\/p>\n\n<p>My CI pipelines run for every change that I push, and if one fails, I\u2019ll either push a small fix to get it passing again or revert the failing change and investigate further.<\/p>\n\n<p>For me, working on a single branch keeps my workflow simple and lean, allowing me to focus on the changes and the tasks that I need to work on and not worry about which branch I\u2019m working on.<\/p>\n\n ",
|
||||
"value": "\n <p>Yesterday, I <a href=\"https:\/\/twitter.com\/scottkeckwarren\/status\/1594752744165847040\">saw a tweet<\/a> where the writer said they were \u201cfalling into the branch, pull request, and merge after actions pass I use at work even though I'm the only one working on it\u201d.<\/p>\n\n<p>After reading this, my question is, \"Should you, or do you need to, create branches if you're the only person working on a project?\".<\/p>\n\n<p>These days, I use trunk-based development as much as possible, so I hardly ever create new branches, whether working on a project myself or with a team.<\/p>\n\n<p><a href=\"\/presentations\/git-flow\">I used to use Git Flow<\/a> and create branches for every new feature and bug fix, but I remember, whilst demonstrating two work-in-progress features to a client, switching between the different branches caused my local site to break. Whilst it wasn\u2019t a major issue, it wouldn't have seemed professional.<\/p>\n\n<p>In a team environment, feature branches are intended to keep different changes and different people's work separate.<\/p>\n\n<p>But is this needed if you\u2019re the only in the team?<\/p>\n\n<p>Assumingly, you're only working on one change at a time, so what's the benefit of creating a separate branch?<\/p>\n\n<p>If you need to switch to a different task, another approach could be to revert your work-in-progress commits, move them onto another local branch temporarily, or wrap them within a feature flag so that the changes are committed but not active.<\/p>\n\n<p>The other part of the tweet said, \u201cI like the little integrations to make sure the tests pass\u201d.<\/p>\n\n<p>I\u2019m comfortable working on a single branch and committing and pushing small changes often.<\/p>\n\n<p>My CI pipelines run for every change that I push, and if one fails, I\u2019ll either push a small fix to get it passing again or revert the failing change and investigate further.<\/p>\n\n<p>For me, working on a single branch keeps my workflow simple and lean, allowing me to focus on the changes and the tasks that I need to work on and not worry about which branch I\u2019m working on.<\/p>\n\n ",
|
||||
"format": "full_html",
|
||||
"processed": "\n <p>Yesterday, I <a href=\"https:\/\/twitter.com\/scottkeckwarren\/status\/1594752744165847040\">saw a tweet<\/a> where the writer said they were \u201cfalling into the branch, pull request, and merge after actions pass I use at work even though I'm the only one working on it\u201d.<\/p>\n\n<p>After reading this, my question is, \"Should you, or do you need to, create branches if you're the only person working on a project?\".<\/p>\n\n<p>These days, I use trunk-based development as much as possible, so I hardly ever create new branches, whether working on a project myself or with a team.<\/p>\n\n<p><a href=\"/presentations\/git-flow\">I used to use Git Flow<\/a> and create branches for every new feature and bug fix, but I remember, whilst demonstrating two work-in-progress features to a client, switching between the different branches caused my local site to break. Whilst it wasn\u2019t a major issue, it wouldn't have seemed professional.<\/p>\n\n<p>In a team environment, feature branches are intended to keep different changes and different people's work separate.<\/p>\n\n<p>But is this needed if you\u2019re the only in the team?<\/p>\n\n<p>Assumingly, you're only working on one change at a time, so what's the benefit of creating a separate branch?<\/p>\n\n<p>If you need to switch to a different task, another approach could be to revert your work-in-progress commits, move them onto another local branch temporarily, or wrap them within a feature flag so that the changes are committed but not active.<\/p>\n\n<p>The other part of the tweet said, \u201cI like the little integrations to make sure the tests pass\u201d.<\/p>\n\n<p>I\u2019m comfortable working on a single branch and committing and pushing small changes often.<\/p>\n\n<p>My CI pipelines run for every change that I push, and if one fails, I\u2019ll either push a small fix to get it passing again or revert the failing change and investigate further.<\/p>\n\n<p>For me, working on a single branch keeps my workflow simple and lean, allowing me to focus on the changes and the tasks that I need to work on and not worry about which branch I\u2019m working on.<\/p>\n\n ",
|
||||
"processed": "\n <p>Yesterday, I <a href=\"https:\/\/twitter.com\/scottkeckwarren\/status\/1594752744165847040\">saw a tweet<\/a> where the writer said they were \u201cfalling into the branch, pull request, and merge after actions pass I use at work even though I'm the only one working on it\u201d.<\/p>\n\n<p>After reading this, my question is, \"Should you, or do you need to, create branches if you're the only person working on a project?\".<\/p>\n\n<p>These days, I use trunk-based development as much as possible, so I hardly ever create new branches, whether working on a project myself or with a team.<\/p>\n\n<p><a href=\"http:\/\/default\/presentations\/git-flow\">I used to use Git Flow<\/a> and create branches for every new feature and bug fix, but I remember, whilst demonstrating two work-in-progress features to a client, switching between the different branches caused my local site to break. Whilst it wasn\u2019t a major issue, it wouldn't have seemed professional.<\/p>\n\n<p>In a team environment, feature branches are intended to keep different changes and different people's work separate.<\/p>\n\n<p>But is this needed if you\u2019re the only in the team?<\/p>\n\n<p>Assumingly, you're only working on one change at a time, so what's the benefit of creating a separate branch?<\/p>\n\n<p>If you need to switch to a different task, another approach could be to revert your work-in-progress commits, move them onto another local branch temporarily, or wrap them within a feature flag so that the changes are committed but not active.<\/p>\n\n<p>The other part of the tweet said, \u201cI like the little integrations to make sure the tests pass\u201d.<\/p>\n\n<p>I\u2019m comfortable working on a single branch and committing and pushing small changes often.<\/p>\n\n<p>My CI pipelines run for every change that I push, and if one fails, I\u2019ll either push a small fix to get it passing again or revert the failing change and investigate further.<\/p>\n\n<p>For me, working on a single branch keeps my workflow simple and lean, allowing me to focus on the changes and the tasks that I need to work on and not worry about which branch I\u2019m working on.<\/p>\n\n ",
|
||||
"summary": null
|
||||
}
|
||||
],
|
||||
"feeds_item": [
|
||||
{
|
||||
"imported": "1970-01-01T00:33:45+00:00",
|
||||
"imported": "1970-01-01T00:32:50+00:00",
|
||||
"guid": null,
|
||||
"hash": "de98c57a7d583eb2f17a08ed813ccc09",
|
||||
"target_type": "feeds_feed",
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue