11–20 of 39 posts
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.
The 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?
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.
The 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 pulli…
I 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.…
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.
Its 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.
Earlier quoted context omitted.
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. Branchin…
I 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.…
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.
The 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?
> 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.
Earlier 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…
Do you feel like you gain anything significant from your method (apart from the simpler git interaction from having just one developer branch)?
People need to understand how simple Git is.