New answers tagged

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


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


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


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


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


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


0

You group commits in branches: each branch is a set of commits. When you merge commits, you are putting one set of commits inside another branch, effectively building a hierarchy of commits: main branch, features, bugs, experiments, you name it. Ideally, your main branch is a succession of merge commits. If you only look at first-parents (git commands ...


0

I had the same issue thinking about this until I discovered that Git numbers its parent branches. Given this, the usually annoying merge commits that are generated can be considered summary nodes. And all extra details can be banished from view, leaving a single, summarized linear history. Check this blog post for details and examples.


0

I run in the same question as yours and here is my way to apply git: for each project folder inside the solution folder, I initialize the git repository. for the solution folder, I also initialize the git repository and add project folders into the .gitignore file of the solution repository. Although I have commit each project and the whole outside ...


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


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


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

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


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


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


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


0

To my understanding (and correct me if I am wrong - sorry for the recursion): No, only for the current branch Selects branch Git is tree-like in nature, but the main purpose is to progress back to the Master - which is the trunk of the tree. What is likely happening is that you overwrite the local files when running make. Read more here.



Top 50 recent answers are included