Working with a team, maybe even inside an organization there's a good chance that there are template projects for different type of projects. If so, I would start with those and create a new projects from the template. If there are no templates, I still prefer to setup the project on GitHub, give it a name, short description - helps to nail the focus of the project - generate with README, gitignore and possibly license.
Once the project exists on GitHub, the rest of the steup depends on how your team agreed to collaborate and work with Git repositories. We have the "main" branch, and create a "development" branch. Then we setup the "development" branch to be the default branch. This avoids accidentially committing to the "main" branch. To prevent committing to "main" directly, we configure it as a protected branch disabling direct commits and force commits, and enabling that PRs may only be merged if certain checks pass.
If you have a CI/CD pipeline, i.e. TravisCI, CircleCI ... there's a good chance that your organization is set up in a way that new repositories are automatically part of the pipeline. For TravisCI the only thing required here is a .travis.yml file at the root of the repository and then builds are automatically triggered when you push to any branch. Our build pipeline is configured to automatically deploy changed on the "development" branch to our staging environment. Changes on the "main" branch will be automatically deployed to production and a release gets created on GitHub using release-it.
But so far, we only created and configured the repository on GitHub. Now it's time to check it out and clone it to our developer machine. I've used Jira with all the teams I've worked with so far. There has always been constent to name the git branch we work on with the Jira ID, i.e. "JIRA-1". After creating the branch, I directly publish it on GitHub. This will trigger the CI/CD pipeline and run build and test scripts on the project, making sure I start with a copy of the repository with successful builds.
We try to commit (not push) often! Anytime a small functionality improves, bug fixed or even just the color of a button was changed we commit. The commit message should describe what was changed/added/removed in a few words. To spice up the messages a bit we use emojis as defined at gitmoji for our commit messages a commit could be :sparkles: edit user profile, or :memo: document data model.
We push at least once a day and don't leave any work dangling between work days. You never know if your development machine breaks over night, gets stolen, or you have an accident on the way home or to work and while you are unharmed your PC/Mac is broken. Another reason for it is, that you may become sick and stay at home the next day(s). If you didn't push your code changes a member of your team cannot take over where you left of the day before.
Once, the (Jira) tasks is complete (code+tests+documentation written/updated!!!) we create a PR on GitHub from the task's branch to the "development" branch. What you write in the PR title, description etc. is up to you and there are articles solely about this topic. In short the title contains the Jira task ID for us, and the title of the Jira task. The body contains a link to the Jira task. If UI changes were involved, we add a before and after screenshot. Not too much description because the way we see it anything you describe in the PR body may belong into proper documentation anyways. If you write to much in the description then check if those parts are missing from the documentation.
Another team member, possibly one you did pair programming with to complete the task, reviews the PR ... Again, details on this part could fill its own blog post. We like the feature in GitHub to comment code lines directly and suggest/ask for changes directly on specific lines of code. In addition, we use DangerCI to automatically comment on PRs. It reminds us to keep the changelog up to date, to increase the version number, to update package-lock.json/yarn.lock and to compliment if the PR is small (not many lines of code changed). Why a small PR? We believe the reviews are faster, more reliable, more enjoyable and contribute to a more stable product if we have more and smallar PRs, rather than few really big ones. Usually the PR reviewer will leave a few comments, asking if the code could be optimized this way or if the other person thought about covering use case XY with a test. While the reviewer leaves comments on the PR, we have to keep in mind that we are still working in one team and not an open source project. Therefore, besides leaving comments we get on a video call together to discuss those topics right away. In our eyes a PR should not be open for longer than one or two days. In the end, the reviewer approves the PR, the author (not the reviewer) merges the PR. Same goes for PRs from the "development" to the "main" branch. PRs can only be merged if the build on the CI/CD pipeline succeeds (tests run, no linter errors) and a reviewer has approved the PR. PRs into the "development" branch get "squashed and merged" to keep the commit history small and clear. It's easier to see then when "JIRA-1" was added when you squash all those commits into one instead of keeping the single commit in the "development" branch. When merging the "development" into the "main" branch we do not squash, instead we choose the "rebase and merge" option on the PR. This allows use to keep the "development" and "main" branch in sync and keeping a linear git history.
Whether you or your team members use the git CLI or a UI client is up to you. I personally prefer GitHub desktop, while most of my colleagues are happy with the git integration in VS Code and IntelliJ.
Thank you for this! As a fairly newbie programmer I've only worked on projects with friends and stuff and it's always a small project so it's just basic commits to main, or small branches here and there. This one shows proper development methods and I would love to try to implement these even in casual projects!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Working with a team, maybe even inside an organization there's a good chance that there are template projects for different type of projects. If so, I would start with those and create a new projects from the template. If there are no templates, I still prefer to setup the project on GitHub, give it a name, short description - helps to nail the focus of the project - generate with README, gitignore and possibly license.
Once the project exists on GitHub, the rest of the steup depends on how your team agreed to collaborate and work with Git repositories. We have the "main" branch, and create a "development" branch. Then we setup the "development" branch to be the default branch. This avoids accidentially committing to the "main" branch. To prevent committing to "main" directly, we configure it as a protected branch disabling direct commits and force commits, and enabling that PRs may only be merged if certain checks pass.
If you have a CI/CD pipeline, i.e. TravisCI, CircleCI ... there's a good chance that your organization is set up in a way that new repositories are automatically part of the pipeline. For TravisCI the only thing required here is a
.travis.ymlfile at the root of the repository and then builds are automatically triggered when you push to any branch. Our build pipeline is configured to automatically deploy changed on the "development" branch to our staging environment. Changes on the "main" branch will be automatically deployed to production and a release gets created on GitHub using release-it.But so far, we only created and configured the repository on GitHub. Now it's time to check it out and clone it to our developer machine. I've used Jira with all the teams I've worked with so far. There has always been constent to name the git branch we work on with the Jira ID, i.e. "JIRA-1". After creating the branch, I directly publish it on GitHub. This will trigger the CI/CD pipeline and run build and test scripts on the project, making sure I start with a copy of the repository with successful builds.
We try to commit (not push) often! Anytime a small functionality improves, bug fixed or even just the color of a button was changed we commit. The commit message should describe what was changed/added/removed in a few words. To spice up the messages a bit we use emojis as defined at gitmoji for our commit messages a commit could be
:sparkles: edit user profile, or:memo: document data model.We push at least once a day and don't leave any work dangling between work days. You never know if your development machine breaks over night, gets stolen, or you have an accident on the way home or to work and while you are unharmed your PC/Mac is broken. Another reason for it is, that you may become sick and stay at home the next day(s). If you didn't push your code changes a member of your team cannot take over where you left of the day before.
Once, the (Jira) tasks is complete (code+tests+documentation written/updated!!!) we create a PR on GitHub from the task's branch to the "development" branch. What you write in the PR title, description etc. is up to you and there are articles solely about this topic. In short the title contains the Jira task ID for us, and the title of the Jira task. The body contains a link to the Jira task. If UI changes were involved, we add a before and after screenshot. Not too much description because the way we see it anything you describe in the PR body may belong into proper documentation anyways. If you write to much in the description then check if those parts are missing from the documentation.
Another team member, possibly one you did pair programming with to complete the task, reviews the PR ... Again, details on this part could fill its own blog post. We like the feature in GitHub to comment code lines directly and suggest/ask for changes directly on specific lines of code. In addition, we use DangerCI to automatically comment on PRs. It reminds us to keep the changelog up to date, to increase the version number, to update package-lock.json/yarn.lock and to compliment if the PR is small (not many lines of code changed). Why a small PR? We believe the reviews are faster, more reliable, more enjoyable and contribute to a more stable product if we have more and smallar PRs, rather than few really big ones. Usually the PR reviewer will leave a few comments, asking if the code could be optimized this way or if the other person thought about covering use case XY with a test. While the reviewer leaves comments on the PR, we have to keep in mind that we are still working in one team and not an open source project. Therefore, besides leaving comments we get on a video call together to discuss those topics right away. In our eyes a PR should not be open for longer than one or two days. In the end, the reviewer approves the PR, the author (not the reviewer) merges the PR. Same goes for PRs from the "development" to the "main" branch. PRs can only be merged if the build on the CI/CD pipeline succeeds (tests run, no linter errors) and a reviewer has approved the PR. PRs into the "development" branch get "squashed and merged" to keep the commit history small and clear. It's easier to see then when "JIRA-1" was added when you squash all those commits into one instead of keeping the single commit in the "development" branch. When merging the "development" into the "main" branch we do not squash, instead we choose the "rebase and merge" option on the PR. This allows use to keep the "development" and "main" branch in sync and keeping a linear git history.
Whether you or your team members use the git CLI or a UI client is up to you. I personally prefer GitHub desktop, while most of my colleagues are happy with the git integration in VS Code and IntelliJ.
Thank you for this! As a fairly newbie programmer I've only worked on projects with friends and stuff and it's always a small project so it's just basic commits to main, or small branches here and there. This one shows proper development methods and I would love to try to implement these even in casual projects!