Git won’t let the second person push if their commit history doesn’t line up with the origin branch.
It should be trivial to do a git pull --rebase to move your new commit after the upstream version, but as far as I can tell, no one on my current project remembers this (or perhaps they’re using gui tools or something). Our log is full of “merge origin/main onto main”.
If you use vscode, try out the merge editor. It’s a lot clearer to me when the merge diffs are huge.
I would also say to check out the latest branch for each file you commit. If your file is file.tsx checkout file.tsx in the main branch to make sure you know what you’re changing.
I’m guessing you don’t mean commits that actually bring updates from a different branch in? I’m responsible for a bunch of commits that catch my feature branch up to main and a couple that bring my branches into main.
If we were working on the same project, what would you want to see for those? This is hosted on a private gh repo, but it’s a small shop and we were working on a tight deadline for an MVP release and were not using PRs for the stuff I was working on.
The boss (co-owner of the business) is the Sr dev on the project and until recently was the only sr dev in the whole shop. I actually don’t think he has experience with using git in a team context.
One of my other tasks is working on internal docs (which didn’t exist before I joined the team) that would include git best practices for branching strategies and commit messages, so I’m interested in what folks who have more experience than I do would like to see as I try to nudge the team practices.
Great question. I’m not the one you asked, but I can answer.
Yes, merge commits, though they get useful work done, cause challenges later. If you’re using GitHub you can actually disable the ‘merge commit’ pattern in the repository settings, under ‘branch protections’, and you’ll have a much nicer time moving code between branches in the future.
Since you’re working on patterns, if you’re using GitHub, here’s my best tip - it’s related but will also cause some other nice outcomes.
If you’re using GitHub, to get a much better branching experience, you can turn on branch protections on ‘main’ and specifically turn on ‘require linear history’. This will let GitHub know that you prioritize the quality of the history in ‘main’ over that of all other branches.
Related: If your team keeps a ‘develop’ branch, you’ll need to get rid of it at the same time as making this change. Using a ‘develop’ branch is not compatible with this setup. Code that used to merge to ‘develop’ should now merge to ‘main’ and git tags should be what indicates code is ready for production.
With these settings GitHub will nudge your team towards squashing and rebasing when merging, and operations to pull other people’s code into your branch will get dramatically easier. (Edit: You’ll start to see the keyword ‘fast-forward’ a lot more often, which is great.)
If you’re not using GitHub, you can still look for tools and setups to “require linear history” to get the same benefits.
I think the idea is both are adding new files and also making changes to various files but his commits to the non-new files caused the conflict. Also, if both new files affect the same deliverable (like a DLL) then that could create a conflict in some cases (though I think that all depends on the build system).
Two new files wouldn’t create a merge conflict though (unless they have the same name)?
Git won’t let the second person push if their commit history doesn’t line up with the origin branch.
It should be trivial to do a
git pull --rebaseto move your new commit after the upstream version, but as far as I can tell, no one on my current project remembers this (or perhaps they’re using gui tools or something). Our log is full of “merge origin/main onto main”.God I fucking hate merge commits.
If you use vscode, try out the merge editor. It’s a lot clearer to me when the merge diffs are huge.
I would also say to check out the latest branch for each file you commit. If your file is file.tsx checkout file.tsx in the main branch to make sure you know what you’re changing.
I’m guessing you don’t mean commits that actually bring updates from a different branch in? I’m responsible for a bunch of commits that catch my feature branch up to main and a couple that bring my branches into main.
If we were working on the same project, what would you want to see for those? This is hosted on a private gh repo, but it’s a small shop and we were working on a tight deadline for an MVP release and were not using PRs for the stuff I was working on.
The boss (co-owner of the business) is the Sr dev on the project and until recently was the only sr dev in the whole shop. I actually don’t think he has experience with using git in a team context.
One of my other tasks is working on internal docs (which didn’t exist before I joined the team) that would include git best practices for branching strategies and commit messages, so I’m interested in what folks who have more experience than I do would like to see as I try to nudge the team practices.
No, fast-forward merges only
Great question. I’m not the one you asked, but I can answer.
Yes, merge commits, though they get useful work done, cause challenges later. If you’re using GitHub you can actually disable the ‘merge commit’ pattern in the repository settings, under ‘branch protections’, and you’ll have a much nicer time moving code between branches in the future.
Since you’re working on patterns, if you’re using GitHub, here’s my best tip - it’s related but will also cause some other nice outcomes.
If you’re using GitHub, to get a much better branching experience, you can turn on branch protections on ‘main’ and specifically turn on ‘require linear history’. This will let GitHub know that you prioritize the quality of the history in ‘main’ over that of all other branches.
Related: If your team keeps a ‘develop’ branch, you’ll need to get rid of it at the same time as making this change. Using a ‘develop’ branch is not compatible with this setup. Code that used to merge to ‘develop’ should now merge to ‘main’ and git tags should be what indicates code is ready for production.
With these settings GitHub will nudge your team towards squashing and rebasing when merging, and operations to pull other people’s code into your branch will get dramatically easier. (Edit: You’ll start to see the keyword ‘fast-forward’ a lot more often, which is great.)
If you’re not using GitHub, you can still look for tools and setups to “require linear history” to get the same benefits.
You’d be squashing those when you merge back down into main anyway, no?
While we’re at it, I like to use
--autostashin addition.i have autostash set up as part of global config
Uuh, thanks for that hint! I’ve been using git over CLI for over 10 years now and never came across that flag.
I think the idea is both are adding new files and also making changes to various files but his commits to the non-new files caused the conflict. Also, if both new files affect the same deliverable (like a DLL) then that could create a conflict in some cases (though I think that all depends on the build system).
Sometimes git just hates you