-
Notifications
You must be signed in to change notification settings - Fork 1
Git workflows
For future reference, please have a look at these two links, they sum up the main good practices:
- http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows : you will discover centralised workflow, Integration-Manager Workflow and Dictator and Lieutenants Workflow which is a multi level version of the integration manager workflow.
- http://git-scm.com/book/en/Git-Branching-Branching-Workflows : you will discover long running branches and topic branches.
Most of these practices derive from the distributed nature of git. Each developer has his own repository, accessible from the world wide web. But No one would give write access to anybody. In open source projects, the norm is however to give read access to everyone. From this statement, derives the idea of Merge Request, also called Pull Request. Historically in many open source projects, if you tried to improve a software, you would make a few changes and send a patch to the mailing list of said project. That is exactly the same idea with pull request. The principle is to tell the right people that you have changes worth reading, on a specific branch, on your server (or on the same if you share the same repo, but not commit right on all branches). Those people are: owner of a project, maintainer, or other person you want an opinion from.
Git still allows you to generate patch e-mails in the old tradition, so good old habits are still not dead git format-patch would generate an email containing the diff necessary for a patch. Enough with history lessons, but you get the idea behind the pull request paradigm. All git hosting website base their git management on single developers cloning a trusted repository, developing on it and creating such merge requests. They allow users to create them through a web interface, that will warn the people targeted by the request.
Outside of the scope here :-P. Merge until you can run on your own.
Jump to Advanced Topics