git poll
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
We all commit to a single master branch, except for the case of big new features where it would be developed in a feature branch. With 150 developers working on the same code base, it wouldn't be feasible to have each one use their own personal branch and create a bottleneck for those tasked with pushing the changes across to master. Another reason we use a single branch is that it helps with integration testing. If we are all pulling up to tip and developing on the current state of the software, we are much more likely to find bugs sooner.
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
It's a very common practice for features to be developed in their own branch, often with a single developer working on each feature. This process ensures incomplete code isn't released to production and allows for peer review through the pull request process.
Eagles may soar, but weasels don't get sucked into jet engines
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Never heard of each developer having a separate branch. If each is working on separate areas, I expect that works fine. But if there's overlap? Welcome to merge hell. We do some local commits when working on an item that requires more than a few days of effort, then merge the local commit back into the central repository when unit testing is passed. In general we try to work on small pieces than can be committed to central after passing unit testing. Frequent merges make the eventual merge conflicts easier to deal with.
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
But since 2 weeks of work from an other developer can drop anytime
This is probably the biggest issue. Having that much work without merging is bad joojoo. Unless people are working on completely separate sections of the project that much work is likely to always cause merge conflicts. Feature branches are one way to go if it's possible. It would be important to me to find a way to section off work so it can be merged in as it's completed if there's no dev branch. Like getting backend code finished and checked in as a "slice" before doing the front end and/or controller part. Any way to get functional chunks of code in without taking 2 weeks to put in huge chunks. That sounds bad man.
Elephant elephant elephant, sunshine sunshine sunshine
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I don't understand how everyone working off of the main branch would even work, that seems ridiculous to me. Topic branches are the standard way of doing things and IMO the best way of doing things. Let's say you and another colleague are tasked with adding a feature, say adding a new window to an app. He starts to work on the view model, and you work on the UI. He finishes a portion of the view model and you want to start testing your UI with it while he finishes the rest. How the heck would you accommodate this without a "feature/new window" branch that you can both push to and pull from? You shouldn't be merging a half-finished view model into the main branch because now everyone else will have a half finished view model when they pull! Or let's say you get sick and need to take a few days off and someone else has to finish up your work...that means: a) they can't because you haven't been pushing code from your local repo to a feature branch in the company repo at the end of each day, or b) he can because you've been pushing incomplete buggy code to the main branch which gets pulled any time anyone pulls the main repo, so now everyone has your half finished code in their code base and has to deal with whatever problems that may cause The way you were using git before and the issues you are having with it now is clearly an organization and management problem. If you guys had someone good at managing distributed projects directing things it would be a world of a difference. I would suggest hiring a consultant who is good at this to help you guys develop a better process. Everyone should be committing many times a day to their local repo, and pushing to the company repo at the end of each day or when they finish something and want to share progress with someone else working on the topic. If the main branch gets some significant updates then you can merge those with the topic branch regularly so that when you finally finish the topic 2 weeks after you started you don't have 2 weeks of merge conflicts to fix all at once, rather you only have to deal with any issues from the last merge you did a day or two ago. Responsibility should be managed such that people working on different topics are extremely unlikely to change the same files. Git is a beautiful thing if used properly, but that requires good management with well thought out processes, discipline on the dev team and well organized code with good separation of concerns.
Blog:
-
In Git, branches are a part of your everyday development process. Git branches are effectively a pointer to a snapshot of your changes. When you want to add a new feature or fix a bug—no matter how big or how small—you spawn a new branch to encapsulate your changes. This makes it harder for unstable code to get merged into the main code base, and it gives you the chance to clean up your future's history before merging it into the main branch. -BitBucket. :) But for smaller changes, that we are very confident of what we are doing, I don't think branching out & merging back is needed?
Full Reset
Rule 1: you never really know what you are doing, so we will come to your office and kill you if you edit directly on the production branch Rule 2: if you think you know what you are doing, please refer to Rule 1.
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
It depends on whether you want to resolve merge conflicts between two branches or merge conflicts between two commits. The best advice I can give you to avoid merge conflicts is to either work alone or re-review your architecture (unlikely to happen). I have worked in both cases, and working on separate branch feels better, since no merge requests are done at the end of the workday and finishing a bug/feature is unlikely to align with the workday schedule. As a result, not everything that goes into the central repository is complete (and tested). So if it is untested, it is better to be on its own branch.
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I guess that is why I could never get my head around "version control" if one was a one man band. A typical "project" includes images, pdf's, text files, utilities, etc. Accumulating over time. I zip everything every day or 2 and create 10 or more generations. Covered most brain fogs.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
Rule 1: you never really know what you are doing, so we will come to your office and kill you if you edit directly on the production branch Rule 2: if you think you know what you are doing, please refer to Rule 1.
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
All features should be on a different branch. If you are getting lots of conflicts then I have to wonder about your project architecture. Are you using something like PrismLibrary to separate out your modules?
-
Current Story: Where I am working now we are using GIT, like many company before. But, and this is a first for me, everyone is working on their own branch and, every now and then people make a pull request to develop to be approved by the lead developer. Of course one should make sure the pull request has no conflict. But since 2 weeks of work from an other developer can drop anytime... despite me merging my branch from develop every morning I am having lots of painful merge conflicts... every few days.... What I wonder: is it common practice to have every developer working on its own branch instead of the whole team working on a common branch?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Plan your work in small units (1 day) if possible. Except where specifically required squash the history of your local branch (`git rebase -i`) down to a single commit. You'll simplify resolution of merge conflicts, keep your features as atomic units, and keep your history clean of junk comments. Your workflow should look something like: pull master -> branch -> commit -> squash -> rebase -> push pull request -> review -> ff merge -> repeat. Commit -> squash -> rebase gets repeated as a whole or individually as needed.