Trying To Understand/Determine A Basic Git Workflow
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
asked Nov 21 at 3:00
Rich
203
add a comment |
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
asked Nov 21 at 3:00
Rich
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
add a comment |
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
asked Nov 21 at 3:00
Rich
203
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
git github merge version-control
asked Nov 21 at 3:00
Rich
203
asked Nov 21 at 3:00
Rich
203
edited Nov 21 at 4:43
asked Nov 21 at 3:00
Rich
203
asked Nov 21 at 3:00
Rich
203
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
add a comment |
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
add a comment |
1 Answer
1
active
oldest
votes
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
featurebranches are merged indevel(where they discover if they can work together or not), thenreleaseis created fromdevel(at which point removing features becomes complex) before being merged back todevel(andmaster).
with gitworkflow:
featurebranches 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
featurebranches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top ofmasterafter each new release. - then a sub-subset of
featurebranches are merged tomaster, 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.
answered Nov 21 at 5:43
VonC
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
|
show 16 more comments
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
});
}
});
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%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
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
featurebranches are merged indevel(where they discover if they can work together or not), thenreleaseis created fromdevel(at which point removing features becomes complex) before being merged back todevel(andmaster).
with gitworkflow:
featurebranches 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
featurebranches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top ofmasterafter each new release. - then a sub-subset of
featurebranches are merged tomaster, 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.
answered Nov 21 at 5:43
VonC
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
|
show 16 more comments
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
featurebranches are merged indevel(where they discover if they can work together or not), thenreleaseis created fromdevel(at which point removing features becomes complex) before being merged back todevel(andmaster).
with gitworkflow:
featurebranches 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
featurebranches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top ofmasterafter each new release. - then a sub-subset of
featurebranches are merged tomaster, 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.
answered Nov 21 at 5:43
VonC
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
|
show 16 more comments
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
featurebranches are merged indevel(where they discover if they can work together or not), thenreleaseis created fromdevel(at which point removing features becomes complex) before being merged back todevel(andmaster).
with gitworkflow:
featurebranches 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
featurebranches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top ofmasterafter each new release. - then a sub-subset of
featurebranches are merged tomaster, 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.
answered Nov 21 at 5:43
VonC
829k28826083152
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
featurebranches are merged indevel(where they discover if they can work together or not), thenreleaseis created fromdevel(at which point removing features becomes complex) before being merged back todevel(andmaster).
with gitworkflow:
featurebranches 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
featurebranches are merged to a "next" ("beta") branch for integration/acceptance test. That "next" ("beta") branch is similarly recreated on top ofmasterafter each new release. - then a sub-subset of
featurebranches are merged tomaster, 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.
answered Nov 21 at 5:43
VonC
829k28826083152
edited Nov 22 at 17:01
answered Nov 21 at 5:43
VonC
829k28826083152
answered Nov 21 at 5:43
VonC
829k28826083152
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
|
show 16 more comments
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
|
show 16 more comments
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.
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%2f53404684%2ftrying-to-understand-determine-a-basic-git-workflow%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
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