Hot answers tagged

31

It'll work, but certain config variables won't travel with you. Git has three levels of configuration: system-wide (all users on a PC), global (user-specific) and repo-specific. The repo-specific configs will move around with your repo; the sytem and global configs won't. I'd check your config files and if necessary also grab a copy of your user-specific ...


25

The best way is to add a remote (even though it's a local folder). In this way you can always transfer commits between the two. When you want to move git init /mnt/usb/repo git remote add usb /mnt/usb/repo git push usb master The last command can be used to push any branches into the folder as desired. If the local branch has no remote currently set ...


8

When working locally commit when: You add a new test case. Your tests pass. You've made any change that works, no matter how insignificant. Renamed a variable? Commit it. Extracted a method? Commit it. Inverted a condition? Commit it. Basically, anytime the code compiles. Then, prior to pushing it to a shared repository, squash the commits into ...


7

First of all, your current approach seems perfectly valid. Working from several systems (I understand here several PCs in different places, or eventually different OS compiling the same sources) doesn't change the fact that you still work on the same piece of software. So this should not not be the major influencer of your branching strategy. However, ...


6

I feel that this is overkill for a single person working on a single web application. I would use tags to give version numbers to versions you release to the production server. The staging server can just use the latest commit on master, whereas production uses a tag. Have a "release" script that updates files with the new release number, commits them, ...


4

Use a branch, this is exactly what branches are designed for. On the other hand, starting on a new dev branch seems less-than-ideal, because I will have to .gitignore a lot of untracked files from the old version to be able to easily switch between the two versions. One possibility would be to have a branch in the GitHub repository, but clone that ...


4

It's not a git problem at all. In fact, it has nothing to do with Git or even a program you're trying to install. It's just a version conflict. To solve this type of problems, there are many possible approaches: Installing each version in a separate virtual machine ... in a separate Docker containers Using smart package managers like nix which would allow ...


4

Yes, this is a common workflow. The popular gitflow workflow has a separate development branch, for instance. Different teams uses different workflows. Which stems from different team compositions. Workflows that works for open source project with large number of external contributors may not necessarily work for internal company project or for personal ...


3

One principle of Git is commit early, commit often. You want to commit whenever you made any tangible progress you are not sure you would regret losing suddenly. If you feel that this results in your git history to end up with too many meaningless commits with vague commit messages, you can squash these commits into one before you push them to the main ...


2

Rule of thumb: Use as few branches as possible, and as many branches as necessary. If a branch is necessary or not is something you mostly learn from experience, but when in doubt: don't branch. The reason for this is branching hell. You need branches when you need to modify the same code at the same time in 2 different ways, for example when you release ...


2

According to GNOME commit style guideline, the first line should of the commit message be a short description (ideally no more than 72 characters) and it should not end up with a full stop. In summary: First line (the brief description) must only be one sentence and should start with a capital letter unless it starts with a lowercase symbol or ...


1

Maybe just use two folders old and new side by side. Since the new version appears to be completely source code incompatible you would not have any useful merge result anyway. It sounds like at some point you are going to just delete the old code and use the new code going forward. Create an empty orphan branch This is very comparable to the two ...


1

I think you are confusing Minor version and Patch version. From http://semver.org/ : Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. This leads ...


1

This is why I have started to commit at the end of the work on the component I'm working on. This means I could do changes without the head-ache of correcting previous commit. In my opinion, this can be a big mistake if you are working in a team. It's a particularly big mistake when one works part time on task A, part time on task B, part time on task C, ...


1

Don't think too much about Pip. If your Setuptools configuration works correctly, it's easy enough to upload all and only those files you actually want to PyPI (at which point end users will be able to install it with Pip; developers will be cloning your git repository since they need history for things like git bisect to work, and Pip does not provide git ...


1

For a small team of 2-3 developers it's okay to use branching on the repo to manage fixes and features. The issue is when you have more developers than that and more features and fixes that are being developed. When that is the case, your main repo in Github will have hundreds of branches; some will be old and forgotten and unmerged. You will also have ...



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