Visualized Git practices for team: branch, merge, rebase
kentnguyen.com
Visualized Git practices for team: branch, merge, rebase
1–10 of 39 posts
Re: Visualized Git practices for team: branch, merge, rebase
#2Its opposite for us. At work, we dont use branch, only git pull --rebase on master. Any idea on when and why to use branches often ?
Re: Visualized Git practices for team: branch, merge, rebase
#3Its opposite for us. At work, we dont use branch, only git pull --rebase on master. Any idea on when and why to use branches often ?
Branching can often be a good strategy if you have a large team and you don't want large uncompleted chunks of work to block quick fixes & deploys, etc. The situation you want to avoid is:
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.
Re: Visualized Git practices for team: branch, merge, rebase
#4Its opposite for us. At work, we dont use branch, only git pull --rebase on master. Any idea on when and why to use branches often ?
Branching can often be a good strategy if you have a large team and you don't want large uncompleted chunks of work to block quick fixes & deploys, etc. The situation you want to avoid is: 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…
We faced this situation before. What we do is:
- When there is a feature that is not done yet, but has some user-facing code, we use feature toggler to disable it on production
- we deploy quick fix by doing a cherry-pick
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.
Re: Visualized Git practices for team: branch, merge, rebase
#5Earlier quoted context omitted.
Branching can often be a good strategy if you have a large team and you don't want large uncompleted chunks of work to block quick fixes & deploys, etc. The situation you want to avoid is: 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…
We faced this situation before. What we do is: - When there is a feature that is not done yet, but has some user-facing code, we use feature toggler to disable it on production - we deploy quick fix by doing a cherry-pick 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 comple…
Yeah, personally I know a number of solid devs who like feature toggling but the notion has always rubbed me the wrong way. Especially because half the time I'm adding a non-trivial feature, I'm always semi-refactoring the code underneath to deal with the common patterns and concepts that emerge as a result of that addition. But I'm a big refactoring-as-you-go kind of person--I don't know how common this is.
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.
Re: Visualized Git practices for team: branch, merge, rebase
#6Its opposite for us. At work, we dont use branch, only git pull --rebase on master. Any idea on when and why to use branches often ?
We have been very happy with the git branching workflow described and justified here: http://nvie.com/posts/a-successful-git-branching-model/
Re: Visualized Git practices for team: branch, merge, rebase
#7Its opposite for us. At work, we dont use branch, only git pull --rebase on master. Any idea on when and why to use branches often ?
A local git branch is super-cheap, so there's hardly any downside to using them. The upside, even for a single developer, is the ability to work on multiple features/bugfixes simultaneously, and merge them into master only when they're ready.
Re: Visualized Git practices for team: branch, merge, rebase
#8The OP gives his own definition for rebase: git rebasing is taking all your local changes since the last push and put them ahead of other people’s changes regardless of the date you made the commit.
But fails to explain _why_ you'd want to do that. Can anyone fill in that why for me?
Re: Visualized Git practices for team: branch, merge, rebase
#9I agree with the author that learning and becoming handy with git cli is very important.
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?
Re: Visualized Git practices for team: branch, merge, rebase
#10The OP gives his own definition for rebase: git rebasing is taking all your local changes since the last push and put them ahead of other people’s changes regardless of the date you made the commit. But fails to explain _why_ you'd want to do that. Can anyone fill in that why for me?
master on your local repo is a different reference to master at origin and master at other developers machines. By merging your master into origin/master instead of rebasing, you leave the history looking like multiple branches were merged together.
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.