8 ms·
If I follow your workflow, my coworkers go ballistic. The problem is that the "git pull" messes up the revision history. I finally learned to use "git pull --
by hardtke 15y ago
If I follow your workflow, my coworkers go ballistic. The problem is that the "git pull" messes up the revision history. I finally learned to use "git pull --rebase".
- rictic 15y agoTechnically speaking it doesn't "mess up" the revision history, it preserves it. Rebasing instead of merging creates a linear revision history, which is simpler and more similar to centralized version control, but at the cost of losing information about the actual path of development.
- ajross 15y agoAll true. Certainly nothing is "messed up". That said, reading through a bunch of fine-grained and uninformative merge commits when looking at a log is really annoying. Serious projects expect submissions to be in the form of clean patch sets that apply in series and "look like" an instantaneous change. No one cares about per-developer histories. If you look at the kernel history, for example, the only merge commits you see are Linus's and the subsystem maintainers'.
- mainguy 15y agoRight, because the kernel patches are emailed and never pushed to a public location. In essence, the "committers" of the kernel are the only ones who do rebases (either explicitly or implicitly). Frankly, git was not designed for a lot of the use cases it's finding itself in. Medium sized agile teams (5-10 devs) with multiple people mucking around in the same files will be removing bullets from their feet repeatedly for a few weeks when first switching.... OR they will have an incomprensible tangle of branches and merge commits that no person will ever be able to figure out.
- ajross 15y agoThat may be overstating things. The incomprehensible tangle is really just an annoyance. Look at it with "git log --no-merges" and it looks exactly like the tangle you'd get with CVS or subversion: lots of independent unsequenced changes by different developers. Git by default shows this stuff, which in the kernel's use case is useful data. But in this case it's just useless chaff, and an annoyance. But hardly a serious problem.
- wcoenen 15y agoAs a SVN user who is not afraid to use feature branches, this "no branching" workflow of many git users amuses me to no end.
- invisiblefunnel 15y agoI have found that branches are the default for git users working on any project larger than a toy.
- latortuga 15y agoIt only "messes up revision history" if you do your development on your remote tracking branch that multiple people are pushing to. If you keep your remote tracking branch clean (e.g. master), you can pull into master whenever you want, merge your changes from a local branch, and push it right back out. Done this way, you never have to use pull --rebase (which will rewrite local history). This workflow actually works pretty well with your desired outcome as well - you can rebase your local branch against newly pulled changes on master. This will make all of your local branch merges look like fast forward merges on master (i.e. no merge commit, linear history).
- billybob 15y agoMy workflow is like this: - Create a feature branch off of development. - Commit lots of times until that's ready. - Switch back to development. Do "git merge --squash featurebranch" This introduces all the changes from the feature branch as uncommitted changes. View the diff to ensure it's exactly what I wanted, and commit them with a single, coherent commit message.