Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been searching the web for best practices, but don't see anything that is consistent. If you have an excellent development process that includes successful releases of your product as well as hotfixes/patches and maintenance releases and you use git.

I would love to hear how you use git to accomplish this. Do you use branches, tags, etc? How do you use them? I am looking for details, please.

share|improve this question
    
1  
Beware best practices! –  Mark C Jan 17 '11 at 16:42
add comment

migrated from superuser.com Jan 17 '11 at 16:20

This question came from our site for computer enthusiasts and power users.

3 Answers

Your observation is correct: there aren't much best practices besides just using your common sense. It is pointless to ask for the right way of doing things with Git. Git was made to fit your process, not to impose a foreign "right" process onto you (as some other tools in this area indeed try to).

Having said that -- indeed you need to establish some kind of process for any of your development projects. But unfortunately there isn't a one size fits all "excellent process". Are you working alone? Are your team mates at the same site or scattered all over the globe? Is there a customer? Is there a project lead or manager? Is there even a product? Are you developing software, or are you tracking the files under your /etc directory or are you writing a novel and want to capture the various drafts...??

No one but yourself can answer these questions. And please don't think you can replace this step by picking any random tool. Tool vendors often try to lure people into this believe -- they are misguided.

Speaking of Git...

  • you can have one mainline -- often called "master"
  • you can have multiple independent mainlines
  • you can follow an upstream development
  • you can maintain multiple versions of some artefact
  • you can develop in feature branches
  • you can use the installed version as mainline and a branch for each developing effort
  • you can have the latest-greatest on mainline and cut stable release branches
  • you can have the same branch in multiple repositories
  • you can have different branches in different repositories and merge them into one official version
  • you can use one central repository which is managed by a almighty Gatekeeper
  • you can use a repository for each developer and over time the common denominator wins
  • you can setup a mob repository which everyone worldwide can push changes without restrictions
  • you can even have largely unrelated trees within the same repository

You see: there is no hope for Git providing you a fixed guideline. Git is pure Chaos -- it is your wit which gives it the necessary structure

share|improve this answer
add comment

I'm sure someone has a great poster of this but I typically develop as follows:

  1. Make changes
  2. Commit
  3. if patch?
    1. Make patch
    2. Apply patch
    3. Tag patch
    4. List patch in bugs
  4. else if new version
    1. Tag
    2. Deploy

I'm not sure in my head corresponds as well to what I have listed, but it's a process of making changes, merging branches, tagging patches and revisions, and listing them in the tracker.

I would love to hear how you use git to accomplish this. Do you use branches, tags, etc? How do you use them? I am looking for details, please.

It's a combination of the two. Normally you have a mainline branch which is code that is in production. Then you have a development (or on-bat branch) which is the +1 stable release. Splitting off of those you have branches for various features and improvements. Tags are used to keep track off recently used branches, identifying releases / patches, and in general "tagging" various commits with specific information.

share|improve this answer
add comment

For small projects, I would suggest setting up a GitHub account, they are reasonably priced and provide a very good service. If you are working on an open source project, then the 'pull request' features of github are very valuable.

I would suggest having a master branch, but work on milestone branches, and then merge your changes into the master branch.

This allows you to have several milestones being worked on at the same time in different branches, which will not interfere with the master branch.

Tags should be used for releases, they simply reference a commit, not any actual files or folders (unlike subversion)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.