Tag Info

New answers tagged

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


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 ...


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 ...


9

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 ...


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

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 ...


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 ...


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 ...


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 ...


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 ...


4

Assuming that this snippet of code x=0 x+=1 if foo x+=1 if bar return x has been changed in one branch into this x=0 x+=1 if foo && xyzzy x+=1 if bar return x and in another branch into this x=0 x+=1 if foo x+=1 if bar && xyzzy return x then I would not want git to merge it into this x=0 x+=1 if foo && xyzzy x+=1 if bar ...


1

Whether its window or unix, git mv basically combines three actions: a file system move a git delete of the original file a git add of the new file. So, without git rm, one might do (this is Unix/OSX but the steps are similar in windows unless using cygwin terminal emulator and then u probably can): $ mv newfile movedfile $ git status On branch master ...


3

If you move the file in Windows Explorer, you still have to git add the new file location and git rm (or git add --all) the old file location. Once those two things are done, git will work out on its own that the new file is mostly identical to the old file, and will automatically display it as a move in commands like git status. The benefit of git mv is ...


0

I would roll back to a version where the CSS works, copy the CSS, go to the version I was working on, and use the CSS that is correct. Forget about the whole forensic analysis. Don't loose time in things that are not worth it. If it happens again, you have an issue that have to look for and fix.


2

Git has features like blame and bisect that should make this job relatively easy. Chances are, it was just a mistake, but it could have been an unintended side effect of fixing another problem, or even an intentional trade off. If you don't know what that other problem is, there's a good chance you will cause it again. There are few things more annoying ...


3

I am not familiar with plugin development at all. However, where your code is in the source control and how you present it to either browser can be separated by adding a build step. With that model: you have a single branch of development (you could have multiple, but you don't need to) your source is wherever you like it to be two distinct build steps ...


2

You might be trying to use git to handle a situation it was not intended to[citation needed], maybe a build script might be the answer. If Chrome is flexible with the folder structure, you could just follow the folder structure required by Firefox. Have one branch for Chrome and another for Firefox to handle the distinct files, then later do a merged by a ...


5

The good schedule is to merge only stable code (or "likely to be stable" code). If you merge half-way just to begin tests, and you know that some of the features you're currently coding are not finished, you surely will get some testing feedback about these features. The question you have to ask is "Am I confident with the completeness of what I already ...


-1

Some questions to help you determine if it is okay to commit non-working code: Are you being over-worked? Do your team mates constantly break the build? Is your code base a mess and seemingly can't get any worse? If you say yes to any of the above, then yes it's okay to commit non-working code. Just remember to fix it as soon as possible, cover it with ...


3

Facebook is actually in the process of implementing server side rebasing (there's a summary here or you can skip to to about 10:55 in the video). In their case they have such a volume of pushes that developers are in competition to push, and they can get stuck trying to pull then push before someone else pushes and forces them to pull again. By ...


4

The basic idea behind merging is that you have to consider resolving conflicts. You cannot just automatically merge and hope the system figured out what you meant - that is mostly does this is convenient but do not get confused and think that all merges work perfectly all the time. After merging, you will want to review the results and only if it passes the ...


3

I can see your dilemma. I had it too, until I unlearned what I always assumed about master. I was taught you want to keep master deployable and not use it as development and from previous places where I've worked master is always meant to be deployable for production. From Git's documentation / book - Git branching The “master” branch in Git is ...


4

There are neither any advantages nor disadvantages to this approach. The reason I say this is simple: to Git, it makes no difference if you develop from master or release from master. You don't even need to release branches; you could tag an arbitrary commit and release that, instead. The real trouble here is one of process and procedure. The more ...


0

It all depends on the overall software development process. Configuration management and how a new version comes to be cannot be defined without knowing about the overall process. There is the "agile" faction who would opt for a "always working first commit area". They would run automated build and test facilities constantly against that area and try to ...


2

I prefer checks over conventions in this case. Every team contains member who are better at getting new features started and other people who are better at stabilizing things for a release. If you lack the latter, then code reviews will help (often, the more disciplined people will want code reviews anyway). That's why we configure our Git repo (we're ...


0

While I have not used this method in production I have been looking at using git to deploy code to our prod server. The basics is that you set up a bare git repo on any server you want to deploy to and then add that as a remote to another repository. When you are ready to deploy you just push your code to the remote repository. From my research I am ...


4

The new Branch wont interfere on the master branch You should leave it there and keep writing and commit on the master branch



Top 50 recent answers are included