Visualized Git practices for team: branch, merge, rebase(kentnguyen.com) |
Visualized Git practices for team: branch, merge, rebase(kentnguyen.com) |
I don't agree that you should stop using a GUI for git, especially if you've already cut your teeth on the command line. Tower, a git GUI for Mac OS X, has a great interface and ties in very well with the core git functionality. I've learned a lot about stashing, merge conflict resolution, and cherry-picking, thanks to that app. Also, Tower shows a tree graph, similar to the network diagram the author "seriously cannot live without."
Why knock visual tools when when you rely on them so much?
I am a very visual person. It gives me greater confidence in what I'm doing when I can see a polished visual overview, it makes me more willing to use powerful features like picking individual lines to commit, to avoid any single commit containing a mixture of use cases.
But I always make sure I know what the GUI is doing on the command line before trusting it to be doing the right thing. I made sure I understood rebasing correctly before setting it to be the default pull behaviour in Tower. Similarly, I never feel comfortable using a one-line deployment script before running through a deployment by hand first.
Any tool that makes our lives easier and less likely to make silly screwups is a good thing in my eyes. It doesn't matter whether that tool is a GUI or a script. I prefer using a GUI for databases too, because the command line is woefully inadequate at letting me grasp the shape of data quickly.
I think more than what tools you use (gui or command line) it's really useful to get an understanding of gits internal model. It informs day-to-day use and is a great example of an elegant, well-designed system.
Really? Awesome. How?
Particularly when the blog post before this is discussing how .m and .h files totally confused you. God help him if he gets asked a linked list question in an interview.
But fails to explain _why_ you'd want to do that. Can anyone fill in that why for me?
Personally, I use merge (with --no-ff) vs. rebase. The only time I actually use rebase is to squash a series of (unpushed!) commits on a feature branch, and I usually only do that if I went hog-wild, committing more than necessary while experimenting.
By rebasing onto origin/master instead of merging, you leave the history looking linear.
Ultimately it's about aesthetics, you don't gain anything by rebasing (when pulling) other than a cleaner history.
> git rebase master
What this does is that it temporarily reverts all my changes on this branch, applies all the changes from master on my branch and then reapplies my changes on this branch.
http://gitguru.com/2009/02/03/rebase-v-merge-in-git/
I really should go back and start making new blog posts... I'd dropped the ball because I ended up on a few enterprise SCM (software configuration management) gigs shortly after.
People need to understand how simple Git is.
I avoid `git commit --amend` because of that, and thought that `rebase` had the same problem. So for that reason, I always use `merge`. Am I mistaken?
If there are updated refs on a shared branch, you need to use the --force flag when pushing, overwriting the previous refs. All the other people pulling will also need to use the --force flag to get their refs updated.
It could also lead to data loss on all the repositories that do this if something goes wrong. And it forces other team members to use the correct flag when pulling and otherwise dealing with cryptic error messages when they don't do this.
--amend is fine if you haven't pushed yet, otherwise it has the same problems as rebase for shared stuff.
The OP's attempt to visualize git concepts falls quite short. This same old branching graph does little to nothing to illustrate these concepts. I cannot tell you how many friends and colleagues threw up their hands when someone tries to graph it out these way.
See this discussion: http://git.661346.n2.nabble.com/Re-Regulator-updates-for-3-3... on the git developer mailing list for more details on why that merging strategy is not liked.
If you do code-review on the contributions/pull requests then I can see where the merge-often strategy causes issues. The auto-generated merge commits don't give you the context of the updates that are pulled in and will lead to having to spend time going back through the commit tree. It may not lead to the introduction of issues or regressions but you can't be sure.
However, if you're set up as a small team with good internal communication or a high level of trust, then merge-often can be a good thing in that you usually aren't left with big merge issues to deal with and you're more likely to have any conflicting updates fresh in your mind.
One practical reason is when doing bisects.
There are certainly two schools of thought on this, but "this is confusing to me so don't do it" shouldn't be considered a valid opinion.
1. Engineers A & B are working on a medium-sized story that's not really done yet, but is in master anyway 2. Somebody discovers a small but critical bug in production 3. Engineer C can write a bugfix very soon, but can't deploy it to production because the other story isn't done yet.
But if your team never ends up saying "I'd deploy that but master isn't clean right now due to different changes", you probably just don't need to branch that much. Maybe your team is smallish or maybe you're capable of always breaking up work into really small increments. It really depends on everybody's situation.
Github does something sort of like this internally: http://scottchacon.com/2011/08/31/github-flow.html
Branching is more overhead in some circumstances but I've also found they can make things much easier. But I also wish that more people were comparing strategies and trade-offs because this stuff gets subtle and there are really lots of ways to do it.
We discussed about branching a while ago to solve this problem more effectively but still not satisfied with the pros vs cons. For us, branching only makes sense if we switch to use branching completely, and thats quite a big change.
origin/master must be deployable.
If that means developing in a branch, fine. If that means accumulating several patches locally in master that you haven't pushed yet because you're not done, fine. Just make sure that origin/master can always be deployed to the servers.
Actually, come to think of it, both of those things are pretty much equivalent to using branches for anything non-trivial.
[alias]
l = log --graph --pretty='%Cred%h%Creset -%C(yellow)%d%Creset %s %Cblue[%an]%Creset %Cgreen(%cr)%Creset' --abbrev-commit --date=relative
To install:
sudo gem install omglog
[alias]
omg = !omglog
[alias]
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %C(bold white)%s%Creset %Cgreen(%cr) %C(blue)@%an%Creset' --abbrev-commit --date=relative
Sourced from multiple results on google and customizations over time.
One thing to keep in mind is that it might lead to a number of merge conflicts that may be difficult or tedious to resolve depending of how the branches have diverged. Merging may avoid these.
Branching is definitely a significant investment for a team. It's best done when you've got somebody in-house who can guide everybody through the etiquette and how to use git to best support it. And if you want to do it all the way then you want to support in multiple places in your development stack -- QA servers, staging servers, CI, etc.
But for large units of work that genuinely should stay out of master -- large user-flow rewrites, big code refactorings or database migrations -- I find it a great way to have significant experimentation off to the side and then bring it back into master when it's ready for prime-time.
Of course, whatever you call what you deploy to production -- master, production, timestamp tagging, etc -- it should ideally pass CI before getting deployed as well. And there are merge conflicts to deal with, too -- that ideally belongs to whoever's doing branching.
So, maybe my ideal workflow looks like this:
* Branch away from master
* As you work in your branch, grab a CI server if you feel like it (telling
everyone else)
* Commit code in your branch, keeping an eye on your CI as you go
* Periodically merge in from master, dealing with merge conflicts in your branch,
*not* in master
* When you feel like it's ready to go, get whatever review you feel like you
need -- code review, product manager review, etc
* If you feel 99% certain it's good, merge it into master and push that back to
origin
* Wait for master CI to pass
* Deploy to production
* Beer
Do you feel like you gain anything significant from your method (apart from the simpler git interaction from having just one developer branch)?