Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think, and I might be wrong, that one of the things that's most misunderstood about git is its distributed nature. This makes it very different to say subversion in the ways you can work although you can mimick SVN behaviour should you want. The problem is pretty much any workflow will do, which is great but also misleading.</p> <p>If I have my understanding of kernel development (I'll focus on that) right, everyone has their own git repository for developing the kernel. There is one repository, linux-2.6.git, looked after by Torvalds, that acts as the release repository. People clone from here if they wish to start developing a feature against the "release" branch.</p> <p>Other repositories do some development. The idea is to clone from linux-2.6, branch out as many times as you like until such a point as you've got a working "new" feature. Then, when this is ready, you may make it available to someone considered trusted, who will pull this branch from your repository into theirs and merge it into the mainstream. In the linux kernel this happens on several levels (trusted lieutenants) until it reaches linux-2.6.git at which point it becomes "the kernel".</p> <p>Now here's where it gets confusing. Branch names don't need to be consistent across repositories at all. So I can <code>git pull origin master:vanilla-code</code> and get a branch from the <code>origin</code>'s master in a branch in my repository called <code>vanilla-code</code>. Providing I know what's going on, it really doesn't matter - it is distributed in the sense that all repositories are peers to each other and not just shared across several computers like SVN.</p> <p>So, with all of this in mind:</p> <ol> <li>I think it is up to each programmer how they do their branching. All you need is a central repository for managing releases etc. Trunk could be <code>head</code>. Releases could be tags or branches and hotfixes are probably branches in themselves. In fact, I'd probably do releases as branches so you can keep patching them.</li> <li>I would merge and not rebase. If for example you take a repository, clone it, branch and do some dev, then pull from your <code>origin</code> you should, in your repository, probably make another branch and merge the latest <code>master</code> into <code>yourbranch</code> so that someone else can pull your changes with as little effort as possible. There is very rarely a need to truly rebase, in my experience.</li> <li>I think it's a case of understanding the way Git works and what it can do. It does take a while and a lot of good communication - I only truly started to understand what's going on when I began using git with other developers and even now, some things I'm not sure about.</li> <li>Merge conflicts are useful. I know, I know, you want it all to work, but, the fact is code changes and you do need to merge the results into something that works. Merge conflicts are in fact just more programming. I've never found an easy explanation for what to do about them, so here it is: note the files that have merge conflicts, go and change them to what they should be, <code>git add .</code> and then <code>git commit</code>.</li> <li>However it suits. As I've said, each users git repository is their own to play with and branch names <em>don't need to be the same</em>. If you had a staging repository, for example, you could enforce a naming schema, but you don't need to for each developer, only in the release repo.</li> <li>This is the merge stage. You only merge into release branches etc when you consider code to be reviewed/pass quality testing.</li> </ol> <p>I hope that helps. I realise VonC as just posted a very similar explanation... I can't type fast enough!</p> <p><strong>Edit</strong> some further thoughts on how to use git in a commercial setting, as this seems relevant to the OP from the comments: </p> <ul> <li>The release repository, we'll call it <code>product.git</code>, is accessible by a number of senior programmers / technical people responsible for actually looking after the product itself. They are analogous to the role of maintainers in OSS.</li> <li>These programmers probably also in part lead development of new versions, so they might also code themselves and maintain varios repositories. They might manage staging repositories for really new features and they might also have their own repositories. </li> <li>Below them are programmers responsible for developing individual bits. For example, someone might be responsible for the UI work. They therefore manage the UI.git repository.</li> <li>Below them are the actual programmers who develop the features as their full day to day job.</li> </ul> <p>So what happens? Well, everyone pulls at the start of each day from the "upstream" source i.e. the release repository (which will also probably contain the latest material from the previous days development). Everyone does this, directly. This will go on a branch in their repository, probably called "master" or maybe if you're me called "latest". The programmer will then do some work. This work might be something they're not sure about, so they make a branch, do the work. If it doesn't work, they can delete the branch and go back. If it does, they will have to merge into the main branch they're currently working on. We'll say this is a UI programmer working on <code>latest-ui</code> so he does <code>git checkout latest-ui</code> followed by <code>git merge abc-ui-mywhizzynewfeature</code>. He then tells his technical lead (the UI lead) hey, I've completed such a task, pull from me. So the UI lead does <code>git pull user-repo lastest-ui:lastest-ui-suchafeature-abc</code>. The UI lead then looks at it on that branch and says, actually, that's very good, I'll merge it into <code>ui-latest</code>. He might then tell everyone below him to pull from him on their <code>ui-latest</code> branches or whatever name they've given them, and so the feature gets explored by the devs. If the team is happy, the UI lead might ask the testing lead to pull from him and merge the changes. This propagates out to everyone (downstream of the change) who tests it and submits bug reports etc. Finally, if the feature passes testing etc, one of the top technical leads might merge it into the current working copy of the program, at which point all the changes are then propagated back down. And so on.</p> <p>It's not a "traditional" way of working and is designed to be "peer driven" rather than "hierarchical" like SVN/CVS. In essence, everyone has commit access, but only locally. It is access to the repository and which repository you designate as the release repo that allows you to use hierarchy.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat Git branching models work for you?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    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
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO+1 for the "distributed" aspect clarification.
      singulars
      1. PO
      1. USVonC
    2. COThanks a bunch for your extensive answer (and votes), I will read it a couple more time to wring useful information out of it. However, we're a company, not a OSS development committee ;-), and I have to help my developers with more clear guidelines than "fiddle around as you want in your own repository". Let's see where this post leads, I feel a good momentum, keep it coming!
      singulars
      1. PO
      1. USHiQ CJ
    3. CO@VonC Thanks. @UncleCJ true, but you do, I'm sure, have release-managers etc. Anyone with access to the repository can do these things. As for development, why not give developers the freedom, within reason, to branch away? Providing you have some protocol for agreeing merges and your central repository(ies) are named as you like, there isn't a problem. Having said that, a common naming schema isn't a bad idea. I tend to use initials-version-feature-subbranches for personal branches and version for branches.
      singulars
      1. PO
      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.

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