Tag Info

Hot answers tagged

31

Committing code is cheap in git. You have several options: Commit and amend later $ git commit --all -m "WIP: half-implemented hack" ... time passes ... $ # back to work $ git commit --all --amend -m "Nice logical atomic commit" Use git stash Same as above, but using a stash: Commands are a little shorter to write A stash by nature ...


10

Commit away. Commit as often as possible. Commit when its incomplete, commit when its finished. It really doesn't matter. I even will commit and push to remote when I get up for a 1 hour meeting or lunch even... The catch is you need to be in your own branch (one that no one else will be pulling from). This should be a part of your normal development cycle ...


6

When releasing a new version of a program is it better to include the full changelog since the beginning of the project or just the part since the last release? Neither. Only provide the relevant, bigger changes that an end user is going to care about. No one cares about the fact that you refactored class Foo so that it can be re-used a bit more ...


5

The concept of committing the code when it reached a 'milestone' is mostly due to, other developers/testers should be able to checkout the latest version without fearing that they can't compile / debug the code because it's broken. When it comes to the distributed version control systems like Git, there is no such issue when checking in the code as it's ...


5

I say that not only you may commit unfinished changes when you need to stop working on it - you probably should do it. When you have to leave a task for a long time, always assume that you are going to "context-switch" by the time you're back. Now, if you are just going to make a coffee - or even take a launch break - you should be fine, but if you leave the ...


4

Don't add any outside contributor right away - make them send pull requests instead. As you review these pull requests, you can: Assess the skill of the contributor from the quality of their code Verify that what they want to add to the project is compatible with your vision See how willing they are to conform to your rules and style Learn to know them a ...


4

Your question really depends on quite a few things: Code Base complexity, change complexity, people working on code base, people affected by your change, etc. I personally avoid committing unfinished business, even if that means not committing for a few days (Many people will disagree here). And it certainly is good to stay "connected". So in light of all ...


4

A local commit can always be safely amended if it hasn't yet been pushed upstream, so you could commit at the end of the day and take it up again the next. However, this is of limited utility as far as code sharing and redundancy are concerned, unless working on a branch that's yours alone. In that case, you've got the right to push one day and force an ...


3

I propose looking into in code migrations for your language or technology. I have .NET stack and I can use Entity Framework Migrations where every schema change is single migration that can be automatically applied to database when needed. What is also possible is downgrading database, so pattern for db migration is that you have method for Up() and Down() ...


2

The approach that I follow is based on the following premises: Developers are not to be bothered with production data. That's for the operations department to worry about. Configuration xml files, scripts, etc must be kept at a minimum. Everything must be in the source code repository. The source code repository is to contain only diff-able text files, ...


2

The issue you are encountering is weird. You may check twice the way NuGet dependencies are stored in source control. What may help is: To use one solution instead of several ones. Unless there are multiple teams in different departments of your company working on completely independent projects with a dependency on a common project, one solution may make ...


2

Often you have files which appear in your project directory which you don't want to have in your git repository. For example files the software reads and writes in its own directory as part of its operation. That's why git doesn't blindly index everything in the project directory but instead asks you to add files manually. Also, any binary files should ...


2

Generally speaking, a software project is a collection of code, data and tests. Typically these should all live in the same repository. Using BDD or TDD means simply to check in (or at least develop) your tests before developing your code. It doesn't have to be any more complicated than that. So, the reason why no specialized workflow has been created is ...


1

Honestly, this doesn't sound like something your VCS should care about. Your VCS should only care about the storage of, revisions to and merging of changes to your source code. The idea of a wishlist of features doesn't fit with any of those things. A wishlist of features is the domain of a product backlog (or something similar). Stakeholders can file new ...


1

so your problem is that you're merging every hot fix two or three times? (First to master, then to develop, lastly from develop to master again)? yeah, that's it! Can't avoid that though, hotfixes have to be merged into develop Sure, but why merge from develop to master if nothing actually changed? Take a look at one of those ...


1

You need to have some kind of version control system. You MUST have it. If git looks too complex try mercurial, even thought they are very similar. Set up a git repository server. My team uses gitlab and it works fine. You need to put some rules for the control versioning. Meaning, ideally not all cannot commit to the main branch for example. You should ...


1

Something to consider, are you using distributed version control or centralized? (Edit: I realize this was tagged as git, but I still feel there's relevant information about deciding when to commit in my post.) If it's on your local machine or your own personal branch then do what feel right, but I'd still lean towards to following below. At my job we use ...


1

It all depends on the meaning of "check in". With git, you can have a private repository, so checking in is nothing more than a personal backup. I make a small change, it works so far, I check it in. I do some experiment, it doesn't work, or the experiment tells me what I want to know, I cancel the checkout. That means I have to check in when there are ...


1

From what I've observed, different people vary greatly in their commit frequency. Some people make frequent tiny commits, and others make rare big commits. I've seen people not commit until they finished several weeks of work, resulting in one gigantic commit that touches hundreds of files. IMHO, huge commits are a bad idea. I like to think of commits as ...


1

Fogbugz + KilnHg have unlimited private repos in Git / Hg (Actually both at the same time) for free for 1-2 users. It also has good integration into Trello. You can organize repos under projects in it. https://www.fogcreek.com/kiln/try/?fccmp=_startup



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