On Sat, 30 May 2015 10:53:47 -0700 (PDT)
Tim Dawson <trhdaw...@gmail.com> 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
> 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,
No, you won't lose these files. Since you've committed them, they will
be available via that 'no-flex' branch no matter what you check out or
Note that, as most (all?) SCMs, Git is generally an append-only
solution -- at least history-wise. Sure, you're able to delete
branches, and rewrite them, but most of the time you just add stuff to
> so I think I need to checkout (i.e. go back to) master and merge
> 'no-flex'. Is that correct ?
No, not quite. See below.
> 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).
That's a very keen observation indeed, congrats with this!
Merging means -- both logically and physically -- "bring the changes
made on the branch I'm merging into the branch which is currently
checked out", so yes, in this case merging is not what you need.
> 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.
Yes, this is understandable. As to what finally do with your 'no-flex'
branch and its relation to 'master' branch, see below.
> 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 ?
Nothing at all. The only ways to lose these files are:
* Delete all the "references" (tags and branches) which, directly or
indirectly has the commits containing these files in their history.
* Rewrite histories of such references (via `git rebase`,
`git filter-branch` etc).
And even after you've tried hard to send your committed files into
oblivion, they will still be recoverable via the "reflog" mechanism:
Git by default logs all "drastic" movements of tip commits of their
branches, and this log is kept for a hefty amount of days before
entries in it get expired and deleted. (Drastic movements are those
which are not due to normal committing.)
> 2. Will that file still be visible in the directory tree of my text
> editor ? (I think not)
That is correct. The whole point of a branch is to provide you with
a line of development separate from all the other lines of development.
So when you check out another branch, Git makes sure your work tree
looks like the state of your project recorded in the tip commit of this
branch. (Well, untracked files which do not conflict with the files
about to be checked out will be left intact.)
> 3. What does Git do if I delete a previously committed file from my
> directory tree ?
Nothing beyond noticing the file appears to be missing compared to the
tip commit of the currently checked out branch (the HEAD).
You will have an option to "confirm" your deletion -- by staging it for
the inclusion in the next commit or to undo it.
Git suggests you both of these actions when you run `git status` -- as
Magnus already explained.
> 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 ?
Well, first, there's no point to mess with the 'no-flex' branch at all.
What would unstaging its files get to you? Return the state of the
files recorded at its tip to that it had right before you forked it off
'master'. But what's the point, really? You don't supposedly intend
to work on it, as it was a one-off gig, right? Hence you basically
have several sensible choices:
* Just delete this branch (possibly after implementing the similar
changes on 'master' -- see below for more).
The command to do this is `git branch -d` (or -D).
* Rename it to something meaning it's obsolete, like
'attic/no-flex' or 'closed/no-flex'.
The command to do this is `git branch -m`.
* Replace it with a tag. Tags don't move, and can be annotated (have a
message attached to them). This is my favorite method for dealing
with branched I don't need anymore but which histories might be of
interest -- either techical or archaeological, or both ;-)
Basically, you do `git tag -a no-flex <that_branch_name>`,
explain in the annotation message why that branch existed and why
it's now closed, then do `git branch -d <that_branch_name>.
As to the relation of 'no-flex' to 'master'...
It's useful to remember that once you've committed your changes, no
matter on which branch did that happen, you're able to get your changes
back without even actually checking that branch out again.
Plain Git has the `git show` command which can be used to get the
contents of a file in any revision.
Say, you'd like to inspect the contents of assets/css/foo.css at the
'no-flex' branch while being on 'master'? -- just do
git show no-flex:assets/css/foo.css
and have those contents printed. Redirect the output to a file -- and
you get the contents saved. You can even make that file appear in your
work tree merely by doing
git checkout no-flex assets/css/foo.css
You can also use any GUI tool to get onto that contents. Say, do
while on 'master' and see the changes/files made on 'no-flex'.
That leads us to a final solution: if the purpose of your 'no-flex'
branch was simply to try out ideas, it's not for merging back into
'master' and so you shouldn't do that. Instead, just use the
techniques just described to refer to what you've done there while
hacking away on 'master', and once finished, get rid of 'no-flex' by
either deleting or archiving it. (For a start, you can surely just let
that branch hang around indefinitely -- until you fill you know what's
your way to dealing with such "expired" branches.)
Just to contrast, if the intent of your branch would really be to apply
certain fixes / implement certain ideas which would be made to the real
content as present on 'master' (I mean, you would modifying those files
existing on 'master'), the end result would really be suitable for
merging back to 'master'.
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
For more options, visit https://groups.google.com/d/optout.