StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2429011
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
11
CommunityOwnedDate
CreationDate
2010-03-11T22:01:54.107
FavoriteCount
0
LastActivityDate
2013-12-08T05:30:50.373
LastEditDate
2013-12-08T05:30:50.373
LastEditorUserId
2074608
OwnerUserId
242493
ParentId
2428722
PostTypeId
2
Score
226
ViewCount
0
LastEditorDisplayName
text
Body
You might benefit from the workflow Scott Chacon describes in <a href="http://git-scm.com/book" rel="noreferrer">Pro Git</a>. In this workflow, you have two branches that always exist, master and develop. master represents the most stable version of your project and you only ever deploy to production from this branch. develop contains changes that are in progress and may not necessarily be ready for production. From the develop branch, you create topic branches to work on individual features and fixes. Once your feature/fix is ready to go, you merge it into develop, at which point you can test how it interacts with other topic branches that your coworkers have merged in. Once develop is in a stable state, merge it into master. It should always be safe to deploy to production from master. Scott describes these long-running branches as "silos" of code, where code in a less stable branch will eventually "graduate" to one considered more stable after testing and general approval by your team. Step by step, your workflow under this model might look like this: <ol> <li>You need to fix a bug.</li> <li>Create a branch called myfix that is based on the develop branch.</li> <li>Work on the bug in this topic branch until it is fixed.</li> <li>Merge myfix into develop. Run tests.</li> <li>You discover your fix conflicts with another topic branch hisfix that your coworker merged into develop while you were working on your fix.</li> <li>Make more changes in the myfix branch to deal with these conflicts.</li> <li>Merge myfix into develop and run tests again.</li> <li>Everything works fine. Merge develop into master.</li> <li>Deploy to production from master any time, because you know it's stable.</li> </ol> For more details on this workflow, check out the <a href="http://git-scm.com/book/en/Git-Branching-Branching-Workflows" rel="noreferrer">Branching Workflows</a> chapter in Pro Git.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POGit branch strategy for small dev team
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USQantas 94 Heavy
UserOwnerUserId
1. USJimmy Cuadra
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POGit branch strategy for small dev team
 singulars
 PostTypePostTypeId
 PTQuestion
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

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.