StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
13757292
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
3
CommunityOwnedDate
CreationDate
2012-12-07T05:12:35.573
FavoriteCount
0
LastActivityDate
2015-01-27T20:03:59.847
LastEditDate
2015-01-27T20:03:59.847
LastEditorUserId
954480
OwnerUserId
64635
ParentId
5330145
PostTypeId
2
Score
25
ViewCount
0
LastEditorDisplayName
text
Body
Since the question has the "github" tag, I'd also add this: specifically in <a href="https://github.com/" rel="noreferrer">Github</a>, if you pull-request a branch and it gets merged (either via the UI or by merging the pull request's branch), you won't lose the pull request data (including comments), even if you remove the branch. A consequence of this: If you incorporate pull requests as a part of your workflow (which blends sweetly with code reviews), you can safely delete branches as soon as they get merged. This is so commonplace that recently Github added a (sweet) feature that pops a "delete branch" button right after you merge a pull request. But it is worth noticing that each group should adopt the workflow that suits it best (and it may or may not lead to deleting such branches). My current work team, for example, prunes all branches that are not master or deployment-related (e.g., production, staging, etc.) as soon as their pull requests gets merged, and we still have full tracking of how the related commits formed each incremental improvement of each product. Of course no history management (pull requests or otherwise) replaces proper tagging of versions (which you preferably automate with the same tool/script that deploys/packages a version), so you can always fast-switch to whatever your users happen to be on at a given moment. Tagging is also the key to solve your original problem: if you establish that any branch merged to the "work" branches can and should be deleted, and that any one that is merged to a version tag, "production", etc. should not, you'll always have the hotfixes alive until they are integrated in a future version.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhen to delete branches in Git?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USMrIsaacs
UserOwnerUserId
1. USchesterbr
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
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.