Help please... SourceTree Version control warning "commits maybe lost"

[ricko_uk]

Hi,

Please see attached screenshot with version control warning...
How can I safely checkout the latest commit while making sure none of those two (or other) commits are changed in any way?

I have been using Sourcetree (i.e. GitHub) version control only in local mode and used it only in "simple way", no branching or anything else. I only keep adding commits and if needed then go back to the latest one ONLY. I have never gone back to an older commit (i.e. not even 2 commits back). But did just now and when trying to get back to the latest a warning comes up... This is the sequence of events and what happened.

With reference to the first attached picture:
1) I went back to the commit previous to the latest as you can see on it being highlighted in bold (Description: "WORKING: But noticed the concurrent ON prints......")
2) I did not change anything (that I m aware of) while that commit is "active"
3) just now I tried clicking on the latest commit (Comment: "WORKING: Concurrent tested correctly") but when I double click on it it shows the error message in the screenshot which I don't understand the explanation of. And it seems might loose commits.

Thank you

[newbrain]

First, a hint: if you want to use git, invest some time going through the book.

In my experience, tools are helpful, but an understanding of the basic working of the tool is fundamental: for me it only 'clicked' when I stopped relying on tools (I still use the integration in VSC and its git graph extension for basic stuff), on answers on stack exchange (which helped me screw up a lot) and on dodgy tutorials.

You might also try Oh my git!, it's a gamified tutorial, but it uses real git, and does not hide its working.

With that out of the way, let's see the specific case:

Your "detached HEAD" is not a symptom of decapitation, but that the pointer to the checked out commit (that's what HEAD is: a pointer to a commit) is not currently associated with a branch.

Your (only?) branch Branch_test is pointing to a later commit.

Yes, branches are also pointers to commits, with the peculiarity of being tied to the "tip" of the commit chain (so they move when a new commit is introduced on that branch).

In this particular case, I don't see the problem (and frankly do not understand the warning, from you pictures):
When you checkout Branch_test, HEAD will be moved to point to the commit Branch_test points to.

However, the older commit is still available in the chain, and can be addressed with "HEAD^" (meaning 'the parent' of HEAD - there are a lot of fine points here, and other ways to address it, this will do for now).

As for going back and forth on the same branch: you should really learn to use branches to add new features, to test ideas etc.: they are cheap!

A small takeaway, with some simplifications:
git is just a way to handle acyclic directed graphs, where each node is a 'commit' == the status of your repository at a specific point in time.
Each node is represented by a unique hash, but to make it simpler (eh...) for humans, we have a number of useful pointers:
HEAD: a pointer to the current commit you are sitting into.
branches: pointers to the tip of a path on the graph, automatically moved when a new commit is added
tags: pointers to a commit, they do not move, so they are useful to friendly identify a specific commit (e.g.: "Rev1.2.3").

EtA: I don't see any connection to Github in Sourcetree, remember: Github is online service that provides git repositories and support for a way of working (the "pull requests" etc.), but they are not the same thing.

[ajb]

newbrain has solid advice, but in general if you have no unstaged changes and all commits end in a branch then you aren't actually going to lose anything, despite the warning.  Sourcetree and similar tools are nice when you get into running multiple branches because they make it very easy to see how the various branches relate to one another, but they (like git itself) really rely on you knowing what the various actions do to the state of the repo. 

It's a really, really good idea if you're going to us git to build solid habits regarding branches and remotes.  A remote is essentially a tracking copy of the repo, synchronized by pushing to and pulling from branches in the local and remote repos.  Sourcetree makes it very easy to add a github (or other) remote, and github is free, so may as well use it to back up what you're working on.  Later on you can take advantage of other benefits of remotes, including collaboration and CI if those things make sense--or maybe you just want to fork an existing project and work on it. 

Branches are a really useful way of isolating possibly-breaking changes from your main, stable build, which may seem excessive if you're the sole developer on a project, but is really valuable even there.  How many times have you started down the path of making a complicated change to an application, but realized partway through that you needed to change approaches, or go back and make a change to another area of the application before you can do the other change properly?  Or in the middle of developing a new feature you discover a critical bug that needs to be fixed ASAP?  Branches make it very easy to manage those situations--you can delete everything on a branch and rebranch if you need to start over, rather than having to go back and revert a bunch of commits.  Or you can set a feature development branch aside and create a new bugfix branch to deal with an urgent problem, then after merging the bugfix into the main branch you can merge the main branch into the feature development branch and (usually) pick up where you left off.  There are also just organizational benefits to branches, you can easily maintain stable/beta/alpha or release/test/dev variants of the project, and when you get into a team development environment branches become essential to allowing multiple people to collaborate on the same codebase.  They will also really help reinforce the git workflow, so better to start sooner than later with them.

[mac.6]

In this case the message is harmless, your commit is on a branch (as seen in history).
Detached HEAD happens when you checkout a commit by sha-1 instead of a branch/tag name, you can then add commits but since they are not tied to a branch name you loose the reference to the commits once you switch branch.
In this case your commits are not "lost" but it will be non trivial to retrieve the commits sha-1 (they are dangling):

http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html

[ricko_uk]

Thank you all, much appreciated!!

[bson]

As mentioned, having a detached HEAD just means you checked out something in the commit history that's not at the head of a branch so you can't add to it.  But you can easily make it the head of a branch by creating one from that point, for example "git checkout -b backout_changes" .  You can then add commits to that branch, and later merge it to master to undo.  This is called rolling forward and is non-destructive in the sense that it always adds commits to undo changes, never rolls back the history.  So you can always go back to the pre-rollback again if you want, and then maybe branch that off and go do more work to fix whatever the problem was, and make another future attempt to merge it into master and ship.  All of this will then be in the history.

[ricko_uk]

Thank you bson!