Tag Info

Hot answers tagged

80

You need a proper Quality Assurance (QA) process. In a professional software development team, you don't push from development right to production. You have at least three separate environments: development, staging and production. When you think that you got something working in your development environment, you push to staging first, where each commit is ...


47

You will probably want to get a dev server, and preferably a staging environment too. Nobody should ever be pushing from local to production except for their own personal website. Your deploy process should only support dev->staging->prod. You probably want someone responsible for signing off new releases - depending on the organisation, this can be a ...


44

You almost certainly want a new repository. The purpose of the repository is: to track history and changes so you can compare them easily to manage branches and merges rather than just emailing patch files around and applying them to working directories manually If you're totally rewriting a project from scratch then there is no point putting the ...


17

At work, we avoid this by using Gerrit. Gerrit is a code review system that acts as a gate to your main/production Git branch which is conventionally called "master". You have code reviews, right? It sounds like you personally do them exceptionally. With Gerrit, you push to a sort of staging branch which, after you and your coworker have executed the code ...


16

I see this as a largely human problem - the process is there and the tools are there, but the process is just not being followed. I agree with what others have said here, about the possibility that it's quite possible the developer in question is just stuck in an SVN mindset, and may well think that he is following the process. I find that the best way to ...


16

I always put rewrites in new repositories myself. That way the builds, tests, and deployments can all be done independently. When you're rewriting a project in another language there's often very little similarity in any of those tasks like building, running tests, and deploying. You'll save yourself pain if you just isolate them in their own repository. ...


7

This is not uncommon, particularly in small teams. Don't make a big deal about it, but make an informal rule: Break the build, bring in donuts. Either 1) You'll get donuts twice a week or 2) they will adhere to the standard. Bring it up in a meeting. Not accusingly, don't mention anyone by name, but something similar to, "Since we introduced version ...


7

Now, how can I force them... Instead of forcing your colleagues, try making them see things from your perspective. This will make things much easier for everyone. Which leads me into... I want this behavior to be punished in some way or make it unpleasant as much as possible. Why is it a pain for you with problems on the live server, but not for ...


6

Yes it does affect other contributers. Changing author name will result in a rewrite of the history. This is because the author name is used while calculating the SHA-1 hash for your commit. For further you can see this page from github Regarding Bart van Ingen Schenau comment how to change the username for furture commits you can do the following(thanks ...


5

What's the worst that could happen? Do you have backups that are good enough so that a bug modifying random records in your database can be fixed by restoring an old version? Let's say you have a bug where you use a record id, and by mistake the amount of a bill in cents is stored in a variable used for the record id. So if I pay $12.34 then the record ...


5

If your systems are sufficiently modular and link compatible, you would benefit from a single repository and build. For example, if C system is being rewritten in C++, the C++ code could call existing functionality and incrementally replace it. However, even in this case some might argue for starting a new repo in which relevant old code is pulled in as ...


4

I would go with a modified version of scenario 1. Instead of adding your real configuration file to the repo, add a prototype config file. When the widget first runs, it detects if the config file is present or not. If not present, it renames the prototype file and then loads it. The prototype file can have sane default values (might no "work" but don't ...


3

It's not about how many commits, and not about how many features either. It's about when you want to make a release. You merge to master when you want to stick a version number to the current state of the project and let your users upgrade(actually, according to formal git-flow you need a release branch for that - but that's usually an overkill for small ...


3

So the idea is: If I check out your git repository, I get a config file template, where I need to fill in the proper values, and you cannot know what the correct values would be for me. In that case, your config file should obviously have plenty of documentation, and building / running the project should fail as early as possible for me if I don't make the ...


3

Run your unit tests on every branch. How do you know your code is actually working as expected otherwise? This goes the same for any other tests you may have. You say it yourself right here, "If they only run on the develop branch and a feature branch going on for long, I am afraid that the developer is pushing changes to his feature branch which would ...


3

You clearly understand various possible process and technical solutions. The issue is how to manage the coworker. This is essentially a change management exercise. Firstly, I'd have a quiet word with the founder to make sure he/she is on board with your point of view. If there is a production outage, I would expect that the founder would be highly ...


3

Has anyone encountered difficulties due to broken historical commits in master? Yes. Backports, reverts and bisects are harder. So is reading the history (see below). If so, is there a simple way to avoid such difficulties, without discarding individual commit messages and changes? Not that I know, although branches are a decent solution. ...


2

No, it's not okay. If you ever did a git bisect (and who doesn't love that killer feature), you know the value of a history where every commit builds. If you have many commits during a bisect that don't build, you'll have lots of git bisect skips that make it difficult to find the last good commit. If you finish a feature branch and merge it into ...


2

The main problem you are going to face is that when you are combining the feature branches to a release branch, you'll need to solve all the inter-branch conflicts. Merge conflicts are the easier ones, since they pop when you are merging specific branches and you can ask the branch owner to solve them(it's far from ideal though, since the branch is not fresh ...


2

I would much rather have a workflow where people clone the repository, create their own branch, make changes and commit them Absolutely they should - in my mind this is the reason for a distributed version control. If they lack confidence in the tools, a little practice should take care of that. We're working with one branch I'm sure this is a ...


1

A couple of suggestions that might make this easier to handle by changing your project structure a bit. First, you are right that managing this in three different repos is probably too much work. Generally I have found that splitting different software components that all seem to make sense to a general project by folder in a repo is a good way to ...


1

I don't see any process to merge the RC or Master branches back into the working branches (Bug###, Task###, etc). This is fine, as long as each Bug/Task make minor changes to Support/Sprint branches and are not affected by the other ones. You want branch drift to be low. You don't want to merge other changes into the task/bug branches, which means these ...


1

My first thought is: Don't store the populated config file in git at all. Put the unpopulated file in git and on installation or first run, create the populated file in another place. If the configuration is user specific, this other place would be in: Windows: %APPDATA% Linux: a dot file or a dot folder in the user's home directory. Something like ...


1

Should unit tests run on every git branch? This one is an easy one. The main point of doing continuous integration is to detect errors as early as possible in the build process. From this it should be clear, that you should a) run a testsuite on every branch of your code b) do not allow checking in code, which neither runs nor passes all tests ...


1

I think you've identified a couple of problems: It sounds like any code that gets checked can be trivially pushed to production by anyone who has the rights to check in code. Frankly I think that setup is just insane. At a minimum the people who can manually trigger a push to production should be restricted to the set of people who can be trusted ...


1

The requirements Following points are important to be considered when you are thinking of spliting the repository. Each new split has it's own trunk now. Each product cann't just be another branch in this case, because now each of these products will have their own versions (tags), their own dev branches and hence they all must have their own trunks ...


1

Short Answer: Yes Testing: Test driven development means you write tests that break (ie show failing). Then you write the code to make the tests work. Development: Commit small, Commit often. Each commit is a rollback point. If you realize you are on the wrong path you can rollback to a previous point relatively easily. If you are commits are fine grain ...



Only top voted, non community-wiki answers of a minimum length are eligible