StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
20530832
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-12-11T22:01:27.973
FavoriteCount
0
LastActivityDate
2013-12-11T22:15:25.340
LastEditDate
2013-12-11T22:15:25.340
LastEditorUserId
202121
OwnerUserId
202121
ParentId
20529412
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
This answer show a workflow which uses local branches as an alternative to the stash mechanism. This is the approach I prefer myself. I'm going to assume that: <ul> <li>Your public branch head is called <code>master</code></li> <li>This "atomic operation" is a script used for making releases.</li> <li>The release tag (<code>product-1.0.0</code>) needs to point to B in the end.</li> <li>The release commit (<code>E</code>) needs to be "added" to the tip of master, after <code>C</code> and <code>D</code>.</li> <li>You have <code>master</code> checked out and your working tree is clean.</li> </ul> The history looks like this initially (the <code>origin</code> remote represents what's public, <code>HEAD</code> points to your currently checked out branch head): <pre><code>(A)<--(B)<--(C)<--(D) ^ ^ / \ master orgin/master ^ | HEAD </code></pre> You need to be able to see this graph yourself. I usually use a git alias like this (<code>g</code> for "graph"): <pre><code>git config --global alias.g "log --decorate --oneline --graph" </code></pre> You can then get the picture above by invoking: <pre><code>git g master origin/master </code></pre> (That displays everything reachable from <code>master</code> and/or <code>origin/master</code>. Use <code>git g --all</code> to show everytihng.) First create a local temporary branch head called <code>temp</code> that points to <code>B</code>, and then check it out. <pre><code>git branch temp <SHA1 of B> git checkout temp </code></pre> The commit graph now looks like this: <pre><code> HEAD | v temp | v (A)<--(B)<--(C)<--(D) ^ ^ / \ master orgin/master </code></pre> Run your release script which tags the current commit, makes a change (probably bumping up the release number or something), and then makes a commit of that change. <pre><code><magic release script> </code></pre> If I understand your release script correctly, then the resulting graph should look like this: <pre><code> HEAD | v temp | v tag: product-1.0.0 (E) \ / v v (A)<--(B)<--(C)<--(D) ^ ^ / \ master orgin/master </code></pre> It's now time to move back to <code>master</code> and to "carry over" the <code>E</code> commit: <pre><code>git checkout master git cherry-pick <SHA1 of E> </code></pre> The <code>cherry-pick</code> command treats a single commit as a patch. The "patch" contains the difference between the tree snapshot at <code>B</code> and the snapshot at <code>E</code>. This "patch" is then applied at whatever branch head you have checked out - in this case <code>master</code>. The changes in the patch are made into a new commit (<code>F</code>) with the same message, and author as the original one (<code>E</code>). <pre><code> temp | v tag: product-1.0.0 (E) \ / v v (A)<--(B)<--(C)<--(D)<--(F) ^ ^ | | origin/master master ^ | HEAD </code></pre> Note that the <code>F</code> commit is not identical to the <code>E</code> commit! It is only "the same in spirit", that is it introduces the same logical change. After this, review the final state and you should be ready to push the new <code>master</code> state to <code>origin</code> to make it public. <pre><code>git push origin master:master </code></pre> You can now remove the temporary <code>temp</code> branch head: <pre><code>git branch -D temp </code></pre> You usually use the <code>-d</code> option to delete a branch, but <code>git</code> won't let you use it here. The reason is that you will lose the <code>E</code> commit. In this case it is OK since we have "saved" <code>E</code> by using <code>cherry-pick</code>. As <code>git</code> considers <code>E</code> and <code>F</code> to be distinct commits it can't know that the "spirit of <code>E</code>" remains in <code>F</code> and no information would be lost. You need to tell <code>git</code> that you have made sure that you know what you are doing by using <code>-D</code> instead of <code>-d</code>. Finally you should have: <pre><code> tag: product-1.0.0 | v (A)<--(B)<--(C)<--(D)<--(F) ^ ^ / \ origin/master master ^ | HEAD </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POCreate tag and make local changes, then rebase against public branch
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USraek
UserOwnerUserId
1. USraek
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POCreate tag and make local changes, then rebase against public branch
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.