text:
Lots of people often code using feature branching on git to avoid the hassle of conflicts while doing pull and/or to avoid pushing incomplete features that would break the system for all the team.
I find these reasons to be baseless and some even harmful to the development cicle. Trying to develop in your little temporal bubble without being distracted by the rest of your team it's a bad idea, imagine the following:
A team of five people have to do a painting of a big landscape, so they split the canvas in five pieces and then each of them paints their part without even looking at what their partners are doing and in two weeks they put all the five pieces together to deliver the product. What do you expect will happen? of course the painting will be a mess with miss aligned items on it that will need to be redrawn at the last minute pulling an all nighter on the worst case. Sounds familiar?
How can we work on a single branch without breaking stuff and without continuous conflict?
First the conflict part: Communication is key, daily meetings are there for a reason and should be used to smooth cooperation between developers working at the same classes.
Now, the scariest part: How to commit half baked features without breaking stuff? or even more, how to commit a new feature that we aren't sure is working correctly? Well, one of the best things about everyone working at the same branch is that if something breaks it will be noticed quickly and fixed at an early stage and therefore less painful process.
For the part of committing without breaking the system for everyone there is a very good technique called "feature toggling". Basically what you do is put an if like this:
if (useNewLogic) {
} else {
This allows to run the new code when you want and where you want without risking all the environments and such.
This way of working also benefits of the fact that because everyone is working at the same place if your new feature conflicts with some change of class contract you can fix it quickly, it means that you are doing continuous integration.
One way I have found in my personal experience that people that comes used to work with branches feels more comfortable to do the switch is to have two branches, for example: develop and master. With the only way to put things on master is via a pull request.
I would love to read your opinions of this matter on the comments.
Posted on by:
Adrián Norte
I have been developing software and doing sysadmin work as a profesional since 2008 and I'm also a proud cat father.
I disagree with most of this article, but respect that it works for you.
Any project I've ever worked on where multiple people are commiting to the same generic "development" branch results in lots of merge conflicts unless people are super careful to always pull the latest changes and merge master often. It's also difficult for audit purposes in the future because many features will be added simultaneously on every PR merge.
If anyone decides to try this, I highly recommend that you keep a changelog and follow some sort of commit message guideline.
In my experience, proper use of Git Flow, CI/CD tools, PR status checks, and merge conflict resolution as needed should take care of most of the issues you have with feature branching.
Some useful Git tooling:
So my team practices continuous delivery / continuous deployment. The idea here is that we're always pushing to master and deploying to live, leaning on our tests to ensure integration. There are other ways, but it's all essentially 'trunk based development' and is definitely opposed to 'git workflows' á la Gitflow.
We're not large, and we're 'colocated' (management speak for 'sit together') so that might be a factor.
A caveat: I am definitely not an expert at any of this.
Any project I've ever worked on where multiple people are commiting to the same generic "development" branch results in lots of merge conflicts unless people are super careful to always pull the latest changes and merge master often.
You don't need to be 'super' careful. You just need to
pull -r from upstream on a very regular basis. I mean, every few minutes. The first point of integration of your code is your machine, the first tests of integration are on your machine. You hit a merge conflict sometimes - it inspires you to pull more often.
It's also difficult for audit purposes in the future because many features will be added simultaneously on every PR merge.
There are no PRs. There are no merges. There are only commits, to master, on your machine, and rebased pulls.
Everything you push will go live on a continuous delivery pipeline. So you cannot be lazy - you must write automated tests to document the features you are implementing.
The key driver here is continuous delivery - no 'releases', no 'big bang deployments'. Just the regular (every 15 minutes usually) integration and deployment of code to live.
I do agree the original author is saying some odd stuff, like:
Now, the scariest part: How to commit half baked features without breaking stuff? or even more, how to commit a new feature that we aren't sure is working correctly?
Just don't deploy broken code. But, conversely, if your code isn't breaking the tests of your other features - then nothing is broken. Feel free to deploy.
A corollary to this: break down your 'features' into small, valuable, deliverable parts. Stop swallowing the elephant whole; use a knife and fork.
Feature flags are a good idea - but only to separate deployment from delivery (i.e. deploy code but prevent its 'delivery' to the user in live). But they should be extremely short lived and probably live in the interface layer. They should not be quite unusual.
Take a look at these just to make sure I'm not mad...
- Continuous Delivery the book!
- infoq.com/news/2018/04/trunk-based... a short piece!
- website about continuous delivery
and also
Why you should deploy on Friday afternoon
Chris James ・ May 28 '18 ・ 7 min read
Maybe I should write some of this stuff up in a post if there's interest?
Good ol gitflow with pull requests. "Gateflow," if you will. Personally I don't mind it at all and like PRs, however I've worked at orgs that got just as far with manual CRs on a trunk model. It usually boils down to how much you trust your devs, or the dual, are they skilled and reliable enough to not need the merge control hand holding.
I really cannot agree with this approach at all. It is dangerous to suggest this for new programmers looking for guidance. This defies the whole point of Git which is to decentralize development so that only working, tested code gets put on the main line. Adding logic switches creates complexity, untested pathways (even only 4 logic switches is 24 possible execution pathways), and requires cleanup work and refactoring once completed and agreed upon by the team.
If you want to work like this proposal suggests, just use SVN. However, reflect on the fact that there is no such thing as svnhub for a reason.
This defies the whole point of Git which is to decentralize development so that only working, tested code gets put on the main line. Adding logic switches creates complexity, untested pathways (even only 4 logic switches is 24 possible execution pathways), and requires cleanup work and refactoring once completed and agreed upon by the team.
If you have a good CI system (it's 2018 we all should have one) nothing untested nor unclean code enters the repo.
I am not going to try to convince you against your thesis. However, I believe you have missed the point of Git (and other decentralized version control tools). Branches are not meant to be lived in for ever, in fact we enforce strict rebasing or develop merge commits into branches throughout their lifecycle. The CI is run on each branch, each mainline, and each bugfix line for every commit. I encourage you to check out my project to see how branching can be very successful: github.com/keepassxreboot/keepassxc
The develop line stays absolutely pristine such that we can post "nightly" snapshots without worry. Nothing is merged in until it passes the branch CI and a merge CI.
I'd say he does understand git, but simply chooses to use it differently. In my company we do not use feature branches, unless absolutely necessary, which would mean a big rewrite of a considerable part of the system, where you just can't roll out changes progressively. It happened like 3-4 times in my 3 years of working here.
The issue he brought up with feature branches, where people work in separation from each other, is pretty substantial (not unsolvable, but still). Imagine you need something from another feature branch, but it will not be merged until a couple of days, because there something else needs finishing on that branch. And also, that required thing is based on lots of other changes made on that specific branch, so you can't just cherrypick it. Now what, rebase on a partially finished feature branch? Manually copy paste the code? Now, what if you need things from more than one feature branch?
In my experience, it is best to simply compartmentalize changes in a way, where a PR to master branch contains a small subset of changes that does not break anything. That way the changes are incorporated by the rest of the team and they can provide you with an actual feedback and vice versa. I know that is not always possible, but I would advocate for this approach in most cases where it is applicable.
I'd say he does understand git, but simply chooses to use it differently.
I cannot agree more with the notion that there are many 'correct' ways to use git.
Imagine you need something from another feature branch, but it will not be merged until a couple of days, because there something else needs finishing on that branch. And also, that required thing is based on lots of other changes made on that specific branch, so you can't just cherrypick it. Now what, rebase on a partially finished feature branch? Manually copy paste the code? Now, what if you need things from more than one feature branch?
In the scenario you're talking about, where Developer A needs some code from Developer B, but that code has dependencies on unfinished code that is not ready to be incorporated with master, I would argue that having that code on master instead does not improve the situation. If the unfinished code were on master, it would imply one of two things; Master is broken, or you're using feature flags. If you're using feature flags, you would have been able to cherry-pick the necessary code onto a separate branch and merge to master.
I would argue, however, that it's the development process that matters here, not the git workflow. If you're consistently finding that you need work from other features in order to complete your features, there are probably other things you should consider: Are your features broken down enough? It could be the case that the work needed by both features should have been done and released in a previous task, as a prerequisite for the two tasks that need it.
The team I'm working on uses feature branches, and also deploys to production multiple times a day. There are other teams who do not use feature branches, but still have many of the issues feature branches are suggested to create. At the end of the day, I think most of the problems brought up in this article and in this comment section are not caused by feature branches.
This is a great point, thank you.
I'm not sure what kind of CI setup you're using (maybe some kind of server hook?), but every CI system I've used (Travis, GitLab, Jenkins) would require code to enter the repo in order for the CI process to run. The CI process isn't going to prevent bad code from entering master; you just end up with a red build on master. Unless of course you use feature branches and use your CI build outcome as a quality gate. But you're advocating the opposite.
Sure. How does a feature toggle work when a feature requires a change to the build process?
Do you feature toggle the build instructions too?
Build steps:
- execute unit tests.
- execute sonarqube analysis and coverage.
- deploy it on a testing environment.
- execute integration tests.
- execute system tests.
If all green then build the artifacts and ship it.
What feature can require to change that?
What if something is red and I need to ship a bugfix?
If you use trunk based development and have a decent continuous deployment process, you don't ship a bugfix. You rollback production to the previous release version, revert changes in git, then add a regression test that fails due to the bug, fix the bug and then commit.
My bug is not in the latest release so "You rollback production to the previous release version, revert changes in git" won't help.
"Fix the bug and then commit" is exactly what I was referring to as ship a bugfix.
The problem here is not how to ship a bugfix or how to revert/rollback changes. The problem here is what if I need to send code to production if the trunk is unstable.
I agree that using branches can be used to develop your features in a bubble. But I think that is a great and awesome feature of git. Perhaps the most important one. You can focus on your stuff in your little bubble, and after you think you're done you just rebase to the develop branch to get all the latest stuff in, and then fix whatever broke.
After your stuff works again, you do the rebase again and repeat this until there is nothing to fix, and then you make the pull request and let others review and then approve it. I can not see how this is a bad thing. Also we at our team are not making pull requests from half-baked stuff anyway. And we rebase often, multiple times a day, which keeps the codebase fresh and prevents the large hassle of fixing the code after it's "done". There are no excuses to not do rebasing multiple times a day, and we have integrated it seamlessly in our workflow.
Do small commits, rebase after each one. That's a recipe to success instead of having to fear large conflict resolving when you're done with the feature.
Just my two cents.
After your stuff works again, you do the rebase again and repeat this until there is nothing to fix, and then you make the pull request and let others review and then approve it. I can not see how this is a bad thing.
Then you realize is 4am and all of you are still on the office because two guys on their bubble made architectural decisions that impacted each other because they forgot to rebase frequently and now all of you need to code a third set of classes to handle the communication between those two subsystems.
No thanks I don't want to return to those nightmares.
Sounds a lot like there is a problem in communication and planning. This is not because of git or branching.
Nothing is because git or branching, those are just tools what I like about not branching is that it doesn't requiere for the developer to be systematic and remember to do this and that.
If the developer isn't going to be systematic, how well do you think the product is going to work?
Well enough if you have a well configured CI server and QA processes.
I think this is more of a band aid approach which will eventually lead to further problems. If the issue is communication then you should fix that instead. Committing directly to development doesn't mean you resolve the issue of two individuals who decided to implement their own architecture. It just means if you weren't communicating then you get to see it sooner when you pull their recent commits but the issue still exists. It's just now it's been committed to the main dev branch.
and you fix it when is still a minor issue instead of a fully developed feature with, in the worst case, several days of work on it.
Communication problem are unavoidable or so says my experience.
CI is not a fix for bad planning and bad code. Fix the communication and planning and you end up with surprisingly good results. CI exists to help with quality, but the quality must start from the planning. CI does not help with maintainability and performance. Maintainability and performance directly affects to upkeep costs of the project.
I think you need to read a book called The Clean Coder. And The Phoenix Project while you're at it.
"and you fix it when is still a minor issue instead of a fully developed feature with, in the worst case, several days of work on it."
This again is a communication issue. Poor architectural design or not following implementation guidelines will not be resolved by checking in directly to a dev branch vs having a feature branch. It actually results in forced roll backs because things are being directly checked in to the same branch as everyone else. Just because they checked in code directly into the dev branch does not mean they didn't implement something incorrectly and didn't spend several days doing it.
Proper use of PRs for code reviews and communicating implementation with the team will help alleviate this issue.
There are different projects with different people and different needs. For my research project, where most of developers are non-professionals and do not follow all the rules (and cannot be forced), we use only single branch. It may sound crazy and really counter-intuitive, but it works best. People commit small and often, mistakes and bad code get quickly noticed. Everything is exposed to others and not hiding in their own branches. We don't even have resources to do much code reviews. But main branch is heavily tested and we use CI. Now, all the features are in the maim branch and work together. Earlier (with cvs, svn and git) we ended up having dozens of branches living on their own since many people never cared pushing them to master. Or if they did, they ended up into integration hell - while sorting the merge problems somebody else pushed his 3 months work to master. Yes, we have a communication problem since the project is very loose. Now, we have always a working version on single remote branch (except occasional hickups between pushes and finished tests). Branching works well only when it is tightly coordinated. Of course, people still can have local branches.
Our "project" is quite special, what I want to say that not all projects are the same.
I think just because some are non-professionals (I assume they want to someday be one) it doesn't constitute bad practices. I think it's important to teach good practices so that they can use good practices moving forward. I also disagree that branching only works when things are tightly coordinated. I think when everyone is on the same branch coordination becomes even more important because you are on the same branch. Again working on the same branch will not prevent someone from pushing in 3 months worth of work.
You are right, it does not prevent. But most people do follow the commit small and often principle. The important thing is that code gets as early visibility as possible and it is not hiding anywhere. In a loose and distributed team, the early pushes serve as an important way of communication - hey, my name is N.N. and I am working on this feature. Often, others step in and propose a better way to do it. In separate feature branch, it often happened that a guy worked months on conflicting/duplicate or badly implemented feature. Then senior developers noticed the problem too late. Then we were left with 2 bad options, accept bad merge to main or loose months of work. In both case, we have at least one angry and frustrated developer... Although we try to force people (esp. the newbies) to communicate their plans in Jira before they do single line of code. Another major problem was that earlier certain branches started to live their own lives, causing serious fragmentation of the code base.
I understand the importance of code visibility and this can easily be done with feature branches via a pull request that does not get completed until code is reviewed and accepted. Direct commits and push to development does not fix issues of poorly implemented code. A developer can easily lose months of work because they committed to their local development branch that tracks origin and then push all their work once. The issue here is that you now are faced with an issue where that code is now in development and you have no chance to deny or approve it. This results in higher need to roll back commits on your development branch as opposed to only accepting code that meets requirements.
Another way to put this is avoiding feature branches enables a team to achieve better continuous integration. Its related to continuous delivery and continuous deployment but those are downstream benefits to achieving better continuous integration.
A team can use feature branches and still achieve a high level of continuous integration, but it requires more discipline.
Reading this discussion, I think I have concluded that there are a lot of pain points for a team to encounter when switching from feature branches to trunk based development. However, I think I would argue that those pain points already exist and just aren't as apparent when using feature branches.
I think something to consider for all the nay-sayers... The author sounds like he has working experience on teams making branches and on teams without branches. He also claims that having a workflow that doesn't involve branching has aided in communication and healthy coding practices. Most of the people arguing against what he said seem to be in the realm of theory. But he is actually letting you know what his practical work experience has been. There is a difference in theory and actual experience. The author isn't theoretically saying he thinks this works better, he is saying he has literally experienced it working better. Git and branching are tools that you and your team can use as you see fit. If you don't want to use the same tools the way he is suggesting that is fine, but why are people trying so hard to convince him he is wrong? He already knows whether or not his teams workflow improved by making the changes he told you about.
Then you have a crappy team, somebody failed to communicate how to work on the team or something else; definitively flesh based problem rather than software tooling problem
Same problem as you described in the original post and same solution: communication.
Do you realise, that you have much bigger problems with your development process and colleagues, than how you use your source control system? Seems like a big mess and here is why:
You need features from other incomplete branches, i.e. you are not planning ahead correctly and your branch lifespan is too high
Your colleagues can't properly use git and branches just like you (why am I not surprised?)
You need better tools to merge code maybe (can I suggest Araxis Merge?)
Everyone works on their own and nobody knows what the other is doing, then you are "surprised" of the outcome and you have to stitch it all together.
Don't be offended by my words - I intentionally wrote it this way, so you can pause and think a bit.
Exactly my thinking. They have serious issues in how they work, I also bet it's not a team that one enjoys working with, and they just blame it on "the system".
I'm pretty sure their task breakdown is also wrong and they start working on huge epics in one branch without properly splitting the work. Probably their tech isn't allowing it.
Chalking things up to poor communication is like saying that the key to standardizing deployments is better documentation. Its true that a wiki can work, but why leave it up to human error when there is a better solution which is automation? Automation is essentially working documentation so you were right if you said the answer is documentation, however, I would give a better grade to the person that answered 'working documentation' over 'documentation'.
The problem we are talking about here is having people and teams come out of sync that can result in integration issues later down the road. Better communication is the right answer. To me, trunk based development essentially means 'working communication'.
I recently left a large codebase that didn't branch. I worked in this code base for 3 years.
As a result, we were forced to cherry pick change sets ready to deploy into a stage branch.
Once stage was certified, we had to again cherry pick change sets into a release branch.
The amount of feature flags required to support this would have been unmaintainable.
The amount of bugs that resulted from this were incredible.
The only way to describe it was a nightmare.
I don't see any possible way a large team can work in this environment.
I would never recommend "no branches" to a team over 3 people.
Because you guys were branching you had all those problems, from your comment I can see at least 3 branches being used.
That was not the cause of the problems. It was the symptom.
The cause was a failure to create a proper branching strategy from the beginning.
No it isn't. Your problem is you are scared to release your own software and instead you are cherry picking changes in your trunk.
Being scared lol. I can tell if you are you being serious or a troll. Has to do with a multi tenant platform that has SLA with it's clients that gives a 30 day review period to sign off on any changes before prod it's updated.
There are legit compliance reasons for staging deployments.
First, the analogy of splitting the canvas into 5 doesn't work. Even though you're working on a single feature, you can see the whole canvas and (one would assume) you're communicating to make sure that the changes are harmonious.
Second, feature toggles are a bad idea in my opinion. They basically translate to increasing the cyclomatic complexity because someone can't decide whether a feature should be on or off. The real problem isn't branching, it's indecision and poor planning. I could very easily see four or five half baked features becoming a testing and maintenance nightmare. If you do this for any length of time, your "bitfield" of features will be a lot more than 4 or 5. Good luck changing things when you realize a half baked feature needs a design change in order to complete and you have a few other half baked features to deal with.
Branches are good for a reason. They follow the UNIX philosophy of "Do one thing and do it well". Nothing will replace good planning and prioritisation.
While feature toggles might seem good in the short term, you're essentially building up more technical debt than you need to and are accelerating paralysis due to it in the long term.
Finally, I'd say if branching on Git is actually wrong, then why is it the cornerstone of so many CI/CD workflows? These workflows have been designed by extremely smart and experienced people and have been proven to work. So either you're missing something or the rest of the world has. Which do you think is more likely?
First, the analogy of splitting the canvas into 5 doesn't work. Even though you're working on a single feature, you can see the whole canvas and (one would assume) you're communicating to make sure that the changes are harmonious.
That is the idea of each project, then reality comes and some people don't even listen on the daily standup much less take a look at slack or whatever they just want to be left alone and code.
Second, feature toggles are a bad idea in my opinion. They basically translate to increasing the cyclomatic complexity because someone can't decide whether a feature should be on or off.
If the feature is marked as delivered then it should be on unless it creates a critical bug on production.
The real problem isn't branching, it's indecision and poor planning.
You will have those you want it or not therefore I prefer a system more resistant to it.
I could very easily see four or five half baked features becoming a testing and maintenance nightmare. If you do this for any length of time, your "bitfield" of features will be a lot more than 4 or 5. Good luck changing things when you realize a half baked feature needs a design change in order to complete and you have a few other half baked features to deal with.
Don't bite more than you can chew. Why start 5 new features if your team can only handle 2 per sprint?
It sounds like the problem you're experiencing is lack of communication and agreement. Code isn't going to fix a human problem.
I suggest you tackle the problem at the layer it manifests instead of trying to reinvent a square wheel at a lower layer.
After years of working on several companies and projects the only thing I saw in common were two:
- lack of communication.
- the managers always wanted more.
If you have some suggestions on the communication part please tell.
The last company I worked at had every dev forking the repos they were working on, and then making PRs to the company repos. For me (being a messy brancher) that worked pretty good, nobody could see my mess, I obviously only committed clean working code, and the company branches were clean and few.
Interesting approach.
wait, you are posting an opinion about git branching and you never heard of forking? this, i think, tells us everything we need to know.
Of course I know what forking is but I never seen a company working that way.
We work like that in my company, this is a very good way for branching without messing with the main repositories branches 👍 Pull request in a lovely team, this makes all my days at work 😍
I like that approach. Sounds like it would work well with really large codebases
This article confuses long lived branches with topic branches.
1) long lived branches are the worst and I'd rather not have branches if long lived branches were unavoidable.
2) not all branches are long lived, and short, feature specific branches are a useful tool to organize developement.
Your feature toggling is the worst suggestion I've seen in a long time. Although it's common to see this, it leads to code rot and maintaining code that's not used. If you're good at organized feature branches, you can immediately toss the old function and get it back in a merge free revert with one command. Forking the code for different versions is every devs worst nightmare.
If you were talking about long lived branches (stuff that lives longer than a sprint) then I would totally agree with most of what you said.
To put this back in your painting analogy, topic branches are more like brush strokes and each time you make one, you get a chance to step back, see if that made it better and find where in the painting it makes sense to work on next.
Having a clean history, and being able to review changes on a topic by topic basis are the hallmarks of git and it's power. When you can just revert a merge commit and cleanly delete a feature the night before a deadline, you'll understand the power
Above all, the purpose of branching is to isolate the impact of said changes. Feature toggle works well in most cases, but not all. It does not handle dependencies well, for one. Also, how do you run your integration and functional tests? With all changes in develop, these will be failing all the time.
The worst part of "gitflow w/o feature branches", I believe this is what we are talking about here, is that a defect introduced by any of the teams working on develop will impact all other teams as well.
how do you run your integration and functional tests? With all changes in develop, these will be failing all the time.
The CI server does it for me.
The worst part of "gitflow w/o feature branches", I believe this is what we are talking about here, is that a defect introduced by any of the teams working on develop will impact all other teams as well.
That is the idea, you want to fail fast to fix it faster.
Wow, I'm surprised by the negativity to this post from the majority of the developers here. The idea is spot on, but the article title and tone could be better - as in all things there is rarely a right or wrong answer to a problem.
I'm gonna argue the case for using one one branch - trunk/master. It may not work for your organisation, but for my organisation it's an essential way of shipping features to customers quickly.
We have 40+ engineers and we all commit directly to trunk - no branches, no pull requests, no QA department. Every push to git is deployed to production, provided that the push passes the pre-push test and quality checks, CI automated tests, etc. We pair-program on pretty much everything, the extra set of eyes is the equivalent of a pull request for us.
When bugs are introduced, it's trivial to rollback production to an earlier version and identify the commits that have likely introduced the problem. It's much harder to identify where a bug was introduced when you have multiple changes from multiple feature branches. Adrian is right failing fast is good! Quick feedback loop is incredibly useful. (That's why we all practise TDD, yeah?) When a problem does happen, engineers quickly pick up on the issue. ("Oh yeah, that was my recent commit on XYZ, I'll rollback production now and then revert those changes"). They are in the zone at that point. Compare that with a release that introduces a bug and engineers are already on a different task or feature. They have to context switch back to the earlier work, which makes problem identification harder. All engineers using the same code base and pushing to production daily helps with this rapid feedback loop.
Feature flags are not used simply as an on/off state to control "half-baked features" not being released. If you want to perform experimentation on your features or canary release features then feature flags are a must. Services like LaunchDarkly or SplitIO can provide matching rules for feature flags that allow you to target cohorts of users and give those users a different UI experience or feature. For example, we can easily create a new sign-in page and target 10% of all users to use that sign-in page while the other 90% get the existing sign-in. If all goes well and we don't get any major problems we can continue to rollout that new page to more users. Increasing or decreasing the percentage rollout is a configuration change and is instantly reflected on production. Experiments are also easy to implement with these feature flags. (For example, what's the affect on user registrations if we change the text? Make the register button bigger? Add a coloured background to the register button?). The results of these experiments allow us to continually improve the customer experience. Experiments and canary releases can also be turned off instantly (no deployment needed!).
If you don't want/need to deploy to production daily, then feature branches will work just fine. But, if you want to move towards continuous deployment, rapid feedback on experiments, canary releases then trunk based development and feature flags is a good approach. It's scary at first, but it's worth it. Not one of our engineers will go back to the bad old days of feature branches and merge conflict hell.
Ask yourself which is more likely:
- You are using the wrong tool for your workflow
- Everyone else is using the wrong workflow for the tool
What I don't get about this argument is, with distributed version control, in a sense everyone "paints their part without even looking at what their partners are doing" even if you don't branch. Unless everyone regularly pulls from the repo, they're only going to see what's in their checked-out copy.
If you want to mandate that they regularly pull in order to stay up to date with others' changes, you can just mandate that they regularly merge
master (or
develop or what have you) into their topic branches.
I don't see how organizing or not organizing your own development into topic branches affects how integration with the rest of the codebase is handled. And as someone else pointed out, if every developer has their own fork of the code (the GitHub model), then that adds a further wrinkle that even this crazy "no branches" position doesn't solve.
I feel like this is trying to solve the wrong problem, by thinking that branching is the problem.
Without branching you can't have pull requests. Without pull requests code reviews are very difficult. I work on shared repos with as many as 10 other devs working on feature PRs at a time and this simple model just won't work for us.
If you think about it branches are just "groups" of commits. Being able to break big features down into small commits and group them is actually something that helps avoid conflicts and increase communication in my experience.
The only time not branching ever worked for me was back when I first started using GIT and was basically just a single developer that used source control as a giant undo history.
In my personal experience PRs are almost useless unless all your team knows how to do them well. In my opinion PRs cannot beat a well configured Sonar + CI Server.
Then you have no idea what you're talking about. You can configure PRs such that if the code is not building, or passing tests, it will never be possible to merge that code to the main branch. With your approach, this is not possible and who knows if you even pay attention to failing tests at the moment. Because when you're not FORCED to solve these issues, sooner or later somebody will say to leave it to later, because now you're busy with other stuff.
Also, you still didn't answer how you conduct code reviews. I'm guessing you don't. But even if you do, the result is that code pushed to main development branch is messy.
In some other comment you mentioned that developers changed architecture in their feature branches. Well, with code reviews, you'd see that and comment on that and tell the developers to not change the architecture, or resolve the situation before it gets to main development branch.
I'm thinking maybe you just never worked in a technically mature team and you never conducted proper code reviews and that's why you have these opinions.
You have an amazing Sonar + CI Server if it can give warnings for inappropriate architectural approaches, business requirement issues, or rolling your own libraries when those already exist in the codebase or in existing dependencies.
"PRs are useless".
I'm seriously more and more horrified I would accidentally one day work for that team. I'm sure I'll see a nightmare tonight. Dude you need a good mentor who can show you how it's done. No offense, try to work with people having worked abroad and have a wide experience in leading teams. You have many misconceptions and dogmas.
You're treating the symptoms not the cause, and misusing tools in the process.
Your team shouldn't be going off on their own for 2 weeks at a time, they should constantly be pushing small PRs. They should be constantly reviewing these PRs so they know what's going into the codebase, and your codebase should be decoupled enough that conflicts are rare.
What's the difference between constantly pushing small PRs and just committing to master?
If someone writes a mess of a PR, it will get hung up in the code review process until it is clean. The only people it will affect are the writer of the PR and the reviewers.
If someone writes a mess of a commit and pushes it directly to master, it affects everyone who wants to push.
What's to stop the PR process pushing something that is "a mess" ? We're not all knowing and make mistakes.
The beauty of software is that it can be changed, so if someone pushes up a "mess" then it can be fixed.
In practice, if you trust your team... then people wont be pushing "messes". Sub-optimal? Sure, but its not a big deal.
The problem with this kind of ceremony is its trying to optimise for perfection, which no one is capable of. What you should be optimising for is fast feedback loops so you can quickly iterate to something that resembles useful software.
I strongly believe there is no one size fits all solution to anything. And for small teams 3ish and under this may work.
I also strongly believe in the "do what works for your team" motto.
If your article had some conditions, for example: very small teams, I could have agreed with you.
But a blanket statement saying git branching is wrong is not only false but dangrous and harmful.
Before branching, this is how software was done. And there were problems with it, which is why the concept of branching was created. To solve the problems with source control that didn't support branching.
For those of us that have been through the advent and evolution of source control systems, we understand why branches exist because we have experienced the pains of not having them.
Communication is key. But we also have another keys:
- merge your master or parent dev branch into your feature branch often
- avoid long lived branches
I agree with some suggestions you made, like feature flags. They help a lot to keep the branches short-lived.
All those premises are the same everywhere I worked that used branches, the result? Years old, thousands of commits behind and totally forgotten branches.
The problem with branching is that it actively requires the developers to be clean.
Forgotten branches are forgotten features or projects - they may happen with or without branches. All proposed solutions also require the developers to be clean at something.
I think lack of planning and communication are the main problems in these situations, or at least that was the case on my experiences.
Agree working in a bubble is bad.
Agree merging to master early and often is good.
Completely disagree with the premise that using feature branches causes the type of problems you describe.
There's definitely something else going on here.
Your feature branch should be short-lived.
You should be merging or rebasing Master into your feature branch one or many times a day so you have the latest commits from everyone else
writing new features and integrating them into preexisting code are/should be separate tasks. keeping them separate cuts down both on feature creep/"oh i'll just do this too while i'm here" and on tech debt caused by timidity in the face of old code.
relatedly, isolating features makes squashing/rebasing easier (especially now that github has those options), which makes pulling problematic code out easier.
A couple of years ago I'd have entirely disagreed with you, but after switching to trunk-based development when I joined my current job (i.e. that was what the company was already doing so it was something I had to do too) I'm right with you.
I think it's easy to think this will be a nightmare, but in practice I can count on one hand the number of merge conflicts I've had in the last 18 months, and they were all very easily fixed. This was the total opposite experience that I've had in the multiple places I've worked that used feature branches.
Edit: okay I do actually disagree with the clickbaity title, branches aren't "wrong". But yeah, I wouldn't be keen to switch back to them.
Conflict resolution is easy if you use the right tool. Do you use web storm or some other ide with à visual conflict résolution tool ?
Conflicts don't happen when you have a good architecture and everyone works in their own component. It also doesn't happen when you communicate and if you rebase often.
I've got to agree with the rest of the sentiments left in this comment section. This is terrible advice and should not be followed. I've worked like this in the past and it's hell compared to gitflow or even a simple feature branch model.
Don't agree with this at all. Suggesting that branching be replaced with further time consuming meetings and features toggles just seems ridiculous.
Part of your role as a developer should be a good understanding of source control and having processes in place to support the use of branching (planning, reviews, correctly identified tasks) is a lot more conducive to having a concise code base than filling it full of broken code and feature toggles.
Only a Sith deals in absolutes.
Suitably controversial subject, especially for post #1, bravo :)
I note that nobody has yet mentioned structural issues, my first reaction to a situation where close co-ordination is required among a significant number of people (say 4-5+), is to question the coupling of the things being worked on - ask if there are better ways to structure the code so more people / teams can work unhindered (yes, apply Conway's Law!), look for more stable interfaces, domain boundaries, to partition work around.
If short term fixes are needed, perhaps ask if there are known working practices which would help like Mob Coding, or appointing a design authority role to make decisions that affect >1 person (this can be a rotating role, as long as there is someone the team can communicate with immediately for such decisions and they are shared).
Respectfully disagree. This defies the whole point of Git. But if it's working for you and your team, stick with it! These days I need to get things done fast and with as few bugs as possible. Use whatever technique saves you time.
I really disagree. Feature branching is an invaluable aspect of development workflow. I agree that code isn't written in a vacuum and individual developers must be aware of everything else going on simultaneously to avoid disjointed software and the bloat that comes with development each developer trying to be independent.
However, feature branching is not the source of these problems. Poor communication is.
My teams are always checking out each other's feature branches to understand changes being made. WIP pull requests are made as soon as a feature's scaffolding is clear enough to be understood by another developer. Comments are made right away suggesting improvements, warning of pitfalls or inconsistencies, or criticizing the entire approach. As commits roll in, particularly affected parties subscribe to notifications so they can see what's changing and discuss.
When developing, I spend at least 20% of my time in other people's branches, piecing together the way everything will work. When I notice divergence between the branches, I start a lengthy thread on Slack and we figure out how to tighten up our architecture.
What about when developing highly-interdependent features? Keep in mind that they're feature branches, not developer branches, and don't exclude cooperative development by multiple developers on a single branch. If the two features are small enough, we develop them on the same branch. If they're more complex, we will often create a branch that acts like a mini-development branch to create feature branches from and make PRs to. When the interdependent features are ready, we make a PR of this mini-dev branch back to development proper.
Trunk-based development (and adding in dev-environment logic) really misses out on the power of Git. The big advantage of version control is that untested code can be rapidly checked out and used without interfering with reliable code. It ultimately increases effort needed to commit and reduces frequency of commits, since developers need to be very careful not to commit code that doesn't work. Moreover, developers must rely on each other to keep the trunk in working condition. One mistake halts all development. No one can test their own features against known working code with the entire codebase in a state of flux. The larger the project, the greater the risk. Soon enough those daily meetings become week-long workshops that resemble change-board reviews. Eventually quality sacrifices are made just to get it working again due to the building pressure of all the developers waiting on the one problem to be fixed.
Git flow is scalable from an individual to a large organization, and allows concurrent, prioritized development with minimal risk of breaking the trunk. When implemented properly with CI/CD and proper merging permissions, there isn't a quality sacrifice. When WIP PRs are made early and a culture of checking each other's work is promoted, the code remains unified and everyone's concerns are heard.
I respect that trunk-based development has worked for you, and I know it's not always unsuccessful for small projects, but I've seen many trunk-based teams slow to a crawl waiting on individuals and become unable to easily produce working builds on demand because their version control was in their way.
I assume when you say "in two weeks try to piece everything together" that you are working in two week sprints in an agile process. The issue in my opinion is that the pieces you are working on are too big and needs to be broken down further. If the single thing you are working on takes up the entire two weeks of your sprint then it's too big. In my experience a good rule of thumb is that items you work on should be less than the sprint they exist in. Also a highly functioning team should know how things are being implemented through conversations and proper design specs resulting in less surprises.
This is not a great approach at all. Every time code is touched it should be it's own branch. This is exactly why Git mimics the structure of a tree.
Having a dev team work on the same branch can cause delays. If one developer breaks a branch it can halt development for everyone else. Unless of course, all members are at the same level of efficiency.
Having work on speperate branches allows for better code review and keeps a nice history of commits. If a developer leaves in the middle of work, another developer can pick up where they left of. They can also refer to a ticket with the same naming convention.
If the dev team has unit tests and CICD in place, they can catch the errors there.
I'm typing on my phone after a few beers. Not the best idea to comment in this state of mind.
I guess tagging could be an option as well, instead of branches.
Any agile methodologies will tell you to keep the features small and talk to your teammates regularly. Also, any good backlog grooming should contains evaluation of inter-dependance between features so special care is taken in those scenarios.
So I definitely agree with you that long lived branches are a nasty thing. However, I don't see were this has anything to do with git branching, gitflow or feature switches. Also feature branches allow to validate the team's "definition of done" in code review before integrating a features, so the team never have to put any feature in production that would lack test coverage, documentation or whatever the team deems important.
I suggest you to take a look at the INVEST mnemonic trick, to evaluate your backlog stories.
See ya!
I see where you are coming from, but I largely disagree.
Development, especially for big teams, should be loosely coupled. This doesn't mean that the team shouldn't meet and have a unified clear vision, on the contrary, this will allow things to scale properly and gives you options to add or remove features with minimal effect on the actual main branch.
Your painting analogy is a moot point imo, since painting is mostly done by one painter not 4 or 5 or way more, like in software.
A better analogy would be a car assembly line. Engine, suspensions and body parts are manufactured on their own assembly line and then they are put together when they are ready, wouldn't you agree?
I think this approach would change your day job from developer, to merge conflict solver...
I do agree that branches can start growing in separate ways which makes it hard to merge them, but if you keep your stories small, and not let your feature branches exist for weeks, but merge them within a day, or tops three days if there is no one available to check the pull request... Then I think the feature branches are a much better solution then the one suggested.


text:
Posts Tagged 'data tapes'
Records Storage: Five Places NOT to Store Your Data
It may be an over-simplification to say that records storage and management companies like The Data Vault exist for a reason, but that wouldn't make it any less true. And it's also too easy to look at your document and tape storage as a necessary evil, or as just another expense sapping money from the…Read More
The Truth About Data Tape
Digital magnetic tape has been around for 60 years now. That's a long time in a world in which humans are constantly striving to come up with The Next Big Thing. Indeed, the appeal of data tape technology has been debated for years, but even with its future existence being questioned by the oncoming surge…Read More
Data Tapes Live On
Rumors of the death of data tapes have been greatly exaggerated. Whereas cloud backup and data recovery is being touted as The Next Big Thing — and it probably is warranted — many are assuming this will spell the end of data tapes. Not so fast. An eye-opening new article from ComputerWorld.com shows the other…Read More

subset: commoncrawl


text:
Property ID : 1514323
Sold $172,500 - Single Family Home
Affordable on the Eastside! This turn of the century home was gutted in the 50's-60's and remodeled at that time with mid century modern finishes. New HE furnace, garage door, and backyard fence in the past year. It has a full walk up attic, and a bonus room off the kitchen that would be ideal for an office or fourth bedroom. Very dry basement with interior drain tile system and sump pump installed. Conveniently located close to UWM, Oak Leaf Trail & Urban Ecology Center. Here's your chance to live on the block with the Boat House!


text:
Similar climate, similar experience. Its too bad I was not able to take mine a further down the road. It has (so far) had THE best battery pack ever!webeleafowners wrote:Curious. So in Canada we probably have a climate similar to Europe. Are we also expected to have less problems? Our 2016 SV was built in April 2016. I can't say we have noticed much range loss yet. It's actually been flawless, like freakin flawless.
I never thought I would be a compliance car fan. Guess I am. .


text:
How to get the WorldPose of Collision Objects?
Short question:
In a custom plugin, I want to retrieve the current pose of a collision object with respect to the world frame. I use the following code for this:
When I run the simulation, I get a pose. However, the pose is always the same, even when I move the robot to which the collision object is attached to. It seems to me that the returned pose is the initial pose. How can I get the updated pose?
physics::CollisionPtr collision;
math::Pose pose;
pose = collision->GetWorldPose();
More details:
The collision objects I get from
collision = link->GetCollision("collision_name");
When I use the link itself for getting the pose, like:
pose = link->GetWorldPose();
the pose is correctly updated, but for the link and not for the collision object. The reason why I want to have the pose of a collision object is that I added some Points Of Interests (POIs) on the robot structure with fixed joints. I want to know the pose of these POIs. Since they are linked to the robot with fixed joints, gazebo does not create extra links for them, but adds just an additional collision object as a child to the link. Hence, an extra question:
Is there a smarter way to get pose information of POIs distributed on the robot's structure?
I'm using gazebo 7.
Possibly related? https://bitbucket.org/osrf/gazebo/pull-requests/2702


text:
The potential of medical device recycling
Hospitals use a lot of single-use PVC-based medical devices every day. Besides being safe and affordable, PVC is easily recyclable and keeps its technical properties through numerous recycling cycles. Also, many of the devices are used on non-infectious patients. These advantages have led to the set-up of medical devices recycling systems in the healthcare sector.
In Australia and New Zealand, more than 170 hospitals collect IV bags, face masks and oxygen tubing for recycling. The scheme is run by the Vinyl Council of Australia with support from medical device manufacturer Baxter. The recyclate, which is of high-grade quality, is used to manufacture mats, hoses and other useful products.
In South Africa, PVC IV bags are recycled into school shoes for disadvantaged children. Only 20 IV bags are needed for a pair of shoes. Because the shoes are made entirely of PVC, they are 100% recyclable. When the shoes get too small for the kids, they hand them over for recycling and then get a new pair of appropriate size. The programme has helped to incubate new small businesses.
About 25 hospitals in Guatamala collect used PVC medical devices for recycling. The PVC is recycled into shoes that are distributed to school children in Guatemala City. The shoes are handmade by indigenous Kekchis women, which provides jobs and income to this minority group.
Why recycle medical devices?The potential for medical device recycling is huge, as studies show that only a small fraction of the medical plastic waste is infectious. By recycling medical devices both hospitals and the environment win:
Cost savings for hospitals
CO2 savings
Energy savings
Low risk of contamination
High grade recyclate
Untapped resource
For each kilo of PVC recycled, 2 kilos of CO2 are saved


text:
Naked Campaigning (Limerick)
Some folks are offended by Scott Brown's "Thank God" retort to Elizabeth Warren's she kept her clothes on joke. But this feminist isn't.
I think Elizabeth Warren is great, but in response to a debate question, she did make a mild nudity joke at Scott Brown's expense. So in that context, I just didn't find Brown's remark especially outrageous.
But that won't prevent me from mocking Scott Brown in this limerick:
Naked Campaigning
By Madeleine Begun Kane
Brown nakedly showed us his tude,
As his race for the Senate debuted:
Vote for me and not Warren—
She's Harvardly foreign.
And I'm cuter than Liz in the nude.
Tags: Campaign Satire, Election Humor, Elizabeth Warren, Feminist Satire, Massachusetts, Nudity, Scott Brown


text:
Set on the Jurassic coast at the ancient Cobb, Lyme Regis we offer exciting sea sailing from March until the New Year. A welcoming Clubhouse on the beach with full facilities and fine sea views. A thriving youth training scheme exists to give a start to our youngsters who can progress onwards via the RYA training program.
A small but active cruising section travels far and wide during the summer, whilst a small fleet of lift keel cruiser racers do the "round the cans" stuff. Temporary memberships available. Come and take a look!


text:
Truck Carrying Splatoon Amiibo Stolen
A truck carrying a shipment of Special Edition Splatoon Amiibo has been stolen in Europe. Tough luck, says Nintendo to the hapless customers who pre-ordered toys that will never arrive.
A truck carrying a shipment of Special Edition Splatoon Amiibo has been stolen in Europe. Tough luck, says Nintendo to the hapless customers who pre-ordered toys that will never arrive.
There has been much ado about cartridges lately. Here's a chance to see what modern games might look like if they were shipped on NES cartridges.
Castlevania on your iPad (the real deal, not the junk puzzle game from 2011)? Konami has decided that since mobile devices are closest to us, they will be the focus of the company's development efforts.
Did you know that Nintendo has been in operation for over a hundred years, they once produced vacuum cleaners, and their weaker than competition graphics are part of a core business strategy?
All that and lots of F-bombs in this video!
Posted by: mwilson
Category: PlayStation, Wii U, XBox
Nintendo's console has always been de facto considered the lame duck among each generation of consoles, but that hasn't stopped the company from continuing to see success from its consistently strong IP.
Is there truth to the Wii U's hardware inferiority complex, or does the system give us more than just a platform for the latest entries to Mario franchise?
Here's two goodies in one. Enjoy Super Mario Bros as the wealthy must surely do (with live instruments instead of dreadful 8-bit sound), and check out the skillful entry into "glitch world" -1.
Posted by: mwilson
Category: NES
In this video interview Charles Martinet – the voice of Mario – talks about how he created the plumber's signature sound.
Over the years, poor Mario has suffered more on-screen deaths than John Hurt. Now the Internet has gotten together to create even more mayhem in Mario's life all over YouTube.
Read on to see how Mario tries to handle an errant Bullet Bill cannon, with hilarious results.
Speed demons rejoice! 200cc mode is coming with downloadable content on April 23.
As if the 50cc, 100cc, 150cc and mirrored 150cc speed levels weren't slapstick enough, the new 200cc class promises to push your kart speeds to the extreme (extreme, at least, for go-karting).
Posted by: mwilson
Category: Humour, Nintendo, RPG, Wii, Wii U
Tags: Legend of Zelda, Nintendo
We've been having so much fun rounding up Fallout memes and illogical game moments, we thought Link deserved a turn.
Read on for the best the web has to offer for Legend of Zelda memes…


text:
Product details
High-quality exhibition carpets are also called Needle Punched Non woven Carpet. It is made of synthetic fibers by needle-punching process, and then made of a certain degree of hardness of pavement materials by dipping method, because it is often trampled on, so there will be a lot of dust on it. In order to avoid the accumulation of these dust for a long time, we need to clean it up to avoid the ground. Blankets have an impact.
Carpets need to be cleaned regularly, because the accumulation of dust on the carpet will cause wear and tear to the fibers, the color of the carpet will also become grey, frequent access areas are most vulnerable to pollution, and pollution will spread to other parts of the indoor, so we should introduce a small carpet at the entrance.
Wiping shoe dust can reduce the accumulation and diffusion of dust. In corridors, lobbies and frequently moving places, two or three times a week, bedrooms should also be at least once a week.
The choice of vacuum cleaner and dust removal method will also affect the cleaning effect. Vacuum cleaner equipped with rotary dust brush can effectively absorb dust inside carpet.
Vacuum cleaner needs to push the vacuum cleaner slowly. The action should first push the dust brush before pulling it forward. In addition to regular cleaning, cleaning carpets can be laid within a period of time, using dry cleaning methods to clean carpets; about every two years, clean carpets thoroughly by employing cleaning companies to ensure that carpets last as new.


text:
How much easier can it get? Ladies! It's just spray and go. The newest invention by Vaseline is the Vaseline Spray & Go Moisturizer, which is meant to absorb the moisturizer onto the skin in seconds, so that you can zip out that door in no time.
Most women have lotions at home, but don't use them on a daily basis as their biggest barrier is "lack of time." Women know they should be using body lotion every day, but skip it because it takes too long to apply and absorb, slowing down their morning routine.
Sounds familiar? That is me, me me! And now, frankly, I have no excuse, and I just love it. I love the fact that I am doing the right thing for my skin, by taking care of it, moisturizing it, minus the 'no time' dialogue that goes on in my head all the time.
I'd rather catch up on my sleep, I tell myself.
The Vaseline Spray & Go Moisturizer line includes three variants, each available in a 190ml can.
My favorite is the Aloe Fresh.
Vaseline Spray & Go Moisturizer is available at all major supermarkets starting at AED 24.


text:
The Basics
Product search, import, modifying, & saving
Specify Alterations
Learn how to include MISUMI's standard alterations to your CAD model.
Converting Features
How to quickly change to a different geometry within the same category.
Dimensional Errors
What happens when venturing outside of the range.
Lock CAD Feature
Understand how to restrict changes being made to the CAD model.
Custom Properties
Link custom properties to auto-populate your BOM.
Auto Recognition
Rapid Design automatically recognizes MISUMI CAD models, learn how and why you'd toggle this function.
Database Check Feature
When a designer configures a product, Rapid Design will query a database and notify the user if this product already exists internally (For example, within a PDM or another library). This will keep users from duplicating processes and CAD files.


text:
Patient Registration
You can download and print the New Patient Information form and the HIPPA form directly from our website. Feel free to fill these out in advance and bring them to your appointment. This will ensure the most efficient check in. You can also fill these forms out when you arrive for your appointment.


text:
- 1.900
- 1.367.011.894
- 680.488.272
T-Rex Ranch - Dinosaurs For Kids
Hi there! We are a family that loves Dinosaurs and toys and we love sharing our all our adventures with you! Make sure to check back regularly for our latest adventures and be sure to subscribe! Thank you for supporting our channel!
FAN MAIL: We receive so many letters every week and we read them all! Unfortunately we can no longer respond to all of them. If you'd like to send a letter to Aaron & LB, get your parent's permission to write to us at this address:
T-Rex Ranch
c/o Moonbug Entertainment
742 North Cahuenga Blvd.
Los Angeles, California 90038


text:
The circumstances under which an individual needs help in an emergency can differ, and there may be a time when you need to call 999, but speaking will put you in danger. Staying silent on the phone does not guarantee that emergency services will come to help you.
That's why the police are now raising awareness of a service that enables people to call them in an emergency when they are unable to make a noise or speak on the phone.
The emergency services receive millions of calls every year, and in some cases operators may be unable to tell if a silent call is accidental or a real call for help.
The Home Office has a system in place called Silent Solution, which helps callers, who cannot talk to an operator. Last Sunday, police watchdog the Independent Office for Police Conduct (IOPC) launched a campaign called "Make Yourself Heard" to increase awareness of the Silent Solution system.
So what happens when you dial 999?
The phone call will be directed to a call centre and answered by a BT operator. The operator will immediately ask which service you require. If you have not been able to speak at this point, you can make yourself heard by coughing, tapping the handset, you will be put through to the operator. You will then be asked to dial "55" to show that you are in danger, otherwise the call will be terminated.


text:
Kim Hanh is a prominent figure in the field of journalism and supporting businesses build their brands in Vietnam. She played a major role in making Tuoi Tre a top news agency before starting to build and shape Sai Gon Tiep Thi in 1995, making it one of the most successful newspapers in Vietnam. In 1996, with SGTT, she launched the High-Quality Vietnamese Goods program. In 2000, she deployed the country's first project in building brands for Vietnamese goods, and after that, the "Supporting Vietnamese retail network" project.
In 2002, Ms. Hanh conducted a national survey for The Business Association of High-Quality Vietnamese Goods for "Vietnamese businesses' awareness and investments for brands," creating the first concept for "brands," which heard for the first time in Viet Nam. In 2004, she was appointed president of HCMC's Investment and Trade Promotion Center (ITPC), the position she used to push into the Cambodian market, to build "Common House" concept as well as making landmarks like the Vietnamese goods chains in Kun Ming – China, or the Asian brands week. Ms. Hanh also organized the "Honouring Vietnamese Brands" street festival, built brands for 20 seed brands, and organized for the first time the ASEAN Brand Expo. She was the one who motivated the HCMC People's Committee to award Vietnam's first 100 strong brands and played a part in creating Leading Business Club (LBC).
In 2008, Ms. Hanh and her fellows in LBC and Sai Gon Tiep Thi newspaper launched Business Studies and Assistance Center (BSA), constantly and regularly promoting The Business Association of High-Quality Vietnamese Goods, LBC, as well as administrating the Vietnam Chief Sales and Marketing Officer Association – CSMO), Businesses for Communities program and many other diversed activities.
Ms. Hanh holds a bachelor's degree in Finance from Van Hanh University (before the liberation) and a n EMBA from UBI.


text: Ethan Hawke Is a Preacher Facing a Crisis of Faith in 'First Reformed' Trailer 10:10 AM PDT 3/29/2018 by Lexy Perez FACEBOOK TWITTER EMAIL ME YOUTUBE "Can God forgive us for what we've done to this world?" Hawke's Ernst Toller asks while confronting the hidden secrets of the church. Ethan Hawke is a preacher whose faith is about to be tested in the official trailer for Paul Shrader's thriller First Reformed, released Thursday. The film centers on Ernst Toller (Hawke), a church minister and ex-military chaplain, who continues to struggle with the grief over losing his son in war. Though getting by with his daily routine, Toller reaches his breaking point when a church member (Amanda Seyfried) confides in him during counseling with her radical environmentalist husband. Soon, his faith is challenged as he is catapulted into a hysteria over the church's suspicious affairs and its hidden complicity with unethical corporations. "I know that nothing can change, and I know that there is no hope," Toller is overheard saying, as he slowly realizes that he now faces a flawed existential perspective and apparent crisis of faith. "Can God forgive us for what we've done to this world?" Schrader wrote and directed the visually enticing thriller. Christine Vachon, David Hinojosa, Frank Murray, Jack Binder, Greg Clark, Victoria Hill, Gary Hamilton and Deepak Sikka produced, with Brian Beckmann, Philip Burgin, Brooke Lyndon-Stanford, Martin McCabe, Luca Scalisi, Mick Southworth and Ying Ye serving as executive producers. The film premiered during last year's Venice Film Festival, with The Hollywood Reporter's review calling it Schrader's "most effective work as a director since Auto Focus 15 years ago." Cedric the Entertainer, Michael Gaston and Van Hansis also star. First Reformed is set to hit theaters May 18. FACEBOOK TWITTER EMAIL ME YOUTUBE Lexy Perez email@example.com LexyJPerez


text:
KEM Weber Airline Chair: Sleek, Stylish, Innovative
September 18, 2014
The Berlin-born and trained architect and designer KEM Weber (1889-1963) arrived in the United States in 1914, during the initial incoming wave of progressive Central European architects, designers and artists. Weber's undoubted masterpiece is the Airline chair (designed 1934-35), and LAMA is pleased to present this custom design in the October 12, 2014 Modern Art & Design Auction. The chair appears in the collections of the Victoria & Albert Museum, the Brooklyn Museum, the San Francisco Museum of Modern Art, and the Los Angeles County Museum of Art, where it was a centerpiece of the landmark 2011-2012 exhibition California Design, 1930-1965: "Living in a Modern Way."


text:
An Amazon princess named Diana (Gal Gadot) lives an idyllic existence on an island occupied solely by female warriors, but her life changes forever after American pilot Steve Trevor (Chris Pine) crash-lands nearby. When he tells her that a massive war is engulfing the planet, she decides to travel with him to the outside world, hoping to use her powers to put an end to the conflict. Along the way, she becomes the legendary superheroine known as Wonder Woman. Directed by Patty Jenkins (Monster), this is the first solo feature film for the iconic DC Comics character.~Violet LeVoit
Warranty:30 Day Warranty
- Genre: Action and Adventure, Adventure
- Subgenre: Period Film, Superhero Film, War Adventure
- Title: Wonder Woman
- Countries Produced: United States
- Duration: 141 minutes
- Year of Release: 2017
- Format: 4K Ultra HD Blu-ray, Blu-ray
- Program Type: Movie
- Studio: Warner Home Video
What you get:One [1] Wonder Woman Steelbook Edition
One [1] 4K UHD Blu-Ray Disc
One [1] Standard Blu-Ray Disc
One [1] Digital Download


text:
Jumping on planes and overcrowded boats to destinations unknown, thousands fleeing the end of the Vietnam War in 1975, opened a new chapter of their lives.
Some Vietnamese refugees recall abuse in holding camps while awaiting entry into willing host countries; others struggled with the emotional upheaval of re-settlement in a strange land.
"You do not have a choice what to bring with you or who to be with you and how things will be and even a choice to say goodbye to your friends and family," said Dr. Suzie Dong Matsuda, a clinical psychologist who worked with Vietnamese refugees for 19 years at the Orange County Health Care Agency.
Dr. Matsuda left her family and Vietnam by boat and lived in a camp in Indonesia before settling in Orange County in 1984.
"My mom said, 'I want you to have a future, just go.' And so I did. I was a teenager," said Matsuda.
Dealing with stigma
Cultural stigma caused many to struggle silently with depression, anxiety, and post-traumatic stress – especially among the first wave of refugees.
"People may speculate that in your past life you did something wrong, maybe in your family there is something wrong," said Matsuda. "They do not think mental illness is a brain illness, but [think of it] more as contributing to one's character. In an interdependent culture, it makes the family look bad."
In Orange County today, home to the largest community of Vietnamese outside of Vietnam, there is a growing movement toward removing the stigma of mental illness through awareness.
Though there is still a great need for more culturally competent providers who speak the language of their clients, Matsuda says, it is still possible for a provider who cannot speak Vietnamese, to help.
"When I was in college, I was saved by a psychologist who knew that I went through depression and I was quite suicidal at the time…and it did help me to get through my school year and graduate. He was not Vietnamese. [He was] not speaking my language, but the empathy and compassion did make a difference."
For more on where to access mental health services and information, see below.
Orange County Behavioral Health and Referral: (855) OC-LINKS/ (855) 625-4657
Los Angeles County Mental Health Services: 877-344-2858
Los Angeles County Substance Use Treatment Services: 800-564-6600
For those who have private health insurance, call your insurance provider and ask for Behavioral Health Services.


text:
Animal Care & Control Division
Welcome to Gila County Animal Care & Control!
Gila County
|Meet our Staff!
Photo (L-R):
|In 2017, the Gila County Animal Control launched a major rebranding strategy; from the development and implementation of our Facebook page to changing our name we underwent significant changes during the past year both internally and externally. Our primary goal is to improve your perception as a pet owner that we care about your pets and want to help any way we can.
We welcome you to the all new Gila County Animal Care & Control webpage!
Please feel free to click on the links below for information you may be interested in.
Adoptions; Animal Disease & Care; Services & Fees; FAQ's; Public Notices; Renew License; Surrender a Pet; Lost Pet;
|Renew License
To purchase a new license, contact the Gila County Animal Care & Control office at (928) 425-5882 or you may renew your license by clicking the image on the right or you may click here to access the license renewal site.
|Public Notices
Gila County Ordinances
Public Information Request
|Surrender a Pet
This section still under construction…
|Lost Pet
If you have lost your pet or your pet has been impounded, please contact the Gila County Animal Care & Control office at (928) 425-5882 and we will be happy to assist you in reuniting you with your pet as soon as possible.
You may also search online for your lost pet: Lost Dog; Lost Cat
Adopting a Pet?
To read these rules in more detail, please click here.
Finding the Perfect Match
We also recommend that you learn a little about animal care and behavior before bringing home your new pet.
|Find your pet here...
There may be one here that is just right for you! You may also search online for your new best friend at PetHarbor.com.
Click on the links to search for Adoptable Dogs; Adoptable Cats
Pet Adoption Application [Printable] [Fillable]
|In addition to the various adoption activities that our Gila County Animal Care & Control team are involved with in reuniting lost pets with their families, we have recently began a new partnership with Bissell and LostPet USA.
This helps reduce the number of animals in shelters and rescues through pet adoption, spay/neuter programs, microchipping and foster care.
|Canine Distemper in Dogs
Canine distemper is a contagious and serious viral illness with no known cure. The disease affects dogs, and certain species of wildlife, such as raccoons, wolves, foxes, and skunks. The common house pet, the ferret, is also a carrier of this virus. Canine distemper belongs to the Morbillivirus class of viruses, and is a relative of the measles virus, which affects humans, the Rinderpest virus that affects cattle, and the Phocine virus that causes seal distemper. All are members of the Paramyxoviridae family. Young, unvaccinated puppies and non-immunized older dogs tend to be more susceptible to the disease.
Canine Distemper Virus (CDV) in Dogs [Video]
Symptoms and Types of Distemper in Dogs
The virus, which is spread through the air and by direct or indirect (i.e. utensils, bedding) contact with an infected animal, initially attacks a dog's tonsils and lymph nodes and replicates itself there for about one week. It then attacks the respiratory, urogenital, gastrointestinal, and nervous systems.
In the initial stages of Canine Distemper, the major symptoms include high fever (≥103.5 ° F, or 39.7° C), reddened eyes, and a watery discharge from the nose and eyes. An infected dog will become lethargic and tired, and will usually become anorexic. Persistent coughing, vomiting, and diarrhea may also occur.
Read more on the distemper here.
Canine Parvovirus (CPV)
Parvovirus in Dogs [Video]
Signs & Symptoms of Parvo in Dogs
Feline Panleukopenia Virus in Cats
Symptoms and Types of FPV in Cats
Read more on FPV here.
Rabies in Dogs
**The information in this section has been obtained by information on the PETMD website. For more information on these diseases or any other health concerns you may have regarding your pet, there is more information available on their website.
|Services & Fees
Adoptions - Adoption fee includes: rabies vaccine, license, spay/neuter deposit, microchip/registration (cats
do not require licensure per Arizona state law, license fee is waived on cats; microchipping is optional for cats only when adopting).
Licenses - Licenses are valid for one (1) year, you must renew and buy a new tag every year, even if you have the three year rabies vaccine, you still need a new license every year. If you are late renewing, you could face a penalty fee adding to the normal cost of the license. Penalties do add together the longer you wait. To renew your license online, click here.
Impound - If your animal is picked up and brought to the shelter there are fees associated with that, you must pay to get your animal back. If your animal is licensed and has current tags on, it will save you money considerably. Always keep your animals current on their vaccines and licenses, it is ordered by law. If your animal is a repeat offender and continually is picked up, the impound offense goes up in price each time.
Click here to view or print a copy of our 2017 price list.
Other Services/Fees
**Note regarding recovery fee: (Fee added when you reclaim your animal from our facility and opt to not have the animal spayed/neutered


text:
David comes from the humanitarian sector, providing technical services for non-profit crisis-response agencies in the developing world. He has completed his master's degree in Geographic Information Systems and has been working for an international NGO.
David is pivoting to offer his operations and engineering skillset to the facilitation of healing retreats to those who may benefit. A decision from the heart!
15 years ago, David suffered a major life-crisis. Psilocybin mushrooms (then legal in Ireland!) played a huge part in his recovery and allowed him to move past old destructive patterns of thinking and experience divine connection to nature.
David has since been exploring the remarkable healing potential of these organisms and has gained the experience to facilitate other's access to this natural medicine.
The Wounded Healer
He is currently in his 3rd year of training as a Transpersonal Therapist at ICSS Dunderry Park. David has counselled many people using these effective techniques and has facilitated group journeys.
David is a passionate advocate of psilocybin mushrooms as master healers. He runs the community website Shrooms.ie to organise events and campaign for an end to psilocybin prohibition in Ireland.
- MSc GIS, University of Leeds
- BA (MOD) ICT, Trinity College Dublin
- 15 years experience with psilocybin medicine
- 15 years training experience with Tai Chi & Qi Gong
- Diploma in Psychotropic Plants
- Diploma in Medicinal Herbs
- Certificate in Shamanic Practice, Dunderry Park, Ireland
- Certificate in Shamanic Counselling, Dunderry Park, Ireland
- Certificate in Sustainable Development, Columbia University, USA
- Certificate in Peace Studies, Tamera, Portugal
- Certificate in Permaculture Design, Permaculture Institute of Turkey
- Certificate in Working with the Patterns of Nature, Schumacher College, UK
- Certificate in Leaders in Global Development, University of Queensland
- Founder, Shrooms.ie
Events with David McNamara
September 20, 2019
5-Day Psychedelic Retreat Our September 2019 retreat takes place in the heart of the Veluwe national park in the Netherlands. The retreat centre consists of 3 houses and has a hot tub, a pond for swimming and lovely walks in the surrounding forest. The autumn retreat will take full advantage of the remaining good weather with plenty of opportunities for outdoor activities and eco-therapy. The gathering will be energising, joyful and will provide the perfect container for a healing and nourishing group journey. During the 5-day retreat we will have 2 sessions with psilocybin truffles, complemented by a range of activities and…


text:
No image found
|List of names as written
|Various modes of spelling
|Authorities for spelling
|Description remarks
|Walk Hill
Walk Hill
Walk Hill
Waugh Hill
Waulk Hill
For other modes of spelling See Page 38
|Mr John BlackMr William McMurdoch
Mr John Douglas
Stat Acc. [Statistical Account] of Dumfries
Johnstone's Co. [County] Map
|[Situation] On the South-western Parish Boundary near the Centre of the range of Keir Hills. A hill of considerable eminence, being the highest of a small range stretching from east to west through the Parish of Keir, and on the culminating point of which Stands a Trigonometrical Station. This is the most Considerable elevation in the range of Keir Hills and is supposed to be betwixt 800 and 900 feet above sea level.
|Barjarg Moor
Barjarg Moor
Barjarg Moor
|W Arundell Esq
Mr John Douglas
Mr William McMurdoch
|031; 040
|[Situation] On the western side of the Parish. An open heathy moor of considerable extent forming part of the estate of Barjarg.
Continued entries/extra info[Page] 53
Ph. [Parish] of Keir Plan 31.13 Traces 1&2
Transcriber's notesReferring to "Wauk Hill" is the note "Wauk or Walk -to watch" Jamieson's Sc Dict. [Scottish Dictionary]
Transcribers who have contributed to this page.
Location information for this page.


text:
Call us: M-F 8am-8pm ET 800-926-6100
Sealed Air
Bubble Pouches | Bubble Wrap Bags
Bubble Roll Stock
Instapak Quick Foam Packaging System
Korrvu Packaging
Padded Packaging
Poly Foam Roll Stock
Tough, silver high-density film is laminated to cohesive foam. Resists punctures and tears, and will not harm delicate surfaces. Press edges together to seal. Test surface to ensure that material lifts off cleanly following application. No tape or staples needed. Rolls are perforated every 6".


text:
Monthly Archives: November 2010
one of our best investments
i was a little amused by his enthusiasm the day mike excitedly told me that he had ordered a juicer from amazon, but this is seriously one of the best purchases he's ever made! it is so fun to make … Continue reading
Posted in Cooking Tagged cooking, fruit, juice, juicer, vegetables Leave a comment
let them eat cake!
i had plenty of chopped apples leftover after making apple pie, so i decided to make an apple cake with homemade caramel glaze. it turned out great! very moist, just the right proportion of apples, and the caramel glaze was … Continue reading
Posted in Baking Tagged apple, apple cake, baking, cake, dessert Leave a comment
the month of the pumpkin has ended. the month of the apple has begun!
well, i'd say i had my share of pumpkin in october. it's november now, so i've moved on to apple goodies!!! surprisingly, i have never made an apple pie. jeff and jodi are on their way from madison for a … Continue reading


text:
NEW homes builder Bellway West Midlands is hosting an Easter extravaganza this bank holiday weekend with children's colouring competitions and an Easter egg incentive for homebuyers.
Anyone who reserves a property at any of Bellway's developments across the region will be given an Easter egg containing a voucher for either a plasma screen TV, fridge/freezer, dishwasher or washer/dryer.
The seasonal offer will benefit the scores of homebuyers who traditionally take advantage of the long bank holiday weekend to choose a new property.
Kathryn Robinson, Bellway sales adviser, said: "Easter is usually an extremely busy time for anyone involved in the property market.
"With an additional day off either side of the weekend, it's always been a popular time for property seekers to view potential new homes and make decisions, so we're gearing up for a busy four days.
"Parents also take this as a good opportunity to bring the kids along and get their reactions to any potential new home, so it's a lively time in the property calendar.
"We're all set for a bumper Easter weekend and I think all the family will enjoy spending a bit of their bank holiday break with Bellway."
Bellway West Midlands has developments spanning the region including Coventry, offering a range of innovative house-types from high specification apartments to detached family homes.
For more information on the latest home designs and developments from Bellway West Midlands, call 01827 255755 or visit www.bellway.co.uk.


text:
It's not 2009 anymore. DTC software is modernizing. Re-watch our livestream of the key features for personalization, engagement and insights and how they are transforming the DTC experience.
Deliver the right content at the right time (both online and via email). Find out how personalization is impacting the customer experience, especially when it comes to the club.
Engage with the right customer in the right context. Find out how better online and wine club engagement can increase retention.
A first look at some of the DTC insights you can gain through leveraging your data.
Access a 30-day free trial, or get a demo from one of our sales associates.


text:
Youth Movement in Full Swing For Rams
Life wasn't exactly glitz and glamor in La La Land in 2016. Sure, the Rams came back home after more than two decades in St. Louis but that is about the only positive to take away for Los Angeles residents. The Rams went 4-12, Jared Goff looked downright awful, Todd Gurley looked anything but the All-Pro he was in his rookie campaign and Jeff Fisher was manning the sideline.
The biggest positive heading into the new season is Sean McVay, an offensive wunderkind who became the youngest head coach in NFL history and runs an offense that looks like it is part of the 21st century. McVay also brought in defensive coordinator Wade Phillips to fix a defense that has yet to become more than the sum of its parts.
The organization made several smart decisions by bringing Andrew Whitworth to fill in at left tackle and Sammy Watkins at receiver. The massive issue right now is Aaron Donald. The best defensive player in the NFL is a holdout and is looking to get paid heading into the final year of his rookie contract. If I'm the Rams, I pay Donald big because you can only imagine how amazing he will be now that he has an expert in Phillips calling the plays.
This team will likely go as far as Goff and Gurley will carry it but nobody has delusions about 2017. The Rams are still rebuilding and are just working toward developing their young talent more than winning right now.
So, without further ado, here is a look at the Rams futures heading into the new NFL season:
Super Bowl: +15,000
This isn't happening. The Rams have intriguing pieces but basically every player on the team would need to make massive strides and McVay would need to basically become the greatest rookie head coach ever.
Hell, the Rams haven't made the playoffs since 2004 and haven't had a winning record since 2003. This team needs to set realistic goals and competing for a Super Bowl any time soon is not one of them.
NFC West: +1200
The last time the Rams won the NFC West was 2003. That roster featured Marc Bulger at quarterback, Torry Holt having the most prolific season of a stellar career and Leonard Little wreaking havoc on opposing QBs.
Now that we are done with the history lesson, if you try really hard you can make a case for the Rams to win the division. The team is loaded with potential on offense and the coaching staff has the talent to conceivably be one of the better ones in the NFL. But Goff has yet to prove that he can be even an average quarterback in the NFL – though that is largely the fault of Fisher's horribly antiquated offensive system last season – and Gurley needs to see the field much better than he did in his sophomore campaign.
To put the final nail in this coffin, the NFC West is also home to the Seattle Seahawks and Arizona Cardinals, two franchises that are in a much better position to win now. If things work out well for the Rams, then they should be able to compete for the division title by the time they move to their new stadium (eventually).
Win Total: 5.5
There is absolutely no chance that the Rams are worse than last season. LA went 1-11 in its final 12 games last season and had the worst offense in football. McVay should be able to get this team out of the basement in that regard and Phillips will inherit a defense that was actually one of the better ones in the NFL.
The Rams will be much more competitive in 2017 but translating that to wins isn't going to be easy with the schedule they have. Of the 13 teams on the Rams schedule this season, only three finished last year worse than 7-9. After last season and a completely revamped coaching staff, it's hard to make predictions in terms of concrete wins for the Rams in 2017. With this schedule, it appears the Rams are going to max out at six wins but it wouldn't shock me if they ended up with fewer.
Jared Goff To Lead NFL In Interceptions: +650
I was going to reserve this section for doting on Aaron Donald but now that the Rams organization is managing to screw up one of the few bright spots on the roster, bettors should look elsewhere. However, if the Rams can get Donald back on the field before the regular season begins, I'll be betting him to win the defensive player of the year award at +1400.
Instead, we are going to be telling you not to bet on Goff to lead the NFL in interceptions. Bettors might convince themselves there is value here but even in a dismal rookie campaign, Goff averaged just one interception per start. Assuming he kept up that pace and didn't improve at all in his sophomore year, Goff would register 16 interceptions in 2017. Since the 2000 season, the leader in interceptions thrown has tossed at least 20 picks in 14 seasons.
Yes, Goff will likely be throwing more in 2017 than he did in 2016 but McVay's offensive system will allow him more opportunities to make better throws. Goff is at his best when he is given time and can sling the ball up the field and McVay's scheme will see receivers and tight ends run a lot of downfield routes to exploit coverages. Plus, the Rams have the players to, theoretically, run these routes without too much of an issue.
There is room on the Goff bandwagon but I would get on now.
|Super Bowl
|NFC Championship
|NFC West
|Win Total
Odds as of August 21 at Bovada


text:
American Transmissions & Auto Repair
1301 Ranger Hwy.
Weatherford, TX 76086
1301 Ranger Hwy, Weatherford, TX 76086
Specializing in
Lexus Scheduled Maintenance Service Center
With over 20 years of experience, American Transmissions & Auto Repair in Weatherford TX has the expertise to keep your Lexus running at its optimal level of performance. Our staff of certified service technicians use state of the art computer automotive diagnostic software and special tools to determine what is wrong with and how to repair your Lexus.
The Joe's Pit Stop Transmission Scan and Protect Check Services are a systematic and comprehensive external evaluation of the overall performance and condition of your vehicle. We are proud to say that we have serviced the DFW region for over 20 years. As a member of both the Better Business Bureau and Chamber of Commerce, we are committed to quality work and customer service.
We can repair/rebuild both manual and automatic transmissions back to Lexus factory specifications.
We are capable of working the following Lexus vehicles: ES300, ES330, GS300, GS350, GS400, GS430, GS460, GX470, IS250, IS300, IS350, LS400, LS430, LS460, LX450, LX470, LX570, RX300, RX330, RX350, SC300, SC400, and SC430.
Whether you are looking for normal factory maintenance to be performed on Lexus, a check engine light to be diagnosed, or a transmission issue to be resolved, we have made it our mission to be YOUR one stop shop.
Lexus Services Provided:
Call us today to schedule an appointment!
|Diesel Engine Service
|Tune Ups
|Air & Heating Systems
|Brake Repair
|Radiator Repair
|Lincoln Scheduled Maintenance
|Infinity Scheduled Maintenance
|Audi Scheduled Maintenance
|Volvo Scheduled Maintenance
|Mini Cooper Scheduled Maintenance
|Jaguar Scheduled Maintenance
|Land Rover Scheduled Maintenance
|Lexus Scheduled Maintenance
|BMW Scheduled Maintenance
|Cadillac Scheduled Maintenance
|Mercedes Scheduled Maintenance