Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Git will not provide the "change management" process you're looking for. This is one of those management requirements that commercial version control systems like to advertise to attract businesses with shiny objects. That doesn't mean you can't do it, it's just outside the domain of git's purpose. Much like, authentication and access control (you can use ssh, and gitolite, but git itself does not provide these services). You'll probably need to develop this integration yourself unless you work with a common bug tracking tool.</p> <p>Locking files is always wrong. This is what "merging" is for.</p> <p>I currently work on a codebase of ~200,000 lines of code with 10 developers and git works very well. We have groups an order of magnitude larger also using git on other projects. Git's strength lies in merging and this is how it deals with multiple developers and lots of commits. Keep in mind, every push is a merge in git, whether it looks like it or not. Your local repository may have a branch named <code>master</code>, but it's not the same branch as <code>master</code> in the central repository. To synchronize them, you do a merge, which sometimes just is a "fast-forward merge".</p> <p>We don't bother to force a strong link to change requests. When I considered writing an interface to do this, one problem I ran into was how to make the dumb tracking system aware of every branch a bug is in. A simple hook isn't enough for this.</p> <p>You should move to git for the development process improvement. For me, it's fundamentally altered (improved) the way I write code. You'll be challenged to present a case for git doing change management better in business-speak without all the prepackaged bullets that come from expensive IBM tools. The real problem is, once you embrace git, you'll never be able to work with any of the other tools again, no matter how good a business case they present...</p>
    singulars
    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. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. COHow would you handle the case where (for example) 20 change requests are scheduled to be put through to production, but at the last minute it's decided that one should be pulled? From what I can see, you'd have to revert to the revision before that merge, then merge any cases that came after it. That seems like a lot of effort. With our current system, we just don't release the files pertaining to that CR (assuming they weren't also part of another CR).
      singulars
    2. CO@Samah This really depends on the development model you follow. I strongly recommend that if you do consider git, you consider adjusting your process to take advantage of its features (such as cheap branching, logical commits). As an example, for bugfix releases, we create a new release branch when we are planning a release. The changes are merged or cherry-picked into this branch by the release lead from various sources (dev branches, topic branches). If we change our mind, he can do a git revert on the commit to back out or rebase and wipe away the change.
      singulars
    3. COVery well put! I work with Mercurial, and when I'm talking to clients they often ask for "change requests". When I tell them that Mercurial had no such notion, they become surprised. Like Git, Mercurial is a *focused* tool. It does version control and lets you define workflows on top. You can phrase the workflows in terms of change requests if you like, but you don't have to.
      singulars
 

Querying!

 
Guidance

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