On 16-3-2016 16:05, Paul Beach wrote: > > Since some of us are newbies to git and github, I need to ask some questions > as I would like to move onto git asap and stop using sourceforge and svn. > > I had started looking at the Firebird 3 build and port for MacOS, and am > curious > as how I can do this work via git. Since git can uses branches for every > piece of > development (small to large), I am assuming I need to create my own > development > branch of B3_0_Release to work on... > > e.g. > git checkout -b mac-port B3_0_Release > > Then I do what I need to inside this checkout, via > git add, git commit, when finished I can then merge > my branch back into B3_0_Release > > Correct - or have I completely misread everything :-) > In which case some pointers would be appreciated
When you use git, you have local copy of the repository on your own machine. Commits go into this local repository, and until you push them to the origin repository, no one but you is affected. So in some ways, a master branch on your machine already is a branch of the master branch on the origin repository. So you don't *need* to create branches just to do things, but it can make life easier, especially in heavy traffic repositories, or when you need to share work in progress with others (pushing the branch to origin). But you can also continue using largely the same workflow as you used with Subversion, but you need to remember not only to commit, but also to push, pull and be prepared to handle the merge conflicts associated with having your own copy of the repository that might be in a different state than the origin repository. 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). 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. However branches can also make life harder, for example long-living branches that diverge from master without regular merges from master that need to be merged back can be hell (especially if you have a co-worker who does a merge with "accept mine" as a conflict resolution strategy, I think I got a few gray hairs that day...). There are lots of tutorials and other documentation that can help, and that probably explain things a lot better than my confused rambling above ;). Mark -- Mark Rotteveel ------------------------------------------------------------------------------ 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
