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

migration rejected from superuser.com Aug 5 at 21:20

This question came from our site for computer enthusiasts and power users. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, MichaelT, GlenH7, Bart van Ingen Schenau, Ampt Aug 5 at 21:20

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
1  
Beware best practices! –  Mark C Jan 17 '11 at 16:42

3 Answers 3

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

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

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