On Sat, May 30, 2015 at 10:53:47AM -0700, Tim Dawson wrote: > I'm fairly new to Git. I've learned how to commit, branch etc. > > I'm working on a web site which has problems with cross-browser > compatibility. > > I have created a branch called 'no-flex' in which I've created new > files to try out a completely different set of CSS styling to a > stand-alone web page. This has been successful. I have committed the > new files in the 'no-flex' branch. > > I now want to introduce this new approach to styling to the 'master' > branch, which contains files for the entire web site. I need the new > files so that I can refer to them and probably do a bit of copy & > paste. If I simply go back to the master branch I think I will lose > my 'no-flex' files, so I think I need to checkout (i.e. go back to) > master and merge 'no-flex'. > Is that correct ? > > This will result in my new files becoming part of the master branch. > But they aren't really part of the main web site, they are just a > side excursion to try something out. Eventually when I've milked > them for their content they will become redundant (though I probably > won't want to delete them from my computer). > > Many of the files in the master branch will get changed radically in > the process, some may no longer be needed, and there will be some > new ones. The final result will be a web site that looks much the > same as now, but whose CSS (and other) files will be incompatible > with the current version. > > Perhaps this is exactly what Git does best, but I have a few > concerns: > 1. What does Git actually do with a file that exists in an un-merged > branch if I go back to the master branch ?
All files that are committed on a branch will remain, and you can at any time check out that branch and you'll find the files in your work area. In fact, this is one of the core pieces of functionality in any VCS > 2. Will that file still be visible in the directory tree of my text > editor ? (I think not) Your work area will reflect the branch (or more generally, the point in history) you have checked out. So, if the file in question doesn't exist in the branch you have checked out you won't have it in your work area. > 3. What does Git do if I delete a previously committed file from my > directory tree ? Just try it! Remove a file that you have committed and then run `git status`. You'll see that git notices that the file now is missing. At that point you can either restore it (`git checkout <file name>`) or stage a removal (`git rm <file name>`). > 4. When I've finished with the files from the 'no-flex' branch, do I > retain them in the current version, or unstage them so they > become untracked (but don't get deleted) ? This may be a matter > of choice, but what is best practice ? Check them in on the 'no-flex' branch. Keeping versions of files is exactly what git is for :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
pgp9cLTXhZZwx.pgp
Description: PGP signature
