Brent Goodrick <bgoodr@xxxxxxxxx> writes: > Suppose I create a git repo called central.git on a machine I will > call "central". In that central.git repo, I put these files: > > work.sh > home.sh > generic.sh > > When I clone the central.git repo on to a different machine I will > call "work", I want this fileset to be pulled: > > work.sh > generic.sh > > But not the home.sh file. You would have one common branch and one branch per deployment. A common branch would host only common files (e.g. generic.sh file from your example). Per deployment branch, e.g. home, would branch from the common branch (so it starts with some version of generic.sh) and may add its own private files (e.g. home.sh). And stick to the following two rules: - You make edits to common files only on the common branch. - You merge from common to deployment, never the other way. So at work, you would have a checkout of your work "deployment branch", and find needs to change things. It is Ok to edit both work.sh and generic.sh (without being able to edit both, it would be hard to verify if the changes would work together) at this time, but don't commit the result in the work branch. Save the changes to work.sh away (e.g. "git diff work.sh >P.diff" and then "git checkout HEAD work.sh"), switch to the common branch, and commit the changes to the generic file. Switch back to the deployment branch, merge the common branch (to pick up the changes to home.sh), reapply the changes specific to the deployment you saved earlier (e.g. "git apply P.diff"), tne commit the result. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
