I'm having a problem in GitLab. My repository commit graph is not showing the main branch. The repo have two branches, main and develop, and its only showing the develop branch. I know that I messed up the branch somehow when I push to 'develop'. But the history said that I merged 'develop' to 'develop'. I don't know where I messed up. Here's the commit graph:

Would someone tell me where and why I messed up?

CodePudding user response：

All is fine. Your main branch is displayed, it points at commit: "fix ajax for register and add validation"

It turns out that, in your current situation, develop and main haven't forked, and develop is ahead of main (all of that is very normal).

So gitlab chose to draw only one single history, with the latest commit of develop on top and main pointing somewhere below -- all git graphical tools I know will do that.

CodePudding user response：

As asked, this question is strictly about GitLab, i.e., about how GitLab goes about showing you the commit graph. That means it should just be tagged with gitlab. But there's a more general form of the same question, which is: what the heck is a branch anyway?

To see more about this question, read What exactly do we mean by "branch"? The graph you've shown here (I edited the question slightly to get it included inline although it's so small that one must generally click through to read it anyway) has two labels attached, namely develope (including that final e) and main. Those are your two branch names. So you do have two branches.

If you've read the question I linked, you may now realize that you have even more branches. For instance, the initial commit, all the way at the bottom, is by itself a branch, containing one commit. The bottom two commits, treated as a pair, is also a branch. Neither of these branches have names, but they are sub-graphs of the overall commit graph. Any connected set of any of these commits can be treated as a "branch".

The merge commit four steps down from the top shows where you merged a commit into another commit, forming one branch from two branches. These two separate branches can now be treated as a single branch by using the merge commit as the last commit of that branch. Or, the two parents of that merge commit can be treated as two separate branches, which share the commits from the point where the graphs diverge.

These earlier separate branches had names develope and develope, in two different Git repositories. Although the names were spelled identically, these two separate branches were different branches. The merge commit that united them made a new branch, which was named develope.

The branch names for each of these branches are quite irrelevant! They only matter in terms of finding the tip commit, from which Git finds the earlier commits. By identifying any one particular commit as a tip commit, you instantly form a branch—whether it has a name or not—from there on backwards.

This—the fact that "branch", in Git, isn't really a meaningful term—is why you need to think about a Git repository in terms of commits, rather than branches.