git Questions

I'm reading the excellently written book REAL WORLD JAVA.   I'm on the "Collaboration with Git" Chapter.  Page 57.  It's talking about rebasing.  It's referring to a branch named refactoring3.  Did I miss a step?  I never created this branch.  Maybe I was supposed to make this branch with a
git branch refactoring3
I'm not completely following git so I must have missed a detail along the way.

Also I'm mixing using the cmd window and intelliJ for the exercises.   I create branches and switch between them.  What I don't understand is that I'm not telling the IDE that I'm working in a different branch.  Maybe that is the point of how git functions.   Maybe intelij always keeps me working on the current branch.  

Thank you Victor and Jeanne for the book.  Thank you to code ranch users.

Kevin

kevin Abel wrote:It's referring to a branch named refactoring3.  Did I miss a step?

Sorry, I can't help you with this, as I don't have the book you're referring to.

Also I'm mixing using the cmd window and intelliJ for the exercises.   I create branches and switch between them.  What I don't understand is that I'm not telling the IDE that I'm working in a different branch.  Maybe that is the point of how git functions.   Maybe intelij always keeps me working on the current branch.

I don't think IntelliJ does anything special to interact with Git. When you switch a branch using the command line window, Git replaces the contents of your working directory. Your IDE sees the changes to the directory, and updates its user interface accordingly. There's no real way to have your CLI work on one branch, and your IDE on another branch, unless you clone your repository twice and have each tool work in a different directory. That's not recommended though, as its easy to confuse yourself, and then do work on a branch you didn't intend to work on. It's a good thing that your CLI and IDE have the same view of the repository.

Yes, your IDE is aware when you switch branches, regardless of how you do it.

Thank you Stephan and Tim.   Now I understand that the IDE is editing the file that is in the place which it is looking. Now I'm curious to see if there is an error in the code I'm looking at, will the IDE immediately catch it.  

I think the book example is correct.  I am missing tiny details and getting off track.  

What I'll do next is make my own project and follow along with the git commands.  If I get mixed up I can show you all what's going on. I can even give give the URL to my code.

I wish some of the code ranchers I chat with would buy the book or get it at the library so we are talking about the same pages.

Thank you,

Kevin

Note that git has little to do with this.

Your IDE is sensitive to ANY changes to the files in its project. It doesn't have to be git-related. You could add a new file to the project with Notepad and the IDE will reflect the addition. For changed files, if the file is open for editing, the IDE compiler will rescan the file.

This wasn't always completely true with Eclipse, which sometimes had to be nudged back in old times, but modern systems hardware is powerful enough that continuous file monitoring for a project in an IDE is no big problem.

Tim,

I wonder how many others brand new to changing the project from other places than the IDE edit page would realize how this is working.  

I didn't realize that the IDE waws pointing to the same folder and files.  The files are changing and the IDE recognizes the change and reacts to it.

Now I can go to a coffee shop and see how this works.  

I'll:
create a new project with a file.
Make a new project in Github
go to CMD and do the git init
git add
git commit
git push
git status
make changes to the file  and keep doing this add, commit, push  while looking around to understand what I'm doing.
I might be ready at that point to make a branch, make changes.  
Merge my changes.
(I don't know what happens when I make changes to the main and the other branch and merge. )
I don't find git to be obvious at all.   I need to understand a little bit at a time.  

Thank you,

Kevin

OK, let me back off git for a second.

I don't have IntelliJ up and running in front of me, but after years of working with Eclipse I can tell you how it organizes projects.

The Eclipse IDE is centered around a Workspace. A Workspace contains Projects. You can have more than one Workspace, although only one can be active at a time for a given instance of Eclipse. For historical reasons I actually have 3.

When I say a Workspace "contains" projects in Eclipse that doesn't mean necessarily that the Project directory itself is a child of the Workspace directory. The Workspace directory contains metadata that describes projects, but the project directories can be located anywhere in the filesystem. By default, however, when you create a Project, its code directory will be located in the workspace directory, but you can select an alternative location in the "create project" dialog. Likewise, Eclipse can import a project from an external directory, but when you do, that doesn't mean it copies or moves code from the external directory into an Eclipse directory, it simply notes the project's directory location as part of the Eclipse project metadata.

Back to git. Git manages resources using metadata in the ".git" directory at the root of a git project. It neither knows nor cares what other apps (such as an IDE) are doing with that project. It's like how you can describe a schema in Java that maps both as JPA Entities (database tables) and XML or JSON objects and neither mechanism cares about the other.

The purpose of git is to track changes to a project. It notes when a file has been added, updated or deleted and can report those activities via the "git status" command. Git is not running as a process, it's simply a set of commands to work with a project in the context of the project's git database (the .git directory). You can do whatever you like with the project, but git only really gets involved when you want to make a snapshot of your changes using the "git commit" command. When you do that, you collect the changes, attache a comment to them, and git assigns a hash ID so that if you need to see what the project looked like for a given commit, you can use that hashcode to identify which commit you want to be referenced.

A notable thing about git is that it's intended for isolated development. Earlier source code archiving systems such as VCS and Subversion were bound to a central server. To change a project, you had to check out code, modify it, and commit back to the server. When you checked out code, that locked it out from changes by anyone else until you either checked it back in, released it (equivalent to database commit/rollback) or the source code administrator forcibly unlocked it. That really didn't work that well for projects with lots of different people all over the world working asynchronous to each other.

So instead, git makes each git project be its own source code repository. Which you can then bind to one or more remote repositories such as github. Since changes are identified by a hashcode, there are no version numbers to conflict, and as with GUIDs, the codes are unique enough that different people aren't going to end up with the same hashcode for different changes.

The remote repos are ignorant of what the local developer is doing until the local developer pushes (git push) their local commit(s) to the remote repo. Likewise, the local developer doesn't know what others have done to the remote repo without doing a "git pull" to bring their changes down. In the event that there are conflicting changes, git supports merging in order to reconcile those changes.

I'll leave the fancier git options such as branches, stashing, rebasing and so forth for another time. Git is very sophisticated and there are things in it I've never explored myself and in many case hope to not have to!

kevin Abel wrote:Tim,

I wonder how many others brand new to changing the project from other places than the IDE edit page would realize how this is working.  

I didn't realize that the IDE waws pointing to the same folder and files.  The files are changing and the IDE recognizes the change and reacts to it.

Now I can go to a coffee shop and see how this works.  

I'll:
create a new project with a file.
Make a new project in Github
go to CMD and do the git init
git add
git commit
git push
git status
make changes to the file  and keep doing this add, commit, push  while looking around to understand what I'm doing.
I might be ready at that point to make a branch, make changes.  
Merge my changes.
(I don't know what happens when I make changes to the main and the other branch and merge. )
I don't find git to be obvious at all.   I need to understand a little bit at a time.  

Thank you,

Kevin

I don't thing that IntelliJ makes branches in git magically. The IDE is aware of an git repository as local clone whether this has a remote repository on  Github or some other remote Git server.

Roland Mueller wrote:I don't thing that IntelliJ makes branches in git magically. The IDE is aware of an git repository as local clone whether this has a remote repository on  Github or some other remote Git server.

No magic, no. You can, however use IntelliJ to make a new branch or switch to an existing branch.

The local git archive contains all of the branches, so when a "git checkout" is use to switch to a branch, git pulls any differences from that branch and makes the workspace completely reflect the git context of that branch. I forget what it does with uncommitted changes, but that's handled as well.

That applies whether the branch was selected via git command directly or via the IDE. The IDE will update itself to reflect those changes, It's not magic, but it is automatic.

Tim,

I completely read your post and it made things way more clear to me.  Every time I read another description and then try the commands it makes more sense.  I had a client last year that spoke in circles about git.  I kept writing down when to use each one and I finally got canned because I didn't catch on.  I had to step away from git for a while.  Then I read Jeanne
and  Victor's book and I went from about 35% to 80% of understanding how to use it.

The git command names didn't always make sense to me.   If they did make sense I kept forgetting them.  I bought a coffee mug with the commands many years ago and look through them and recall what each one does.   Now that I know the important commands, I cannot think of a way to make them more intuitive.  

While reading about how .git has it's own working files on each device, it reminded me of the little bit that I know about bitcoin.  I think everyone can get a copy of many or all existing bit coin identifiers.  

Thank you,

Kevin

Roland,

That is how it seems to work for me also.

Thank you,

Kevin

I'll let you in on a dirty little secret.

I started with RCS (local-only), moved up to VCS (server-based), then from there to Subversion (better server-based), did a side stint on a Mercurial project, then landed on git because everybody was doing git.

Server, non-server, or server-optional, all of them tended to have certain common functions. Download, lock, branch, commit/rollback, status info.

So when I picked up git, it was mostly just re-mapping the same concepts. I didn't have to check code in or out anymore. I could do strictly local for stuff I didn't need backed up on a server, and git didn't number versions like most other systems did, but there was still a way to pull a project from a remote repository (git clone), commit changes, make branches, and so forth. Git was nice because I could not only switch branches without creating a new project directory (which was a constraint when disks were smaller).

But at heart, there are really only about 5 essential git commands: clone, commit, status, push, pull, and log. There are lots more commands in the kit, but a lot of them are for really gnarly things that I don't generally worry about.

Now the one thing in git I don't find simple is how to revert changes. I start working on a file(s), realize it's just one big screwup and want to get rid of the uncommitted local changes. It's not simply "git revert", because that deals with changes already committed and a clean project. So I have to look up how to do that every time (it's via git reset, incidentally). In Eclipse, it's easier just to let the Eclipse local history tracker undo the changes without git getting involved.

Tim,

I went through some of those version control software packages also.   SVN with the tortoise showing up in File Explorer didn't work on my PC.  I had the IT people try to fix my PC and it never could work.  I couldn't check out work and eventually I got let go on the project.  It was OK because I wanted to only work in FL during the winter months and it was ready to go back home to NYC.  This was 20+ years ago.

The only other git command I use a lot is :
git add

I think that I want to get git working just so I know that I accomplished it in my life time.

Thank you,

Kevin

Sorry to hear about your tortoise/svn problems. It always worked fine for me. Works on git, too.

Yeah, I knew I'd forget at least one important git command. Actually, "git init" is also an essential command now that I think of it. The "git remove" command has never seemed truly necessary, since git will detect deleted files automatically, but maybe I'm simply missing something subtle there.