4 ms·
The typical effective way to work with Git is to develop on master while running "git pull --rebase" regularly, and before you commit. Prefer to build up a feat
by Pyxl101 11y ago
The typical effective way to work with Git is to develop on master while running "git pull --rebase" regularly, and before you commit. Prefer to build up a feature as one commit, with "git commit --amend" or "git commit --fixup". Since you pull and rebase regularly, your code is closely in sync with all shipped changes, and if there are any conflicts you get to resolve them in small incremental pieces. When your change passes CR, push it.
The result is a simple, clear, linear commit history with a minimum of effort spent on branching and merging fuss. The fuss is rarely worth it. This model works for quite large teams. After a certain size, it might be better to split the package into several rather than add branching/merging complexity.
- icebraining 11y agoDoesn't that prevent you from using commits while developing the feature?
- finishingmove 11y agoYou can make as many commits as you need on your feature branch. When you're done with the feature, you do `git pull --rebase origin master` (or whatever the main branch is) and squash your commits into one (or a few -- when it makes sense) using `git rebase -i`.
- icebraining 11y agoI know the workflow of rebasing a feature branch into one commit on master, but that doesn't sound like what Pyxl101 was talking about, regarding the use of "git commit --amend" and "git commit --fixup".
- Bahamut 11y agoBetter to squash before the rebase so you resolve conflicts once rather than x times...and hope there are no nasty merge commits to ruin the history.