On Wed, Mar 16, 2016 at 08:48:31PM +0100, Mark Rotteveel wrote: > > Branches can make life easier. You can keep your work in progress out of > the way from the changes to master, and when you are done you can merge > them back into master (which occasionally requires something akin to > magic spells with merges from master to branch, conflict resolution, > rebases, merges from branch to master, holy wars about the preferences > of merge method (do you rebase and fast-forward, or not), etc).
One of the advantages of getting used to use these "topic" branches rather than adding commits directly to a local copy of "upstream" branch (e.g. B3_0_Release here) is that it allows you to work on several different bugs or features and simply switch between the branches as needed. The workflow could look like git checkout master git checkout -b CORE-6001 ... (some editing) git add ... git commit git checkout -b CORE-6002 master ... (some editing) git add ... git commit git checkout CORE-6001 ... (some editing) git add ... git commit and when you are done with the fix, you can do e.g. git checkout B3_0_Release git pull git checkout -b CORE-6001-3.0 git cherry-pick master..CORE-6001 With some luck, it might work even for 2.5 after resolving some conflicts. One can also have branches that are never intended to be merged back. For example, I have branches tracking patches used in openSUSE packages. These are then updated regularly by git checkout B3_0_Release git pull git checkout mk-3.0 git rebase B3_0_Release >From time to time, some conflicts need to be resolved and then git format-patch B3_0_Release provides me with updated patches fitting on top of current snapshot. Probably the most important thing to remember is that the same thing can be done in few different ways and that it doesn't necessarily mean that one of them is the right one and others are wrong. > Or you can keep your changes in the branch, push the branch to the > origin repository and then use a pull request as a review mechanism. With Github workflow, one usually pushes into his fork of the original repository and then creates a pull request using the web interface. > There are lots of tutorials and other documentation that can help, and > that probably explain things a lot better than my confused rambling > above ;). One of the good ones is "Pro Git" book by Scott Chacon which can be viewed or downloaded at https://git-scm.com/book/en/v2 For basic developer needs, chapters 1-3 are sufficient, to participate in a project, chapter 5 can help (at least first two sections) and as we are moving to Github, chapter 6 can be handy (again, at least first two sections). Michal Kubecek ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
