Trying To Understand/Determine A Basic Git Workflow












0














I've been reading this popular document over and over to try and draft my own git workflow.



I think I have got it down, but I am still a little lost. Here is my current understanding...







We have two branches that will always remain active.




  • Master: This is where I will push code that will actually be deployed to my production server and be used by my users.

  • Development: This will be branched from the master branch. It will include all my new features, bug fixes etc that will be pushed into the next release.





We have multiple topic branches that will be branched from the development branch (I think). Once the topic, example the bug as been fixed, we merge that branch back into the development branch. Some examples:




  • Topic Branch 1: feature-ajaxify-shoping-cart

  • Topic Branch 2: bugfix-navbar-font-overlapping





Prepare The Release




  • We have 1 release branch at a time that will be branched from the
    feature branch.

  • Now we pull/merge all the features, bug fixes etc we
    want to push into the next release.

  • We can leave some features we have been working on that wont be in the next release (I think).





Creating The Release




  • Once satisfied with the releases, we can then merge that release branch into the master branch, and name the commit something like 'v1.2.0'.

  • We also want to tag that commit with 'v1.2.0' so we can easily go back in time and see releases.





Side notes I have learned



The master branch is always nice and clean, and only contains commits that are releases (I think thats why we have a separate release branch, right?).



Please let me know where I have messed up or misinterpreted something etc. Thanks!














share|improve this question
























  • What you have explained is correct, but looks like you have just focused on branch only though git have much more to offer. You may refer this answer to cover few more cases stackoverflow.com/questions/40892485/…
    – user7154703
    Nov 21 at 6:40
















0














I've been reading this popular document over and over to try and draft my own git workflow.



I think I have got it down, but I am still a little lost. Here is my current understanding...







We have two branches that will always remain active.




  • Master: This is where I will push code that will actually be deployed to my production server and be used by my users.

  • Development: This will be branched from the master branch. It will include all my new features, bug fixes etc that will be pushed into the next release.





We have multiple topic branches that will be branched from the development branch (I think). Once the topic, example the bug as been fixed, we merge that branch back into the development branch. Some examples:




  • Topic Branch 1: feature-ajaxify-shoping-cart

  • Topic Branch 2: bugfix-navbar-font-overlapping





Prepare The Release




  • We have 1 release branch at a time that will be branched from the
    feature branch.

  • Now we pull/merge all the features, bug fixes etc we
    want to push into the next release.

  • We can leave some features we have been working on that wont be in the next release (I think).





Creating The Release




  • Once satisfied with the releases, we can then merge that release branch into the master branch, and name the commit something like 'v1.2.0'.

  • We also want to tag that commit with 'v1.2.0' so we can easily go back in time and see releases.





Side notes I have learned



The master branch is always nice and clean, and only contains commits that are releases (I think thats why we have a separate release branch, right?).



Please let me know where I have messed up or misinterpreted something etc. Thanks!














share|improve this question
























  • What you have explained is correct, but looks like you have just focused on branch only though git have much more to offer. You may refer this answer to cover few more cases stackoverflow.com/questions/40892485/…
    – user7154703
    Nov 21 at 6:40














0












0








0


1





I've been reading this popular document over and over to try and draft my own git workflow.



I think I have got it down, but I am still a little lost. Here is my current understanding...







We have two branches that will always remain active.




  • Master: This is where I will push code that will actually be deployed to my production server and be used by my users.

  • Development: This will be branched from the master branch. It will include all my new features, bug fixes etc that will be pushed into the next release.





We have multiple topic branches that will be branched from the development branch (I think). Once the topic, example the bug as been fixed, we merge that branch back into the development branch. Some examples:




  • Topic Branch 1: feature-ajaxify-shoping-cart

  • Topic Branch 2: bugfix-navbar-font-overlapping





Prepare The Release




  • We have 1 release branch at a time that will be branched from the
    feature branch.

  • Now we pull/merge all the features, bug fixes etc we
    want to push into the next release.

  • We can leave some features we have been working on that wont be in the next release (I think).





Creating The Release




  • Once satisfied with the releases, we can then merge that release branch into the master branch, and name the commit something like 'v1.2.0'.

  • We also want to tag that commit with 'v1.2.0' so we can easily go back in time and see releases.





Side notes I have learned



The master branch is always nice and clean, and only contains commits that are releases (I think thats why we have a separate release branch, right?).



Please let me know where I have messed up or misinterpreted something etc. Thanks!














share|improve this question















I've been reading this popular document over and over to try and draft my own git workflow.



I think I have got it down, but I am still a little lost. Here is my current understanding...







We have two branches that will always remain active.




  • Master: This is where I will push code that will actually be deployed to my production server and be used by my users.

  • Development: This will be branched from the master branch. It will include all my new features, bug fixes etc that will be pushed into the next release.





We have multiple topic branches that will be branched from the development branch (I think). Once the topic, example the bug as been fixed, we merge that branch back into the development branch. Some examples:




  • Topic Branch 1: feature-ajaxify-shoping-cart

  • Topic Branch 2: bugfix-navbar-font-overlapping





Prepare The Release




  • We have 1 release branch at a time that will be branched from the
    feature branch.

  • Now we pull/merge all the features, bug fixes etc we
    want to push into the next release.

  • We can leave some features we have been working on that wont be in the next release (I think).





Creating The Release




  • Once satisfied with the releases, we can then merge that release branch into the master branch, and name the commit something like 'v1.2.0'.

  • We also want to tag that commit with 'v1.2.0' so we can easily go back in time and see releases.





Side notes I have learned



The master branch is always nice and clean, and only contains commits that are releases (I think thats why we have a separate release branch, right?).



Please let me know where I have messed up or misinterpreted something etc. Thanks!











git github merge version-control






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 21 at 4:43

























asked Nov 21 at 3:00









Rich

203




203












  • What you have explained is correct, but looks like you have just focused on branch only though git have much more to offer. You may refer this answer to cover few more cases stackoverflow.com/questions/40892485/…
    – user7154703
    Nov 21 at 6:40


















  • What you have explained is correct, but looks like you have just focused on branch only though git have much more to offer. You may refer this answer to cover few more cases stackoverflow.com/questions/40892485/…
    – user7154703
    Nov 21 at 6:40
















What you have explained is correct, but looks like you have just focused on branch only though git have much more to offer. You may refer this answer to cover few more cases stackoverflow.com/questions/40892485/…
– user7154703
Nov 21 at 6:40




What you have explained is correct, but looks like you have just focused on branch only though git have much more to offer. You may refer this answer to cover few more cases stackoverflow.com/questions/40892485/…
– user7154703
Nov 21 at 6:40












1 Answer
1






active

oldest

votes


















0














Your summary is accurate: you can find illustrated in this cheatsheet.



Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).

There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)



The difference is:




  • with git flow, multiple feature branches are merged in devel (where they discover if they can work together or not), then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).


  • with gitworkflow:



    • feature branches are merged to a "public" "alpha" branch, which is reset after each release (meaning, deleted/recreated on top of the new release)

    • then a subset of those same feature branches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top of master after each new release.

    • then a sub-subset of feature branches are merged to master, to prepare the next release.




The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.

Only feature branches are merged to the lifecycle branches (public, next, master).
That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.






share|improve this answer























  • Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right?
    – Rich
    Nov 21 at 10:39












  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….
    – VonC
    Nov 21 at 12:45










  • @Rich The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other."
    – VonC
    Nov 21 at 12:45










  • Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol.
    – Rich
    Nov 22 at 5:55












  • @Rich The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release.
    – VonC
    Nov 22 at 5:57













Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53404684%2ftrying-to-understand-determine-a-basic-git-workflow%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









0














Your summary is accurate: you can find illustrated in this cheatsheet.



Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).

There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)



The difference is:




  • with git flow, multiple feature branches are merged in devel (where they discover if they can work together or not), then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).


  • with gitworkflow:



    • feature branches are merged to a "public" "alpha" branch, which is reset after each release (meaning, deleted/recreated on top of the new release)

    • then a subset of those same feature branches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top of master after each new release.

    • then a sub-subset of feature branches are merged to master, to prepare the next release.




The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.

Only feature branches are merged to the lifecycle branches (public, next, master).
That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.






share|improve this answer























  • Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right?
    – Rich
    Nov 21 at 10:39












  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….
    – VonC
    Nov 21 at 12:45










  • @Rich The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other."
    – VonC
    Nov 21 at 12:45










  • Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol.
    – Rich
    Nov 22 at 5:55












  • @Rich The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release.
    – VonC
    Nov 22 at 5:57


















0














Your summary is accurate: you can find illustrated in this cheatsheet.



Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).

There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)



The difference is:




  • with git flow, multiple feature branches are merged in devel (where they discover if they can work together or not), then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).


  • with gitworkflow:



    • feature branches are merged to a "public" "alpha" branch, which is reset after each release (meaning, deleted/recreated on top of the new release)

    • then a subset of those same feature branches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top of master after each new release.

    • then a sub-subset of feature branches are merged to master, to prepare the next release.




The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.

Only feature branches are merged to the lifecycle branches (public, next, master).
That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.






share|improve this answer























  • Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right?
    – Rich
    Nov 21 at 10:39












  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….
    – VonC
    Nov 21 at 12:45










  • @Rich The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other."
    – VonC
    Nov 21 at 12:45










  • Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol.
    – Rich
    Nov 22 at 5:55












  • @Rich The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release.
    – VonC
    Nov 22 at 5:57
















0












0








0






Your summary is accurate: you can find illustrated in this cheatsheet.



Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).

There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)



The difference is:




  • with git flow, multiple feature branches are merged in devel (where they discover if they can work together or not), then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).


  • with gitworkflow:



    • feature branches are merged to a "public" "alpha" branch, which is reset after each release (meaning, deleted/recreated on top of the new release)

    • then a subset of those same feature branches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top of master after each new release.

    • then a sub-subset of feature branches are merged to master, to prepare the next release.




The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.

Only feature branches are merged to the lifecycle branches (public, next, master).
That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.






share|improve this answer














Your summary is accurate: you can find illustrated in this cheatsheet.



Be aware though that in order to test your feature with the other ones, you have to merge them to develop (git flow feature finish MYFEATURE).

There is another workflow (the Git workflow) which allows for a better feature promotion (to develop, then to release)



The difference is:




  • with git flow, multiple feature branches are merged in devel (where they discover if they can work together or not), then release is created from devel (at which point removing features becomes complex) before being merged back to devel (and master).


  • with gitworkflow:



    • feature branches are merged to a "public" "alpha" branch, which is reset after each release (meaning, deleted/recreated on top of the new release)

    • then a subset of those same feature branches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top of master after each new release.

    • then a sub-subset of feature branches are merged to master, to prepare the next release.




The "public" and "next" (aka 'devel') branches are never merged to master. They are "transient" or "ephemeral", always deleted/recreated.

Only feature branches are merged to the lifecycle branches (public, next, master).
That means at any time you can chose to drop a feature between one stage of the development lifecycle and the next.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 22 at 17:01

























answered Nov 21 at 5:43









VonC

829k28826083152




829k28826083152












  • Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right?
    – Rich
    Nov 21 at 10:39












  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….
    – VonC
    Nov 21 at 12:45










  • @Rich The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other."
    – VonC
    Nov 21 at 12:45










  • Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol.
    – Rich
    Nov 22 at 5:55












  • @Rich The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release.
    – VonC
    Nov 22 at 5:57




















  • Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right?
    – Rich
    Nov 21 at 10:39












  • @Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….
    – VonC
    Nov 21 at 12:45










  • @Rich The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other."
    – VonC
    Nov 21 at 12:45










  • Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol.
    – Rich
    Nov 22 at 5:55












  • @Rich The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release.
    – VonC
    Nov 22 at 5:57


















Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right?
– Rich
Nov 21 at 10:39






Good to hear. So this method is called 'git flow'? I didnt really understand the link you posted, but I will try and make sense of it.I can do everything manually instead of using that git tool right?
– Rich
Nov 21 at 10:39














@Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….
– VonC
Nov 21 at 12:45




@Rich All the details are in github.com/rocketraman/gitworkflow. That workflow uses regular Git commands though, not a wrapper like "git flow"). See more in hackernoon.com/….
– VonC
Nov 21 at 12:45












@Rich The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other."
– VonC
Nov 21 at 12:45




@Rich The key passage: " in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts. Gitworkflow allows both goals to be achieved without sacrificing one for the other."
– VonC
Nov 21 at 12:45












Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol.
– Rich
Nov 22 at 5:55






Ok I understand the problem with gitflow (pollution of topic branches that may not be ready to go in the next release, so a lot of back and fourth pollution). But I still don't see how gitworkflow solves this. Instead of merging the topic branch into development, we merge it into next. Then what? All I see is the development branch changing the name to next lol.
– Rich
Nov 22 at 5:55














@Rich The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release.
– VonC
Nov 22 at 5:57






@Rich The key difference is gitworkflow is using a transient branch to try and merge features branches, before merging (again) a selected subset of those feature branch to the actual release, as part of the next release.
– VonC
Nov 22 at 5:57




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53404684%2ftrying-to-understand-determine-a-basic-git-workflow%23new-answer', 'question_page');
}
);

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







Popular posts from this blog

404 Error Contact Form 7 ajax form submitting

How to know if a Active Directory user can login interactively

TypeError: fit_transform() missing 1 required positional argument: 'X'