Tag Info

Hot answers tagged

19

You should commit often. But @durron597! I'm a beginner programmer! I don't trust my commits! This is why you are committing on a separate branch! You can even have many branches that you're committing to for your own use, for different fits and starts and experiments and whatnot. Don't worry about big fancy commit messages. The only commit messages that ...


8

There's no way in Git to exclude changes to just part of a file. What you can usually do however is externalise that part of the file to a different config file and then add that other config file to the .gitignore file. That lets each developer customise the config as they require but stops them accidentally checking in their changes and affecting others. ...


6

The problem with force pushing isn't about your feature branch and master, but about pushing your master to someone else's master - that synchronization is going to be overwriting their master with your changes, ignoring whatever is on their tip. Considering this danger, there's a reason why you should not be using it at all unless things have screwed up ...


4

I would commit a new revision (or several) that deletes all files except for a readme.txt containing the new link. Then I'd build a new release containing just that readme.txt (so if they do decide to create a bundled .zip, at least it will contain a link to the new location and not just an old, obsolete version. You can also, helpfully, include details of ...


4

The solution you are looking for is a dependency management tool in coordination with git submodules Tools such as: Maven Ant Composer You can use those tools to define dependencies of a project. You can require a submodule to be at least version > 2.x.x or denote a range of versions that are compatible = 2.2.* or less than a particular version ...


4

Pro and Cons: For: will store different versions over time will still be able to use compression to reduce file size for older versions. will enable different developers to share one code (or asset in this case) base. will make sure any common files stay with 1 version. will track who touches which files. can use the git-fat tool ...


4

It is operating system specific. If your application runs on Linux (so perhaps also on Android), you can use a memory based file system like tmpfs. So git pull (or git clone, etc...) would put it in that FS which sits in virtual memory, and it will run quite fast. However, the bottleneck is probably the network (unless your application is running in some ...


4

Your situation today: Our team uses shared folders (Windows) to work on projects together. We never make local copies, but always edit the files in-place. One Source No versioning No chance to even detect what is called merge conflicts. What you play is »last saved wins« You have to put social constraints like »Okay, we agree never to edit the same ...


3

Rebase isn't essential, as you say it is mostly cosmetic. Sometimes it is a lot simpler then a merge. So it can have some "actual" value, but only "sometimes" Improper use of rebase can be costly. Unlikely to lose data if you know enough to not panic and look up recovery procedures, but "hey nobody push for a while I have to fix ..." isn't great. Nor is ...


3

Git is not very will suited for this as evidenced by the fact that currently at least three different extensions exist to handle this problem git-fat, git-annex, git-media. Svn also have the possibility to only check out only a sub folder of the repository which git was explicitly designed to NOT to do. Since git is distributed all clones must contain all ...


3

There is a fundamental conflict between with the git model and what you are trying to do here. git clone makes a full copy of the repository on your local machine. The idea of git is to keep a complete copy of the repository locally. There is nearly no communication with the server with most commands. The only time there is communication is when you git ...


3

Kind of putting out the obvious here, but maybe worth to mention it. Usually, git repos are tailored per lib/project because they tend to be independent. You update your project, and don't care about the rest. Other projects depending on it will simply update their lib whenever they see fit. However, your case seems highly dependent on correlated ...


3

As the number of users have grown, there is a lot of churn in trunk, and features are often spread out on multiple commits making code review hard to do. Also without branching there is no way to "gate" bad code out, reviews can only be done after it is committed to trunk Moving to git will not solve these problems, they're issues in how you use ...


3

Pick your choice - do you prefer always getting a warning when there might be a potential conflict in the near future since two people are going to edit the same file (Clearcase)? Or do you prefer to get a warning when the VCS detects there is an actual conflict since the two people edited the same source code lines, or lines very near to each other (Git)? ...


2

In one case the person who locks first wins. In the other case the person who is ready to push first wins. Most of the time, the person you want to have precedence is the one who is ready to push. If I have a week left on my new feature, and you are done fixing a bug for today's release, you should have priority on checking in. This leads to a lot of ...


2

First of all, Git is a decentralized VCS (as opposed to ClearCase, which is very centralized: see "What are the basic clearcase concepts every developer should know?") That means, there is no central server to keep track of a "locked" file. Secondly, you generally don't just pull, but you pull --rebase with autostash in order to replay your local (not yet ...


2

I'll describe how this is typically handled in github. However all of that is just code, so it is relevant elsewhere. Really spiffy projects like the ones I run, have tests to make sure everything is working okay. Furthermore, the way cool projects like the ones I work with have some sort of continuous integration. That just means there is a way for some ...


2

I would leave a pointer to the new location. Leaving SF entirely seems not to protect you from bundling your stuff with third-party software, when I read the media reports correctly.


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

You need to read and understand the entire license. Here are a few noteworthy points: Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual... ...no-charge,... ...copyright license to reproduce, prepare Derivative Works... ...and distribute the... ...Derivative Works in ...


1

In my organization, all developers, both junior and senior, submit pull requests that are reviewed by other developers. Just because you are senior doesn't mean you can't make a mistake. But we also don't limit write access to anyone. We trust our people to not force push to master. (And worst case, the git server is backed up.) Just because you are ...


1

It's really no different than any other change. If it's a significant amount of work, run it by the mailing list first. Someone may already be working on it. If it's a trivial amount of work, just do it and submit a pull request with a clear explanation. The worst that will happen is it will get rejected. Deprecation is done for different reasons, and ...


1

What is the best way to set up the initial repository? Should it be done on the GIT server first and then on the local machine or vice versa? Typically this is done by adding a remote after you have created the project and initial project files on your machine. Should the initial master branch be just the skeleton structure for the project and then ...


1

You have changes to commit, but they are based on an old version. That's no good. In any source control system, you can rebase your changes so that they are now based on the current version. That's not automatic, it is work, there might be conflicts, but it's all unavoidable. So far, everything's the same. But because the process of rebasing and retesting ...


1

Christopher did a very good job of enumarating the disadvantages of a one-project-per-repository model. I would like to disucss some of the reasons you might consider a multiple-repository approach. In many environments I have worked in, a multi-reposity approach has been a reasonable solution, but the decision of how many repositories to have, and where ...



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