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

> 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

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 :)


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.

Attachment: pgp9cLTXhZZwx.pgp
Description: PGP signature

Reply via email to