Return to Question

I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy:

• Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

• All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies.

• Merges to higher-level branches are always rebased or squashed (to avoid clutter).

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

edit: it says "always use squash", but I meant for small hotfixes; and use rebase --interactive for local feature branches before merging, as explained in this article.

https://i.sstatic.net/nQjZZ.png

I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy:

• Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

• All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies.

• Merges to higher-level branches are always rebased or squashed (to avoid clutter).

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

edit 2: fixed bad idea in the original flowchart and made it a bit easier to navigate.

I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy:

• Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

• All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies.

• Merges to higher-level branches are always squashed (to avoid clutter).

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

edit: it says "always use squash", but I meant for small hotfixes; and use rebase --interactive for local feature branches before merging, as explained in this article.

https://i.sstatic.net/nQjZZ.png

I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy:

• Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

• All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies.

• Merges to higher-level branches are always rebased or squashed (to avoid clutter).

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

edit: it says "always use squash", but I meant for small hotfixes; and use rebase --interactive for local feature branches before merging, as explained in this article.

https://i.sstatic.net/nQjZZ.png

I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy:

• Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

• All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies.

• Merges to higher-level branches are always squashed (to avoid clutter).

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

https://i.sstatic.net/nQjZZ.png

I'm trying to come up with a personal workflow. I've put together a flowchart of the hypothetical lifespan of a release: one developer pushing to a public github repo + a friend helping with some feature and fixing a bug.

Is this a reasonable approach to version control?

The main idea is to keep the public repo tidy:

• Each new release gets on its own branch until it's finally tagged in the master branch when it's finished.

• All work is done on "feature" or "hotfix" branches, never on an actual release branch, to prevent anomalies.

• Merges to higher-level branches are always squashed (to avoid clutter).

If it's overkill I don't mind because the whole point is for me is to learn skills I might need for a larger project. The only problem would be if I'm doing something flat out wrong or unnecessary.

edit: it says "always use squash", but I meant for small hotfixes; and use rebase --interactive for local feature branches before merging, as explained in this article.

https://i.sstatic.net/nQjZZ.png