Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I second the idea of using <strong>two branches</strong>: a public branch for the general version (which is pushed to GitHub) and a private branch for your specialized code (which is not published on GitHub). However, I would like to add that <code>git stash</code> is an essential tool that allows you to do what you want to do in the scenario that you outline (you're in the middle of working on the personal version, and you find a change to be done in the general version).</p> <p>It is indeed good practice to always implement general changes in the general branch, and then do</p> <pre><code>git checkout personal git merge general </code></pre> <p>Now, <strong>you can usefully use, in addition,</strong> <code>git stash</code>; let's take the scenario where your are updating the specialized version and thinking about a general change:</p> <ol> <li><p>You save your current changes to the specialized version:</p> <pre><code>git stash </code></pre> <p>This stashes the changes compared to the last commit, without creating a new commit. This is useful for storing your uncommitted work in progress.</p></li> <li><p>You go to the general branch so as to make the general change that you were thinking about:</p> <pre><code>git checkout general # or master, or whatever name your general branch has </code></pre> <p>You can then implement your general modification and commit it as usual.</p></li> <li><p>Before resuming work on your specialized version, you import the general change:</p> <pre><code>git checkout personal git merge general </code></pre> <p>git is intelligent enough to do this nicely: only the latest, generally useful update should be made to your code.</p></li> <li><p>You resume your work on the specialized branch by importing your stashed work in progress:</p> <pre><code>git stash pop </code></pre></li> </ol> <p>That's all! The key is to use <code>git stash</code> in order to save changes in the middle of your work, without creating a commit just for this, and then to apply back your changes with <code>git stash pop</code>.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow do I handle two separate yet very similar code-bases with git /github?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USEric Lebigot
    1. USEric Lebigot
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for the stash stuff. I would prefer to make a change while in 'personal'. So example, I just changed a var definition that was needed to be customized on 'personal' branch. While doing that, I notice that the comment for that variable could be better. I go ahead and update that too, right in the 'personal' branch. Now, after saving that file, if there were some command to say "Ok, now go do an interactive merge of this back to 'general', and in that interaction, I get to pick that I only want the comment to come over to 'general'. I think this is what was referred to as cherry picking
      singulars
      1. PO
      1. USNay
    2. CO@NickYeates: `git cherry-pick` only allows you to selectively import some *commits*. This means that you would use it this way: *commit* the special changes to the personal branch; *commit* the general changes to the personal branch; cherry-pick the last commit and apply it on the general branch. `git stash` is more flexible, as it allows you to avoid committing; this can be useful if, say, you want your committed code to always be in a working state. To summarize, both `cherry-pick` and `stash` are useful; if you know them both, you can really do what is most convenient for you.
      singulars
      1. PO
      1. USEric Lebigot
 

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.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload