 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
There is something I don't understand about Git branches.
I have some projects that have been on my hard disk for years, but have
just recently converted to Git repositories. I want to start a branch
on one of them. My understanding is that Git tracks changes in both the
main/master branch and the new branch. But I only have one working copy
of the actual files in my directory. Which branch do these files
represent, and where are the files of the other branch? How does this
all work?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 23 Oct 2021 19:17:07 -0400, Cousin Ricky wrote:
> There is something I don't understand about Git branches.
>
> I have some projects that have been on my hard disk for years, but have
> just recently converted to Git repositories. I want to start a branch
> on one of them. My understanding is that Git tracks changes in both the
> main/master branch and the new branch. But I only have one working copy
> of the actual files in my directory. Which branch do these files
> represent, and where are the files of the other branch? How does this
> all work?
The only change tracking is on the active branch. If you're working
outside of master, no changes you make are recorded in master unless you
either do a cherry pick or a merge - in either case, at the point of the
merge or cherry pick, the changes you've made (or selected, in the case
of a cherry pick) are brought into the target branch (can be master, can
be some other branch).
In git, you're only ever working in a single branch, ever.
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-10-13 7:22 PM (-4), Jim Henderson wrote:
> On Sat, 23 Oct 2021 19:17:07 -0400, Cousin Ricky wrote:
>
>> There is something I don't understand about Git branches.
>>
>> I have some projects that have been on my hard disk for years, but have
>> just recently converted to Git repositories. I want to start a branch
>> on one of them. My understanding is that Git tracks changes in both the
>> main/master branch and the new branch. But I only have one working copy
>> of the actual files in my directory. Which branch do these files
>> represent, and where are the files of the other branch? How does this
>> all work?
>
> The only change tracking is on the active branch. If you're working
> outside of master, no changes you make are recorded in master unless you
> either do a cherry pick or a merge - in either case, at the point of the
> merge or cherry pick, the changes you've made (or selected, in the case
> of a cherry pick) are brought into the target branch (can be master, can
> be some other branch).
>
> In git, you're only ever working in a single branch, ever.
But which branch are my files attached to? If I switch branches, where
are the files in the new branch that I want to edit?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoo com> wrote:
> There is something I don't understand about Git branches.
>
> I have some projects that have been on my hard disk for years, but have
> just recently converted to Git repositories. I want to start a branch
> on one of them. My understanding is that Git tracks changes in both the
> main/master branch and the new branch. But I only have one working copy
> of the actual files in my directory. Which branch do these files
> represent, and where are the files of the other branch? How does this
> all work?
The files you're seeing in the directory of the repository are the files of the
currently selected branch. 'git status' will tell you on which branch you
currently are if you forgot. To select a branch, you can use 'git checkout
name_your_branch'. After selecting another branch, if you look again in the
directory it will contain the files of that selected branch. Behind the scene
git moves files from/to hidden folders, so everything is there but you only see
the files of one branch at a time.
Pascal
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 23 Oct 2021 23:11:32 -0400, Cousin Ricky wrote:
> On 2021-10-13 7:22 PM (-4), Jim Henderson wrote:
>> On Sat, 23 Oct 2021 19:17:07 -0400, Cousin Ricky wrote:
>>
>>> There is something I don't understand about Git branches.
>>>
>>> I have some projects that have been on my hard disk for years, but
>>> have just recently converted to Git repositories. I want to start a
>>> branch on one of them. My understanding is that Git tracks changes in
>>> both the main/master branch and the new branch. But I only have one
>>> working copy of the actual files in my directory. Which branch do
>>> these files represent, and where are the files of the other branch?
>>> How does this all work?
>>
>> The only change tracking is on the active branch. If you're working
>> outside of master, no changes you make are recorded in master unless
>> you either do a cherry pick or a merge - in either case, at the point
>> of the merge or cherry pick, the changes you've made (or selected, in
>> the case of a cherry pick) are brought into the target branch (can be
>> master, can be some other branch).
>>
>> In git, you're only ever working in a single branch, ever.
>
> But which branch are my files attached to? If I switch branches, where
> are the files in the new branch that I want to edit?
The branch that's active is where your files are, assuming you did a 'git
add' (or equivalent). With git, you have to tell it that you've added
new files so it will track them.
If you switch branches, the files are in the branch where you added them
- and only in that branch.
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-10-24 5:14 AM (-4), BayashiPascal wrote:
>
> The files you're seeing in the directory of the repository are the files of the
> currently selected branch. 'git status' will tell you on which branch you
> currently are if you forgot. To select a branch, you can use 'git checkout
> name_your_branch'. After selecting another branch, if you look again in the
> directory it will contain the files of that selected branch. Behind the scene
> git moves files from/to hidden folders, so everything is there but you only see
> the files of one branch at a time.
Thanks, that's really clever!
I haven't been ignoring you. I've just been spending the past week
trying to deal with it. I set up a sandbox repo to try to see what was
going on, couldn't get the branching to work, set up a 2nd sandbox repo,
re-watched that hour long tutorial video, paused it every few seconds to
take detailed notes, rewound the video frequently, returned to the 1st
sandbox video, and went back and forth between Git-Cola, the command
line, and my notes.
Eventually, I figured out--or so I think--that I skipped a step in the
sandbox, and that's why I couldn't get it to work. (Like I said in the
last thread, my head can't seem to retain Git commands and procedures
past an hour or so.) I applied that step, and things then looked as you
described. I presume that this shit will become intuitive at some
point; how long did it take you all?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 31 Oct 2021 19:29:01 -0400, Cousin Ricky wrote:
> Eventually, I figured out--or so I think--that I skipped a step in the
> sandbox, and that's why I couldn't get it to work. (Like I said in the
> last thread, my head can't seem to retain Git commands and procedures
> past an hour or so.) I applied that step, and things then looked as you
> described. I presume that this shit will become intuitive at some
> point; how long did it take you all?
I had worked with Subversion and Perforce previously, so the only thing
that was really different for me using git was the lack of file locking
(which is by design).
I still learn things off and on when I go back to using it - not quite as
frequently as I used to. And when I was learning it, I had a really
awesome development team that I was working with who helped me when I got
into trouble. The good news is that with git, as long as something's
been committed, you can usually recover it even in the most dire of
circumstances (as long as it's in a local and at least one remote repo).
The bad news is that sometimes it can be *really* ugly figuring out how
to fix things if multiple people are committing to the same repo and are
not communicating effectively.
The single most important thing is to ensure that all files you're
working on in the repo are tracked by git. If they're not, when you
switch branches, they'll still be there, and that can get really
confusing, really fast. (Unless it's something that you *meant* to not
track, like a config file, for example).
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> wrote:
Glad you've found how to make it works.
> how long did it take you all?
I can't tell. I've been using version control systems before Git since around
2000. So the concepts already looked natural to me when I started using Git. I
guess it depends on how often you're using it. If it's every day like I do it
shouldn't take long. And even less if you're working on small projects where
only very few commands are enough.
I recommend you to try online interactive tutorials like the one below to get
use to the basics:
https://learngitbranching.js.org/
Have fun !
Pascal
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
