With git/github I really only pull and push. I don’t really use any of the other features. Same for the kids on my robotics team. The only thing I have taught them is pull and push. The kids do a pull at the beginning of practice and a push at the end. Yet sometimes I see this in the commit logs. Why are these merges happening? Even I have some merges and I know I didn’t do anything differently. Should I be concerned? We are doing all of our git/gihub work in VS code if that matters.
If your local branch and the branch on GitHub diverge, they need to be merged. If you pull using the console it will tell you that, apparently VScode does this automatically?
Anyways, nothing to be concerned about. If you’re annoyed by the merge commits, you can configure git to “rebase on pull”, google it, you’ll find instructions pretty quickly.
To expand on this a bit,
git pull
under the hood is basically a shortcut forgit fetch
(get the remote repository’s state) andgit merge origin/main main
(merge to remote changes to your local branch, which for you is always main).When you have no local changes, this process just “makes a line” in your commit history (see
git log --graph --decorate
), but when you have local changes and the remote has changed too, it has to put those together into a merge commit - think a diamond shape with the common ancestor at the bottom, the remote changes on one side, your changes on the other side, and the merge of the two at the top.Like the above comment says, normally this process is clarified at the command line - VSCode must be handling it automatically if there are no code conflicts.
Nothing wrong like others have mentioned. It sounds like this is for a robotics class so personally I wouldn’t spend time trying to get rid of them, it’s not a minor change to eliminate them
If you wanted to or want to look into it just to understand, you could do something like having each student work on separate branches that starts from main, then instead of pushing to the main branch they could create a pull request to merge their work back to main, and use a squash commit when closing that PR (this is the important part to get rid of the merge commits). In that way, there’s no divergence on main, main is like the trunk of your tree and everything else is accumulated / returned to main.
It is definitely a skill that would help the students if they end up in real world engineering roles using git, but personally I think that’s a lot of extra complexity for a non problem.
It is for a middle school robotics team (FIRST Lego League if you have ever heard of it). No, I don’t have some burning desire to get rid of the merges. I was mostly woried that we were doing something wrong. We definitely do not have any branches. We really just use github to have a safe place to store our code and so that all of the laptops can have all of the code from all of the teammates.
For sure I don’t want to add any complexity. I think that since from their end it looks like it is doing exactly what they think it does (i.e., I upload my code with a push, and I get everyone else’s code with a pull), there’s definitely no need to fix a non-problem.
Yeah, you’re good!