Creating new Git branches all the time even for minor/trivial changes
up vote
0
down vote
favorite
For a big project (front-end for filters), I have been working on a branch called filtersfrontend. But then I need to apply very minor fixes such as moving a button a few pixels down or changing the padding of an element a little bit for a <div> or <span> element for something that has absolutely nothing to do with the front-end for filters project.
This question is not intended to generate debate and I hope it does not get closed as a result of not having a Yes/No answer. I am looking for a best practice. Should I create new branches with intuitive names for every minor/trivial change that is unrelated to my big project, or is it okay the way I have been doing it, keep working on my filtersfrontend branch for the big project and just add minor changes to it. Yes, the problem is that minor/trivial changes multiplied for several times can became several lines of code and if I decided to abandon that branch because the big project of the front-end for filters does not end up being released, I will need to search in the commits to rescue code about minor/trivial changes that I had included in that branch.
Hopefully you can share with me if there is a best practice about this and this question does not get closed by administrators.
git version-control versioning
asked Nov 8 at 19:01
Jaime Montoya
1,01421429
add a comment |
up vote
0
down vote
favorite
For a big project (front-end for filters), I have been working on a branch called filtersfrontend. But then I need to apply very minor fixes such as moving a button a few pixels down or changing the padding of an element a little bit for a <div> or <span> element for something that has absolutely nothing to do with the front-end for filters project.
This question is not intended to generate debate and I hope it does not get closed as a result of not having a Yes/No answer. I am looking for a best practice. Should I create new branches with intuitive names for every minor/trivial change that is unrelated to my big project, or is it okay the way I have been doing it, keep working on my filtersfrontend branch for the big project and just add minor changes to it. Yes, the problem is that minor/trivial changes multiplied for several times can became several lines of code and if I decided to abandon that branch because the big project of the front-end for filters does not end up being released, I will need to search in the commits to rescue code about minor/trivial changes that I had included in that branch.
Hopefully you can share with me if there is a best practice about this and this question does not get closed by administrators.
git version-control versioning
asked Nov 8 at 19:01
Jaime Montoya
1,01421429
1
There is no good or bad answer. Best practices are set by the team and project demands. There people who work only onmaster, there are people who makesbranches, there are people who usegit-flow. There is an old arguably well explaining article onbranchingnvie.com/posts/a-successful-git-branching-model. However, again it is all matter of setting up your practices. Just remember, that there is always amergein the end of the day.
– muradm
Nov 8 at 19:20
1
For your case, if change does not fit the scope of current branch, you probably could create another branch, commit it, merge it to master, then sync master with previous branch, then finish it, commit it and merge to the master. So I think question will be a flame of holy wars.
– muradm
Nov 8 at 19:21
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
For a big project (front-end for filters), I have been working on a branch called filtersfrontend. But then I need to apply very minor fixes such as moving a button a few pixels down or changing the padding of an element a little bit for a <div> or <span> element for something that has absolutely nothing to do with the front-end for filters project.
This question is not intended to generate debate and I hope it does not get closed as a result of not having a Yes/No answer. I am looking for a best practice. Should I create new branches with intuitive names for every minor/trivial change that is unrelated to my big project, or is it okay the way I have been doing it, keep working on my filtersfrontend branch for the big project and just add minor changes to it. Yes, the problem is that minor/trivial changes multiplied for several times can became several lines of code and if I decided to abandon that branch because the big project of the front-end for filters does not end up being released, I will need to search in the commits to rescue code about minor/trivial changes that I had included in that branch.
Hopefully you can share with me if there is a best practice about this and this question does not get closed by administrators.
git version-control versioning
asked Nov 8 at 19:01
Jaime Montoya
1,01421429
For a big project (front-end for filters), I have been working on a branch called filtersfrontend. But then I need to apply very minor fixes such as moving a button a few pixels down or changing the padding of an element a little bit for a <div> or <span> element for something that has absolutely nothing to do with the front-end for filters project.
This question is not intended to generate debate and I hope it does not get closed as a result of not having a Yes/No answer. I am looking for a best practice. Should I create new branches with intuitive names for every minor/trivial change that is unrelated to my big project, or is it okay the way I have been doing it, keep working on my filtersfrontend branch for the big project and just add minor changes to it. Yes, the problem is that minor/trivial changes multiplied for several times can became several lines of code and if I decided to abandon that branch because the big project of the front-end for filters does not end up being released, I will need to search in the commits to rescue code about minor/trivial changes that I had included in that branch.
Hopefully you can share with me if there is a best practice about this and this question does not get closed by administrators.
git version-control versioning
git version-control versioning
asked Nov 8 at 19:01
Jaime Montoya
1,01421429
asked Nov 8 at 19:01
Jaime Montoya
1,01421429
edited Nov 8 at 19:09
asked Nov 8 at 19:01
Jaime Montoya
1,01421429
asked Nov 8 at 19:01
Jaime Montoya
1,01421429
asked Nov 8 at 19:01
Jaime Montoya
1,01421429
1,01421429
1
There is no good or bad answer. Best practices are set by the team and project demands. There people who work only onmaster, there are people who makesbranches, there are people who usegit-flow. There is an old arguably well explaining article onbranchingnvie.com/posts/a-successful-git-branching-model. However, again it is all matter of setting up your practices. Just remember, that there is always amergein the end of the day.
– muradm
Nov 8 at 19:20
1
For your case, if change does not fit the scope of current branch, you probably could create another branch, commit it, merge it to master, then sync master with previous branch, then finish it, commit it and merge to the master. So I think question will be a flame of holy wars.
– muradm
Nov 8 at 19:21
add a comment |
1
There is no good or bad answer. Best practices are set by the team and project demands. There people who work only onmaster, there are people who makesbranches, there are people who usegit-flow. There is an old arguably well explaining article onbranchingnvie.com/posts/a-successful-git-branching-model. However, again it is all matter of setting up your practices. Just remember, that there is always amergein the end of the day.
– muradm
Nov 8 at 19:20
1
For your case, if change does not fit the scope of current branch, you probably could create another branch, commit it, merge it to master, then sync master with previous branch, then finish it, commit it and merge to the master. So I think question will be a flame of holy wars.
– muradm
Nov 8 at 19:21
1
1
There is no good or bad answer. Best practices are set by the team and project demands. There people who work only on
master, there are people who makes branches, there are people who use git-flow. There is an old arguably well explaining article on branching nvie.com/posts/a-successful-git-branching-model. However, again it is all matter of setting up your practices. Just remember, that there is always a merge in the end of the day.– muradm
Nov 8 at 19:20
There is no good or bad answer. Best practices are set by the team and project demands. There people who work only on
master, there are people who makes branches, there are people who use git-flow. There is an old arguably well explaining article on branching nvie.com/posts/a-successful-git-branching-model. However, again it is all matter of setting up your practices. Just remember, that there is always a merge in the end of the day.– muradm
Nov 8 at 19:20
1
1
For your case, if change does not fit the scope of current branch, you probably could create another branch, commit it, merge it to master, then sync master with previous branch, then finish it, commit it and merge to the master. So I think question will be a flame of holy wars.
– muradm
Nov 8 at 19:21
For your case, if change does not fit the scope of current branch, you probably could create another branch, commit it, merge it to master, then sync master with previous branch, then finish it, commit it and merge to the master. So I think question will be a flame of holy wars.
– muradm
Nov 8 at 19:21
add a comment |
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
I don't see the point of creating separate branches for minor changes related to the work you are doing on a long-running branch... Unless you want to keep those minor changes as "merges" and not just fast-forwards on a linear branch when you merge them into the original long-running branch.... But, hey... that's a mater of taste, if you ask me. I would rather worry about the question of "when do I delete those minor-change branches? Do I keep them for long?" And then my answer would be "what's the point of keeping them?".
answered Nov 8 at 19:22
eftshift0
4,154817
Me neither. I do not see the point of creating separate branches for minor changes related to the work that I am doing on a long-running branch. The point here is that the minor changes are UNRELATED TO THE WORK. As I mentioned, maybe some margin or padding in the footer that has nothing to do with the current long-running branch that I am using.
– Jaime Montoya
Nov 8 at 19:59
1
No need to yell at me
– eftshift0
Nov 8 at 20:01
I am sorry for using capital letters, I should have used bold instead, or quotes. I was just trying to emphasize that part and I never meant to be mean. It is the opposite, thank you for providing an answer to my question.
– Jaime Montoya
Nov 8 at 20:02
1
Use a separate branch to keep them so that they are "unrelated" to the long running branch that we are talking about. Say you have a minor-ui-fix branch for this work. What I would do is: fix the problem on the long-running branch, checkout minor-ui-fix, cherry-pick the other branch (that will apply only the last fix related to UI, as we said), then go back to the long running branch and dogit reset --hard HEAD~1to remove the last ui-related change that you already cherry-picked into the right branch....
– eftshift0
Nov 8 at 20:14
or reset --soft or --mixed if you have stuff laying around that you don't want to clean with --hard, whatever you consider will be right for your workflow.
– eftshift0
Nov 8 at 20:14
add a comment |
up vote
0
down vote
One thing that occurs to me is to have a branch for miscelaneous or minor changes whose purpose is precisely to fix minor things unrelated to the big projects that I am developing on my long-running active branches. For example, for a request for fixing the padding of a link in the footer, instead of applying that minor/trivial change to the long-running branch that I am using, I could apply it to the branch of miscellaneous changes and then that could be merged into "master" regularly. By doing that I could make sure that the names of branches are always intuitive 100% for what the code really does.
answered Nov 8 at 20:46
Jaime Montoya
1,01421429
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
I don't see the point of creating separate branches for minor changes related to the work you are doing on a long-running branch... Unless you want to keep those minor changes as "merges" and not just fast-forwards on a linear branch when you merge them into the original long-running branch.... But, hey... that's a mater of taste, if you ask me. I would rather worry about the question of "when do I delete those minor-change branches? Do I keep them for long?" And then my answer would be "what's the point of keeping them?".
answered Nov 8 at 19:22
eftshift0
4,154817
Me neither. I do not see the point of creating separate branches for minor changes related to the work that I am doing on a long-running branch. The point here is that the minor changes are UNRELATED TO THE WORK. As I mentioned, maybe some margin or padding in the footer that has nothing to do with the current long-running branch that I am using.
– Jaime Montoya
Nov 8 at 19:59
1
No need to yell at me
– eftshift0
Nov 8 at 20:01
I am sorry for using capital letters, I should have used bold instead, or quotes. I was just trying to emphasize that part and I never meant to be mean. It is the opposite, thank you for providing an answer to my question.
– Jaime Montoya
Nov 8 at 20:02
1
Use a separate branch to keep them so that they are "unrelated" to the long running branch that we are talking about. Say you have a minor-ui-fix branch for this work. What I would do is: fix the problem on the long-running branch, checkout minor-ui-fix, cherry-pick the other branch (that will apply only the last fix related to UI, as we said), then go back to the long running branch and dogit reset --hard HEAD~1to remove the last ui-related change that you already cherry-picked into the right branch....
– eftshift0
Nov 8 at 20:14
or reset --soft or --mixed if you have stuff laying around that you don't want to clean with --hard, whatever you consider will be right for your workflow.
– eftshift0
Nov 8 at 20:14
add a comment |
up vote
1
down vote
accepted
I don't see the point of creating separate branches for minor changes related to the work you are doing on a long-running branch... Unless you want to keep those minor changes as "merges" and not just fast-forwards on a linear branch when you merge them into the original long-running branch.... But, hey... that's a mater of taste, if you ask me. I would rather worry about the question of "when do I delete those minor-change branches? Do I keep them for long?" And then my answer would be "what's the point of keeping them?".
answered Nov 8 at 19:22
eftshift0
4,154817
Me neither. I do not see the point of creating separate branches for minor changes related to the work that I am doing on a long-running branch. The point here is that the minor changes are UNRELATED TO THE WORK. As I mentioned, maybe some margin or padding in the footer that has nothing to do with the current long-running branch that I am using.
– Jaime Montoya
Nov 8 at 19:59
1
No need to yell at me
– eftshift0
Nov 8 at 20:01
I am sorry for using capital letters, I should have used bold instead, or quotes. I was just trying to emphasize that part and I never meant to be mean. It is the opposite, thank you for providing an answer to my question.
– Jaime Montoya
Nov 8 at 20:02
1
Use a separate branch to keep them so that they are "unrelated" to the long running branch that we are talking about. Say you have a minor-ui-fix branch for this work. What I would do is: fix the problem on the long-running branch, checkout minor-ui-fix, cherry-pick the other branch (that will apply only the last fix related to UI, as we said), then go back to the long running branch and dogit reset --hard HEAD~1to remove the last ui-related change that you already cherry-picked into the right branch....
– eftshift0
Nov 8 at 20:14
or reset --soft or --mixed if you have stuff laying around that you don't want to clean with --hard, whatever you consider will be right for your workflow.
– eftshift0
Nov 8 at 20:14
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
I don't see the point of creating separate branches for minor changes related to the work you are doing on a long-running branch... Unless you want to keep those minor changes as "merges" and not just fast-forwards on a linear branch when you merge them into the original long-running branch.... But, hey... that's a mater of taste, if you ask me. I would rather worry about the question of "when do I delete those minor-change branches? Do I keep them for long?" And then my answer would be "what's the point of keeping them?".
answered Nov 8 at 19:22
eftshift0
4,154817
I don't see the point of creating separate branches for minor changes related to the work you are doing on a long-running branch... Unless you want to keep those minor changes as "merges" and not just fast-forwards on a linear branch when you merge them into the original long-running branch.... But, hey... that's a mater of taste, if you ask me. I would rather worry about the question of "when do I delete those minor-change branches? Do I keep them for long?" And then my answer would be "what's the point of keeping them?".
answered Nov 8 at 19:22
eftshift0
4,154817
answered Nov 8 at 19:22
eftshift0
4,154817
answered Nov 8 at 19:22
eftshift0
4,154817
answered Nov 8 at 19:22
eftshift0
4,154817
4,154817
Me neither. I do not see the point of creating separate branches for minor changes related to the work that I am doing on a long-running branch. The point here is that the minor changes are UNRELATED TO THE WORK. As I mentioned, maybe some margin or padding in the footer that has nothing to do with the current long-running branch that I am using.
– Jaime Montoya
Nov 8 at 19:59
1
No need to yell at me
– eftshift0
Nov 8 at 20:01
I am sorry for using capital letters, I should have used bold instead, or quotes. I was just trying to emphasize that part and I never meant to be mean. It is the opposite, thank you for providing an answer to my question.
– Jaime Montoya
Nov 8 at 20:02
1
Use a separate branch to keep them so that they are "unrelated" to the long running branch that we are talking about. Say you have a minor-ui-fix branch for this work. What I would do is: fix the problem on the long-running branch, checkout minor-ui-fix, cherry-pick the other branch (that will apply only the last fix related to UI, as we said), then go back to the long running branch and dogit reset --hard HEAD~1to remove the last ui-related change that you already cherry-picked into the right branch....
– eftshift0
Nov 8 at 20:14
or reset --soft or --mixed if you have stuff laying around that you don't want to clean with --hard, whatever you consider will be right for your workflow.
– eftshift0
Nov 8 at 20:14
add a comment |
Me neither. I do not see the point of creating separate branches for minor changes related to the work that I am doing on a long-running branch. The point here is that the minor changes are UNRELATED TO THE WORK. As I mentioned, maybe some margin or padding in the footer that has nothing to do with the current long-running branch that I am using.
– Jaime Montoya
Nov 8 at 19:59
1
No need to yell at me
– eftshift0
Nov 8 at 20:01
I am sorry for using capital letters, I should have used bold instead, or quotes. I was just trying to emphasize that part and I never meant to be mean. It is the opposite, thank you for providing an answer to my question.
– Jaime Montoya
Nov 8 at 20:02
1
Use a separate branch to keep them so that they are "unrelated" to the long running branch that we are talking about. Say you have a minor-ui-fix branch for this work. What I would do is: fix the problem on the long-running branch, checkout minor-ui-fix, cherry-pick the other branch (that will apply only the last fix related to UI, as we said), then go back to the long running branch and dogit reset --hard HEAD~1to remove the last ui-related change that you already cherry-picked into the right branch....
– eftshift0
Nov 8 at 20:14
or reset --soft or --mixed if you have stuff laying around that you don't want to clean with --hard, whatever you consider will be right for your workflow.
– eftshift0
Nov 8 at 20:14
Me neither. I do not see the point of creating separate branches for minor changes related to the work that I am doing on a long-running branch. The point here is that the minor changes are UNRELATED TO THE WORK. As I mentioned, maybe some margin or padding in the footer that has nothing to do with the current long-running branch that I am using.
– Jaime Montoya
Nov 8 at 19:59
Me neither. I do not see the point of creating separate branches for minor changes related to the work that I am doing on a long-running branch. The point here is that the minor changes are UNRELATED TO THE WORK. As I mentioned, maybe some margin or padding in the footer that has nothing to do with the current long-running branch that I am using.
– Jaime Montoya
Nov 8 at 19:59
1
1
No need to yell at me
– eftshift0
Nov 8 at 20:01
No need to yell at me
– eftshift0
Nov 8 at 20:01
I am sorry for using capital letters, I should have used bold instead, or quotes. I was just trying to emphasize that part and I never meant to be mean. It is the opposite, thank you for providing an answer to my question.
– Jaime Montoya
Nov 8 at 20:02
I am sorry for using capital letters, I should have used bold instead, or quotes. I was just trying to emphasize that part and I never meant to be mean. It is the opposite, thank you for providing an answer to my question.
– Jaime Montoya
Nov 8 at 20:02
1
1
Use a separate branch to keep them so that they are "unrelated" to the long running branch that we are talking about. Say you have a minor-ui-fix branch for this work. What I would do is: fix the problem on the long-running branch, checkout minor-ui-fix, cherry-pick the other branch (that will apply only the last fix related to UI, as we said), then go back to the long running branch and do
git reset --hard HEAD~1 to remove the last ui-related change that you already cherry-picked into the right branch....– eftshift0
Nov 8 at 20:14
Use a separate branch to keep them so that they are "unrelated" to the long running branch that we are talking about. Say you have a minor-ui-fix branch for this work. What I would do is: fix the problem on the long-running branch, checkout minor-ui-fix, cherry-pick the other branch (that will apply only the last fix related to UI, as we said), then go back to the long running branch and do
git reset --hard HEAD~1 to remove the last ui-related change that you already cherry-picked into the right branch....– eftshift0
Nov 8 at 20:14
or reset --soft or --mixed if you have stuff laying around that you don't want to clean with --hard, whatever you consider will be right for your workflow.
– eftshift0
Nov 8 at 20:14
or reset --soft or --mixed if you have stuff laying around that you don't want to clean with --hard, whatever you consider will be right for your workflow.
– eftshift0
Nov 8 at 20:14
add a comment |
up vote
0
down vote
One thing that occurs to me is to have a branch for miscelaneous or minor changes whose purpose is precisely to fix minor things unrelated to the big projects that I am developing on my long-running active branches. For example, for a request for fixing the padding of a link in the footer, instead of applying that minor/trivial change to the long-running branch that I am using, I could apply it to the branch of miscellaneous changes and then that could be merged into "master" regularly. By doing that I could make sure that the names of branches are always intuitive 100% for what the code really does.
answered Nov 8 at 20:46
Jaime Montoya
1,01421429
add a comment |
up vote
0
down vote
One thing that occurs to me is to have a branch for miscelaneous or minor changes whose purpose is precisely to fix minor things unrelated to the big projects that I am developing on my long-running active branches. For example, for a request for fixing the padding of a link in the footer, instead of applying that minor/trivial change to the long-running branch that I am using, I could apply it to the branch of miscellaneous changes and then that could be merged into "master" regularly. By doing that I could make sure that the names of branches are always intuitive 100% for what the code really does.
answered Nov 8 at 20:46
Jaime Montoya
1,01421429
add a comment |
up vote
0
down vote
up vote
0
down vote
One thing that occurs to me is to have a branch for miscelaneous or minor changes whose purpose is precisely to fix minor things unrelated to the big projects that I am developing on my long-running active branches. For example, for a request for fixing the padding of a link in the footer, instead of applying that minor/trivial change to the long-running branch that I am using, I could apply it to the branch of miscellaneous changes and then that could be merged into "master" regularly. By doing that I could make sure that the names of branches are always intuitive 100% for what the code really does.
answered Nov 8 at 20:46
Jaime Montoya
1,01421429
One thing that occurs to me is to have a branch for miscelaneous or minor changes whose purpose is precisely to fix minor things unrelated to the big projects that I am developing on my long-running active branches. For example, for a request for fixing the padding of a link in the footer, instead of applying that minor/trivial change to the long-running branch that I am using, I could apply it to the branch of miscellaneous changes and then that could be merged into "master" regularly. By doing that I could make sure that the names of branches are always intuitive 100% for what the code really does.
answered Nov 8 at 20:46
Jaime Montoya
1,01421429
answered Nov 8 at 20:46
Jaime Montoya
1,01421429
answered Nov 8 at 20:46
Jaime Montoya
1,01421429
answered Nov 8 at 20:46
Jaime Montoya
1,01421429
1,01421429
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53214466%2fcreating-new-git-branches-all-the-time-even-for-minor-trivial-changes%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
There is no good or bad answer. Best practices are set by the team and project demands. There people who work only on
master, there are people who makesbranches, there are people who usegit-flow. There is an old arguably well explaining article onbranchingnvie.com/posts/a-successful-git-branching-model. However, again it is all matter of setting up your practices. Just remember, that there is always amergein the end of the day.– muradm
Nov 8 at 19:20
1
For your case, if change does not fit the scope of current branch, you probably could create another branch, commit it, merge it to master, then sync master with previous branch, then finish it, commit it and merge to the master. So I think question will be a flame of holy wars.
– muradm
Nov 8 at 19:21