https://community.element14.com/technologies/open-source-hardware/What is the connection between Open Source Hardware and traditional engineering companies. How can professionals & hobbyists learn from each other. What can hardware developers learn from Open Source Software.en-USTelligent Community 12https://community.element14.com/technologies/open-source-hardware/b/blog/posts/github-for-professional-beginners-from-first-repository-to-first-releaseSat, 06 Jun 2026 00:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:4f93f685-a031-4a13-8f6b-e11ac68cc430shabazTable of Contents Introduction What are Code Branches and Code Commits? Some Terminology, and the Branch Strategy! Main Branch Development Branch Release Branch Feature Branch Local and Remote Push versus Pull versus Pull Request! At-a-Glance Overview of the Strategy Is It Safe? Tutorial Step Zero: Create a GitHub Repository 1. Create an Integration (Development) Branch 2. Create a local Feature Branch# 3. Code the Feature 4. Publish the Feature Branch 5. Merge Request (aka Pull Request) to Development Branch 6. Update your local Development Branch 7. Destroy the local and remote Feature Branch 8. Create a Release Branch 9. Make Minor Fixes in the Release Branch 10. Merge Request (aka Pull Request) Release Branch to both Main and Development Branches 11. Tag the Release 12. Destroy the Local and Remote Release Branch Summary Further Reading Introduction A while back, Jan Cumps and I worked together on a series of GitHub-related blog posts, developing a workflow that proved suitable for commercial software projects. Fast-forward several years, and I recently came across an excellent article in Code Magazine by Sahil Malik titled Git Branching Strategies . I was pleased to find that its recommendations closely aligned with the approach Jan and I had adopted. That inspired me to revisit the topic and document the workflow again with a fresh re-write and new example screenshots that hopefully augment all of the earlier content we created (I reused many of the same branch names I used in an earlier blog post which happened to use a graphical user interface; this blog post uses the command line). Firstly, the phrase Professional Beginner might seem like an oxymoron, but it accurately describes the intended audience for this article. It is aimed at professional engineers who are new to Git and GitHub and would like to become productive quickly. It is equally relevant to students and hobbyists, who will inevitably encounter GitHub when sharing and maintaining their own projects, or when contributing fixes and enhancements to other people's applications and libraries. An aim of this article is to walk through a complete, practical workflow, from creating a repository, through feature development and code review, to producing and tagging a release, using the same processes that are suitable for real-world commercial software projects. It’s followed by a 12-step example (actually a baker’s dozen) that is easy to try out yourself, and hopefully have good success with it. What are Code Branches and Code Commits? When you first write a ‘hello world’ program, all you have access to is the code as you’ve written it; at best you can hit the undo button if you need to go back a little bit. With more complex software, you’ll soon want to be able to have the ability to add features incrementally, but also be able to go back and see what code was modified to create each feature. Plus, you may want to delegate coding of some features to others. Code commits are ways to ‘checkpoint’ what you’ve done at suitable points during each feature development; they can be labelled with a description to help mentally recall your purpose for each commit. Code branches are used to work on different streams of code; for instance, you may need to make tiny fixes to released code, while others are working on adding more features that are currently untested, in a different branch. Some Terminology, and the Branch Strategy! GitHub is an online platform that hosts software repositories, allowing individuals and teams to collaborate on software projects. Repositories can be public or private. The system used to manage the contents of a repository is called Git . Git can be used from a PC's command line after installing git . Using Git together with the GitHub website , you can create repositories, create branches , commit changes, review code, and merge content from one branch into another. These capabilities become especially important when multiple developers are working on different features at the same time and their work eventually needs to be combined into a single code base. Without some discipline, it is easy for a project to become difficult to manage. That is where a branching strategy comes in. The strategy described in this article uses several different branch types. Two branches are long-lived, while the others are temporary and exist only for specific tasks. Main Branch When a repository is created, a branch called main usually exists by default. This branch should contain stable, releasable code that can be built and used with confidence. Developers do not normally make feature changes directly on the main branch. Instead, tested and approved changes are merged into it from other branches. Development Branch The workflow described in this article uses a second long-lived branch called the development branch (often named develop or similar). This branch acts as the integration point for completed features. As developers finish their work, their changes are merged into the development branch. Once enough new functionality has accumulated, integration testing can be performed to verify that the various features work correctly together and have not introduced bugs. Release Branch When the project is ready for release, a release branch is created from the development branch. This branch contains all of the functionality intended for the upcoming release and provides an opportunity for final testing and minor fixes. Once the code is considered ready, the release can be tagged (for example, v1.1) and merged into both the main branch and the development branch. The release branch can then be deleted because the tag preserves a permanent reference to the released code. Feature Branch A feature branch is temporarily created by a developer for specific pieces of work; each feature is developed and tested independently on its own branch. Once the feature is complete, it is merged into the development branch and the feature branch is no longer needed. Temporary feature branches help isolate changes and reduce the risk of developers interfering with each other's work. Local and Remote The code is stored in a remote repository, and Git typically refers to that remote repository as the origin . A software developer will make a copy of the entire repository on their PC, and then locally switch to the branch they wish to work on, independently of any changes that might take place in the origin. In other words, their local copy is just a large dump of the entire repository and its history; there’s no automatic sync if other developers happen to modify code in the origin. Actual code changes are usually made by developers on their local PC, as mentioned by switching (called a checkout in Git terminology) to the local copy of the desired branch. In the steps further below, you’ll frequently see git checkout commands followed by git pull commands. Together, those two commands will locally switch to a specified branch, and then immediately update or pull the latest content from the corresponding branch at the origin. That way, you’ll effectively have created the most recent local snapshot of that branch. Push versus Pull versus Pull Request! These terms are notoriously confusing. Usually, a git pull means retrieving content from the origin, to update your local copy. A good example of that is mentioned above, after a git checkout. A git push means placing content (specifically, code you’ve committed, i.e. checkpointed in your local copy), to the branch at the origin. If the branch didn’t exist yet at the origin, then it also gets created with the git push command. Key tip: A Pull Request is best mentally understood as “Merge Request”. It is used in the opposite direction to the “pull” direction mentioned above, hence it’s best to pretend you’re reading “merge request” whenever you see the words “pull request”. Once you have pushed content to the origin, you can submit a merge request so that other developers or the project maintainer can view your request (and usually review it), and then one of them will merge in your code, to, say, the development branch or whichever branch was requested. At-a-Glance Overview of the Strategy The diagram below can be used to partially explain how the branches are used, and doesn’t indicate when branches are created or destroyed. There’s no timeline on this diagram; it is not followed from left-to-right either. Assume that the main branch, and the development branch ( dev-branch-1 ) are already created beforehand when viewing this diagram. By examining the diagram on the left side, you can see that it’s possible for a developer to use a git push command to place their changes from their local feature branch into the respective feature branch at the origin GitHub Repository; the push command would also create that feature branch at the origin, if that remote branch didn’t exist. For the merge operation to occur from the feature branch to the development branch, a Pull Request (i.e. a Merge Request) is submitted as discussed earlier. Later, the feature branch is destroyed since all content from there is inside the development branch (the destruction is not shown in the diagram) and then a release branch is formed based on the development branch. Any small final tweaks to the code are made in that release branch, and then it is merged (technically another Pull Request) into both the development branch to its left side in the diagram, and to the main branch to its right side in the diagram. Finally, a release tag is applied at that point on the origin main so that it is always possible to determine at what commit to main the release was created, and then the release branch can be destroyed, leaving nothing behind except the main and development branches. Is It Safe? Generally, yes! The workflow is designed to avoid using the main branch for direct feature development. One could still mistype Git commands, but most things are generally reversible. Perhaps one may accidentally erase code they had not committed, but that could occur even if one was not using Git. Furthermore, you can try to prevent people from deliberately (or accidentally) working around certain parts of the workflow, by creating branch rulesets (not detailed here, but you can explore that from the GitHub site; see the screenshot below to find where to navigate to. This blog post uses a real-world repository containing a simple project called project1, and you're welcome to try things out using that repository, or create your own. To keep it realistic, I'll happily accept any pull requests that either improve the project, even in minute ways, or result in minor tweaks to README files (I'm OK even with "this is a test" sentences added to the project1 README ). OK; it’s time for the step-by-step tutorial. You could try this yourself by creating a GitHub account , and then following from step zero! Tutorial Step Zero: Create a GitHub Repository Use the GitHub site to create a repository if you don't already have one to use. It’s worth getting the site to automatically add a README file at this stage. Next, on your PC: git clone https://github.com/ /project1.git # Creates a local copy of the repository onto your PC git remote -v # Displays the remote repository URL, in case you later forget! It may display multiple URLs for clarity about which URL later operations like git pull and git push will use 1. Create an Integration (Development) Branch The plan is to create a branch which will be used as a long-lived development branch. It will be reused for each sprint. git checkout main # View your local copy of the main branch. Since this is local to you, this may eventually be old compared to the origin (remote repository) if someone else makes changes to that meanwhile git pull --ff-only origin main # update your view with the latest from the origin (the --ff-only means abort if you have local commits that have not been pushed and origin has also moved forward meanwhile). git checkout -b dev-branch-1 # Create the branch on your local PC git push -u origin dev-branch-1 # Publish the branch on the remote (i.e. origin) 2. Create a local Feature Branch# git checkout dev-branch-1 # View the project on your local copy of the development branch git pull --ff-only origin dev-branch-1 # update your view with the latest from the origin git checkout -b feature1-branch # Create the feature branch locally on your PC 3. Code the Feature git add . # Prepares (stages) any new/modified/deleted files in your local view git commit -m "Implement feature 1" # Checkpoints your changes and new files in your local view 4. Publish the Feature Branch git push -u origin feature1-branch # Creates or updates the feature branch at the origin 5. Merge Request (aka Pull Request) to Development Branch In GitHub, click to create a Pull Request , with the feature branch being the source, and the development branch being the destination. Wait for the request and your code to be reviewed and merged! This screenshot shows where to go to create the pull request: In the drop-down boxes, select such that the feature branch is the source (notice the arrow direction in the screenshot) and that the development branch is the destination . Next, the user will be prompted to click a button that will perform the merge. Now the feature code is in the development branch in the repository. 6. Update your local Development Branch git checkout dev-branch-1 # View the project on your local copy of the development branch git pull --ff-only origin dev-branch-1 # update your view with the latest from the origin 7. Destroy the local and remote Feature Branch git branch -d feature1-branch # delete the local PC feature branch git push origin --delete feature1-branch # delete the feature branch at the origin 8. Create a Release Branch git checkout dev-branch-1 # View the project on your local copy of the development branch git pull --ff-only origin dev-branch-1 # update your view with the latest from the origin git checkout -b release-1.1 # Create the release branch on your local PC git push -u origin release-1.1 # Creates or updates the release branch at the origin 9. Make Minor Fixes in the Release Branch git checkout release-1.1 # View the project on your local copy of the release branch git pull --ff-only origin release-1.1 # update your view with the latest from the origin git add . # Prepares (stages) any new/modified/deleted files in your local view git commit -m "Prepare release 1.1" # Checkpoints your changes and any new files in your local view git push origin release-1.1 # Updates the release branch at the origin 10. Merge Request (aka Pull Request) Release Branch to both Main and Development Branches You want the release branch content to be within both the main and the development branches. In GitHub, click to create a Pull Request , with the release branch being the source , and the main branch being the destination . Wait for the request and your code to be reviewed and merged! Repeat, this time with the development branch being the destination. Here is a screenshot of the merge to the main branch about to be performed. The merge to the development branch is performed in a similar way. 11. Tag the Release git checkout main # View the project on your local copy of the main branch git pull --ff-only origin main # update your view with the latest from the origin (the --ff-only means abort if you have local commits that have not been pushed and origin has also moved forward meanwhile). git tag -a v1.1 -m "Release version 1.1" # create a tag in your local view at the current commit you’re at git push origin main --tags # Updates, including tags, the main branch at the origin 12. Destroy the Local and Remote Release Branch git checkout dev-branch-1 # Switch away from release-1.1 first git pull --ff-only origin dev-branch-1 # update your view with the latest from the origin git branch -d release-1.1 # Delete the release branch on your local PC git push origin --delete release-1.1 # Delete the release branch at the origin Summary The basic concept when using GitHub and Git is that developers work on their own local copies of a project, periodically exchange changes with a shared repository, and use a simple review process before combining (merging) their work with that of other team members. This article introduced a practical workflow or strategy suitable for both individual developers and teams. The particular workflow uses a small number of branches with clear responsibilities: one main branch for stable released code, one for ongoing development, temporary branches for new features, and temporary release branches for preparing a software release. It was explored how to create a repository, create and switch between branches, save work locally, publish changes to GitHub, submit Merge Requests, create releases, and apply version tags. The terminology can sometimes be confusing, it pays to closely focus on the meanings of Pull, Push, and Pull Request. The overall process helps developers work independently while still allowing their changes to be combined in a controlled and predictable manner. Once you have worked through the steps for a few small projects, hopefully things will be easier to follow. No major damage is likely to happen if you create a test repository on GitHub to just experiment. Plus, it’s free. Understanding the workflow will make one more confident in participating in professional software projects and for contributing to open-source software hosted on GitHub. If you have suggestions, for instance particular command line parameters and switches you like to use at various stages, or any other comments or criticisms, tips/tricks and so on, it would be great to hear about them. Thanks for reading! Further Reading (+) Firmware Version Control with GitHub part 1: Branch Strategy for New Features - element14 Community (+) Break-Fix with GitHub: part two: push bug fixes to the development team - element14 Community (+) GitHub: automate project documentation with DoxyGen, and publish online after pushing commits - element14 Community (+) GitHub for Beginners: Incrementally Adding Features to your Code - element14 Community (+) GitHub for Beginners: Working with PyCharm and other JetBrains IDEs - element14 Community (+) GitHub for Beginners: Feature Development for Projects - element14 Communitygithubgithttps://community.element14.com/technologies/open-source-hardware/m/managed-videos/151372Mon, 25 May 2026 22:18:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:9fed2818-2126-438a-8075-d9a834ac7d40shabaz1-minute video explanation and demo. It's a 45 dB gain audio preamplifier designed for speech applications (radio receivers and intercoms) but with high quality - and deliberately all through-hole easy-to-obtain parts, so that anyone can construct...https://community.element14.com/technologies/open-source-hardware/b/blog/posts/building-a-transistor-audio-preamplifierMon, 25 May 2026 22:17:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d20f2e52-15ce-4b77-a9e1-95e3fb434df5shabazIntroduction This blog post discusses a high quality three-transistor audio preamp, intended for speech applications such as radio or intercoms. The circuit was designed by michaelkellett and there is more detail at the blog page Two pre-amplifiers and a power amplifier. The K2 Preamplifier PCB layout that was used is on GitHub ; the project is deliberately through-hole, uses easy-to-find parts, and can be assembled within half an hour. What Does it Do? The amplifier basic specifications are below. It can be used as an audio amplification stage for amateur radio receivers, or it could be used as an electret microphone element amplifier, say for transmitters. With the component values as shown in the circuit, the specifications are as follows: Power Supply : 9V (e.g. PP3 battery) Gain : 45 dB (170 times amplification) Frequency Response : 100 Hz to 3.5 kHz (speech bandwidth) For more detailed, additional specifications and measurements, please refer to the blog link in the introduction. How Does it Work? I’m no audio expert! See the circuit diagram below. Here’s my layman’s interpretation, which could be very wrong in places: R13, C6 : Provides a filtered voltage supply, needed for rejecting power supply noise R8, R9, R10, C3 : Stable biasing for Q1 R1, Q1, R3, C1, R2 : Common Emitter amplifier, providing the bulk of the voltage gain, with inverted output at the Q1 collector Q2, Q3, R11 : This is a DC coupled pair, which I believe may sometimes be called a Sziklai (Complementary Darlington) pair, providing the bulk of the current gain and another inversion. R11 results in negative feedback for these two transistors, and a more linear output, important for reducing distortion. Please refer to Michael’s blog post for more detail and the history regarding this type of design. R5, C4 : Provides negative feedback from the output to the first stage; the gain and bandwidth can be adjusted by tweaking these components. Circuit Diagram Simulating It The KiCad files for the amplifier contain a SPICE simulation. Simply open up the circuit within KiCad 10, then click on Inspect->Simulator, and you’ll see simulation tabs. Click on any of them and then click on the triangular run icon. The results will appear either in charts, or directly overlaid on the circuit, as appropriate. If you make any changes to the circuit, click on the run icon again to see the result. The following simulation tabs are available: DC voltages and currents : Select the tab labelled OP (Operating Point), and when run, all the voltages and currents (that may also be observed in real life with a multimeter) will be displayed overlaid on the original schematic. Time-domain signals : Select the TRAN (Transient) tab, and when you click run, you’ll see signals as if an oscilloscope was connected to various nodes such as the input and output. You can choose the nodes from a list that will be displayed. Frequency response : Select the AC tab. Click run and you’ll see a chart appear with the results. Building It The circuit was easy to solder up in half an hour. There is space on the board for soldering 3.5 mm audio sockets, or plain 2.54 mm pin headers. Although overkill, I soldered on cheap SMA connectors, just to make it a little easier to attach the circuit to a signal generator/oscilloscope. I used surface-mount BC849 transistors (they fitted nicely on the underside) since I didn’t have any through-hole ones (BC549). BC547 could be used too. Results Output Quality One worthwhile measurement is to apply a known signal (in my case, a 1 kHz sine wave, at 10 mV p-p amplitude), and then connect an oscilloscope to the output, and switch on the FFT or spectrum view. In the screenshot below, the yellow trace is the input signal, and the green one is the output. The spectrums for each are shown over the range 10 Hz to 100 kHz (on a log scale) and I set the ‘resolution bandwidth’ to 10 Hz. Here I was keen on visually observing harmonics, because they indicate distortion. It’s possible to calculate a total harmonic distortion (THD) figure from this, but in reality it’s already very clear from visual observation, that the distortion is extremely low and negligible (the vertical axis is logarithmic). As can be seen, there is about 65 dB of difference between the 1 kHz tone output, and the second harmonic (the scale is 10 dB per tick on the vertical axis). Frequency Response It’s possible to obtain the frequency response of the amplifier by attaching a signal generator to the input, and measuring the output amplitude say with an oscilloscope, and plotting measurements as the signal generator frequency is adjusted. The result is shown below, on a log frequency scale. For this test, I used a 10 mV peak-to-peak sine wave input signal, varied in frequency over the range of 10 Hz to 100 kHz. It was seen that the amplifier frequency response very closely matches the simulation. The results show the amplifier gain over the speech bandwidth is approximately 45 dB. The vertical scale is 3 dB per axis tick. Practical Use: Microphone Amplifier I made an identical copy of the circuit on a PCB called "Mic Board" , and added very little; a few resistors and a capacitor and an electret microphone element. This board also has a barrel DC power input connector, and on/off rotary switch. I’m going to use it to make an intercom, hence the curved edge (a speaker needs to fit there). I tried two mic elements. One (slightly lower-cost) had a sensitivity figure of -64 dB according to the datasheet. The other one was far more sensitive at -32 dB. You’d probably need to reduce the amplifier gain for many practical uses with the -32 dB mic element. Here’s a short video demonstration with the -64 dB sensitivity mic element: https://youtu.be/6m04J7hLxmY Summary The “K2 Preamplifier” is a three-transistor audio amplifier with extremely low distortion, very good output current capability, and decent bandwidth all ready for speech applications such as radio communications and intercoms (overkill for that!). The measured performance is very good; with a sine wave input, the harmonics were observed with an oscilloscope, and were seen to be extremely low. The design was rebuilt identically, but with power switch and a handset connector, so that it can be used for an intercom (which is a work-in-progress). Thanks for reading!audioanalog_electronicssimple_dcrintercomhfpreamplifierradiohifiamateur radiohttps://community.element14.com/technologies/open-source-hardware/f/forum/56877/the-pam8403-amplifier-is-very-noisy/235358Tue, 05 May 2026 15:01:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:bb70ce50-e172-468c-9249-347553ee2c79me_CrisOf course, you can see in the post.https://community.element14.com/technologies/open-source-hardware/f/forum/56877/the-pam8403-amplifier-is-very-noisy/235320Mon, 04 May 2026 16:31:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:70367b99-d0ed-4de3-9ef4-b493a39dce12geraldsCan you make photos of your assembled amp., that show us details about your built?https://community.element14.com/technologies/open-source-hardware/f/forum/56877/the-pam8403-amplifier-is-very-noisy/235319Mon, 04 May 2026 14:35:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:446a7cc5-80ca-486c-924e-fd099621f452me_CrisI did a test, I used the 5V power supply from the board to power another circuit also with addressable LEDs, and the noise is reduced (not by much) than when using LEDs that are already on the speaker. The noise source (addressable LEDs) being further away has some positive effect.https://community.element14.com/technologies/open-source-hardware/f/forum/56877/the-pam8403-amplifier-is-very-noisy/235318Mon, 04 May 2026 14:29:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:5baad642-d413-492e-a077-ddb1d4d5e2b2me_CrisI'm waiting for the PAM8406 version which should not be so noisy. I didn't achieve much using the ferrite bead + capacitors filter.https://community.element14.com/technologies/open-source-hardware/f/forum/56877/the-pam8403-amplifier-is-very-noisy/235317Mon, 04 May 2026 14:27:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:8aa13adc-450b-4225-885a-4493b3fc026bme_CrisI experimented a little by inserting a filter, I didn't use the same speakers (it's more difficult than it seems) but I noticed some reduction in "noise". Waiting for my PAM8406 version to arrive which should be improved on this side.https://community.element14.com/technologies/open-source-hardware/f/forum/56877/the-pam8403-amplifier-is-very-noisy/235204Tue, 28 Apr 2026 15:29:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:c8050f99-12bb-4550-af9b-c1dc3d23127ame_CrisNot really, but maybe I don't need to go that far. I can also try other 5V powered circuits.