3

Just curious as to what the general consensus is for committing code of GitHub.

Should you commit only build-able code? Or is there a time when unbuildable code commits have their place?

Or am I totally miss-understanding GitHub completely? If so, please inform me how it should be?

KyloRen
  • 2,691
  • 5
  • 29
  • 59
  • Your repository/code, your rules. Someone else's repo, their rules. In many cases, for my own repositories, I commit to github to have it as a backup of my local code (even if it does not even compile, let alone build into an artifact) - when working on someone else's repository I follow their rules. In either case, I always work on branches merging into master only when the code is ready (compiles, builds, etc.) – blurfus Jul 28 '17 at 14:48

4 Answers4

3

If the master needs to stay buildable, I recommend that you make a branch, and merge the branch only when the code is working as intended.

Gustavo Magalhães
  • 330
  • 3
  • 17
3

GitHub is a place for sharing your code to everyone, it's your wish if you want to make it public for everyone to use or contribute or keep it private. There are so many advantages in uploading code to GitHub :
1> Others can look at your code for reference and can also contribute to it
2> It keeps all your coding records with history so you can show them to your company when you apply for a job

yes, you can also upload unbuildable code and open an issue and wait for anyone else to fix it. and it's a good practice to keep 2 branches one for buildable code (master branch) and another test branch for testing stuff

rohit negi
  • 56
  • 1
  • 6
2

In general for git, the master branch is reserved for only buildable features. Other branches can be reserved for in-progress features to be later merged into the master branch once completed and tested. GitHub, for the most part, follows these rules too.

To me, it really depends on the kind of project you are working on:

  1. If the commit is for a private project, (and therefore probably has little following) you can do what you want
  2. If the commit is for a highly visited project, maybe think twice before submitting unbuildable code without making a note in the commit message that it is unbuildable

As always, if you own the repo, you can follow any rules you like, but if it is owned by another individual, be sure to follow the rules that they set out for the repo.

ifconfig
  • 6,242
  • 7
  • 41
  • 65
2

It just depends. Some argue that all commits should compile or be "build-able", but IMO that defeats the purpose of frequent commits.

Typically, when I'm developing a project my rule of thumb is commit after 20 minutes or so of developing, and push every hour or when I finish the branch/feature I was working on. So if you are working on a project individually, then committing with issues in your code may not raise any problems. Committing frequently is the whole purpose of version control applications like Git, and you have the ability to go back to any previous versions whenever you like. If you are working on a project with a team there may be some guidelines as to when you commit/push, so make sure to check with your team if that is the case. Check out What are the differences between "git commit" and "git push"? if you are trying to better understand Github.

TEK
  • 125
  • 10